The form of the PX4 GUID is as follows:
offset:0 1 2 - 17
<ARCH MSD><ARCH LSD><MSD CPU UUID>...<LSD CPU UUID>
Where <ARCH MSD><ARCH LSD> are a monotonic ordinal number assigned by
PX4 to a chip architecture (PX4_SOC_ARCH_ID). The 2 bytes are used to
create a globally unique ID when prepended to a padded CPU ID.
In the case where the CPU's UUID is shorter than 16 bytes it will be
padded with 0's starting at offset [2] until
PX4_CPU_MFGUID_BYTE_LENGTH-PX4_CPU_UUID_BYTE_LENGTH -1
I.E. For the STM32
offset:0 1 2 3 4 5 6 - 17
<ARCH MSD><ARCH LSD>[0][0][0][0]<MSD CPU UUID>...<LSD CPU UUID>
I.E. For as CPU with a 16 byte UUID
offset:0 1 2 - 17
<ARCH MSD><ARCH LSD><MSD CPU UUID>...<LSD CPU UUID>
This uses now the same sleep time logic as mavlink, depending on the
baudrate.
CPU usage on a Pixracer for different sleep times:
#num reads/sec sleep time CPU usage
17-18 2.8ms 0.233-0.31% (this PR)
12 5ms 0.155-0.3%
9-10 10ms 0.155-0.233%
6 20ms 0.155-0.233% (previous)
to fix Cygwin upload. It failed silently but when catching it prints
"non-standard baudrates are not supported on this platform".
Discussion about platform independet FTDI detection is in issue #10429.
A filtered update update interval is calculated for each receiver.
If dissimilar interval data is detected, blending occurs when data is received from the slower of the receivers.
If similar interval data is detected, blending occurs when receiver data with similar time stamps is available.
If no data is received from either receiver for longer than 300msec, then no blending will be performed and the most recent data will be used instead.
David Sidrane
Martina
Beat Küng
Matthias Grob
Daniel Agar
Lukas Woodtli
Bart Slinger
Paul Riseborough