I would like to propose some changes/added features to the Asynchronous communications setup panel. These changes would would extend the capability of the Logic series to receive and decode more asynchronous communication protocols without have to write custom decoders (at least at the bit level).
First, I was pleased to see that the number of bits for a frame was programable out to 64 bits.
A “traditional” asynchronous data frame begins with a “Start” bit, data bits, maybe a parity, and one or more “Stop” bits. However, not all asynchronous messages begin or end this way. The ARINC 429 protocol is an example of an asynchronous protocol which uses a 3 level signaling. The Idle state of the bus is approximately 0V. A logic 1 is represented by a signal level >= 6.5V which a logic 0 is represented by a signal level <= 6.5V. A transition from an Idle condition (0V) to either >= 6.5V or 0V to <= 6.5V represents the start of a frame. For this protocol, the frame length is 32 bits with no parity or stop bit(s).
To successfully be able to decode this protocol, or similar protocols, the following features would need to be added.
- The ability to set a more complex trigger level and edge.
- The ability to tell the decoder how much to delay from the trigger point to the 1st data sample. The
2nd, and subsequent samples would be taken at the bit rate.
- The ability to tell the decoder that there are no start or stop bits. The first data bit would be taken as
described in #2, and could continue until all bits were sampled (based on the Bits Per Frame
setting).
Added these features would allow the user to decode many more asynch protocols without having to write custom decoders.
A document is attached which may describe this in a little more detail.
Saleae_Feature_Request_1.pdf (451.0 KB)
@g.helton Thanks for the request! The main limitation with our current hardware might be the ability to detect 3 logical states. This could potentially be solved in software (i.e. generate a virtual digital channel based on an analog recording). We’re currently tracking this idea below, and might be the first step towards supporting your feature request.
I have some follow up questions for you below:
- A transition from idle (0V) to a logic 1 (>= 6.5V) sounds pretty straighforward. Can you describe in more detail what a transition would look like from idle to logic 0?
- What typical/maximum baud rates are supported in this protocol mode?
Hi Tim,
Thank you for the reply. I have attached two more documents which describes in more detail the requirements for this particular protocol. While this protocol officially uses a trinary level scheme, a binary level scheme (two level) trigger and decoding should work most of the time. That is, triggering on a rising edge of >= 6.5V OR a falling edge of <= -6.5V, then using those same signal levels for logic decoding. The NULL signal level usually isn’t a problem since the transmitter connects the bus to GND level during these times. Ideally, the hardware would support two triggers with two programmable trigger levels. Of course, if hardware won’t support that type of trigger, then the signal would have to be sampled in software, and the trigger decision made there.
Thank for you questions and your interest. If I can be of more help, please let me know.
Saleae_Feature_Request_1a.pdf (130.6 KB)
ARINC429.pdf (1.5 MB)
@g.helton Ah that makes sense now. Glad to hear a binary level scheme would work out.
That is, triggering on a rising edge of >= 6.5V OR a falling edge of <= -6.5V
Logic Pro 8 and Logic Pro 16 have an anlog voltage range of -10V to +10V, so this could theoretically work with current hardware. If our software could implement the ability to process analog channels to digital, that would be the first step (i.e. provide the ability to set voltage thresholds in software with hysteresis).
In summary, you highlighted 3 steps earlier:
- The ability to set a more complex trigger level and edge.
- The ability to tell the decoder how much to delay from the trigger point to the 1st data sample. The
2nd, and subsequent samples would be taken at the bit rate.
- The ability to tell the decoder that there are no start or stop bits. The first data bit would be taken as
described in #2, and could continue until all bits were sampled (based on the Bits Per Frame
setting).
Step 1 could be done in software via the method above. We don’t officially have this on the roadmap, but we’re continuing to monitor user need for it. I ended up adding a comment for you so we can remember your use case and we can refer back to your documentation if needed (the feature request post that I linked above).
If we were to implement the feature in step 1, then Step 2 and 3 could then be done by creating a custom analyzer using our Protocol Analyzer SDK below.
Thanks again for bringing up your need for this! Also, apologies we don’t have an immediate solution for decoding it at this time.
Just wanted to put in an additional vote/request for ARINC 429 decoding.
To the point about the need for ternary logic states, I have an alternate suggestion. If the signal trigger threshold issue above gets resolved then decoding could be done directly by sampling the same signal across two channels. One channel triggers at >=6.5V (0/1 threshold), and the other triggers at <=2.5 (NULL/0 threshold). The protocol decoder could then use both channels as inputs to decode for all three states directly, similar to I2C or any other multi-wire protocol.
1 Like
Thanks @rsbonini ! I took note of your request in the idea post below: