SDS2104x+, 1.3.7R5, Test of the SENT decoder
This post replaces the previous one on this topic. To some extend I could tell when it works. A Python simulator for SENT messages is attached. It is made for an ESP32 with micropython firmware. A suitable binary image is here:
https://github.com/robert-hh/Shared-Stuff/blob/master/firmware_ESP32_RMT_IDLE_SPIRAM.binTest of the SENT decoder.
The test of the SENT decoder were made using a Python protocol simulator
based on a ESP32 module. That simulator was expanded to support as many as possible
message types. Tests were made with a tick time of 5 µs. The simulator can
change the tick time in steps of 0.1 µs.
General impression:
The protocol decoder seems to be work in progress. Some basic functions are there,
but also quite a few inconsistencies and some unexpected behavior.
There is also no documentation yet about the decoder. So I had to guess about
the intentions.
Protocol decoder:
1. Protocol signal
After booting, the protocol signal level was always at about 8V. The state before
shutdown is non memorized. That's the case for both the decoder and the trigger
sections. That may be a common behavior of the oszilloscope and more an inconvence
than a serious problem. For automated testing I would anyhow expect the use
of scripts which set all test parameters again.
2. Protocol config & decode
a) Protocol timing
SENT is designed as timing tolerant. The standard calls a tolerance range of 25%. The
protocol config has a setting for both a CLK and a tolerance. For CLK I assumes it is the
duration of the basic protocol tick. So for a setting of 5µs I expected a range of
3.75 to 6.25 µs tick time, which would be accepted as decodable and valid messages.-
That is NOT the case. With a message tick time of exactly 5µs and the CLK set to 5µs,
the decoder flags a length error and decodes data wrong. Only with real tick settings
between 5.1µs and 5.2µs both no error was flagged and the decoded data was right. For
message tick times between 5.3µs and 5.8µs no error was flagged, but the data decoding
was wrong.
b) Display of decoded data
- The CRC display seems to be unfinished. You can select between two CRC Formats.
But both are displayed the same, and especially there is no difference in the display
between a correct and incorrect CRC. I tried all 16 values for a given data frame,
and besides the value they all look the same (same color.
- When moving such a burst of frames horizontally, the decoding sometimes switches
to completely wrong values. Increasing the horizontal scale fixes that.
Inmy test this happened only at aquisition memory depths if 20M and 200M.
When reducing the acquisition size to 2M i could not reproduce that error.
- Changing the horizontal time/div affects the ability to decode.
Which is puzzling, since the captured data does not change. So it looks as if
the decoding is based on the decimated display points and not on the captured data.-
- The Short Serial data is NOT decoded if only 16 frames are sent. If a 17th frame
follows, the data is decoded. In that case, also triggering on serial data works.
As far as I understand, Short Serial Data requires 16 data frames.
But no joy unless there is another data frame following the first 16.
- Same for the 12 bit and 16 bit variants of Enhanced Serial Data. The coding as
displayed in the decoded list for frames is right, but the decoded values are
not shown, unless a 19th data frame follows the 18 frames required for the
Enhanced Serial Data Message.
3. Serial trigger
- There are inconsistencies between the protocol config menu for serial trigger and
protocol decode. Some like the CRC are named different, some like idle level
do not exist. Different names may be an (avoidable) inconvenience, but the
omission of the idle level setting may be a problem.
- Triggering on the start condition of slow serial channels works, both for
frames with idle level low & high.
- Triggering on the ID value of slow serial frames works only with a trailing frame.
- Triggering on data works for slow serial works only, if the ID's also match.
When the ID is set to don't care, data trigger fails. In any case, triggering
on data requires a trailing frame.