Change ublox 6 GPS baud rate? Anyone?

#1
Hello,
I have a ublox 6 GPS with a 20x2 chip. The default baud rate is 9600. It's a bit slow. I've tried to change the baud rate with

Code:
setfreq m32
 pause 200
 serout GPSRX, baud, ("$PUBX,41,1,0007,0003,19200,0*25")
 debug
 pause 500
 debug
 serin GPSTX, T19200_32,("$GPRMC,"), b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10
 debug
The 3rd debug never runs. So, at 19200, I don't get any data. But, if I change it back to 9600 I get data. So, my PUBX line never changed the GPS baudrate.

Anybody have any idea how to change a ublox GPS baudrate?

Thanks,
Norm
 

srnet

Senior Member
#2
You might want to try adding a CR & LF to the end of the $PUBX strings, otherwise the GPS will not know when the incoming command has finished ?

But of more interest why is you think 9600baud is slow, why does it need to be faster ?
 
#3
Thanks for the reply. I changed code to this,
serout GPSRX, baud, ("$PUBX,41,1,0007,0003,19200,0*25,CR,LF")'added CR & LF
debug
pause 500
debug
serin GPSTX, T19200_32,("$GPRMC,"), b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10
and no data on the serin line. I built a GPS speed pulse generator. But, the time it takes to talk to the GPS receiver slows my pulse down (It leaves my pulse loop to talk to the GPS). So, if I can't speed up GPS communication I'm thinking of adding another chip to just send out the pulse and talk to the chip hooked to the GPS. But, I'd rather keep it simple, if I can.

Norm
 

rossko57

Senior Member
#4
Sending the five-character character string "CR,LF" is not the same as sending the single control character CR followed by character LF.
Luckily they are defined as constants within PE, so I think you can do
... "your string",CR,LF
 

bpowell

Senior Member
#6
There is also a UBLOX configuration utility...I configure my GPS receivers with that...that way I don't have to deal with configuration from the microcontroller.
 

srnet

Senior Member
#7
Try;

serout GPSRX, baud, ("$PUBX,41,1,0007,0003,19200,0*25",CR,LF)

But not sure why you even want to change it, 9600baud is plenty fast.
 

srnet

Senior Member
#8
There is also a UBLOX configuration utility...I configure my GPS receivers with that...that way I don't have to deal with configuration from the microcontroller.
Maybe so, but not all Ublox GPSs can actually store the configuration.

You can store the config in the GPS on some varients and on others you can connect an external I2C EEPROM, but most often they forget the config when the power is lost.
 
#10
Thanks a lot. I got this to work,
serout GPSRX, T9600_32, ("$PUBX,41,1,0007,0003,57600,0*25",CR,LF)'set to 57600 baud rate
debug
pause 2000
serin GPSTX, 57600,("$GPRMC,"), b0,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10''''read 57600 baud rate
debug
To use ublox utility, do I need a cable or can I just use the picaxe cable. Or, is it straight USB TX,RX to GPS TX,RX.

Thanks,
Norm
 
Last edited:
#12
I have a electric power steering unit. But, it is at full power all the time, making steering twitchy at high speeds. It takes a pulse input to dampen the amount of power steering. So, I used a ublox GPS speed to create a pulse. Now, at higher speeds the amount of power steering is reduced.

My problem is that getting speed data from the GPS takes too long, which interrupts my pulse. The fastest baud rate I've been able to establish is 19200. Here is a code sample,
symbol baud = 19200

do
pulsout SteeringPulse,400
gosub GetSpeed'''''this takes too long''''''
toggle greenLED
pause 1'SteerDelay'frequency of pulses
loop

GetSpeed:
ptr = 0
serin GPSTX, baud, ("$GPVTG,"), @ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr '''this is what takes too long''''

'get speed code....
return
I think I'm ready to give up and use 2 chips. One to talk to the GPS and another to send a pulse. Unless, there is a way to run a loop in the background on a 20x2 chip while another loop queries the GPS, without affecting the other loop. Any ideas?

Thanks,
Norm
 
#15
I think I'm ready to give up and use 2 chips. One to talk to the GPS and another to send a pulse.
It's not the first time I read this kind of solution...
But, the GPS chip have to send data to the Pulse chip. Via a serial link ?
==> The Pulse chip will do a serin(...) to read data... With the same causes producing the same effects, this will take to long...
====> I suggest a third chip to read data from the first one...
=======> etc...
But you can use parallel link between to 2 Picaxes and write/read data very fast.

Is there a way to run a loop in the background on a 20x2 chip while another loop queries the GPS, without affecting the other loop ?
YES : but you need to use the dedicated hardware serial.
Have a look to HSERSETUP and HSERIN (background receive...)
 
Last edited:

bpowell

Senior Member
#17
So, you got the command working to change the baud to 19.2, but it still is too slow?

I think the slowness might be in the receiving / parsing of the data. I don't think the HSERIN will help you there...if I recall, the 20x2 only has a 2-character buffer...so you're still going to have to deal with the serial data in near real-time.

What about using something else to determine your speed...maybe tapping into whatever signal drives the speedometer? Or, looking at some kind of a pulse-counter and a hall-effect sensor to monitor wheel RPM?
 

hippy

Technical Support
Staff member
#18
Or is the long delay simply that the GPS only puts out a message at that rate. You may read it faster and faster by increasing the baud rate, but if it's only outputting every second you'll only generate a pulse every second.

You could use a timeout on SERIN but a 1ms timeout is pretty short and you may end up missing messages.

It might be possible to use background serial receive to accept and parse the GPS data and generate the pulses at the same time. A dual PICAXE system would likely be easier if you are satisfactorily reading the GPS with SERIN.
 

hippy

Technical Support
Staff member
#20
I think you need to tell us what the characteristics of this pulse you need to generate are.

You may be able to generate it with background PWMOUT which will keep running while a SERIN is waiting for the GPS speed message. You can then simply update the pulse frequency and duty as required by the last message.
 

AllyCat

Senior Member
#21
Hi,

Yes, we particularly need to know the period (and acceptable tolerance) of the "pulses". The pusle width appears to be 400 ms (or perhaps 400 / 8 = 50 ms) which is probably too long for background PWM. Most GPSs report their major data elements with an exactly 1 second period, but some can be configured up or down from there and also some of the more "minor" data strings may be transmitted less frequently.

One possibility might be to "wrap" the pulse around the serial data with HIGH and LOW commands (and suitable attention to timing delays), but if it's an X2 then background HSERIN seems the obvious solution.

Cheers, Alan.
 

srnet

Senior Member
#22
Or is the long delay simply that the GPS only puts out a message at that rate
Thats close to the problem. GPS by default put out many different sentences, so you may have to wait around quite a while for the right one to come along.

Like most GPSs you can turn off the sentences on the Ublox that you dont want, and alter the rate per second too.

All explained in the Ublox manual, and they also provide a nice utility to change the config and monitor the results.
 

srnet

Senior Member
#25
I have just been building a portable receiver that I can use to log (to an Openlog card) GPS data sent from a Ublox equipped tracker. I will use it to check the reliability of the tracker (and GPS) when I take the tracker for long drives. This is not a safety critical application at all, but the effort is required to make sure the tracker software is reliable.

I have done a fair bit of this type of testing aleady and you do see occasional drop outs with the GPS, plus sometimes extended first fix times at initial power on.

If the 'pulses' stop for whatever reason, say at high speed, does the steering revert to 'twitchy mode' ?

I am surprised a GPS is considered for the application of feeding speed pulses to control the steering of a vehicle, is it a common approach ?
 
Top