Adafruit Ultimate GPS Breakout

jaybeetoo

New Member
I recently bought an Ultimate GPS Breakout http://www.adafruit.com/products/746 with the MTK3339 chipset.

I couldn't find any documentation for use with the PICAXE so I've been playing around with it. The factory default setting is 9600 baud. The only PICAXE pins I could get to work with the GPS were hserin/hserout. Any other pins just produced garbage. I assume the chip can't keep up with the 9600 baud from the GPS.

The problem with hserin is you can't look for input starting with a string (e.g. "$GPRMC") like you can with serin. I got around this problem by linking hserout on the PICAXE to the Rx pin on the GPS and linking the GPS Tx pin to an In pin (e.g. B.0) on the PICAXE.

I then changed the baud to 4800 from my program which meant the PICAXE could keep up with the GPS and I could then use serin.

This code shows you what I mean.....

Code:
hsersetup B9600_8, %10000		        ; GPS serial output (input not used)

hserout 0,("$PMTK251,4800*14",CR,LF)	; Slow GPS output down to 4800 baud so I can use serin command

serin B.0, T4800_8, ("$GPRMC"), b0, b1, b2, b3, b4, .......etc.     ; Read NMEA $GPRMC sentence from GPS
I can now just read the NMEA sentences I want.

I hope this information will save other people many hours of head scratching.
 
Last edited:

g6ejd

Senior Member
If you search the forum, you will find using examples using @bptr, where you can read GPS at that speed OK and use the filter too.
 

Goeytex

Senior Member
The Picaxe has problems with a setting of 9600_8. At 9600_8, the actual serout baud rate is < 9200 and serin is looking for data at ~10100 baud. This is too far off specification for many devices. In fact, two Picaxe 20x2 chips cannot communicate with each other at 9600_8. Not a single byte.

If you want to use serin /serout at 9600 baud then set the Picaxe to M16 and use T9600_16.

[The information in this post is out of date and not accurate. Only older 20X2 firmware had a slow 9600 baud, and this is fixed in current release 20X2 parts (firmware C.3)].
 
Last edited by a moderator:

srnet

Senior Member
One of the issues with reading the GPS string into a sequence of variables (assuming you have enough!) is that field sizes can vary, so you may not get the data in the variables you expect.

With the background receive option of the X2s, you can just run it for a couple of seconds, stop it, and then go searching in the scratchpad for the $GPGGA or whatever. It works and you dont need a heap of spare variables.
 

jaybeetoo

New Member
If you search the forum, you will find using examples using @bptr, where you can read GPS at that speed OK and use the filter too.
I tried serin with variables, @ptr and @bptr at 8M and 16M - none of them worked.

The only way I could get it to work was to use hserin or reduce the baud rate to 4800 on the GPS.
 

Jeremy Harris

Senior Member
Yes, the 9600 baud serin gotcha can cause a fair bit of head scratching, it certainly had me doing the same a year or so ago, when trying to get reliable comms to a couple of hardware serial devices.

Once you know the work arounds (as mentioned above) things become a lot simpler. Apart from the speed error, I think there's also a slight issue with the Picaxe software serial port code not quite being fast enough to process one byte before the next arrives, unless the Picaxe clock speed is increased. I found this when trying to get the VDrive2 USB module working, the VDrive2 responds very quickly to a command and the Picaxe would miss the first byte or two unless I used the hardware serial port.
 

jaybeetoo

New Member
One of the issues with reading the GPS string into a sequence of variables (assuming you have enough!) is that field sizes can vary, so you may not get the data in the variables you expect.
I agree and thank you for pointing that out. I used variables just for the code example - I'm actually using the scratchpad in my program.
 
Top