Send Message
Weather | Buy&Sell | Forums |  |
Weather | Buy & Sell | Gallery | Forums | |
.
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?
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.
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,
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.
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.
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.
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.
