From what I can tell this signal (attached) uses a variable bit duration, between 960 micros and 1000 micros (1 millis). I want to write an an analyzer to overlay and print the bits easily which seem to be variable. Also from what I can tell the signal uses ~8 zero bits to start each transmission, so its a bit unusual. But if I could overlay all the bits including those, that would make it easy for me to repro the signal with Ardruino
Is it possible to do this, it seems like the HLA expects you to already have an analyzer capture some bytes and then feed it into the decode method. At least from what I could tell when I got an example to work and printed some debug statements.
Sorry, if there is an obvious answer, I am new to signal analyzing and using saleae. But have python experience
For context, I am trying to analyze the Serial signal on a Bose Lifestyle 50 head unit, so I can replace it with an ardruino (as it has a few issues that make it hard to use) and control the 5.1 speaker system it comes with. I have found some resources on the serial signal some of the Lifestyle models supposedly use, but what I capture doesn’t seem to match what others have documented at all, and I noticed many others have had issues trying to send it documented signals. So my plan is to capture the exact bits it sends and send them back.
Taking a quick look at the attached file, and it seems like the protocol might be something like:
IDLE: is high FRAME:
1 x SOF (‘start’) = ~8 ms low pulse
(or ~7 ms low pulse + first 'data bit’s ~1 ms low pulse)
N x BIT (‘data’ ?):
BIT-A: bit type A (‘long high pulse’) = ~1 ms low (‘space’) + ~2 ms high
BIT-B: bit type B (‘short high pulse’) = ~1 ms low (‘space’) + ~1 ms high
1 x EOF (‘stop’) = ~2 ms low pulse
It doesn’t quite look like typical UART/Async Serial protocol, as all the low pulses are either:
~8 ms (always at the ‘start’ after ‘idle’ period)
~1 ms (in the middle, for ‘data’ bits – or, could just be ‘space’ between ‘high pulse’ bits)
~2 ms (at the end, before going ‘idle’ again)
… and you would expect a typical UART/Async Serial protocol trace to have recorded more variety of low pulse widths than just the three listed above.
Anyway, given above general bit-level encoding, then it seems like each frame is either N = {13 or 21} ‘data bits’ long. You’ll have to study more deeply to figure out which BIT (A or B) is encoded as a digital ‘1’ or ‘0’ bit, and if there are more bits dedicated to framing/other purpose besides just ‘data’. Unfortunately, I don’t think there’s a built-in decoder in Saleae for this type of encoding scheme. Instead, you could use the ‘Export Raw Data…’ menu option and save Channel 1 as a CSV file to study/decode offline within a spreadsheet and/or other analysis tool(s).
However, I’d suggest studying the ‘raw data’ captures first, and carefully collect specific command sequences one at a time to find if there are specific repeating patterns. Based on that, you might just be able to do a simple ‘replay’ of the recorded data/patterns for whichever commands you want to replicate (rather than building up a native low-level analyzer to display it in Logic).
If your more ambitious, you could try to reverse-engineer the entire protocol, but that shouldn’t be needed to just ‘replace it with an Arduino’ (if that’s your primary goal). Without knowing the protocol, it will be a challenge to design the low-level analyzer – as you don’t know the format of what you’re trying to decode.
Thank you this is really helpful, your tip to just export to a CSV file to analyze will probably be the easiest way for me to make some sense of this information. I’ll take a look later but if the CSV file can just tell me the duration of lows and highs, I can easily write a python program to iterate through that and make some sense out of it.
Then hopefully I can use some low level API in the ardruino to try and reproduce a similar signal
Also, your analysis of the protocol is really helpful as well. Thank you for that too! I don’t have a ton of experience with signal analysis so
