search

trilliumeng / orion-sdk

Public SDK and ICD for Trillium Engineering's Orion Gimbals.
http://www.trilliumeng.com
MIT License
15 stars 15 forks source link

serialized length of `ORION_PKT_GEOLOCATE_TELEMETRY` #10

Closed arikrupnik closed 4 years ago

arikrupnik commented 4 years ago

Hi, I'm trying to parse ORION_PKT_GEOLOCATE_TELEMETRY packets coming from the payload, and I'm running into an apparent discrepancy between the current XML spec and the data.

My software is in Python. I cannot take advantage of Protogen and must roll the parser/generator by hand. The most likely source of my difficulty is an error in transcribing the XML into Python. I have done this for about a dozen Orion packets now, and they work fine, but ORION_PKT_GEOLOCATE_TELEMETRY's complexity makes errors more likely on my end.

Here's an example of a packet I receive: d00dd451000554d80005534806841222ffffd59d00006201003c9deafdb0011b000058da0058fcb65c13ecb0ffb70c5106f7000000000000050002d03000000000ffffffaeffffffe2008fffffff00000010fef600189e It has the right header, the length field matches actual length, and the checksum passes. Data length is 81 bytes.

When I add up all the fields in the XML, I end up with 89 bytes. The problem must be somewhere at the start of the packet. The first three fields in the XML are

    <Data name="systemTime"      inMemoryType="unsigned32" comment="Milliseconds since system bootup"/>
    <Data name="gpsITOW"         inMemoryType="unsigned32" comment="GPS time of week in milliseconds"/>
    <Data name="gpsWeek"         inMemoryType="unsigned16" comment="GPS week number since Jan 6 1980"/>

If I count 64 bits into the data and take the next 16 (0x0684) I get gpsWeek==1668, which is long time in the past.

For reference, the PAYLOAD_VERSION indicates version==1.5.8279 (e564f6d) and P/N=78-0932

jefffisher commented 4 years ago

Hi @arikrupnik – that's not necessarily an unexpected gpsWeek value if you don't have GPS. Regarding the length, I would check whether insRotationOptions is reporting a value of 0. In that case, the insQuat field will not be encoded into the serialized data.

arikrupnik commented 4 years ago

Thank you for your note, @jefffisher. insRotationOptions is indeed 0x00. My assumption had been that packets have fixed length. Is the assumption that any packet may be missing any number of fields off the end, or are there special-case, variable-length packets and ORION_PKT_GEOLOCATE_TELEMETRY is one of them?

jefffisher commented 4 years ago

Most are not variable length, but there are several that do vary. I'd maybe start, if you haven't already, by having a look at the readme for ProtoGen: https://github.com/billvaglienti/ProtoGen.

The main ones to look out for in our SDK are fields that use the dependsOn, variableArray, or (especially) default attributes.

arikrupnik commented 4 years ago

Thank you, @jefffisher . I thought I had read enough of the Protogen documentation to parse Orion packets, but clearly there's much more to it than I'd seen. Thank you for the heads-up. The packets are parsing now.