summaryrefslogtreecommitdiff
path: root/decoders/pjdl
AgeCommit message (Collapse)Author
2020-07-17pjdl: support PAD bit adjacent to last HIGH DATA bit (no LOW)Gerhard Sittig
The PJDL decoder's previous implementation was incomplete. It assumed that PAD bits always start with a rising edge. Which made the decoder miss the next byte when a previous byte's MSB is set, and the last DATA bit and the next PAD bit kept the signal HIGH between them (no LOW phase was seen between these symbols). Keep the check for the LOW level after the byte's last DATA bit within the bit times' tolerance. But accept when the level remains HIGH, and check for the HIGH bit's width starting from the end of the last DATA bit. Also start the PAD bit's annotation from that "virtual" edge. This patch is based on a fix that was Submitted-By: Julio Aguirre <jcallano@gmail.com>
2020-07-07pjon: fixup PD category for PJDL and PJONGerhard Sittig
2020-07-02pjdl: prepare for "stretched" timingsGerhard Sittig
Since the spec is vague on the subject, and real world captures were found to occassionally run on odd clocks, internally prepare to inspect traffic and interpret its content although the input data is invalid in the strictest sense. Keep this hack internal, don't suggest to users that invalid traffic would be perfectly acceptable.
2020-07-02pjon: use underscore in input/output names for stacked decodersGerhard Sittig
Rename 'pjon-link' to 'pjon_link' for consistency with other decoders.
2020-06-24pjdl: introduce decoder for PJON single wire serial link layerGerhard Sittig
Introduce a protocol decoder which generates 'pjon-link' output from 'logic' input by interpreting the PJDL single wire serial communication link layer of the PJON protocol stack. This decoder extracts frame markers, data bytes, as well as their pad/sync decoration. Inspection of data values, or checks for frame validity remain the responsibility of a stacked decoder which is shared among several link layer types. This implementation "violates" the PJDL spec in those places where the spec is incomplete or vague, and real world traffic would not decode at all when the strict letter of the spec is applied instead of its spirit. When in doubt, the decoder implementation errs to the usability side. Carrier sense detection is incomplete in this version. Data extraction works for all currently available captures. Recovery from synchronization loss after glitches is acceptable. Glitch filtering is missing (the spec is silent on this subject).