Old signals
I was recently approached by a company willing to give new life to old security equipment. The system had a proprietary serial bus, but the manufacturer refused to disclose any information about it. Provided it was more than twenty years old it should not be a big challenge.
However, figuring out the details of a serial communication you know nothing about will require some nice tools. This time I bought a nice USB oscilloscope. It's only 1 Mhz bandwith but fast enough for my needs in this case. With it I was able to capture bidirectional communication (as it is dual channel) and start the process of figuring it out.
Just looking at the scope signals will tell you the encoding and bitrate (look for the shortest pulses, they are likely single bits and its time-length will tell you the bitrate). Serial communication used to be mostly asyncrhonous, and this was also the case. Once the time duration of a bit known you can figure out the data length and wether parity is being used or not.
It helped me a lot to code some small programs in Java so I could convert several megabytes of logged signals into something I could print on a page to carefully look at it. So I converted first the analog signals into simple ASCII "1" or "0" characters and, later on, I used that as the input to another program that converted the bitstream into an SVG graph (actually, I tried the TurtleGraphics OpenOffice macro, but it turned out quite slow for my needs). I then used Inkscape program to view the created SVG graph and to generate a PDF file too.
Once you have a file with your favourite signal you can write some code to perform the decoding. In my case a piece of Java code did a similar work as an UART. With one of the signals everything was going fine, but wiht the other I was having trouble as I was getting both parity and framing errors. Later on I realized that latter signal needed to be inverted to get the right one.
As a final treat I combined signal decoding and waveform drawing into a single program that drew and added the decoded values to the graph so I could use all that information to figure out how the protocol worked on the type of messages I was interested. (Yes, I know it's a shame I did not put the text on top of the signals to get a more readable result).
Before doing all this work I actively researched the net and I discovered a couple of guys that wanted to do this same thing, although it was several years ago, but either them or their employers decided it was not worth. I contacted them and I told them what I've learned.
I didn't mention it, but the StingRay USB scope is supported under Linux too :-)
However, figuring out the details of a serial communication you know nothing about will require some nice tools. This time I bought a nice USB oscilloscope. It's only 1 Mhz bandwith but fast enough for my needs in this case. With it I was able to capture bidirectional communication (as it is dual channel) and start the process of figuring it out.
Just looking at the scope signals will tell you the encoding and bitrate (look for the shortest pulses, they are likely single bits and its time-length will tell you the bitrate). Serial communication used to be mostly asyncrhonous, and this was also the case. Once the time duration of a bit known you can figure out the data length and wether parity is being used or not.
It helped me a lot to code some small programs in Java so I could convert several megabytes of logged signals into something I could print on a page to carefully look at it. So I converted first the analog signals into simple ASCII "1" or "0" characters and, later on, I used that as the input to another program that converted the bitstream into an SVG graph (actually, I tried the TurtleGraphics OpenOffice macro, but it turned out quite slow for my needs). I then used Inkscape program to view the created SVG graph and to generate a PDF file too.
Once you have a file with your favourite signal you can write some code to perform the decoding. In my case a piece of Java code did a similar work as an UART. With one of the signals everything was going fine, but wiht the other I was having trouble as I was getting both parity and framing errors. Later on I realized that latter signal needed to be inverted to get the right one.
As a final treat I combined signal decoding and waveform drawing into a single program that drew and added the decoded values to the graph so I could use all that information to figure out how the protocol worked on the type of messages I was interested. (Yes, I know it's a shame I did not put the text on top of the signals to get a more readable result).
Before doing all this work I actively researched the net and I discovered a couple of guys that wanted to do this same thing, although it was several years ago, but either them or their employers decided it was not worth. I contacted them and I told them what I've learned.
I didn't mention it, but the StingRay USB scope is supported under Linux too :-)
Comments
as always your article is amazing. I wonder how doy you manage to solve this kind of problems?
I see that your interdisciplinary knowlege helps you a lot!!, and the practical reality too.
Best regards, Juanjo.