Closed kc2rxo closed 1 year ago
You are correct. Both for encode and decode.
Apparently this was already fixed a while ago in the Android receiver application but no-one thought of fixing this in the core-c library.
Pull Requests are very welcome. Otherwise, let's see when I have a moment to look at this.
Per F3411-22a the encoding and format of the UAS ID's are as follows:
<ICAO Nationality MarkA >.<CAA Assigned ID>
Due to the behavior of
strncpy
[1] as currently written any Type 3 and Type 4 UAS IDs with a byte of value0x00
will be truncated at that byte. For example a Type 4 of the value0x0120010030112233058899AABBCCDDEEFF000000
will be encoded and displayed over air as0x0120010000000000000000000000000000000000
as the0x00
in byte position 4 will be treated as a null terminator bystrncpy
.Either the
strncpy
should be swapped formemcpy
to be agnostic to the null terminator (0x00
) or have a clause based on the ID Type and usestrncpy
for Type 1 and Type 2, andmemcpy
for Type 3, Type 4 or other currently undefined ID Types.I suspect that the decode side also treats the UAS ID as ASCII at all times but have yet to check and confirm this. I suspect a simple
memcpy
replacement there as well would suffice but have not analyzed any side-effects of such a change.[1] https://en.cppreference.com/w/cpp/string/byte/strncpy