Ublox GPS incoherent data output

Paul Hoshovsky

New Member
Greetings

I have a UBLOX GPS device (bought in Jan 2015) mounted on the GPS010 board. I am using a 3.3 VDC power supply.

I could not get the 18M2 to read anything from this device. So I connected a USB/Serial adaptor to my PC and made the connection to UBLOX GPS via RS232 voltage level shifters (5V <->3.3V) . I used RealTerm and found out that the data stream output from the UBLOX was not in ASCII. The baud rate was 9600. The data stream from the device was consistent in that a large block of data was sent every 1-2 seconds. That block of data is shown in the attached file.

I then started the U-Center software. This software detected the COM port. I also selected the autobauding feature which did not help. It could not connect to the GPS unit. The red icon at the lower right hand of the window began blinking and remained in this mode 'forever' (until I stopped the U -center software). The connection icon on the top left hand was green (only to tell me the software found the COM port).

I have sent this query to Ublox 13th April 2015 and as yet do not have a reply from them.

Is there some way to reset this device to get it back to normal?

Regards
 

Attachments

hippy

Technical Support
Staff member
Welcome to the PICAXE Forum.

What serial cable are you using and how did you create your voltage converter ?

It could be that the polarity is inverted which may explain why the terminal output is less than meaningful and the U-Center software is unable to communicate with it.
 

srnet

Senior Member
I would not jump to the assumption that the GPS is faulty in some way.

A USB\Serial adapter, the type with a 9 pin D connector on it, which is what you can use use to program a PICAXE, will be the wrong serial polarity.

The same is true of an AXE027 program lead, as supplied its the wrong serial polarity to connect to a GPS.
 

neiltechspec

Senior Member
You need a USB2Serial TTL adapter, I use CP2102 based units (I have 3 of them).

I've also got 6 of those UBLOX modules (5 NEO-6's and 1 NEO-M8) and have no issues setting them up through U-Center.

Neil.
 

Paul Hoshovsky

New Member
Ublox GPS

Greetings

Thanks for the quick response from everyone.

The USB serial adaptor is the 'standard' type using the Prolific driver. This adaptor receives data when the 18M2 is transmitting out its serial port. The 18M2 is running at 3.3 VDC and yet the adaptor has no problem accepting the data stream from the 18M2. The level shifter data sheet is attached. I will look at the the inverted voltage situation.

Regards
 

Attachments

srnet

Senior Member
The USB serial adaptor is the 'standard' type using the Prolific driver. This adaptor receives data when the 18M2 is transmitting out its serial port. The 18M2 is running at 3.3 VDC and yet the adaptor has no problem accepting the data stream from the 18M2.
There really is not a 'standard' USB serial adapter.

However if the one you have receives SERTXD data from the 18M2, its the wrong polarity and you need the other 'standard' type of driver to read the GPS.

Do bear in mind that its possible to send both inverted and non-inverted serial data from the 18M2, we have no way of knowing which you are using.
 
Last edited:

eggdweather

Senior Member
Try this:
setfreq m8
Data_in:
'Use the qualifier "$GPGGA" to input the GGA NMEA sentence.
bptr = $50
Serin 0, T4800_8,("$GPGGA,"),@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc

Then get your bytes from the memory address $50 onwards
 

Paul Hoshovsky

New Member
Greetings

Many thanks to Srnet and Eggdweather for their insights. I ran the code from Eggdweather with two changes. I removed the qualifier and changed the baud rate to T9600_8. This change provided a data stream - which was a relief as I was not sure that the unit was functioning.

What now is the question is getting GPGGA data from the unit. I am getting GPRMC, GPVTG, GPGSV, GPGLL and GPGSA messages but no GPGGA. I have made a valiant attempt to read u-blox6_ReceiverDescriptionProtocolSpec to find out what commands I need to sent to the UBLOX to get the GPGGA message. I admit to be overwhelmed by the sophisticated manual. I suppose that the command I need to send is in that manual but I dont readily see it.

my code snippet is listed next. the serin command with the qualifier does not sent any data to the terminal window. The line without the qualifier does.


;Serin [2000,main], B.3, T9600_8, ( "$GPGLL," ), @bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,_ ;;; no data is received with qualifier. next line does work.

Serin [2000,main], B.3, T9600_8, @bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,_
@bptrinc,@bptrinc ,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,_
@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc, @bptrinc,@bptrinc,@bptrinc,_
@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,_
@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,_
@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc,@bptrinc

FOR bptr = 30 TO 78
SERTXD(@bptr)
NEXT bptr
SERTXD(ret,lfeed)

below is the data stream.


$GPRMC,205623.00,A,2609.00513,S,02806.28692,E,0.0
&[89][89][89][89])r[CA][9A]b[82]r[CA][CA]b[8A]r[B2][B2]R[82]25$GPGSV,3,1,12,04,03,258,,
i[CA]b[AA][CA]b[9A][AA][9A]bR[BA][1A]5$GPGLL,2609.00513,S,02806.28692,E,
$GPRMC,205624.00,A,2609.00508,S,02806.28692,E,0.0
&[89][89][89][89])r[CA][9A]b[82]r[CA][CA]b[8A]r[B2][B2]R[82]25$GPGSV,3,1,12,04,03,258,,
i[CA]b[AA][CA]b[9A][AA][9A]bR[BA][1A]5$GPGLL,2609.00508,S,02806.28692,E,
$GPRMC,205625.00,A,2609.00504,S,02806.28694,E,0.1
&[89][89][89][89])r[CA][9A]b[82]r[CA][CA]b[8A]r[B2][B2]R[82]25$GPGSV,3,1,12,04,03,258,,
i[CA]b[AA][CA]b[9A][AA][9A]bR[BA][1A]$GPGLL,2609.00504,S,02806.28694,E,
$GPRMC,205626.00,A,2609.00500,S,02806.28692,E,0.1

One point that is 'obvious' is that the GPGLL data packet is incomplete and has been interrupted by the GPRMC command. Also there is no leading comma before the $GPGLL. it is possible that I am printing too few/many characters to the terminal window.

I would welcome any more insights on this situation.

Thanking you in advance.
 

srnet

Senior Member
One point that is 'obvious' is that the GPGLL data packet is incomplete and has been interrupted by the GPRMC command. Also there is no leading comma before the $GPGLL. it is possible that I am printing too few/many characters to the terminal window.
The data stream does not make sense, the GPS does not put out a pile of square brackets, so where are they coming from ?

You should not need to turn on the GPGGA sentance, it goes out by default.

I would strongly recommened you use a 28X2 or 40X2, the background serial capability makes what you are trying to do a whole lot easier.
 

eggdweather

Senior Member
All of the GPS units I have used including UBLOX cycle around the GPS sentences, so it's a matter of waiting for the GPGGA one to come around and you need to add the qualifier ("$GPGGA,") because I suspect you are not getting back to read the GPS before the next sentence arrives and then you miss it. I think the default update frequency is 1/sec although the ublox can update at 20Hz or every 100mS. Printing out your 50 characters will take ~60mS so that's one limitation plus some command overheads before your routine can get back for the next sentence.

See this in the manual: "If the amount of data configured is too much for a certain port's bandwidth (e.g. all UBX messages
output on a UART port with a baud rate of 9600), the buffer will fill up. Once the buffer space is
exceeded, new messages to be sent will be dropped."

I was using 4800baud and the update rate was 1/sec so I had plenty of time, I think your may be configured for more data output and you can't read it fast enough leading to dropped messages. You should try to slow the unit down a bit and use a different time-out value.
 

srnet

Senior Member
Ah maybe you were using the PE terminal with the display non ASCII as HEX, in which case something is wrong, the GPS does not put out non-ASCII anyway.

However the method you are using to get at the GPGGA sentence is flawed, the sequence of sentences that are sent by the GPS could mean that you always miss the GPGGA.

What you do need to do is disable all bar two sentences, say only have GPRMC and GPGGA coming out.

I would then wait for the GPRMC, as a qualifier, and as soon as that is received, start the serin again with a $ as a qualifier, you then stand a chance of getting the GPGGA data as you have 5 characters before the data starts. You could also configure the GPS to have only GPGGA coming out.

There is no &#8216;leading comma&#8217; for a NMEA sentence, one sentence terminates with a carriage return, then the next character is a $ for the start of the next sentence.
 

hippy

Technical Support
Staff member
The Terminal displays readable ASCII characters but translates non-readable characters to [XX]. Getting those, in what should be an entirely readable character stream, suggests there is data corruption going on. Possibly the PICAXE not running fast enough to keep up with the data stream.
 

Paul Hoshovsky

New Member
Greetings

Thanks for the response. I had thought about the output speed from the Ublox being too high as well. The example1.bas found at the picaxestore (http://www.picaxestore.com/index.php/en_gb/gps010.html) did mention the change in baud rate. So at the time, I was more interested in getting some output from Ublox unit. Anyway.. I did the following:

I reduced the number of values inputted with serin to 7 values and printed only those to the serial terminal window. The data stream was confused

[89] [82][82][82]R[BA][00]
,28,23,[00]
r[C2][8A]b[8A]r[9A][00]
,30,247[00]
i[8A][C2]b[92][C2]b[00]
Y[B1]4,2,1[00]
L&i[82]b[8A][92][00]
7*71
$[00]
[89][82]b[92][9A]b[8A][00]
33,33,2[00]
&i[CA]b[AA][CA]b[00]
0179,S,[00]
b[B1]D*73[00]
$GPRMC,[00]
i[C5][82][92][C2][82][B2][00]
,,,D*68[00]
r[82][C2][A2]bZ[00]

Clearly this was not quite what I needed so I extracted from the example1.bas the statement that reduces the baud rate to 4800. I am not so sure that this is correct.

serout b.2, T9600_8 ,( $B5, $62, $06, $00, $14, $00, $01, $00, $00, $00, $D0, $08, $00, $00, $C0, $12, $00, $00, $07, $00, $03, $00, $00, $00, $00, $00, $CF, $E4 )
sertxd("Baud rate changed to 4800",13,10)

I changed the serin to read at 4800_8 and the output was

[FF][F6][F4][F2][F6][D2][FF][F8][F8][FC][F9][FC][F8][F8][F8][F8][F8][F8][F9][F9][F8][FC][FC][F9][F1][FD][FC][F8][D2][FF][F7]
[FC][F9][F4][FE][F9][FE][F1][F4][FE][FB][F4][FE][F4][F6][FF][F8][F4][F4][F1][F2][D2][FF][F1][FE][F9][F4][FE][F9][F4][FF][FC]
[F6][FF][F8][F4][F0][F1][F2][FC][F4][FF][F9][FC][D2][FF][F4][F4][F5][F9][F8][F9][FC][F8][F1][FD][F8]

I revisited the UBlox manual ReceiverDescriptionProtocolSpec and on page 127 CFG-PRT is described. I looked at UART variant of this data packet and on page 129 there is a mention of the data byte size, parity and stop bit. On page 128 it states that the baud rate starts at 8 bytes offset (presumably at $08, $00, $00, $C0 in the statement above) and is in bits per second. I am sure that 4800 baud = 4800 chars/sec and each char is 8 bits + one start bit + one stop bit = 10 bits per char. So I get 48000 bits per second. That value in hex is BB80 which does not look like the value given in example1.bas.

Once again, I am open to suggestions. I understand Srnet's comment of getting a 28x2 or 40x2. Had I known that the 18m2 was not quite to the task, then it would have advisable to note that limitation on the web page for the GPS010.

Thanks
 

srnet

Senior Member
Once again, I am open to suggestions. I understand Srnet's comment of getting a 28x2 or 40x2. Had I known that the 18m2 was not quite to the task, then it would have advisable to note that limitation on the web page for the GPS010.
Thanks
I dont recall anyone saying the 18M2 was not up to the task.

The published code on the GPS010 web page is for the 20X2, but I dont see why it would not work with the 18M2, assuming changes are made for the different default operating frequencies.

Did you try the sample GPS010 code, it has the stuff for reducing the GPS baud rate to 4800, and how to turn off the unwanted sentances ?

The X2 PICAXES do however have the ability to run background receive, and you can run the GPS at high speed, without dropping characters.
 

hippy

Technical Support
Staff member
I do not recall the exact format of the commands sent to the uBlox but they were tested so would say that whatever is in the example is correct.

The problem with corrupt serial data is often that, when characters arrive back-to-back, the PICAXE has to have dealt with the last to be ready for the next. If it is not it can subsequent characters can be corrupted.

The ways round that are to run the PICAXE faster (SETFREQ), decrease the baud rate ( allowing the PICAXE more stop bit time to deal with the last received ) or to use background serial receive buffering available with the X2's.

As you appear to be running at 8MHz the simplest option is to jump straight to 32MHz and adjust the baud rate suffixes appropriately.
 

neiltechspec

Senior Member
For reliable serial I/O using serout & serin on M2 chips, I have found the following gives reliable comms.

2400 baud, clock at 4mhz (default)
4800 baud, clock at 8mhz
9600 baud clock at 16mhz
19200 baud, clock at 32mhz

I have never had any comms issues with M2 chips talking to ublox GPS's @ 9600 baud when clocking at 16mhz.

Neil.
 

Paul Hoshovsky

New Member
Greetings

I am getting somewhere at last.

Before going forward to changing the clock speed as has been suggested, I thought it would helpful for others to learn from my experiences today.

As we know, the Ublox requires 3.3V. To communicate to the RealTerm serial program, the voltages from the RX and TX lines of Ublox must be raised to 5 V. This I did with a logic level converter. The output signals, now at 5VDC, are sent to the FTDI USB card known as

USB-serial TTL PCB,3.3V,FT232RQ,TTL-232R

As noted by SRnet and NeilTechSpec, you cannot use the 'standard' USB to serial port adaptor. Even if you use the 'standard' unit coupled to the logical level converter, it will not work. What does work is the FTDI unit. A note of caution. The manual for this unit is incomplete. The hookup sketch left me in confusion as the manual does not tell you which pads are what. After nagging the local RS Electronics supplier, I got a photo from FTDI that shows clearly what is what. I have attached a PDF showing who is in the zoo. Note that the FTDI device will provide 5V despite the title suggesting 3.3V. Use the 5 V supply to drive the logic level converter.

The natural follow-on was the Ublox u_center software was able to communicate with the device!

the next step is speed!

Thanks to all
 

Attachments

srnet

Senior Member
Glad your making progress.

There are FTDI adapters that can be switched to 3V3 mode, although not all do.

The PICAXE AXE027 (5V) lead uses an FTDI, and if you use the FTDI config program to invert the serial polarity on this lead you can connect it to a Ublox GPS, just use a 22k resistor between the FTDI TX and Ublox RX.
 

Paul Hoshovsky

New Member
Greetings

Yes it was timing. Not quite where I had expected though...

the UBLOX unit starts transmitting the moment power is applied. What it sends is not readable. At my end of the planet, it takes up to 2 minutes for sensible data to be issued. There is a subtle point about hotstarts and coldstarts which, although useful to know, I ignored and just waited 2 minutes.

I had a moment of success in which I managed to change the default baud rate from 9600 to 4800. That worked for a while and then I must have done something... and well, it remained unchanged at 9600 baud. I found that the U_center software will display the binary strings shown in EXample1.bas. I was able to select the feature CFR_PTR to change the baud rate and get the identical byte string shown in Example1. bas

another thing that I discovered was the interaction between the Serial terminal baud rate and the M2 clock frequency. If the setfreq is set to M32 then the baud rate of the serial terminal (#terminal 38400) had to increase.

By setting the clock frequency to M32, I was able to input the lengthy strings for $GPGGA and parse it to get the time, lat, long and elevation. at the M8 rate, it was too slow.

I was also able to send the byte strings shown in Example1.bas to suppress the unwanted NEMA messages.

Thanks to everyone for their insights.

regards

I attach the code that does work.
 

Attachments

srnet

Senior Member
The UBLOX unit starts transmitting the moment power is applied. What it sends is not readable. At my end of the planet, it takes up to 2 minutes for sensible data to be issued.
At startup, the UBLox does send the apprpriate NMEA sentances as normal, but since it has no lock then most of the fields are empty\null so a lot of fields dont display.

This is part of the problem with reading GPSs, the fields although in a standard sequence do vary in length, both between lock and no lock and between different models of GPS. So if your looking for the fix character ("A" for GPRMC) its actual position in the full NMEA sentance can vary from one GPS to another.
 
Last edited:

MPep

Senior Member
So if your looking for the fix character ("A" for GPRMC) its actual position in the full NMEA sentence can vary from one GPS to another.
Actually, the location doesn't change. The RMC sentence is 'set' as per the following:

EG:

$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A

Where:
RMC Recommended Minimum sentence C
123519 Fix taken at 12:35:19 UTC
A Status A=active or V=Void.
4807.038,N Latitude 48 deg 07.038' N
01131.000,E Longitude 11 deg 31.000' E
022.4 Speed over the ground in knots
084.4 Track angle in degrees True
230394 Date - 23rd of March 1994
003.1,W Magnetic Variation
*6A The checksum data, always begins with *

But here:

$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47

Where:
GGA Global Positioning System Fix Data
123519 Fix taken at 12:35:19 UTC
4807.038,N Latitude 48 deg 07.038' N
01131.000,E Longitude 11 deg 31.000' E
1 Fix quality: 0 = invalid
1 = GPS fix (SPS)
2 = DGPS fix
3 = PPS fix
4 = Real Time Kinematic
5 = Float RTK
6 = estimated (dead reckoning) (2.3 feature)
7 = Manual input mode
8 = Simulation mode
08 Number of satellites being tracked
0.9 Horizontal dilution of position
545.4,M Altitude, Meters, above mean sea level
46.9,M Height of geoid (mean sea level) above WGS84
ellipsoid
(empty field) time in seconds since last DGPS update
(empty field) DGPS station ID number
*47 the checksum data, always begins with *

As can be seen in the GGA sentence, the position along the sentence of the Fix Quality is fixed in the 6th location between the ,,. However, if counting from the $ the number of characters, then yes it can and will change, depending of there is a position fix, the number of decimal places of the Lat/Long etc.
 

srnet

Senior Member
Actually, the location doesn't change. The RMC sentence is 'set' as per the following:

EG:

$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
It does change !!!!

Some GPS will display the start of the GPRMC as;

$GPRMC,123519.000,A,

Note the actual position of the "A" has changed because the length of the time field is diferent between two GPSs.
 
Top