How to convert data stream to binary using a scope? - Page 1
Forum section: electronics / beginners

author: Chriss
author_rank: Frequent Contributor
timestamp: July 22, 2020, 10:15:28 pm
content: Hi!I'm playing with a small project where I wish to interface my digital china cheap caliper with my pc.So far I hooked up my scope to the caliper and watching the data stream.I never decoded any protocols before and have no experience how to do that with my scope, which has noprotocol analyzer function, even if it would have I think the china caliper use some sort of non-standard protocol,which would also be a problem for a scope with protocol decoding function to decode the data protocol.The main goal of my project is to understand how to read the data with a scope and convert the data to binary value.In the picture you can see what I wish to achieve.That is a part of my real signal.I would really appreciate if somebody could share a link from YT or other place with me.I'm not sure what is the correct name of this what I wish to do and it is hard for me to find on the net a correct tutorial.I just wanna learn the relation between the CLK line and DATA line lets say on my caliper and how to interpret such a data on the screen of the scope.Thank you very much for any help.

author: eblc1388
author_rank: Frequent Contributor
timestamp: July 23, 2020, 12:22:35 am
content: Try the following website:http://pcbheaven.com/exppages/Digital_Caliper_Protocol/?topic=chinesebcd

author: Chriss
author_rank: Frequent Contributor
timestamp: July 23, 2020, 07:37:04 am
content: Hi!Thank you for the replay and link.I found and read your suggested link before my post too. But I can not really understand the fundamental technique of count8ng the bit's in the relation of the clock cycle.I have some knowledge from school about this but no practice.Can somebody interpret the data in relation with the clock cycle from my picture?So I can under stand from my example how to count the bit's.Forget for now my project about the caliper. I wish to learn how to get the data out correct from such of signals.Thank you.

author: eblc1388
author_rank: Frequent Contributor
timestamp: July 23, 2020, 09:15:28 am
content: Ok. It is not difficult to do that.First of all, we can see that the information are sent in 4-bit mode, by looking at the extra long pulse on the clock waveform. Then we have two choices. We can either read the data on the falling edge or on the rising edge of the clock pulse, with both of equal possibility. We don't know yet. Therefore we'll try one first and if the decode data does not make sense or disagree with what was displayed on the caliper, we then try the other.I have done both and the result is shown in the images attached. After we have decoded the bits, we still have to consider if the bit order is right or not. I have assume the least significant bit(LSB) is sent first but this is at liberty of the software designer. He can choose either. The final decoded value is shown as "pink". You then have to decide if the pink character value is decoded successfully or not by comparing it with the actual caliper display.Do try to take the same picture as in my first reply and show us your decoded result.

author: Chriss
author_rank: Frequent Contributor
timestamp: July 23, 2020, 08:46:48 pm
content: Thank you sooooo much for your time.I think I understand how this is working but I have to practice.So, here is the homework you give me.I counted the bits on rising edge and falling edge on the second pic.I have a question:What are for that white arrows crossed on the picture where you give the explanation?I hope I did it well.Thanks.

author: eblc1388
author_rank: Frequent Contributor
timestamp: July 23, 2020, 11:45:36 pm
content: Quote from: Chriss on July 23, 2020, 08:46:48 pmThe crossed white arrows is just my way of saying reversing the bit order, so that the MSB now becomes the LSB.Yes, you've done very well(except one careless mistake). Now you can read serial data without relying on the decode option on the scope. Take this opportunity to learn about how to decode the common RS232 data format, which does not have a clock line associated with the transmitted data.

author: Chriss
author_rank: Frequent Contributor
timestamp: July 24, 2020, 08:12:30 pm
content: Hi!I'm very happy and thank you for your time helping me.Yes, the error is based on nit focusing enough to the job I did.I misaligned the bit's when I relocated them.I have to search for a solution to capture some rs232 data and try to figure out how to decode them manually.Most of time I use logic analyzer to do this jib but I wish to learn this too to do manually.Can you pls give me some good link with tutorial for learning that too?Thank you.

author: Electro Fan
author_rank: Super Contributor
timestamp: July 24, 2020, 10:34:24 pm
content: The info provided by eblc1388 is important - you want to be sure to understand the significance of MSB (most significant bit) vs LSB (least significant bit); without correctly specifying and adopting the proper MSB vs LSB convention the sequence of bits will be backwards. (Note also that the acronyms MSB and LSB are generally capitalized but by convention bits are referred to with a lower case "b" and Bytes are referred to with an upper case "B").Ultimately, bits (binary digits, ie 1s and 0s, ie conceptually the presence or absence of electricity, ie on or off) will be put together intoBytes. In this case each Byte can be thought of as representing a human character (alpha, numeric, special character, etc.)(In other cases a Byte (a combination of some number of bits) might represent something interesting to a machine (for example, the value of a pixel) but maybe not so interesting to a human).With RS-232 you are looking at a mechanical and electrical interface standard that specifies how the physical pins (typically in a DB9 connector) are used for various functions. Some of the functions have become less likely to be used over time as technology has changed from when analog telephone lines were more common and now digital transmission lines are more common. In any event, 3 of the pins on a DB9 connector that are most often used are TX, RX, and GND. For now you can focus on one way transmission (and therefore focus on TX or RX along with GND). In RS-232 the voltage can have a range as discussed here:https://en.wikipedia.org/wiki/RS-232#:~:text=The%20standard%20specifies%20a%20maximum,3%20or%205%20volt%20supply."The standard specifies a maximum open-circuit voltage of 25 volts: signal levels of ±5 V, ±10 V, ±12 V, and ±15 V are all commonly seen depending on the voltages available to the line driver circuit. Some RS-232 driver chips have inbuilt circuitry to produce the required voltages from a 3 or 5 volt supply."So, what you are looking for are the transitions between 1s and 0s as the signal goes high or low as represented by the voltage; one thing to keep in mind is that logic can be normal or inverted - depending on the convention used a high might represent a 0 rather than a 1, so pay attention to that as well as MSB and LSB.Another thing to keep an eye on is the length of the Byte; a Byte often contains 7 data bits but it could be 8 (or possibly some other number of data bits).The reason for this is that 27= 128 and 28= 256, etc. When we use 7 data bits (each being one of two possible states, a 1 or 0) we get 128 possible combinations (represented in decimal as 0-127), and this is generally what we know as ASCII (the American Standard Code of Information Interchange).With ASCII's 128 possible combinations we can have enough for all the Alphabetics (both 26 lower case and 26 upper case) plus all the numerics (0-9) plus various punctuation and special characters. In a variation of the code that was popular with IBM back in the day called EBCDIC (Extended Binary Coded Decimal Interchange Code) a Byte consisted of 8 bits, which provided 256 possible combinations (represented in decimal as 0-255). IBM wanted to leave room for expansion/growth. Occasionally you might see ASCII used with 8 data bits in which case the 8th (or 1st bit depending on whether you are using MSB or LSB) is "padded" (ie filled with another bit.) So you have to make sure your oscilloscope, or logic analyzer, or terminal program is set properly to know if you are expecting 7 data bits or 8 data bits (or possibly some other number of data bits). Again, you also need to set up properly for LSB or MSB and normal or inverted logic.Next, is another bit called the parity bit. The parity bit is used to help keep the data bits from getting scrambled so typically after each 7 or 8 data bits the parity bit might be set for even or odd (or maybe none). With even parity if all the data bits add up to an odd number, the parity bit then will insert a 1 to turn the Byte sequence even. Or with odd parity if all the data bits add up to an even number the parity bit will insert a 1 turn the Byte sequence odd. (Otherwise, if it's not needed the parity bit will insert a 0.)Not quite last, depending on the convention, start and stop bits also need to be set. This way we know that say with 7 data bits and a parity bit, every first and tenth bit should be the same (a 0 or a 1) reflecting the agreed upon value for the start bit and the stop bit - which enables the system (and potentially the user) to know where each overall Byte starts and ends.The specific values of ASCII Bytes can be found in an ASCII table:http://web.alfredstate.edu/faculty/weimandn/miscellaneous/ascii/ascii_index.htmlYou will see rows that give information for the sequence of 1s and 0s as they relate to each ASCII character, and as they relate to other codes including decimal and Hexadecimal.Finally, one other setting to keep in mind is the baud or speed of the encoding and decoding process. Both ends (TX and RX) need to be set for the same speed. This might be 1200 bps, 2400 bps, 4800 bps, 9600 bps or some higher rate. Typically these speeds are somewhat standardized but you might find some custom speeds.If you do this often and consistently enough with respect to LSB or MSB and normal or inverted logic you might start to recognize some of the patterns of some of the Bytes as you watch on an oscilloscope or with a Logic Analyzer - which I guess is what manual decoding means.Good luck!

author: eblc1388
author_rank: Frequent Contributor
timestamp: July 25, 2020, 04:31:58 am
content: I don't have good link or tutorial at hand but searching the internet can reveal a lot of them. Instead I wrote some notes for you below. Hope it helps.Manual decoding of serial RS232 data is difficult, because there is no clock edges to help reading the data bit value. Usually decoding is done with help of logic analyser but if the parameters of the RS232 communication is not known, then it might not be a straight forward matter.We start off with a scope trace, showing several possible data blocks/chunks. If the signal voltage varies between positive and negative rather than between positive & Gnd, and the idle(separation) level between the data blocks is more negative w.r.t. GND , then it is a proper RS232 data signal. Else it might be an USART signal from the MCU or microcontroller I/O port output instead, which has no negative level.Then visually, for bit-timing, we look for the narrowest transition(either high-low-high or low-high-low) timing in the scope trace and read off the timing on the scope graticule or measure it using cursors. Expands the trace at portion of interest in order to get a more accurate reading. Compare the timing result obtained to the one shown in the following image to get the bitrate, note the possibility of timing error of a few percent. If there isn't any plausible match, then the communication is via non standard bitrate, which is unusual but equally possible for some particular reasons. Also it is possible(but unlikely with many data blocks) the narrowest transition are for two consecutive "1" or "0" bits due to the actual data, then the result would not be correct.After the 'bitrate' is found, then the data can be decoded. In case of RS232, voltage level below ground is designated a logic "1" and above ground level a "0". However, this is not the end of story. Every data block is made up of a "start bit(logic 0)", follows by 5,6,7,8 or 9 data bits. Then an optional parity bit and finally a "stop bit(logic 1)" of length of one, 1.5 or two bit-time. Faced with so many possible choices, most users would choose to start with the most commonly used configuration by everybody, namely the famous "8N1" config. This actually means 8 data bits, No parity bit and 1 stop bit. I would say this would work out in most cases if ASCII characters are transmitted but not with numeric data, which the designer will most likely have selected to use either odd or even parity bit as a check for data integrity.We first start off at the point the data changes from idle(negative) to positive, and wait 1.5 x bit-time, doing so will skip the start bit and lands us in the middle of the first bit, which is usually the LSB. We read the data level and convert it into bit value. We then move forward another bit-time and read off the second bit value......repeats till we have done with the parity bit if it exist.That's about it, in a nutshell. Two sample RS232 8N1 waveforms is attached for your practice, the bit-time is found by measurement to be 102us. Find the bitrate and the data being transmitted.

author: Chriss
author_rank: Frequent Contributor
timestamp: July 26, 2020, 07:28:09 pm
content: Thank you so much to all of you for such of nice writing.I really appreciate your time spent on these valuable posts.I finally got a whole picture about this.If I understood correct the RS232 "manual decoding" stuff then it is like this, simplified version:The RS232 has no clock signal providing so we cant simple count the rising or falling edge and count the bit's.But it has the baud rate which is actually the time of the length of one bit signal.If we know this timing then we can actually calculate the frequency and practically we can "extract" the bits from the scoped signal.Am I correct with this simplified version and how I understood this?btw.:I'm not really sure what for and what means the LSB and MSB?Can somebody explain to me in some simpler way?Thank you very much.

author: Electro Fan
author_rank: Super Contributor
timestamp: July 26, 2020, 11:13:21 pm
content: Your simplified version is good – you’ve got it.BTW, the Time per bit chart provided by eblc1388 is very helpful (it's the first time I've see such a chart) and his overall approach to decoding is really excellent. I think you are on the fast track to decodingRegarding MSB and LSB, in binary counting is as follows:0110111001011101111000etcTo help us understand the counting system the column furthest to the left is referred to as the Most Significant Bit (MSB)In binary as above we only have 2 numbers (1 and 0) so we have to carry to the next column to the left after using those 2 numbers (vs in decimal we carry after using 10 numbers (0-9) by adding a new column to the left.0123456789101112etcIn decimal, as an example, we know by convention that 1024 is one thousand twenty four because we know that the one is in the thousands column (the most significant column) and the four is in the ones column (the least significant column). If for some reason we read it backward we would instead call it four thousand two hundred and one. This doesn’t happen because we are very familiar with the convention – but if for some reason we did read it as 4201 rather than 1024 this would lead to errors and confusion.Sometimes when looking at waveforms (pulses of highs and lows) scroll by on an oscilloscope or computer screen it’s possible to lose track of whether the bits are going left to right or right to left. To signify which bit in a Byte is most significant we refer to it as the MSB and we refer to the bit on the other end of the Byte as the LSB. If it helps, you can think of the LSB as analogous to the “ones” column in decimal.As with nearly everything there is a convention that might or might not be followed, so on an oscilloscope or with a logic analyzer there is usually a setting that can be toggled between MSB and LSB. As long as the decoding (RX) side is set the same as the encoding (TX) side the decoding process should work as intended.

author: eblc1388
author_rank: Frequent Contributor
timestamp: July 26, 2020, 11:57:14 pm
content: In addition to the explanation by Electro Fan, I will give you a real life example.You need to handover a document of 8 pages to a friend but you'll do it page by page, until its done.You give the first page to him, but he immediately questions, "Is this the first page or the last page?". You answered, this is the "First page". Then you hand out more pages and your friend stacks them under the previous page, until all pages are received. Should your answer be "Last page" instead, he will then place new pages over the previous pages until its done.Either way the document assembled would be valid and in correct order. The concept of LSB/MSB is the same. In serial transmission, the bit received will be stack in a temporary buffer first until the full *byte*(could be less/more than 8 bits) has been received. If the receiver knows the intention of the sender, then he can place the bit into the correct buffer bit location.

author: Chriss
author_rank: Frequent Contributor
timestamp: July 27, 2020, 10:33:08 am
content: WoW! you are amazing how both of you are simple but powerful explain this kind of science.It's so easy to read and understand, even if English is not my natural language.Thank you so much!This is the way I understood the MSB/LSB stuff:From the "real life" example:The MSB is the first page and the LSB is the last page.Am I right?

author: eblc1388
author_rank: Frequent Contributor
timestamp: July 27, 2020, 11:39:53 am
content: Not quite. The MSB/LSB of a binary value is well defined and fixed.Whether the first page to be sent is LSB or MSB depends only on the sender's choice. He can choose either. He only have to tell you beforehand for you to assemble the document successfully.

author: RJSV
author_rank: Super Contributor
timestamp: August 09, 2020, 04:18:20 am
content: Hello, thanks for your question, and skimmed all the replies, but don't see mention, SCOPE doesn't have much time depth. Let me explain, standing back a bit:A session might consist of some exchange, let's guess every half- second, when active. Say there are 4 new (bytes) of caliper data, and then you press "New Measurement" on the PC. That PC issues, regardless of protocol, some predictable list of, say, 5 bytes.Now, that might only happen once, unless some internal timer indicates nothing came back. So you see, that alone could go past the Scope screen width, practically, and only once.Do you have a smart buffer, for storing (that) one single transmission, a command to send down a measured caliper string of digits. If long SEND stream can be seen that helps. I would look for the following interpretation:Sent Byte 1, an address, 0 thru 31 max. for large networks that include the caliper of interest. Next Sent Byte 2, a bit-map where bit 7 is a command, to 'dump your stuff now', obvious reading the caliper.Next, a byte, like 1111, 1111 b, meaning 'blink LED', assuming no error. Next a parity byte, for checking if the whole string is likely free of transmission errors.Ok, so assuming approx that happened, your SCOPE channel two goes to display, soon, a response string.See how much guessing, but continuing, the response might consist of:Byte 1, dataA, dataB, dataC, etc. ... That could be number 987, for example, as in 987 mm.Then, a parity byte, for (your) PC to accept the data, and finally show it on-screen.However, that's expertise from way back, 40 years.I do think you can at least get a sense of transaction and bursts of exchange, as Send / Recieve sessions.Plus, you still need the direct clocking and data hints seen in previous replies.Does your Scope have that deep capture capability ?

author: RJSV
author_rank: Super Contributor
timestamp: August 09, 2020, 04:34:53 am
content: Oops, meant to say 'Parity BIT' at the end of transmitted string of bytes.(Some systems have used a 'checksum byte' which is a successive addition, for a sort of summary almost never accidently correct... Sorry to mislead, on the Parity error check.