BINEX

[gwbres]

* introducing BINEX parser

[gwbres]

The only BINEX specs I know https://www.unavco.org/data/gps-gnss/data-formats/binex/binex.html

The first objective is to achieve one first test method that decodes one message correctly.

The ultimate objective is to be able to provide seamless interface between RINEX and BINEX (ideally both ways)

[gwbres]

@lnicola,

I would like to make this no-std compatible, maybe not right now, but in the long term I think it definitely should:

• this is just a simple parser and forger
• forging is data production oriented and you want to use this nearby the gnss firmware or on the same plateform

do you have recommendations on how to replace Vec in this scenario ? maybe a small external library so we don't have too much code to write. It is most convenient to use Vec in the decoder Buffer currently, but it will then have to change

[lnicola]

Sorry, I saw the notification after you merged the PR, then I forgot to answer. If the format has some built-in limits (say, for the number of frames in a record, the maximum size of a record etc.) then something like arrayvec should work work. If the records can be arbitrarily large, then I don't think that's going to be compatible with #[no_std] without using the alloc crate.

[gwbres]

Sorry, I saw the notification after you merged the PR, then I forgot to answer

No worries, your input is always much appreciated. The no-std support can be a long term thing, it does not have to be accomplished right away, I personnaly have very limited experience with that. I think it's an important topic, because open-source GNSS firmware (embedded) could then easily use the BINEX encoder/decoder

If the format has some built-in limits (say, for the number of frames in a record, the maximum size of a record etc.) then something like arrayvec should work

unfortunately not, you cannot say at the beginning of the parsing process, how many bytes you will encounter for the Geodetic and Signal frames. For the first one (comment/description) you can have as many comments as needed: I currently use a Vec<> (convenient but then incompatible). For the latter, it depends on the GNSS receiver capabilities, and it may be able to sample many carriers so you then have to describe all your observations (not supported yet).

If the records can be arbitrarily large, then I don't think that's going to be compatible with #[no_std] without using the alloc crate

Yep I saw a couple of times the possibility to implement no-std with an allocator, but I need to study how that works

[lnicola]

unfortunately not, you cannot say at the beginning of the parsing process, how many bytes you will encounter for the Geodetic and Signal frames

No 64 KB record limit? No 16-bit length field? :-)

Yep I saw a couple of times the possibility to implement no-std with an allocator, but I need to study how that works

I think you can use alloc::Vec<T> and let the user figure out where to get an allocator from.

[gwbres]

No 64 KB record limit? No 16-bit length field? :-)

Hum, at first I thought that was correct (have not read the specs since last week 😄), but unfortunately that does not stand in the case of the BINEX protocol.

In BINEX, a few sensitive bytes are encoded using the so called 1-4 BNXI algorithm, which can describe an integer value (usually U32) using only the required amount of bytes to describe the actual value. That applies to the message length (MLEN) and gives up to 2^32 hypothetical record length

[gwbres]

@lnicola

No 64 KB record limit? No 16-bit length field? :-)
I think you can use alloc::Vec<T> and let the user figure out where to get an allocator from.

In BINEX, a few sensitive bytes are encoded using the so called
1-4 BNXI algorithm,
which can describe an integer value (usually U32) using only the required amount of bytes
to describe the actual value. That applies to the message
length (MLEN) and gives up to 2^32 hypothetical record length

correcting this statement which is wong or at least inacurate. Although t is true that this protocol may describe 2^27 byte long frames, that does not mean we cannot operate using a static buffer with reasonnable size. All we need is some way to describe partial / incomplete frames. Side note, BINEX only has about 10 different frames and apparently all with reasonnable sizes. So this may only apply to closed source prototypes, that this protocol permits