There is no need to transmit one telemetry update per second for this uavo on controllers where no OP-GPS is present.
For the controllers where an OP-GPS is present, the FlightTime field updates will trigger a telemetry update.
UBX-NAV-SVINFO (id 30) and UBX-NAV-SAT (id 35) packets are NOT critical to the navigation.
Their only use is to update the nice GPS constellation widget in the GCS.
These packets become very large when a lot of SV (Space Vehicles) are tracked. (8 + 12 * <number of SV>) bytes
In the case of 3 simultaneously enabled GNSS, it is easy to reach the currently defined tracking limit of 32 SV.
The memory taken up by this is 8 + 12 * 32 = 392 bytes
The NEO-M8N has been seen to send out information for more than 32 SV. This causes overflow errors.
We will ignore these informational packets if they become too large.
The downside of this is no more constellation updates in the GCS when we reach the limit.
An alternative fix could be to increment the maximum number of satellites: MAX_SVS and UBX_CFG_GNSS_NUMCH_VER8 in UBX.h
This would use extra memory for little gain. Both fixes can be combined.
Tests indicate that, once we reach this amount of tracked SV, the NEO-M8N module positioning output
becomes jittery (in time) and therefore less accurate.
The recommendation is to limit the maximum number of simultaneously used GNSS to a value of 2.
This will help keep the number of tracked satellites in line.
- Improve Alt label in the GPS display widget. The displayed altitude is Above Mean Sea Level (AMSL).
AMSL label has been added to clarify the reference from which this altitude is measured.
- Make values bold to draw more attention to them. The labels are less important.
- Replaced an empty horizontal layout by a vertical spacer
Changed the int xDelay to a define and put the define next to the other major delay in the GPS task.
Increased the time we wait for PIOS_COM_ReceiveBuffer from 5 to 20 ms.
LP-538 Set correct reg.72 value for 256kbps and 150Khz Tx deviation - Cleanup
Approved-by: Lalanne Laurent <f5soh@free.fr>
Approved-by: Brian Webb <webbbn@gmail.com>
Approved-by: Philippe Renon <philippe_renon@yahoo.fr>
Approved-by: Alessio Morale <alessiomorale@gmail.com>
LP-533 incorrect MCU pin used to toggle inverter for rcvr port on Sparky2
Approved-by: Vladimir Zidar <mr_w@mindnever.org>
Approved-by: Jan NIJS <dr.oblivium@gmail.com>
Approved-by: Philippe Renon <philippe_renon@yahoo.fr>
Approved-by: Lalanne Laurent <f5soh@free.fr>
Approved-by: Brian Webb <webbbn@gmail.com>
Approved-by: Alessio Morale <alessiomorale@gmail.com>
LP-531 Adds support for Qt 5.9.0
Approved-by: Philippe Renon <philippe_renon@yahoo.fr>
Approved-by: Lalanne Laurent <f5soh@free.fr>
Approved-by: Brian Webb <webbbn@gmail.com>
Approved-by: Jan NIJS <dr.oblivium@gmail.com>
Approved-by: Paul Jewell <teulupaul@gmail.com>
Approved-by: Alessio Morale <alessiomorale@gmail.com>
Bug introduced by LP-480. The wrong MCU pin is used for toggling the input inversion. This inverted the serial signal when it should not be inverted.
ibus reception and possibly other serial receiver protocols where not working.
PC4 was controlled, but according to the schematic, PC6 is connected to the xor port.
PC4 is actually connected to the gyro interrupt.
This bug explains another issue I saw from time to time. After a restart of the Sparky2 board, gyro and accelerometer graphs remained locked at 0. Making the board unusable for flight.
