On Wed, 2020-06-24 at 21:09 +0200, Gerhard Sittig wrote:
>
> Out of interest I whipped up a decoder implementation. Looks
> pretty usable to me, and is assumed to be operational. But hasn't
> seen much test yet, mostly due to lack of example captures. [ ... ]
Status update: The decoder implementation was found to be
incomplete, and incorrect in previously untested code paths. I'm
aware of these issues:
- Checksum calculation is wrong in the CRC32 case. Julio spotted
this and fixed it in his repo. I'd push a slightly rephrased
version of that fix later (find a spot in common code to
address the CRC length dependent location of payload data).
- Data bytes which follow a data byte with a high MSB are not
detected. The lack of a low phase between the last data bit and
the next pad bit was unexpected. Giovanni Blu Mitolo the PJON
protocol author acknowledged that the low phase is not
mandatory. Again Julio identified the issue and addressed it in
his repo. I'd have to check, and may have to slightly tweak the
fix before pushing something. Because there really are nine bit
times which we need to cater for. The "absolute tolerance" of
the PD implementation is a HACK that's not backed by the spec
(until a recent update which still is in flux) to begin with.
To keep the decoder as robust as it currently is, I'd rather
"calculate" the adjacent pad bit relative to the last SYNC
pad's falling edge. It's the only reliable condition we have,
and is what the spec uses for the byte's data bits.
- The decoder's tolerance violates the (previously available
version of the) spec. An update is currently under discussion,
but not finished yet. This can get addressed in the decoder
when the spec became stable.
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
