A few weeks ago I went to grab my helmet out of the wagon, to load it up with GPSs.
But it wasn't there!
It still hasn't turned up, so I've taken the opportunity to simplify things.
I'm no longer testing devices, so I don't need to be able to carry two devices on my head.
And it would be good to have the device on my head with plenty of battery life, V3 is relatively power hungry, so I'm going with V2.
My aim is to shrink it, to make the thing on my head more aerodynamic. So I've removed the serial to usb converter, because I no longer need to play with the UBX configuration, that's also meant the removal of the change over switches. also gone is the old 800mAh round battery, that's been replaced with an 1100mAh flat battery, bigger but as it's flat, allows a lower profile device.
All I have now is the M8N, Spark Fun openlog, battery charger and protector, on/off switch and of course the battery.



So this is fairly simple and works well at 5hz, 10hz sees quite a lot of missed points.
And as you see I managed to finally find a fairly good schematic CAD, but this is my first attempt with it, so still a bit rough, only complaint so far I can't find an earth symbol.

I'm now in the process of making a curved enclosure for it to fit on the helmet, pictures when I make a bit more progress.

Yeh, looks fairly simple to me also Mike

Mike,
I use TinyCAD for electrical schematics, it works really well and is free/open source

Select to expand quote

tbwonder said..
Mike,
I use TinyCAD for electrical schematics, it works really well and is free/open source

Thanks tb, but I like to stick to the mint repos, it's safer that way. I don't remember seeing it in there but I'll have another look.
No wonder it's not there, it only runs under windoze

Here's how it's set up

M8N
Baud rate 19200
Acquisition rate 200ms (5hz)
Sentence UBX NAV PVT
GNSS GPS, Glonas, Galileo

Openlog
Baud rate 19200
config file
19200, 26, 254, 0, 1, 1, 0
baud, escape, esc#, mode, verb, echo, ignoreRX

I've loaded mine with the openlog-light firmware version, that doesn't have the command line mode, so doesn't need the escape stuff, but if using the standard firmware, you need to set these numbers high so it doesn't unintentionally switch to command mode.

Select to expand quote

decrepit said..
Here's how it's set up

M8N
Baud rate 19200
Acquisition rate 200ms (5hz)
Sentence UBX NAV PVT
GNSS GPS, Glonas, Galileo

Openlog
Baud rate 19200
config file
19200, 26, 254, 0, 1, 1, 0
baud, escape, esc#, mode, verb, echo, ignoreRX

I've loaded mine with the openlog-light firmware version, that doesn't have the command line mode, so doesn't need the escape stuff, but if using the standard firmware, you need to set these numbers high so it doesn't unintentionally switch to command mode.

Back when Daffy and I made the Bluetooth-Logit device, I worked out that at 10hz you would need 115,000 baud... simply due the number of bytes being sent is more than the channel-capacity. (Obviously it depends on the sentence length.)

Importantly, the docs for the M8N say that UART buffer will fill if the out-bound data isn't transmitted quickly enough... and thus sentences will be dropped ( internally prior to being stored in the UART buffer ).

And there is interrupt-handling on the UBlox-chip side, between the UART and the processor - which reduces your theoretical throughput.

Have you tried say 115k baud or even 56k ?

Select to expand quote

mathew said..

Back when Daffy and I made the Bluetooth-Logit device, I worked out that at 10hz you would need 115,000 baud... simply due the number of bytes being sent is more than the channel-capacity. (Obviously it depends on the sentence length.)

Importantly, the docs for the M8N say that UART buffer will fill if the out-bound data isn't transmitted quickly enough... and thus sentences will be dropped ( internally prior to being stored in the UART buffer ).

And there is interrupt-handling on the UBlox-chip side, between the UART and the processor - which reduces your theoretical throughput.

Have you tried say 115k baud or even 56k ?

Hi Mathew,
I think Daffy was including NAV DOP and NAV Sat sentences, with the Ublox 8 series NAV PVT is adequate for our needs.
Yes it was originally set up at 115k and I tried all sorts of things to get it to work at 10 hz. I went on the sparkfun forum for advice here.

forum.sparkfun.com/viewtopic.php?f=102&t=50967
Surprisingly their advice was to try dropping the baud rate, that's how I ended up at 19.2k it seemed to give the best results. But the test results were all over the place, what gave a bigger out buffer didn't improve results.
It's too late for me to check it now, but I suspect the problem was as you say, the UART receive buffer was sacrificed to give a bigger tx buffer to write to the card. The sparkfun focus was about card write speed, and distracted me from the needs of the receive buffer.
I'd love to have another go at it, but the idea of pulling every thing apart again, so I can connect to u-centre and the arduino IDE, is very discouraging.

Yes, we are trying to Write NAV-PVT and NAV-DOP at the full Hz rate (5Hz or 10Hz) and NAV-SAT at 1Hz.

@10Hz, some days it is fine and some/most days it misses points. At it's worst, it misses every 10th Point!

It seems to be entirely related to how much SAT info it is trying to write. If used with the GPS system only, to does not miss points. Infact, it will work fine @18Hz on just the GPS system (with which it is limited to @18Hz anyhow).

I must try reconfiguring it to just write NAV-PVT and see if it can cope with 10Hz, muliti GNSS, without missing points. I very strongly suspect it will be fine like that.

Oh, I just remembered I am waiting for Mat to come by and 'tune it up'. For some reason I have not been able to get it a 'FIX' with it for a while. I suspect it is just a loose wire somewhere.....

And the other issue is that GPS-Logit, which I use as the BT interface, auto sets alll three NAV sentences. I might have to use another app to be able to Log just NAV-PVT.

Woops I got that totally wrong! (trouble with being a silly old fart, I tend to forget stuff or get it back to front).

May be it's the other way around, I should have allowed some memory for the transmit buffer, here's the relevant part of the openlog-light code.

SerialPort*0, 850, 0* NewSerial;
//This is a very important buffer declaration. This sets the *port #, rx size, tx size*. We set
//the TX buffer to zero because we will be spending most of our time needing to buffer the incoming (RX) characters.

This is a pain, I can't post the actual code because posting removes everything between the "*"s.
i've used them to replace the left and right arrows that indicate code

I think it would be interesting to try rx 512 and tx 338.
So if anybody else is building one, it may still be possible to run at 10hz without missing points, but it will be touch and go, I'm not convinced by this theory, but it's possible my problem was a write to card thing.

Decrep, If you are feeling keen.....

A plain old DPDT switch sitting on the +/- data lines, should be a good enough hack to allow serial-access to the uBlox.... Use the switch's common-pin to connect to the ublox, with one side connected to the logger and the other side to an I/O port. [ not the best solution when the serial port is running at 1Mb... but 19200 / 115k should work fine ] ... and dont switch the change-over, while power is connected.

or... just tap the +/- lines and disconnect the +ve from the logger.


If someone was feeling really keen, it might be better to use SPI mode....

Mat that was my original set up, just flip a switch and I could re program the M8N, but it needed and extra USB to serial converter. All that is now gone to reduce size, and I have no intention of putting it back at the moment.

If this is the original SparkFun logger, you are going to run into the problem with throughput because of the SD block allocation. The write speeds are okay, its just that the cards can hesitate when they find they need a new block to write to, and then have to allocate it. It takes longer than you would expect.
The people that have made these devices write as fast as the cards can handle have effectively created a file large enough for the expected data, so that the blocks are preallocated and the SD card does not have to find them as they are already there.

SPI or serial UART, the problem will still be the SD card allocating blocks.

I think a reasonable approach would be to preallocate a blank file of the required size, maybe for 24 hours, or 48 hours, when the GPS is first initialised.

I looked at this stuff ages ago and it seems achievable, but enthusiasm ran out!

Yes, I've heard that explanation before, but I've no idea how to do it.

Spark fun also says most formatting software, doesn't do SD cards properly, here's what the SD Association has to say.

"It is strongly recommended to use the SD Memory Card Formatter to format SD/SDHC/SDXC Cards rather than using formatting tools provided with individual operating systems. In general, formatting tools provided with operating systems can format various storage media including SD/SDHC/SDXC Cards, but it may not be optimized for SD/SDHC/SDXC Cards and it may result in lower performance."

I did notice a difference when I re formatted with this.

I thought the case was coming along quite well until I realised I hadn't left any access to the USB socket or SD card!
Mods underway at the moment, pics are still a few days off.

Select to expand quote

decrepit said..

only complaint so far I can't find an earth symbol.

Do a search for GND. The symbol is "gnd-1.sym".

Thanks jn, I'll see if that turns up anything later

Good one jn, it's hidden in power rails. Much better than my hand drawn attempt. I've also discovered how to make the background white.

The only thing I can add is follow any EMI/C proofing methods you can find with this module. I had a look at the datasheet. There's no guidance for this. As a minimum, do something with all of the pins. Either ground them, connect them to the power rail. Don't leave them floating. They become antennas and will reduce the sensitivity of the module if the module itself does not treat them.

www.u-blox.com/sites/default/files/NEO-M8_DataSheet_%28UBX-13003366%29.pdf

These sort of things are in the "Hardware integration manual".

Select to expand quote

decrepit said..
I thought the case was coming along quite well until I realised I hadn't left any access to the USB socket or SD card!
Mods underway at the moment, pics are still a few days off.

I picked that, was waiting for you to see it.

Select to expand quote

jn1 said..
The only thing I can add is follow any EMI/C proofing methods you can find with this module. I had a look at the datasheet. There's no guidance for this. As a minimum, do something with all of the pins. Either ground them, connect them to the power rail. Don't leave them floating. They become antennas and will reduce the sensitivity of the module if the module itself does not treat them.

www.u-blox.com/sites/default/files/NEO-M8_DataSheet_%28UBX-13003366%29.pdf

Well I guess, my cct is misleading, I'm actually using a module designed for drones, all the UBLOX pins are taken care of.

Yes, I remember looking at the Ublox modules that I got that were meant for drones, and the USB lines had been neatly terminated so that there was no prospect of using them. Its a shame they didn't bring them out to a neat header, but they just terminated them in a place where you couldn't get them and I think they tied one of the lines to disable the USB option.

Yes my memory matches, also was it Steve from NZ pulled the chip off and enabled the USB connection, then re-pasted the chip back. Unfortunately he had one of the Chinese cheapies with faulty memory, so his settings didn't stick.

Select to expand quote

Mark _australia said..>>> I picked that, was waiting for you to see it.

OK, so where have you hidden the spy camera?
I've looked in the fan, smoke detector, behind the mirror, no sign, or is it soo small I need a microscope?

So at last I've got the thing together.

I've used double sided tape to stick the modules in the device. I haven't made up my mind about a lid yet. Could maybe pot the whole lot, but I want to be able to see the lights. It's nice to know that everything is working. It will be safe enough in the aquapack as long as nothing hits it.


It ended up a bit bigger than necessary, but I wanted nice rounded corners so it doesn't stress the aquapac

Here's the side view, that shows the curve to fit the helmet.






The helmet carrier is now under construction, all I've got to figure out is how I'm going to retain it all.

Battery is now charging, when that finishes, I'll do a discharge test, and see how much more I get from the 1100mah than the previous 800mah version.

Finished the discharge test.

9-10 nov 2019 battery test 1
1a/ 09 Nov. 2019 18:20 - 18:27 no missed points = 7min.
Had a look to make sure it was recording properly, then left it on all night.
1b/ Time: 09 Nov. 2019 18:33 - 10 Nov 10:06 = 15:33
total time = 15:40

File: LOG00173.UBX (1b)
Observed time distribution (in ms):
200 279744
205 1 (This extra 5ms often happens at GPS start up)
1 time errors (0 above 5.0 knots), about 0 missing points
279422 filtered points:

So I'm happy with that, plenty for dawn to dusk on a long summer day, but I can't see me doing that now.
Not long enough for Kato, but a 2000mah battery is only 3mm thicker, and should do excess of 30hrs

You are using a NEO module, going above 3 GNSS networks overloads the internal CPU when you logging above 3hz.

I had the same issue, dropping Galileo solved my issues above 5hz.

When the device is stationary it works like a charm, when you start using the module it starts to drop data points....

Thanks Raymond I'll keep an eye on it, but so far it's OK.
I've been looking thru past data, here's one form February

File: 5 Feb Lilacs V2 5hz.ubx
Observed time distribution (in ms):
200 65325
400 1

Points with untypical dt (and speed > 5.0 knots):
1 400 ms at #29020 06:00:00.400 speed: 22.230 sAcc: 0.194
1 time errors (1 above 5.0 knots), about 1 missing points
Added 1 missing points
22555 filtered points:
Low speed 22555 points; max speed: 0.6 kn
Satellites 4 points; max speed: 0.1 kn

Filters were applied
Start: 05/02/2019 04:23:16.200 end: 05/02/2019 08:01:01.600

So that's one missed point in about 3:38 and that was with 28 sats being used.
I'm not overly concerned about this, as you see above Speedreader adds missing points back in, I guess the average of points either side.

So a 5hz file for one point goes to 2.5hz, I think that's better than having the whole 3:28 at 3hz

And while I'm here, the helmet adaption is finished.
view from side,

view from top with DIY v2a inside. The strap isn't tightened, it goes thru the helmet and is fastened by velcro. The wide opening at the rear is for the long aquapac seal to enter the carrier

Had a bit more of a browse, here's a 6hr 34min 156Km session.

File: 29 jan V2 fangys.ubx
Observed time distribution (in ms):
200 118129
205 1
400 1

1 400 ms at #37890 14:19:42.400 speed: 13.352 sAcc: 0.179
2 time errors (1 above 5.0 knots), about 1 missing points
Added 1 missing points
28558 filtered points:

Satellites 30 points; max speed: 0.3 kn
Start: 29/01/2019 04:13:24.195 end: 29/01/2019 10:47:10.600

V3 with the BN880 GPS and the sparkfun logomatic v2 is superior.
Here's it's time distribution for the same session
Observed time distribution (in ms):
197 1
200 118669

It will even do 10hz with 3 GNSS woops only 21 sats so probably no Galileo
File: fangys 11 nov V3.ubx

Observed time distribution (in ms):
100 115333

0 time errors (0 above 5.0 knots), about 0 missing points
28299 filtered points:
Low speed 28299 points; max speed: 0.6 kn

Filters were applied
Start: 11/11/2018 04:24:40.100 end: 11/11/2018 07:36:53.400

Not bad for 3hrs 12min

With all the trouble I had trying to log at 10Hz without missing points with the BT M8 gps, I have literally got NO missing points using at at 5Hz in my last few sessions (checked with GPS-Speedreader and GPSAR-Pro - I don't consider 199's and 201's 'missing points', but there were ony a few of those as well)

And that is logging NAV-SAT and NAV-DOP as well as NAV-PVT using 3 GNSS! Thats good enough for me.

Interestingly, when I logged at 10Hz (GPS only) the other day on a 4 hr stationary test, I didnt get any missed points either (checked with GPSAR-Pro). But I dont like that option as much as there is still the possibility of dropping points with low sat numbers (Not that I have seen it though) and there should be better accuracy with 2 or more GNSS, even at 5Hz

Julien has obviously solved the issue though, as there were no problems logging at 10Hz with all the tests I did on the Motion. I just checked a few files in GPS-SpeedReader and no missing or timing errors. But there is no SAT data either except for the numbers of Sats.