Tektronix Technical Forums are maintained by community involvement. Feel free to post questions or respond to questions by other members. Should you require a time-sensitive answer, please contact your local Tektronix support center here.

Faulty/corrupted RIBinary data // Python-usbtmc-TDS2004b

Post Reply
Bbelonder
Posts: 2
Joined: April 11th, 2016, 7:46 am
Country: Germany

Faulty/corrupted RIBinary data // Python-usbtmc-TDS2004b

Post by Bbelonder » April 11th, 2016, 8:11 am

Hey folks,

I'm currently writing a program which is supposed to read points from the TDS2004b as often as possible and store them into a file.
My setup is python 3.4.2 with usbtmc running on a raspberry pi mod 3 with rasbian and the TDS connected via USB.
While most commands are working perfectly fine, the readout via ASCII encoding is also working but very, very slow. Since the Programmer's manual stated that the transfer rate should be much faster using ribinary or sribinary, I also tried this. But with either transmission width, the data seems to be corrupted in some way I do not get yet. But let's get to the code first (This is basically reading the waveform from one channel:

Code: Select all

import usbtmc
TDS=usbtmc.Instrument(VendorID,ProductID)
TDS.write("Data:SOUrce CH1")
TDS.write("Data:Encdg RIBinary")
TDS.write("Data:Width 1")
TDS.write("Data:Start 1")
TDS.write("Data:Stop 2500")
TDS.write("CUrve?")
raw_bin=TDS.read_raw()
Output then takes the form

Code: Select all

b'#42500dccdcedccddccbcbccdccbbcccbcdbbcbbcbccbcbcbcbbbb`c`cbbcbbbcb`aaaaa``aabbabb``a_aba__```aa`a`a`_```__`_`___a````__`__^`^_^^`_`^____^^__^]^^__^_^^]^^\\^]]]]]]]^]]]\\]\\\\]\\\\\\]\\]]][]\\[[\\\\\\\\Z[\\[\\[\\\\Z\\\\[\\[[[[ZZ[ZZ\\[[Z[ZZZZZZZYZZZYZZZYXYZYZZYYYZYYZXYXXYXXYXXXXXYYWXYXXXWWUWWXWVXXWWWVWWVUVWVVUVVVWWWVUVUVVUUUTTUUTVUUTTUUTUUTSUUSTTSSTUSRSSSSTTSTSSSRRRSRRRRRQSQSSRSQQRRRRRPPQQPPPQPQQQOOOOOOPQONPPPPPOPOOOOOONONMOONNONMNNMMNNNMOMMLMLLLLLMLLMLMMLKLKKLKKMLKKJKJKJJKIJJJKKJJIIIJJIIJIIJIIHHGHHGIIGGHHIIGGGHGFGG[email protected]@[email protected]@[email protected]@AA>@@[email protected][email protected][email protected][email protected]?>??>?>>>>>>===>=><===<=<<<<<<<<:<<;;<;;;::;:;:;:::;:::999:889999899:889777787877786667666666766665555564553445445445344333243223322221102112222201111101000/0///0//////.-.-....-..-.--,--,,,-++,-,++,,++,+++***)*****)*+**))*))*((()((\'\'\'(((((\'&(\'\'\'\'\'\'\'%&&&(\'&&%%%&%&$&%$$#%$$$$$$%$"##"###"#"""!"""!"!!! !  !! !   \x1f! \x1f \x1f\x1f \x1f\x1f\x1d\x1f\x1f\x1f\x1f\x1e\x1e\x1d\x1d\x1e\x1d\x1e\x1e\x1d\x1d\x1d\x1d\x1d\x1d\x1d\x1c\x1c\x1c\x1b\x1b\x1c\x1c\x1c\x1b\x1b\x1b\x1b\x1c\x1c\x1b\x1b\x1b\x1b\x1b\x1a\x1b\x1b\x1a\x1a\x1a\x19\x1a\x1a\x19\x18\x19\x18\x19\x18\x1a\x1a\x18\x19\x1a\x19\x17\x18\x18\x18\x17\x17\x17\x17\x17\x16\x18\x17\x16\x17\x17\x17\x16\x15\x17\x16\x18\x15\x16\x16\x15\x14\x14\x15\x15\x14\x15\x15\x14\x15\x14\x15\x13\x13\x13\x13\x14\x14\x14\x13\x12\x14\x14\x13\x12\x12\x13\x13\x12\x12\x13\x13\x12\x12\x11\x11\x12\x11\x10\x12\x12\x11\x10\x10\x11\x11\x10\x10\x11\x10\x10\x10\x10\x10\x10\x10\x0f\x0f\x10\x10\x0f\x0e\x0e\r\x0e\x0f\x0f\x0f\x0e\x0e\x0e\x0e\x0e\r\x0e\x0c\x0c\r\r\x0c\r\x0c\x0c\x0c\x0b\x0c\x0c\x0c\x0b\x0c\x0c\x0c\n\n\x0b\x0b\n\n\n\x0b\x0b\n\n\x0b\n\n\n\n\x0b\t\t\t\t\t\x07\x08\x08\t\t\t\x07\x08\x07\x08\x08\x08\x07\x07\x07\x07\x06\x07\x07\x07\x07\x06\x07\x06\x07\x05\x05\x05\x05\x06\x05\x06\x05\x05\x05\x05\x04\x04\x04\x04\x04\x03\x05\x05\x05\x05\x03\x03\x03\x02\x04\x03\x03\x03\x02\x03\x04\x02\x02\x02\x01\x02\x02\x01\x00\x00\x01\x00\x01\x01\x01\x01\x01\x01\x00\x00\x00\xff\xff\x00\x00\x00\x00\xff\xfe\xfe\xfe\xff\xff\xff\xff\xfe\xfe\xfe\xfe\xff\xfd\xfe\xff\xfc\xfd\xfd\xfd\xfd\xfd\xfd\xfd\xfe\xfc\xfc\xfd\xfc\xfd\xfc\xfb\xfb\xfc\xfb\xfb\xfc\xfb\xfb\xfb\xfb\xfb\xfa\xfa\xfb\xfa\xfa\xfa\xfa\xfa\xfa\xfa\xf9\xfa\xf9\xf9\xfa\xf9\xfa\xf9\xf7\xf9\xf9\xf8\xf9\xf8\xf8\xf7\xf8\xf7\xf7\xf7\xf8\xf7\xf8\xf8\xf7\xf6\xf6\xf6\xf7\xf6\xf6\xf5\xf6\xf5\xf6\xf5\xf6\xf6\xf5\xf5\xf6\xf5\xf5\xf5\xf4\xf4\xf4\xf3\xf5\xf5\xf3\xf4\xf3\xf3\xf3\xf4\xf3\xf4\xf3\xf3\xf2\xf3\xf3\xf2\xf3\xf1\xf2\xf2\xf2\xf2\xf2\xf0\xf1\xf1\xf2\xf0\xf1\xf0\xf0\xf0\xf0\xf1\xf1\xf0\xf0\xf0\xef\xf0\xef\xef\xef\xf0\xee\xef\xef\xef\xf0\xef\xef\xee\xee\xee\xee\xee\xed\xee\xef\xed\xec\xee\xed\xed\xed\xed\xed\xec\xed\xeb\xec\xec\xec\xec\xec\xeb\xeb\xec\xeb\xec\xeb\xea\xeb\xea\xea\xeb\xea\xe9\xe9\xea\xea\xe9\xe9\xea\xe9\xe9\xe9\xe9\xe8\xe9\xe7\xe8\xe9\xe9\xe9\xe7\xe8\xe8\xe7\xe8\xe7\xe8\xe8\xe6\xe7\xe7\xe7\xe7\xe7\xe8\xe7\xe8\xe6\xe5\xe5\xe6\xe5\xe5\xe6\xe6\xe7\xe5\xe4\xe6\xe5\xe6\xe5\xe5\xe4\xe4\xe4\xe4\xe4\xe4\xe4\xe3\xe4\xe3\xe3\xe4\xe2\xe4\xe3\xe4\xe3\xe3\xe3\xe3\xe3\xe3\xe2\xe0\xe2\xe1\xe2\xe1\xe1\xe2\xe2\xe2\xe1\xe2\xe2\xe2\xe1\xe0\xdf\xe1\xe0\xe0\xe0\xdf\xe0\xe0\xe0\xe0\xde\xdf\xe0\xde\xdf\xdf\xde\xde\xde\xdf\xde\xdd\xdf\xdf\xde\xdd\xdd\xde\xde\xdd\xdd\xdd\xdd\xdd\xdd\xdc\xdc\xdc\xdd\xdc\xdd\xdd\xdc\xdd\xdb\xdb\xdd\xdb\xdb\xda\xdb\xdc\xdb\xda\xda\xdc\xdb\xdc\xdb\xda\xda\xdb\xda\xda\xd9\xda\xda\xd9\xd9\xda\xd9\xd9\xda\xd8\xd8\xd9\xd9\xd9\xd9\xd8\xd9\xd8\xd7\xd7\xd8\xd7\xd6\xd8\xd6\xd8\xd8\xd7\xd8\xd7\xd6\xd6\xd6\xd7\xd5\xd6\xd6\xd5\xd6\xd5\xd6\xd5\xd5\xd6\xd6\xd5\xd5\xd5\xd4\xd5\xd4\xd4\xd4\xd5\xd4\xd4\xd3\xd4\xd4\xd3\xd4\xd4\xd2\xd4\xd3\xd3\xd3\xd2\xd2\xd2\xd2\xd1\xd1\xd2\xd2\xd2\xd2\xd1\xd4\xd2\xd1\xd2\xd0\xd1\xd1\xd0\xd0\xd2\xd0\xd0\xd1\xd1\xd1\xd0\xd0\xd0\xd0\xd0\xcf\xce\xcf\xcd\xcf\xcf\xcf\xce\xce\xcf\xcf\xcf\xcf\xcf\xcf\xce\xcd\xce\xce\xcd\xce\xcd\xcd\xcc\xcd\xcd\xcd\xcd\xcd\xce\xcd\xcc\xcc\xcc\xcb\xcc\xcb\xcb\xcb\xca\xcb\xcb\xcb\xcb\xcc\xcb\xcb\xcb\xca\xca\xca\xca\xc9\xca\xca\xca\xca\xc9\xca\xca\xca\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc8\xc8\xc8\xc8\xc8\xc9\xc8\xc8\xc8\xc8\xc7\xc8\xc9\xc7\xc7\xc7\xc7\xc7\xc6\xc6\xc7\xc6\xc7\xc6\xc7\xc5\xc6\xc4\xc5\xc6\xc5\xc6\xc5\xc5\xc5\xc5\xc6\xc6\xc6\xc4\xc6\xc4\xc5\xc4\xc4\xc4\xc3\xc3\xc3\xc3\xc4\xc4\xc3\xc3\xc3\xc5\xc2\xc3\xc3\xc2\xc3\xc3\xc3\xc4\xc3\xc2\xc2\xc2\xc2\xc2\xc1\xc2\xc1\xc2\xc2\xc2\xc2\xc1\xc1\xc2\xc1\xc2\xc0\xc0\xc1\xc0\xc1\xc1\xc0\xc1\xc1\xc0\xc0\xc0\xc0\xc0\xbf\xc0\xbf\xbe\xbe\xbf\xbe\xbe\xbe\xbf\xbf\xbe\xbe\xbe\xbf\xbe\xbe\xbd\xbe\xbe\xbd\xbe\xbc\xbc\xbc\xbd\xbd\xbc\xbc\xbd\xbd\xbd\xbc\xbc\xbc\xbc\xbd\xbc\xbb\xbd\xbb\xbb\xbc\xbc\xbb\xbc\xbb\xbb\xba\xbb\xbb\xbb\xbb\xba\xbb\xba\xba\xba\xbb\xb9\xba\xbb\xba\xbb\xb9\xb9\xba\xba\xb9\xb9\xb9\xb9\xb8\xb9\xb8\xb9\xb8\xb8\xb9\xb8\xb7\xb8\xb8\xb7\xb8\xb9\xb7\xb9\xb8\xb8\xb7\xb6\xb7\xb8\xb7\xb9\xb7\xb7\xb7\xb7\xb7\xb7\xb7\xb6\xb7\xb7\xb6\xb6\xb6\xb5\xb5\xb6\xb5\xb5\xb6\xb5\xb5\xb4\xb6\xb5\xb5\xb5\xb4\xb6\xb4\xb5\xb4\xb5\xb5\xb4\xb4\xb4\xb3\xb5\xb3\xb3\xb3\xb4\xb3\xb3\xb4\xb3\xb3\xb3\xb2\xb3\xb3\xb3\xb3\xb2\xb3\xb2\xb2\xb2\xb2\xb2\xb2\xb2\xb1\xb2\xb2\xb1\xb2\xb2\xb1\xb3\xb1\xb1\xb2\xb1\xb1\xb0\xb2\xb1\xb0\xb0\xb0\xb1\xb0\xaf\xb0\xb0\xb0\xb1\xb1\xb0\xaf\xaf\xb0\xaf\xad\xb0\xaf\xaf\xaf\xb0\xaf\xaf\xae\xae\xaf\xae\xaf\xae\xaf\xae\xae\xad\xaf\xaf\xaf\xae\xae\xad\xae\xad\xae\xae\xad\xad\xad\xad\xad\xad\xad\xac\xad\xad\xad\xac\xad\xad\xac\xab\xad\xac\xac\xac\xab\xac\xab\xac\xac\xac\xac\xac\xab\xab\xab\xac\xac\xab\xac\xab\xab\xaa\xaa\xaa\xab\xab\xaa\xaa\xa9\xa9\xab\xab\xaa\xaa\xaa\xaa\xa9\xa9\xa9\xaa\xaa\xaa\xa9\xa9\xa8\xa9\xa9\xa9\xaa\xa9\xa9\xaa\xaa\xa8\xa8\xa8\xa9\xa8\xa8\xa8\xa8\xa8\xa8\xa8\xa8\xa7\xa8\xa8\xa9\xa9\xa7\xa8\xa6\xa8\xa8\xa8\xa8\xa7\xa6\xa6\xa6\xa7\xa7\xa7\xa7\xa7\xa7\xa7\xa7\xa7\xa6\xa6\xa6\xa6\xa6\xa5\xa6\xa7\xa5\xa5\xa6\xa5\xa5\xa5\xa6\xa4\xa6\xa5\xa5\xa6\xa5\xa5\xa4\xa5\xa6\xa4\xa5\xa4\xa4\xa5\xa4\xa4\xa5\xa5\xa5\xa5\xa6\xa4\xa4\xa5\xa5\xa4\xa3\xa3\xa4\xa3\xa4\xa4\xa3\xa3\xa4\xa3\xa3\xa2\xa3\xa3\xa3\xa4\xa3\xa3\xa3\xa3\xa4\xa4\xa1\xa4\xa3\xa2\xa2\xa4\xa2\xa2\xa1\xa2\xa3\xa2\xa1\xa2\xa2\xa1\xa2\xa1\xa3\xa2\xa2\xa2\xa1\xa1\xa1\xa1\xa2\xa2\xa1\xa2\xa1\xa0\xa1\xa0\xa1\xa1\xa0\xa0\xa0\xa0\xa1\xa1\xa1\xa1\xa1\xa1\xa1\xa0\xa0\xa1\x9f\xa0\xa0\xa1\xa1\xa0\xa0\xa0\x9f\xa0\x9f\x9f\xa0\x9e\x9f\x9f\x9f\xa0\x9f\x9e\x9f\x9f\x9f\x9e\x9f\x9f\x9f\x9f\x9f\x9f\x9f\x9e\x9e\x9f\x9e\x9f\x9e\x9e\x9e\x9f\x9e\x9d\x9f\x9d\x9d\x9d\x9e\x9f\x9e\x9c\x9e\x9d\x9e\x9e\x9d\x9d\x9e\x9e\x9d\x9d\x9e\x9e\x9c\x9e\x9d\x9c\x9d\x9d\x9d\x9d\x9c\x9d\x9c\x9c\x9c\x9d\x9c\x9c\x9c\x9c\x9d\x9b\x9b\x9d\x9b\x9c\x9b\x9d\x9d\x9c\x9c\x9b\x9b\x9c\x9b\x9b\x9c\x9b\x9c\x9a\x9b\x9b\x9c\x9b\x9b\x9c\x9a\x9b\x9b\x9b\x9b\x9b\x9b\x9b\x99\x9a\x9b\x9c\x9b\x99\x9c\x9b\x9a\x9b\x9b\x9b\x9a\x9b\x9b\x9b\x9a\x99\x9a\x9a\x9a\x9a\x9a\x99\x99\x98\x9a\x9b\x9a\x99\x9a\x99\x99\x9a\x99\x99\x9a\x99\x98\x99\x99\x9a\x99\x98\x9a\x99\x99\x9a\x9a\x98\x99\x99\x9a\x98\x99\x99\x99\x98\x98\x99\x99\x9a\x98\x99\x99\x9a\x99\x98\x98\x99\x99\x98\x99\x98\x98\x98\x99\x97\x99\x99\x98\x97\x97\x97\x96\x98\x97\x98\x98\x97\x98\x97\x98\x98\x97\x97\x97\x97\x99\x97\x97\x96\x97\x97\x98\x97\x97\x97\x98\x98\x97\x97\x98\x97\x98\x97\x97\x97\x97\x96\x97\x96\x96\x96\x96\x96\x98\x98\x97\x97\x96\x97\x95\x94\x96\x95\x95\x96\x97\x97\x96\x96\x95\x96\x97\x96\x96\x96\x96\x96\x96\x97\x97\x96\x95\x96\x96\x96\x95\x95\n'
I think I got, that the \xnn items are the data. But the start seems to be awefully corrupted. With width set to 2, the result is very similar, the "good" datapoints are seperated by \x00 items, while the corrupted items take the form \x00P.
Also, if the datapoints are rightly interpreted, \xff should be the maximum value, but on the curve corresponding to the posted output, the maximum of the curve is at the leftmost corner of the screen, so also the order of the items seem to be messed up.
Questions being:
- Does anybody know the source of corruption?
- Am I interpreting the data right? If so, how do I sort it properly along the time axis?

Dave W
Tektronix Applications
Tektronix Applications
Posts: 266
Joined: April 26th, 2010, 12:01 pm
Country: United States

Re: Faulty/corrupted RIBinary data // Python-usbtmc-TDS2004b

Post by Dave W » April 11th, 2016, 12:10 pm

Hi Bbelonder,

If you set the data width to 2 then you need to take into account that you have the byte order set correctly with the WFMPre:BYT_Or command. On Intel/Windows based systems you would normally use LSB. You will need to determine what order is required for your Raspberry Pi.

As for the data itself, be sure you are parsing it correctly. Binary trace data is always returned with an ascii format block header at the start of the data. #<byte count length><byte count><data bytes>

<byte count length> is a single ascii character that tells you the length of <byte count> in bytes. <byte count> is 1 or more ascii characters that tell you the length of <data bytes> in bytes. After <byte count> bytes, the instrument will output a termination character ('\n'), an extra byte beyond the <byte count> bytes.

When you print the returned data to the console in Python, byte values in the data that fall within the range of printable ASCII characters will be displayed as those printable characters. Byte values that fall outside of that range will be shown as hex value \x<hex value>.

When you parse the returned data you will want to first remove the block header from the data (#<byte count length><byte count>). You then want to move through the rest of the data, byte by byte, and perform some arithmetic on each byte to scale the raw byte value into a floating point value that represents the measured voltage value. Every byte in the data (assuming a byte width of 1) represents a single sample's Y-value (voltage). The scope does not return X-values (time). To get the corresponding x-values you need to calculated them yourself by reading from the scope what the horizontal scale settings were.
You can get the values you need by querying HORizontal:POSition?, HORizontal:SCAle? and HORizontal:RECOrdlength? If you take the scale and multiply it by 10 (for the 10 divisions on the screen), this will get you the overall length of time the record covers. If you then take this result and divide it by the recordlength, this will get you the time per point, or how far apart in time each sample is. For simple graphing, you can then just start your x-values at 0 and increment the value of each x-value by the calculated time per point value. If you want your graph to look more like the scope screen, then you will have to account for the horizontal position value when calculating your x-values.

Hope this helps!

Bbelonder
Posts: 2
Joined: April 11th, 2016, 7:46 am
Country: Germany

Re: Faulty/corrupted RIBinary data // Python-usbtmc-TDS2004b

Post by Bbelonder » April 12th, 2016, 2:37 am

EDIT2:
alright, I just got the return correctly interpreted. Python returns a bit array but prints it in a very strange matter.
Hopefully last question: is it normal, that when the width is set to 2, every other byte is 0, there's no sign to the integers and the max value is 255 (With either binary encoding setting)?
If you set the data width to 2 then you need to take into account that you have the byte order set correctly with the WFMPre:BYT_Or command. On Intel/Windows based systems you would normally use LSB. You will need to determine what order is required for your Raspberry Pi.
Alright, I just checked that, but it doesn't seem to make too much of a differencs, data looks pretty much the same with MSB and LSB on, except for the order of NULL characters (which are before or after the data bits).
As for the data itself, be sure you are parsing it correctly. Binary trace data is always returned with an ascii format block header at the start of the data. #<byte count length><byte count><data bytes>

<byte count length> is a single ascii character that tells you the length of <byte count> in bytes. <byte count> is 1 or more ascii characters that tell you the length of <data bytes> in bytes. After <byte count> bytes, the instrument will output a termination character ('\n'), an extra byte beyond the <byte count> bytes.
I checked that aswell, at least for ~10-30 datapoints everything seems to work fine in terms of the number of transmitted data points (at least, if you account for the printed ascii characters to be datapoints)
Do i have to interprete the printed Ascii characters as follows from Appendix A: ASCII Code Chart p A-1 tek Programmer's Manual? Meaning a printed "a" in the console equals a dec value of 97?

The time scaling is not too much of a problem, i was merly wondering, if I'm interpreting the hexvalues right. Meaning that \xff would represent 255

Edit: Before I forgeet: Thanks so much for your fast and kind reply! I do honor the effort you're putting into this

Dave W
Tektronix Applications
Tektronix Applications
Posts: 266
Joined: April 26th, 2010, 12:01 pm
Country: United States

Re: Faulty/corrupted RIBinary data // Python-usbtmc-TDS2004b

Post by Dave W » June 2nd, 2016, 2:17 pm

When you set the width to 2, every data point is returned as a 16-bit (2-byte) value. If the acquisition mode in use only produces 8-bit values then the data returned will only be using the upper 8 bits of the 16-bit value so the lower order byte will always be 0, hence every other byte is 0. The default acquisition mode is Sample which only produces 8-bit data. The average acquisition mode produces 16-bit values. If you use this mode, you will not see a 0 value byte every other byte, but rather the averaging will cause the scope to fill the lower order byte as well.
I checked that aswell, at least for ~10-30 datapoints everything seems to work fine in terms of the number of transmitted data points (at least, if you account for the printed ascii characters to be datapoints)
Do i have to interprete the printed Ascii characters as follows from Appendix A: ASCII Code Chart p A-1 tek Programmer's Manual? Meaning a printed "a" in the console equals a dec value of 97?
You shouldn't need to interpret any ASCII characters. The data returned by the "raw_bin=TDS.read_raw()" call is a binary data string. When you print it to the console, python shows ASCII characters in the console only because the byte values have an ASCII printable equivalent, not because those bytes are any different from the others; they are still just binary values. Being that they are still just binary values, your code should not treat them any differently. Just perform the arithmetic on them as you would any other byte in the binary string.

Post Reply

Return to “Programming Support”

Who is online

Users browsing this forum: No registered users and 5 guests