Select to expand quote

sailquik said..
This is a bit of a surprise to me becasue I thought the signal strength used to be displayed for SBN files as well. I need to go back to some older files and check them when I get some time.

Or you could look at the source code for GPS Babel for a description of the SBN data structures. The relevant info is in navilink.h. The only satellite-specific info in it is:

UINT32 SVIDList; /* SVs in solution: Bit 0=1: SV1, Bit 1=1: SV2, ... , Bit 31=1: SV32 */
UINT8 SVIDCnt; /* Number of SVs in solution [0 to 12] */

Select to expand quote

sailquik said..
But it seems that the Mac version of GPS-Results doesn't not display this data.

Yes, the Mac version of GPSResults is unfortunately very crippled. There are many things that can be done only in the Windows version (including changing how error estimates for speed categories are calculated, by averaging or "Gaussian propagation".

Select to expand quote

sailquik said..
But I think your thinking on Gaussian error propagation is flawed. The error has to be Random. Symmetrical is not random. IMHO, the math is not invalid.

When evaluating the GT-31 data many years back, Manfred Fuchs had concluded that the data were filtered with a time-constant somewhere in the several-seconds range, and that therefore, "Gaussian error propagation" can not be used to estimate the error. GPSResults therefore uses averaging rather than standard deviations to calculate the +/- numbers for 1 Hz GT-31 data. This is certainly the proper way for all short categories (2 seconds, 10 seconds, 100-500 m).

The same logic needs to be applied to data from newer chips. Instead of stating that "The error has to be Random", the actual data need to be analyzed. It is very easy to find examples where the error is clearly non-random, especially in regions where the accuracy is not great (SDoP > 0.8). Here is one example from the first couple of traces I looked at, where the error is correlated for 1.5-2 seconds (~ 8 points in 5 Hz data):


The blue line and left columns are Locosys data, the red line/right columns are ublox data. Both show rather strong evidence of strongly linked errors even at 5 Hz.

You are actually correct in saying "the math is not invalid". You can certainly calculate the standard deviation for data with random and non-random errors. However, you have to be very careful about what conclusions you draw from the numbers you get. In particular, the conclusion that higher-rate data are more accurate just because the "+/-" numbers you get will be lower will be wrong if your data have characteristics like those shown in the graph above. There was a perfect example of this when Roo posted 18-Hz results in 2016 (www.seabreeze.com.au/forums/Windsurfing/Gps/18hz-GPS-units?page=1).

Manfreds conclusions about the GT-31 filtering were a matter of debate at the time. In the end we decided to err on the side of conservatism for that device.

All parties, including Manfred,consulted regarding the newer devices agreed that 'Gaussian error propagation' is valid for the higher Hz devices where filtering effect is not evident.

Happy to see more data for 10Hz ubx that proves I'm wrong though. All the data I have now sindicates 'Gaussian error propagation' is valid for both GW52/69 and ublox M8 multi GNSS ubx <10Hz

On a lower key, I'm in the middle of updating the pi zero. What a neat little machine!

Select to expand quote

decrepit said..
On a lower key, I'm in the middle of updating the pi zero. What a neat little machine!

I agree! booted mine up for the first time today during my lunch break, will start going through the very basics and then getting a serial GPS interface sorted and other hardware over the coming weeks.

At the moment I'm trying to get samba to work so I can copy Peters Program in. Will also be useful when I get round to downloading data

Select to expand quote

decrepit said..
At the moment I'm trying to get samba to work so I can copy Peters Program in. Will also be useful when I get round to downloading data

I had no problems getting the file sharing to work on one of my Pies, but the second one required a bit of fiddling. That was on the Mac, though.

The SD card from the Pi has one partition (root, I think) that is formatted so Windows and Macs can read it. One way to use it is by creating a file with the WiFi info on it so you can access a Pi without a monitor. You may also be able to use it for file transfer. But samba etc. is definitely easier.

Well I've got your stuff on it simply by downloading from your site.
But I have a problem with samba, there's no /etc/init.d/samba file. But I've a few things to try tomorrow

Select to expand quote

sailquik said..
Happy to see more data for 10Hz ubx that proves I'm wrong though. All the data I have now sindicates 'Gaussian error propagation' is valid for both GW52/69 and ublox M8 multi GNSS ubx <10Hz

For both the GW52/60 and ublox chips, errors looks reasonably random if the accuracy is high (SDoP/sAcc below ~ 0.8 kn). But if the accuracy is not good, then both Locosys and ublox units will routinely display biased (non-random) error over longer periods. I have shown pictures with examples many times, for example:
boardsurfr.blogspot.com/2018/02/the-disappointment.html (ublox)
boardsurfr.blogspot.com/2018/01/speed-deltas.html (GW-60)
boardsurfr.blogspot.com/2017/05/60-knots-new-speedrecord.html (GW-60)
boardsurfr.blogspot.com/2017/05/the-fastest-way-get-faster.html (GW-60)
boardsurfr.blogspot.com/2017/05/overstating-speed-by-4-knots.html (GPSTC data)

I often posted links to the posts and/or relevant pictures on this forum.

If you always mount your GPS units on your helmet, rarely crash, and never sail mountain lakes, all your data probably has high accuracy, so you may never see these issues. But anyone who uses the GW-60 on their wrists, or crashes on a regular basis, or uses any device on an arm band, will probably have such areas in their tracks. They can lead to artificially high speeds (check the last two links above for examples). Unless the errors are very large, or you're carefully comparing the tracks from two units, the problems will generally not be obvious.

If Gaussian error propagation is appropriate, the the "+/-" values (which are two standard deviations) should describe a 95% confidence interval. When comparing data from two devices, the ranges would be expected to overlap ~90% of the time, and not overlap less than 10% of the time. In the data Roo had posted, 40% of the ranges for 10-second runs did not overlap. That's a rather strong indication that the error estimates are overly optimistic. One likely cause are coupled (i.e. non-random) errors.

Finally got Samba working! Apparently the repository was updating it when I was trying to install it. That lead me in circles for a couple of days, but The computer can now talk to the pi.
Next step is to try and connect the serial to usb converter.
Am I right in assuming that RX and TX are crossed over between the GPS module and the converter?

Select to expand quote

decrepit said..

Am I right in assuming that RX and TX are crossed over between the GPS module and the converter?

You can try it and find out. If the GPS is already setup to stream data, it will be sending something. If the baudrates don't match it will probably look like gibberish.

Alternatively, instead of using the Rpi, connect the adapter to a PC for the initial testing and use something like PuTty to connect to the adapter, and see if you can communicate with the module. If not, reverse tx and rx.

Select to expand quote

FormulaNova said..
>>>>> Alternatively, instead of using the Rpi, connect the adapter to a PC for the initial testing and use something like PuTty to connect to the adapter, and see if you can communicate with the module. If not, reverse tx and rx.

Great idea I have to do that anyway to set up the module. But I'll probably swallow my pride and boot into windows and use the ublox software.

Select to expand quote

decrepit said..

Great idea I have to do that anyway to set up the module. But I'll probably swallow my pride and boot into windows and use the ublox software.

The logging software will configure the essential GPS parameters (protocol and rate). You don't need the ublox software unless you want to use a non-standard satellite mix or similar.

On the Pi, you can use the terminal program minicom to see what the GPS + adapter are sending. Use
dmesg | grep tty
before and after connecting the USB adapter to see where to connect to. Typical dongle ports are /dev/ttyACM0 and /dev/ttyUSB0

Then start a terminal and type:
minicom -D /dev/ttyACM0
Change the /dev/ttyACM0 if necessary.

Thanks Peter,
I've a bit to do to my new board today, but I'll probably get round to soldering this arvo

Soldering done, but no success Pi reboots when I connect module, but stays on when I disconnect.
Also of course I don't have a USB hub, so don't have mouse/keyboard when dongles is connected.
No file created in "PiLogger"

So installed minicom on this computer, plugged the dongle in here and got this. I guess it hasn't been configured so don't know how meaningful this is. So may go back to the windows thing and see if that will connect.

michael@Mate:~$ dmesg | grep tty
[ 0.000000] console [tty0] enabled
[ 2587.742440] usb 1-1.1.1: cp210x converter now attached to ttyUSB0
michael@Mate:~$ minicom -D ttyUSB0
minicom: cannot open ttyUSB0: No such file or directory
michael@Mate:~$

I realised what the "i" after of RX and "o" after TX stand for on the converter, receive in and transmit out. So assuming RX and TX on the module was the same, I've crossed over those wires.

Select to expand quote

decrepit said..


So installed minicom on this computer, plugged the dongle in here and got this. I guess it hasn't been configured so don't know how meaningful this is. So may go back to the windows thing and see if that will connect.

michael@Mate:~$ dmesg | grep tty
[ 0.000000] console [tty0] enabled
[ 2587.742440] usb 1-1.1.1: cp210x converter now attached to ttyUSB0
michael@Mate:~$ minicom -D ttyUSB0
minicom: cannot open ttyUSB0: No such file or directory
michael@Mate:~$

You forgot to use the '/dev' directory.

"minicom -D /dev/ttyACM0"

so, you need to use /dev/ttyUSB0 in your minicom line.

Also, serial comms has never been easy because they started with the concept of RX to RX and TX to TX, with one device being the terminal and the other the computer. So, it all depends on what each device considers itself to be.

If it was RS2323 (i.e. something like +12v and -12v) you would use a breakout box to see what line is the TX line, but in the end you just end up swapping them if they don't work anyway. Thank goodness people don't use a lot of serial control lines these days. What fun that was, working out what each device expects to see in order to communicate and what it changes when it doesn't want to receive any more.

FormulaNova said,

Select to expand quote

You forgot to use the '/dev' directory.

Thanks Formula, can I blame this on getting old???? I'm certainly missing things a lot more these days.

That gives this with the device plugged in
Welcome to minicom 2.7

OPTIONS: I18n
Compiled on Feb 7 2016, 13:37:27.
Port /dev/ttyUSB0, 19:41:31

Press CTRL-A Z for help on special keys
----------------------
and this when I unplug it.

Welcome to minicom 2.7

OPTIONS: I18n
Compiled on Feb 7 2016, 13:37:27.
Port /dev/ttyUSB0, 19:36:08

Press CTRL-A Z for help o+-----------------------------+
| |
| Cannot open /dev/ttyUSB0! |
| |
+-----------------------------+

So the computer is seeing the converter, ok, but how do I see the GPS module?
And pressing CTRL -A Z just shrinks the screen.

First thing to check is if the LED on the GPS module is on. Usually a solid red light indicates power, and blinking (green?) indicates a GPS fix.

If the GPS module has power, try swapping the Rx-Tx lines.

The next things to try is specifying the baud rate for minicom, and to run it as sudo. I never had to do either, but that may have been luck. The commands to try would be:
"minicom -D /dev/ttyUSB0 -b 9600"
and
"minicom -D /dev/ttyUSB0 -b 115200"

If you still get nothing, check in the chip configuration in ucenter on Windows. To see something in mini com, the default config (NMEA at 1 Hz) is easiest. Make sure to save the config to the chip in the configuration window if you had to change it.

Thanks Peter, one red light was on the module. So I'll try swapping RX, Tx

Select to expand quote

decrepit said..
Thanks Peter, one red light was on the module. So I'll try swapping RX, Tx

If it helps any the GPS module I first tried had a default of 38400 bps, but it was a module meant for a drone. I also have the same module as you do but I haven't tried them yet.

Undid the crossover so RX goes to RX and TX goes to TX, but still no luck.
And Samba has stopped working on the Pi.
This is certainly not a plug and play approach.
I've ordered a dongle so I can compare what should happen with what I get, I'm starting to suspect a problem with the converter.

So swapping the wires did make a difference, when I connect with minicom I get a single red light on the converter, when I close minicom that light goes out.
Before I had two constant red lights on the converter. I'll see if I can find some data on it to see what it should do.

I also took the module and Pi outside to see if getting a fix made any difference, so saw the flashing green light OK, but Pi didn't turn off when I disconnected the module and there was no new file in PiLogger.

I just figured out that to connect with the u-box software you need to specify the connection, but I only had a choice of two and neither worked. Could that be why I didn't get anywhere yesterday? I didn't try selecting a source.

Just found some info on the converter module, seems like I may have to add a driver.

The board is calling again, so I'll try that later.

Select to expand quote

decrepit said..
Undid the crossover so RX goes to RX and TX goes to TX, but still no luck.
And Samba has stopped working on the Pi.
This is certainly not a plug and play approach.
I've ordered a dongle so I can compare what should happen with what I get, I'm starting to suspect a problem with the converter.

So swapping the wires did make a difference, when I connect with minicom I get a single red light on the converter, when I close minicom that light goes out.
Before I had two constant red lights on the converter. I'll see if I can find some data on it to see what it should do.

I also took the module and Pi outside to see if getting a fix made any difference, so saw the flashing green light OK, but Pi didn't turn off when I disconnected the module and there was no new file in PiLogger.

I just figured out that to connect with the u-box software you need to specify the connection, but I only had a choice of two and neither worked. Could that be why I didn't get anywhere yesterday? I didn't try selecting a source.

A simple trick with serial comms is that you loop the rx to the tx at the adapter/comm port. This means that everything you type is echoed back to your terminal program (minicom), or if you have local echo turned on (unlikely these days) you get two of each character echoed back to you. This will tell you if the adapter is working or not. This won't harm anything.

This works regardless of baud rate, so it removes that from the equation.

A good way to work out comm ports is to open your serial program, in this case u-box software, and then check out the ports that it thinks are available BEFORE you plug in the usb to serial adapter.

Note the comm ports that it finds.

Then insert the USB to serial adapter, wait a minute at most, and then check the serial comm ports that now show up in that section of u-box. If it is detecting the adapter, a new port will show up, and that's the one you need to use.

If you have the wrong baud rate, you will get gibberish, or nothing, depending on the baud rates that are used.

I might get off my backside and go check the same modules that you are using to see what they default to for the baud rate. It was 38400 for the other one, so who knows.

I just soldered up one of the gps modules. It will be the same as the one you have if you bought from the link Daffy provided.

This one has defaulted to 9600 bps, so i would assume that's normally what they will be out of the box.

What was labelled as TX on the GPS connects to my USB adapter's RX, which conveniently has an arrow to suggest its an input.

Are you sure you are powering the GPS with 3.3v? I noticed that Jaycar sell a USB to serial adapter that uses 5v even when you switch to 3.3v. I am using a freetronics one and have never had a problem with it.

Oh yeah, it also started sending NMEA packets straight away without any need to change any configs.

I have noticed that the red light on the GPS module is always on when its powered up. The green led lights up when it sends data, which looks to be every second. In my house, the GPS modules seem to work inside, but having a tiled roof may be the reason for that.

Select to expand quote

FormulaNova said..
>>>>> Are you sure you are powering the GPS with 3.3v? I noticed that Jaycar sell a USB to serial adapter that uses 5v even when you switch to 3.3v. I am using a freetronics one and have never had a problem with it.

Oh yeah, it also started sending NMEA packets straight away without any need to change any configs.

I have noticed that the red light on the GPS module is always on when its powered up. The green led lights up when it sends data, which looks to be every second. In my house, the GPS modules seem to work inside, but having a tiled roof may be the reason for that.

No I thought that vcc on the gps module went straight to the onboard 3.3v regulator. You think maybe I should use the 3.3v regulator on the converter and use that instead of the +5v

Yes my RX is RXi with an arrow and TX is TXo with an arrow, that's why I was confident there was a crossover.
So I'll swap them back and use the 3.3v output after I've got the board ready for glassing tomorrow morning.

Select to expand quote

decrepit said..

FormulaNova said..
>>>>> Are you sure you are powering the GPS with 3.3v? I noticed that Jaycar sell a USB to serial adapter that uses 5v even when you switch to 3.3v. I am using a freetronics one and have never had a problem with it.

Oh yeah, it also started sending NMEA packets straight away without any need to change any configs.

I have noticed that the red light on the GPS module is always on when its powered up. The green led lights up when it sends data, which looks to be every second. In my house, the GPS modules seem to work inside, but having a tiled roof may be the reason for that.

No I thought that vcc on the gps module went straight to the onboard 3.3v regulator. You think maybe I should use the 3.3v regulator on the converter and use that instead of the +5v

Yes my RX is RXi with an arrow and TX is TXo with an arrow, that's why I was confident there was a crossover.
So I'll swap them back and use the 3.3v output after I've got the board ready for glassing tomorrow morning.

Just so its clear, looking at my GPS module, the TX is an output and the RX is an input. In my case the TX from the GPS is going to the RX with the input arrow on the USB adapter.

I hadn't thought to check the voltage requirements for the module itself. I understand that the ublox module is 3.3v (or around that anyway), but not 5v tolerant as far as I am aware. My USB to serial adapter can supply 5v or 3.3v and I have just left it set to 3.3v from when I was playing with the other m8n meant for use in drones. It certainly works as I have left it running since I first connected it up, and all I have done since is change the baud rate to 115200, and its still working. The 3.3v is just feeding straight into VCC on the GPS module.

Is there a regulator on the GPS module? If so, it seems to be okay with me feeding it 3.3v, which is strange... I will see if I can find its specs. Just a cursory glance doesn't seem to show a typical 3 terminal regulator package, but it could as easily be something else...

I just checked, and the ebay listing suggests the M8N can take 2.7 to 3.6v. It doesn't list a separate spec for the board, so I am assuming that it has no onboard regulator.

Don't be surprised if its fine though. Some devices can tolerate overvoltage, for a time.

If you are lucky you might only be running into a problem with the voltage levels between the USB to serial adapter not quite matching. My adapter is set to 3.3v, and it all works.

Edit: I looked up some diagrams for these using Google, and they seem to show a LDO to supply the 3.3v. Some circuits show the input as 5v into the LDO, so it looks like that's what it handles. Hopefully if it sees 3.3v it doesn't drop that much ;-) From what I just read, it sounds like it will drop 0.1v at 3.3v input, so its all good.

Even though you feed it 5v from the usb to serial converter, the uart on the M8N is going to be expecting signals within the range of the supply voltage which is 3.3v. Maybe that's part of the problem? (yet another edit: my board looks like it has some level shifter on the RX input to the GPS, so maybe it is 5v tolerant)

This is where I say, suck it and see if it works at 3.3v Vcc. This runs the serial converter at 3.3v.

If I were you and I was still having problems, I would go back to windows and set it up there first. Once you know it streams data there, you know the config is fine and the voltage is fine.

Thanks formula,

Yep, I have much the same thoughts. I've downloaded the converter driver for windows, so when I've finished here, I'll give that a go.
I have gone back to crossover and connected vcc to 3.3v.

I found some data on my conversion module and it has 3 leds, power on, data in and data out. But I can't find any info on which is which.

So I'll be back later with the next instalment.

Select to expand quote

decrepit said..
Thanks formula,

Yep, I have much the same thoughts. I've downloaded the converter driver for windows, so when I've finished here, I'll give that a go.
I have gone back to crossover and connected vcc to 3.3v.

I found some data on my conversion module and it has 3 leds, power on, data in and data out. But I can't find any info on which is which.

So I'll be back later with the next instalment.

If you managed to understand my last posts, which I had a few redo's of, it seems that these modules do have 3.3v LDO regulators. If you feed them with 3.3v, they output 3.2v, which is fine. I also noted that on the board the RX input has a resistor and something else inline, so its probably tolerant of 5v logic from the converter. The TX doesn't but 3.3v logic generally falls into the acceptable range for 5v logic anyway.

But, I know the 3.3v works, so I will stick with that. It also means that when I connect to a lithium ion battery in the future it will work the same. My Arduino setup runs at 3.3v.

To be honest, you should be able to power up the GPS module, and it should straight away stream data at 9600bps. Just swap the TX from the GPS and you will get something.

Use windows and PuTTY and it should be easy to find out one way or the other.

FWIW I prefer the 'drone' module I used first. It has the antenna and GPS circuits on the same board, so the mounting of it should be easier, whereas this one has the separate antenna and PCB which will just create more work for me.

Well something has improved since I swapped to 3.3v. I'm now getting data flowing in minicom, looks like this
G,,,,,,,,,N*2E
$GNGGA,,,,,,0,00,99.99,,,,,,*56
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
$GPGSV,1,1,00*79
$GLGSV,1,1,00*65
$GNGLL,,,,,,V,N*7A
$GNRMC,,V,,,,,,,,,,N*4D
$GNVTG,,,,,,,,,N*2E
$GNGGA,,,,,,0,00,99.99,,,,,,*56
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
$GPGSV,1,1,00*79
$GLGSV,1,1,00*65
$GNGLL,,,,,,V,N*7A
$GNRMC,,V,,,,,,,,,,N*4D
$GNVTG,,,,,,,,,N*2E
$GNGGA,,,,,,0,00,99.99,,,,,,*56
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
$GPGSV,1,1,00*79
$GLGSV,1,1,01,,,,24*62

And installing the windows driver for the converter gives me comp port 3, which allows me to connect to u-center.

?b Q$GNRMC,,V,,,,,,,,,,N*4D
$GNVTG,,,,,,,,,N*2E
$GNGGA,,,,,,0,00,99.99,,,,,,*56
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
$GPGSV,1,1,00*79
$GLGSV,1,1,00*65
$GNGLL,,,,,,V,N*7A
$GNRMC,,V,,,,,,,,,,N*4D
$GNVTG,,,,,,,,,N*2E
$GNGGA,,,,,,0,00,99.99,,,,,,*56
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
$GPGSV,1,1,00*79
$GLGSV,1,1,00*65
$GNGLL,,,,,,V,N*7A
$GNRMC,,V,,,,,,,,,,N*4D
$GNVTG,,,,,,,,,N*2E
$GNGGA,,,,,,0,00,99.99,,,,,,*56
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E

It hasn't got a fix at the moment, and Dot's watching the TV.
I don't want to start up the Pi and not be able to turn it off safely. so a live test will have to wait until tomorrow.

The big if is the converter driver, it's in the ubuntu kernel but is it in the Pi?

So the 5v/3.3v thing is a mystery. I'm not going to revert to 5v to see if it stops working.