Diy Gps V2a

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.

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

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

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.

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.

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.

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.

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".

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.

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

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 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.

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.

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....

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

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.