Serial data format - start bits

[Mr S]

I am trying to read NMEA GPS data from a module and am slowly trouble shooting issues!

I am now able to recieve data using "Serin" but have not yet actually received anything intelligable. I am recieving TTL level serial data (I can see it on the oscilloscope) but the picaxe will not read it as intelligable ascii. Having re-consulted the data sheet for the GPS module it is supplied in the following format:

9600baud, 8 data bits, 1 start, 1 stop, no parity.

I can see that the picaxe will support 9600 baud, 8 data bits, 1 stop and no parity but I cant see anything anywhere (I havent managed to find any timing diagrams) about start bits.

Does anyone know if I can configure the picaxe to read this data format or am I out of luck with this module?

Cheers,
Darryl

 

[jmumby]

I haven't seen your code but if you made the same mistake as me you will have something like this.

start:
serin 1,t2400,b0
sertxd (b0)
goto start

The pic is not fast enough to grab a byte display it and turn around and grab another so it gets a partial byte this is your garbage.

try.......

start:
serin 1,t2400,b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10
sertxd (b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10)
goto start

And see if you at least get those bits, also start with a qualifier.

If this does not work then I would suggest you have a baud problem. The ABSOLUTE best investment when working with serial is a MAX232 serial adapter. Look at the picaxe manual under serial circuits there is a MAX232 circuit there (I used 10uF capacitors) slap a MAX232 on some variboard half a dozen capacitors and a DB9 plug and you have the perfect serial trouble shooter. The picaxe terminal is good as you can click through all the bauds on one screen

I have three serial devices connected to a 28x1 and with out my MAX232 I would have given up ages ago.

 

[Mr S]

Will try those ideas, many thanks,

Darryl

 

[westaust55]

in another thread you say:

I am trying to read in GPS (GPRMC) data from a WD-G-ZX4120 GPS module. The device outputs RS232 at 9600baud and I am trying to read this on an 18X overclocked at 8MHz and reading in at 4800baud which i think should work out OK.

RS232 involves inverting the data for reading into a PC.

I also got caught out initially with this for keypad serial data entry recently.

Note that you are also using the command setfreq m8 to get the 9600 baud rate.

In your case, try using:

serin 1, [B]N[/B]9600_8, b0

 

[moxhamj]

Re jmumby "The ABSOLUTE best investment when working with serial is a MAX232 serial adapter"

and westaust55 "RS232 involves inverting the data for reading into a PC."

The Max232 inverts the data so this may well be a solution. It is a single chip with 4 capacitors.

Another option is to read it into a PC rather than a picaxe. At least then you can change baud rates and parity and stop bits etc easily in code and prove it works. Any of the free .net languages will work, as will simple things like hyperterminal.

 

[jmumby]

I might clear things up a bit here.

I have only used to the MAX232 to connect directly to the PC i.e picaxe out of the loop to see what is coming out. ala serial GPS.

Your data sheet (assume this the NEMERIX gps) states TTL so you should not have to use a MAX232 between the Picaxe and the GPS, in this case you will use T.

If you want to try a MAX232 between the GPS and Picaxe you will need to use N. I am not sure how you would do this as I assumed that the MAX232 is supposed to up the voltage to UART level +-25v but Im guessing.

If you have the GPS connected to the picaxe directly now and get garbage you may want to fluff around with setfreq as well.

 

[moxhamj]

Ah, the perils of RS232. With both GPS to PC and GPS to picaxe, you can have control over the polarity, either N or T. The picaxe programmer for instance runs straight into the picaxe and you can change from programming mode to running mode just by moving the serial input from the programming pin to an input pin and still use serout from pin 0 as it is. This assumes a protocol where zero is 0V and high is 5V, and this translates to an RS232 of low is -12V and high is +12V. (I don't think it goes up to +/-25V, but no doubt RS232 receivers can handle that).

So if you want a "poor man's" RS232, use the 10k/22k network for the PC Tx to picaxe on any serial input pin including the programming pin, and run the picaxe to PC directly.

If you want real RS232, the usual protocol is to use something like a Max232 at both ends, or 1488/89 chips (these latter chips are still available and they do work out cheaper than a Max232, though they need a -12V supply). So, the protocol starts out with 0=low and 5V=high, the max232 inverts the signal, and the max232 at the other end inverts it again so the data comes out in the same polarity.

The confusion can arise when you only have one max232 in the system - is the data inverted or not? It almost is worth writing some vb.net code to go through all the baud rates and all the polarity and stop bit combinations and work out which one works. There are so many combinations. I once resorted to reading ascii characters off a CRO trace.

 

[maitchy]

Note that, although nobody changes the number of START bits in RS232 transmissions, the trick is to add STOP bits (same thing, really). But even with 2 stop bits many systems (for a picaxe to a VAX) can get swamped with the speed of input from some devices unless they buffer enough incoming data (via an interrupt routine).

Once you know you have the signals connected correctly (TxD of your GPS to serial in) with the correct polarity, baudrate, parity and handshaking (i.e. whatever handshaking lines your GPS requires to be high, e.g. Clear-To-Send wired to Request-To-Send perhaps), then you should at least be able to get some bytes being received correctly. The next step is to make sure the slow serial input of the picaxe doesn't miss any important bytes - it has to do its processing when no data is coming, or at least no important data. That requires knowledge of the GPS interface protocol (and a bit of playing with different picaxe serial reception methods). Lastly, you need to work out how to recover from starting to receive a string of bytes in the middle - how do you recognise the start, and re-synchronise?