Select to expand quote

Roo said..

GPS Results used the HDOP from my UBlox 8 just as Manfred designed it to do, certainly not PDOP or PaccH. I must have one of the hokey bluetooth U-Blox 8 GPS units, seems to do this every time...not sure what I'm doing wrong.

Manfred designed the software well, and you're not doing anything wrong with your bluetooth GPS. Ublox decided not to include HDOP in the "main" data structure, NAV-PVT. However, they did include PDOP. They say so in the ublox specifications.

When dealing with a ubx file that does not have HDOP, but has PDOP, the choice was to either have all points fail the HDOP filter, or to use PDOP. While PDOP is a bit higher than SDOP, it is generally way below the HDOP cutoff of 5.0 when the GPS has half-way decent reception.

Manfred chose to use PDOP if he does not have HDOP. I think that was the right decision, even if if confused us for a few days .

Ever since I started working with Doppler and U-Blox GPS back in 2006/7 I have always included these messages, DOP, Sat Info and Navigation solution.

This is what the current Bluetooth UBlox8 outputs.
19:16:51 L -> UBX NAV-DOP, Size 26, 'Dilution of Precision'
19:16:51 L -> UBX NAV-PVT, Size 100, 'Navigation PVT Solution'
19:16:51 L -> UBX NAV-SAT, Size 376, 'Satellite Status and Information'

This is the output from 2007 Bluetooth UBlox4:
18:34:24 L -> UBX NAV-SOL, Size 60, 'Navigation Solution'
18:34:24 L -> UBX NAV-POSLLH, Size 36, 'Geodetic Position'
18:34:24 L -> UBX NAV-DOP, Size 26, 'Dilution of Precision'
18:34:24 L -> UBX NAV-VELNED, Size 44, 'Velocity in WGS 84'
18:34:24 L -> UBX NAV-SVINFO, Size 208, 'Satellite Status and Information'

Things have gotten simpler but DOP has always been included.

Manfred and Yann designed their software to use this output with various updates as we moved from UBlox4 to UBlox8.

The REAL M8N with v5 board arrived today, so I uncoupled the old module from the serial to USB converter. And I think I found why my last data from it was rubbish. Squashing it together in the Dophin box had pushed one of the spare converter terminals against one of the module terminals, probably making a very noisy connection. Haven't tried the old module yet to prove the theory, I was too interested in how the new one works.

So, the USB to serial converter still works! my patch up soldering does the job, and the new module got it's first fix very quickly.
I installed ucenter on the laptop, and had the antenna in our downstairs bay window. Much too cold and wet to go outside with it. I should have thought of this before, the sky view is better than the upstairs window.

Interesting looking at PDOP and HDOP, the former was in the low 2s, the latter the low 1s, so no need to get concerned over what looks like high HDOP if it's really PDOP.

I then plugged it into the Pi, and experimented with position of antenna and the Pi.




Started off with the Pi fairly close to the antenna, results didn't look as good as I expected, so tried moving the Pi as far away as the cable would allow, and made it worse!
In the process the antenna had taken on a slight angle, pointing more out the window than up. So I repositioned the antenna so it was close to horizontal, and that gave the best results. I then moved the Pi back close to the antenna, and results worsened, almost back to how they were at the start.
When the weather clears up, I'll take it outside for a good sky view, and take it for another bike ride, to compare with the results from the fake unit

Interesting. The effect of antenna orientation is quite dramatic. It would be interesting to see what this looks like outside, with a clear view of the sky. This made me look at the difference between the unit on top of my helmet one on my upper arm yesterday:


Top is satellites, bottom is speed error estimate (sAcc). Blue is on top of helmet, red is on arm. Here's a zoomed section:

The effect is not as dramatic as in your case, but still quite visible. The red GPS was on my right arm, where I use an often under grip if the hand is in front, which turns the GPS a bit more sideways. The GPS got the arm got about 2 satellites less than the one on the helmet; the SDOP spikes were about 50% higher (0.45 vs. 0.25 kn). The doppler speed graphs look quite similar, though, neither track is obviously better. 10 second speeds differ by less than 0.03 knots, 2 second speeds by less than 0.2 (most less than 0.1) knots.

It's all very interesting, and confusing. Looks like the actual error isn't very different, but the chance of error is higher?

Select to expand quote

decrepit said..
It's all very interesting, and confusing. Looks like the actual error isn't very different, but the chance of error is higher?

The error does seem to be quite random. With 50 points for a 10-second run, random errors will cancel out quite nicely. Even with +- 0.35 for individual points, the expected error would be just +- 0.05 for 10 seconds, which is roughly what I am seeing. Observed differences for 2 seconds are ~2-3-fold higher, again as expected (although if you add the effect of sampling/search bias, even larger differences for 2 seconds would not be surprising).

I did a stationery test today with the Drotek NEO-M8N connected to the Pi over USB, comparing it to the Beitian ublox 8 with Openlog. The Neo-Pi combo had about 50% higher error estimates (~ 0.5 vs. 0.3 kn) and about 0.05 knot higher stationary "speed" (0.09 vs. 0.04 kn). Maximum "speeds" over 2 seconds in this ~ 20 minute test were ~ 0.2 knots for the Neo-Pi, and 0.08 knots for the Beitian. So the higher error estimates are nicely correlated with an increase in speed error in the roughly the expected magnitude.

I did not do anything about RF shielding today. The NEO-8 was about 4-5 cm from the Pi, with the top of the antenna at about the same level as the Pi. WiFi and HDMI was turned off, but bluetooth may have been on. The Beitian was about 20 cm away. Clearly, the Pi needs some careful attention to RF shielding and/or GPS module location. In yesterday's windsurfing test, I had the NEO-8 connected to a phone, and the accuracy estimates were (a) better than today, and (b) very similar to the Beitian GPS I had on the other arm.

It's a bummer that the stationary tests cannot be used for direct comparison to the Locosys units, since those have a "low speed" filter that tends to set low speeds to 0, and also reduces the SDoP numbers. Maybe Dr. Chalko's tests may have given them some motivation to use such a filter, or maybe it is the default for the chips, since this kind of filter makes sense in cars etc.

Finally got the new module working inside the dolphin box, had a lot of reconfiguring to do to get everything to fit nicely.

Placed it on top of our main shade sail pole.



(Oh yes, that's my shed in the background. And closing in the underneath with that tin, to keep the rain off the timber stumps, is what I really should be doing, instead of playing around with this stuff!)

Skyview is much better than in the baywindow, but still not perfect, it's very close to the casurina.

Still much better results than the other day.
No shielding, antenna quite close to the PI.


I think that spike is when I lifted the GPS on to the pole, shortly after boot up.

Looking at that, I'm not sure it's worth worry about shielding. I'll go for a ride with the GWs and see how they compare, before I decide.

Your +/- numbers are probably pretty close to what the GWs will show, and speeds should be quite similar. You may want to leave the GPS on for at least 15-20 minutes before you start the bike ride. Sometimes, it takes that long to get the maximum number of satellites.

Bugger, another fail. The little battery's lead went iffy, as I closed the dolphin box lid. Lost the lights to module and Pi, wiggled the lead and they came back. So I had to abandon the dolphin box, and use the nice big cardboard one the yanks had packaged the little M8N module in. So I had the big battery, Pi, module and GW52 in the box. I tried to wedge them in so they wouldn't rattle around. Both the GW52 and Module antenna about the same distance from the Pi, but the GW52 was closer to my back.
Left the GPSs on for about 7 minutes the went for a longer ride than last time and down a bigger hill.++

Here's how GPSResults see it.



The watch was on my right wrist with the face very close to horizontal. It's interesting that it's +/-s are the best of the three.
The module is consistent in the 0.3s and the GW52 varies from 0.15 to 0.88.

I'm not all that happy with the way I stabilised things, when I finished the ride stuff had shifted around. I'll need to come up with a better method.

Interesting. I'd expect the GW-52 to have the same or better accuracy as the watch, but it's quite a bit higher. Also, the errors for the ublox are quite high, they should be below 0.5 (closer to 0.3 with no trees or houses around) for individual points. It's quite possible that there's quite a bit of RF noise from the Pi. Did you have WiFi turned off in the script? Most WiFi devices send lots of "probe requests" on a regular basis, and WiFi is more powerful than Bluetooth.

Let me know when you're ready to hook up a display to your Pi so you can see speed and accuracy in real time. I have the e-ink hat working. I also have a smaller two-color LED module that I have not yet tested.

I think the problem may be my body, the worst numbers are from the unit closest to it. There again it might have been the way the units weren't very well secured and sliding around.

I'm not sure about adding a display, the big problem I have is room. That's why the battery cable failed, it was bending too tightly.

We're going to busy the next few days, I'll have another go next week.

Select to expand quote

decrepit said..
I'm not sure about adding a display, the big problem I have is room. That's why the battery cable failed, it was bending too tightly.

We're going to busy the next few days, I'll have another go next week.

When using the Pi, I use a waterproof armband, and put the Pi + GPS setup inside a second ziplock bag. With the waterproof bags now made for large-screen phones, that leaves plenty of space. I'll be playing around with the Pi a bit more since the Openlog results are very clearcut (simple + very good), and the Drotek unit has USB. But there's little wind in the forecast, and then I have a trip coming up, so there will be little on-the-water testing in the next weeks.

I also ended up making my own USB cables to connect the Drotek NEO-M8N to the Pi, since I could not find any really short cables with the right connectors online. Messed up the first one, but fortunately, the Drotek has reverse-polarity protection. Besides being shorter, my cables ended up more flexible, making the packing easier. But if you'd like visual feedback with minimal space requirements, you could also think about Blinkt (shop.pimoroni.com/products/blinkt). I got one, it's small and the LEDs are very bright. No numbers, but it would be easy to use colors to indicate what's going on, for example orange when it's searching for a GPS, and slowly pulsing green LEDs when it's recording.

Thanks Peter, stuff to think about while I'm doing other things.

Select to expand quote

decrepit said..

Looking at your setup, I'd suggest that you add some more foil, at least between the antenna and the Pi. Check boardsurfr.blogspot.com/2018/06/foil-against-noise.html for details.

Yes it was my intention to experiment with screening, but I was thinking of the antenna, then I worried about shorting stuff out. Your idea of wrapping the Pi makes more sense.

So, My open logger has arrived, so I've been playing in U-center, trying to set up the GPS.
I've used NAV-PVT at 5hz. Saved the file from U-Center, but this is all I get from a stationery test in the upstairs window.



It's tracked a path, but there's no corresponding speed, accuracy or distance numbers. Any ideas what I'm missing?

Just looked at the PVT data in U-Center and it's showing speed over ground, so maybe it doesn't record speed and accuracy data when it saves a log?
Maybe I'll just wire it up to the logger and see what I get.

Another big flop, no data on the card at all, in fact it's just not being written to.
I started off with my own config.txt file, but when nothingb happened, I deleted that, to see if the open logger created it's own config.txt file.
It didn't.
So reformatted card in windows, still nothing.

I've got. VCC to 5v, Gnd and Blk to Gnd, rx to tx, tx to rx. But I've left Gn open, is that meant to go somewhere?

Next step is to connect it to the serial converter and see what happens plugged into the computer.

So another cheap Chinese disaster, or an old fool who doesn't know what he's doing?

so plugged into Ubuntu, all the computer sees is the USB converter, I'm not exactly sure what should happen. The guide here
learn.sparkfun.com/tutorials/openlog-hookup-guide
says,

Select to expand quote

Once you have the connections between the OpenLog and the FTDI Basic, plug your FTDI board into a USB cable and into your computer. Open up a serial terminal, connect to the COM port of your FTDI Basic, and go to town!

I'm not sure just what a serial terminal is, but I've tried minicom, and that sees nothing either.

And my converter has slightly different connections to the FTDI,
The hook up diag shows GND on the logger going to CTS on the FTDI, and BLK on the logger going to ground on the FTDI.
I have no CTS on my converter, so I have both GND and BLK going to GND.
So I'm still not sure if I have a dodgy logger.

What to do, buy another open logger from an aussie supplier? I'll check local prices, may be the easiest way to find out.

New one ordered from Core electronics, $20, but $7 postage.

Select to expand quote

decrepit said..

New one ordered from Core electronics, $20, but $7 postage.

Only a small positive to add, but the service and support I have had from Core in the past, has been very good.

Select to expand quote

decrepit said..
So, My open logger has arrived, so I've been playing in U-center, trying to set up the GPS.
I've used NAV-PVT at 5hz. Saved the file from U-Center, but this is all I get from a stationery test in the upstairs window.

It's tracked a path, but there's no corresponding speed, accuracy or distance numbers. Any ideas what I'm missing?

Just looked at the PVT data in U-Center and it's showing speed over ground, so maybe it doesn't record speed and accuracy data when it saves a log?
Maybe I'll just wire it up to the logger and see what I get.

Remove the filter checkbox, everything under 5kts is removed. (data shown in red)

My own software works very nice
forum.windsurfing.nl/viewtopic.php?f=62&t=13890429&start=660#p7415252
Difference between display and GPSResults is 0.001 (km/h) most of the time.

Couple of things I learned the hard way
- SD cards are very sophisticated, unless you use the cheap ones (Samsung rules here!)
- Buffers... You need them and they should be quite big!
- Check your code on delay and wait commands
- Make sure you test the speed of your code
- If you use software for components like displays, test the driver that comes with it

After the summer holiday I will build some additional units, If someone is interested just pm me.

Mike, start with a breadboard setup. You should only need GND, VCC, TX and RC (crossed, I think). I simply ignored GRN and BLK and that worked.

You'll need to edit the config file to match the baud rate of the GPS chip.

You can hookup the GPS to both the serial converter and the OpenLog at the same time, using GND and VCC from the converter. The card should then log what you see in u-center. Use the "Package" window to see what's being sent.

Select to expand quote

decrepit said..
It's tracked a path, but there's no corresponding speed, accuracy or distance numbers. Any ideas what I'm missing?

Just looked at the PVT data in U-Center and it's showing speed over ground, so maybe it doesn't record speed and accuracy data when it saves a log?
Maybe I'll just wire it up to the logger and see what I get.

I find recording in u-center a bit confusing. It can be easy to misinterpret what's happening. Your best bet may be to open the file in the "Player" in u-center, and then look at the package window, to see what's really in the file. Even with filters on, I have always seen speed numbers in the GPSResults table. Perhaps you can send me the file and I'll have a look at it.

Thanks Raymond and Peter,
I was wondering if it's OK to run the openlogger and converter in parallel, or if a splitter of some sort is necessary. They are both on the same bread board at the moment, so that's just a quick solder job.
I'll do that tomorrow and check the low speed filter.

Select to expand quote

decrepit said..
They are both on the same bread board at the moment, so that's just a quick solder job.
I'll do that tomorrow and check the low speed filter.

Now you are confusing me:

Select to expand quote

decrepit said..
Thanks Raymond and Peter,
I was wondering if it's OK to run the openlogger and converter in parallel, or if a splitter of some sort is necessary. They are both on the same bread board at the moment, so that's just a quick solder job.
I'll do that tomorrow and check the low speed filter.

You can run the Tx from the GPS to multiple units
But I would just use a single unit to keep everything neat and tidy...

It would be a better idea to copy Serial_1 to Serial_2 and catch the output from Serial_2 on your device.
I only have experience with the ARM I use, but latency should be fine.

For my raw device testing I catch the data from Serial_1 and throw the output to USB
And USB data to Serial_1 to update the Ublox unit.
USB also powers my (test)unit, it is easy to use just 1 micro-usb cable.

Mike's current problem is that he does not get the expected recording from one serial port. Adding a second serial port to the design does not help that problem in any way, it only adds additional things that can be misconfigured. Furthermore, the GPS module he is using most likely only has easy access to one serial port, anyway. That's at least the case for the 6 different GPS modules I have.

Raymond's suggestions might make sense for an electrical engineer working directly with a ublox chip. For Mike's situation, they only add confusion. The issues Mike reported are most likely due to some kind of misconfiguration, which may include wrong messages, wrong cable connections, mismatched baud rates, or a combination of these (and possibly other things). There's also a chance that the Openlog unit is not functional, but I think that chance is small, and the other potential issues should be excluded first.

Select to expand quote

boardsurfr said..
Now you are confusing me:

Semantics again Peter, back in the old days, a breadboard was anything you could temporarily hook stuff up on for development/testing purposes. Solderless versions are a very modern development as far as I'm concerned. I'm happy to use what is now called a development board I guess, with vcc and ground running down the sides and individual/twin connections in the middle.

Peter, my understanding of the openlog, is that with only a virgin, fat 32 card in and nothing connected. It will write a config.txt file to the card. Mine is not doing that, that's why I suspect a faulty openlogger.

Logged into windowz, and did a replay. Looks like I need a lot more practice with U-Centre because although I was sure I'd set it to NAV PVT
all I've got is reams of this.
08:14:56 L -> UBX NAV-SOL, Size 60, 'Navigation Solution'
08:14:56 L -> UBX NAV-SVINFO, Size 268, 'Satellite Status and Information'
After I've done some more work to Rob's board, I'll reconnect the serial to USB converter and see if I can figure it out.

Select to expand quote

raymondw said..
After the summer holiday I will build some additional units, If someone is interested just pm me.

Raymond,

It would be a good idea to start a separate thread, with an idea of price and details, because there are probably a few people interested.
That aren't checking this thread anymore