This is data taken from DSO with usb.....

SC92F7323 microcontroller is used in display which is receiving this data and there are total 97 bits including start bit.

 

Is that 97 bits per TEK file or 97 bits across all the files?

 

Is that 97 bits per TEK file or 97 bits across all the files?

97 bits per frame including start bit

 

Files TEK0000 - TEK0008 have 2500 samples at 20uS = 50mS, or about 15 bits at 3mS/bit, so they are only snippets of a message. TEK0000 AND TEK0001 both give DC DC, I've not looked at the others. TEK0009 has no content. TEK0010 - TEK0015 (but not TEK0013) are sampled at 100uS so give about 0.25s of data, though again only snippets.

TEK0010 gives F8 80 00 DC DC DC 00 DC DC DC (but no complete start bit)
TEK0011 gives DC C4 F0 01 01 B8 79 B9 01
TEK0012 gives D? DC DC C4 F0 01 01 B8 79
TEK0013 gives C? F0 01 (its only 0.1 sec long)
TEK0014 gives D? 00 DC DC DC DC C4 F0 01 ?1
TEK0015 gives D? DC DC C4 F0 01 02 70 F3

So, your data capture isn't consistent but at least we can see the data is in line with the spec (other than its little endian but the spec makes no mention of that).

 

Hello Everyone, I am currently working on a EV project which has a Chinese UART based Protocol. which is used to transmit various data like speed, RPM, Errors etc to display.

Almost appears to be the form of Modbus used by some of the Chinese VFD units, They use RS485 and either RTU or ASCII code.
.

 

Files TEK0000 - TEK0008 have 2500 samples at 20uS = 50mS, or about 15 bits at 3mS/bit, so they are only snippets of a message. TEK0000 AND TEK0001 both give DC DC, I've not looked at the others. TEK0009 has no content. TEK0010 - TEK0015 (but not TEK0014) are sampled at 100uS so give about 0.25s of data, though again only snippets.

TEK0010 gives F8 80 00 DC DC DC 00 DC DC DC (but no complete start bit)
TEK0011 gives DC C4 F0 01 01 B8 79 B9 01
TEK0012 gives D? DC DC C4 F0 01 01 B8 79
TEK0013 gives C? F0 01 (its only 0.1 sec long)
TEK0014 gives D? 00 DC DC DC DC C4 F0 01 ?1
TEK0015 gives D? DC DC C4 F0 01 02 70 F3

So, your data capture isn't consistent but at least we can see the data is in line with the spec (other than its little endian but the spec makes no mention of that).

Yes sir data is not consistent.. manually i have tried to calculate i have got F8 80 00 DC bytes \... i will try to get consistent data and upload it

 

OK, here's an Arduino sketch that works and one that simulates a VFD. Run them on two Arduino's linked GPIO2 to GPIO2.

Simulator takes keyboard input from Arduino IDE serial monitor of 1 - 12 bytes; case, white space and non-hex is ignored, so 0 1 2 fxx 4E is same as 012F4E and will be transmitted, little endian, as 01 2F 4E. An odd number of valid characters will ignore the last one, ie 01234 will transmit as 01 23.

 

With the Chinese VFD's I have worked with, the last two bytes are checksum.
Help to know the model No. ?

 

With the Chinese VFD's I have worked with, the last two bytes are checksum.
Help to know the model No. ?

According to the spec in post #1, only the last byte is a checksum. With enough real data examples the calculation method can be identified. Maybe the TS has the model #.

 

OK SIR let me

OK, here's an Arduino sketch that works and one that simulates a VFD. Run them on two Arduino's linked GPIO2 to GPIO2.

Simulator takes keyboard input from Arduino IDE serial monitor of 1 - 12 bytes; case, white space and non-hex is ignored, so 0 1 2 fxx 4E is same as 012F4E and will be transmitted, little endian, as 01 2F 4E. An odd number of valid characters will ignore the last one, ie 01234 will transmit as 01 23.

ok sir let me check...

 

According to the spec in post #1, only the last byte is a checksum. With enough real data examples the calculation method can be identified. Maybe the TS has the model #.

Here is the doc provided by manufacturer