LP-547 Increases the telemetry buffer lengths (both UART and radio) to fix saving large UAVObjects over OPLink.
Approved-by: Lalanne Laurent <f5soh@free.fr>
Approved-by: Philippe Renon <philippe_renon@yahoo.fr>
Approved-by: Vladimir Zidar <mr_w@mindnever.org>
Approved-by: Brian Webb <webbbn@gmail.com>
LP-537 update f0 gps to be more similar
Approved-by: Philippe Renon <philippe_renon@yahoo.fr>
Approved-by: Alessio Morale <alessiomorale@gmail.com>
Approved-by: Lalanne Laurent <f5soh@free.fr>
Approved-by: Brian Webb <webbbn@gmail.com>
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.
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>
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.
LP-526 Adds support for the MSP_SERVO command to the MSP module.
Approved-by: Vladimir Zidar <mr_w@mindnever.org>
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>
