Decode data stream to ASCII characters

Hi there,

I have an oscilloscope readout of a serial communication (NMEA from a GPS). I need to decode the signal into ASCII characters without running the stream through any hardware. I have attached a snippet of the signal, and how should I initialize the decoding?

The GPS I'm using is a Linx RXM-GPS-SR (https://www.electro-tech-online.com/custompdfs/2013/01/RXM-GPS-SR_Data_Guide-19336.pdf), and the default settings are baud=9600, data=8 bits, stop=1 bit and no parity.

Should the decoding begin from the falling edge and then 1/9600 seconds ahead for the first start bit and then detecting the level of each interval. Or is it the direction of the edge?

According to the datasheet, the first characters should be $GPGGA..., but I can only get the $ using the level of each interval. Can anyone spot the problem? Thanks

Sorry but your screen dump from the scope is a bit incomprehensible, just a band of bits.

The $ character is 24 in Hex, which gives a binary bit pattern of 0010 0100 with bit 0 at the RHS of the pattern and bit 7 at the LHS.

Whan viewed on a scope, the characters will be written from the left of the screen, so the bit pattern will be 0010 0100 with bit 7 at the RHS of the pattern and bit 0 at the LHS.
Oh dear! it is a symetrical character!
If you are decoding it the wrong way round it will still make sense, but none of the other characters will make sense.

Have a look at the attachment, I have sent a $ character using Hyperterminal on the PC, and recorded it on my scope.
This is an RS232 output, so a "1" is a negative voltage and a "0" is a positive voltage.
The comms set-up is 9600baud, 8 data bits, 1 stop bit, no parity.

The scope was triggered on the rising edge of the start bit.

Does this help?

JimB

here is my code to detect 232, it only detects the first edge since the start bit is always the same value, @9600baud detect every 100us afterwards, my code is @300baud now so change the 3.33ms wait to 100us


it sounds like your timing is off just abit, so it is lined enough for the first bit but dis-aligns for the rest, also if you try using edge detection on each bit it wont work since two zeros in a row wont display an edge in between,

also if you are interested in just testing the gps, you can always just hook in to a serial port and set up data terminal software, i have similar gps too that puts out the $GPG codes too, and thats how i tested mine,

my code is in basic, but should be easy for you to convert, the first loop loads 9 BYTES to an array then takes its time in the second loop to load the array to eeprom

loop b loads the bits to a byte
loop a loads the byte to array
rotate val right command is same as: val=val/2;




...but how are you decoding? if you are not using hardware?

Electronics4you said:

...
Should the decoding begin from the falling edge and then 1/9600 seconds ahead for the first start bit and then detecting the level of each interval. Or is it the direction of the edge?
...

Click to expand...

Ideally you start timing on the first edge of the start bit, then wait a 1.5 baud period (which puts you in the middle of bit0) then detect the level of that bit. Then 7 baud periods, each is the next bit, and finally a stop bit (which should always be high) which shows you your baudrate and timing were probably ok.

Thanks, it was the 1.5 I had forgotten, but still the data is not right. I get the '$' but then an 'â', which should be 'G' or 'P' according to the datasheet
After the stop bit (a high), I look for the next falling edge and proceeds as before (1.5 baud forward etc...)
I don't know why the data should be wrong. The GPS provides a data block every 1 second for around 300 ms.
Does the 'â' character make any sense in NMEA?

Yes, like I said earlier, you are reading the characters the wrong way round, ie from MSB to LSB rather than LSB to MSB.

G = 47hex = 01000111 binary

â = E2 hex = 11100010 binary

JimB

Is this an academic exercise? Are you trying to build a UART? Read the data sheet for any PIC that includes UART hardware. It does a really good job of explaining the process of capturing the data steam, and how to decode it...

Agreed! Or just invert the data using one NPN transistor and a couple of resistors, and feed it into the PC serial port, then simply use hyperterminal (or any of the better free terminals from the 'net) to view the decoded serial data.

@JimB: I missed the LSB/MSB point because - I think the symmetric character confused me again.

@MikeMI: No, it is not an exercise, but for the moment I need to decode oscilloscope samples.

It works now. Thanks again.

Mr RB said:

Agreed! Or just invert the data using one NPN transistor and a couple of resistors, and feed it into the PC serial port, then simply use hyperterminal (or any of the better free terminals from the 'net) to view the decoded serial data.

Click to expand...

Hola Roman,

Aren't we talking of reading the bits in the reversed order instead of inverted?

atferrari said:

Aren't we talking of reading the bits in the reversed order instead of inverted?

Click to expand...

Both, the main culprit was reversed order, but also RS232 has the levels inverted compared to TTL UART, so to be able to read it in PC you need some level converter.

kubeek said:

Both, the main culprit was reversed order, but also RS232 has the levels inverted compared to TTL UART, so to be able to read it in PC you need some level converter.

Click to expand...

I see. The necessity of converting escaped to me. Gracias.