Hi Andrew,
The Ublox Modules you are linking to both have a serial interface.
The PI zero only has code working for the USB interface as it was written for the USB dongle due to its plug n play nature.
The Pi zero does have a serial interface though, and despite never playing with the Pi or its software I'm confident this can be easily done.
I will look into this when I get my hands on a Pi....there are currently NONE available in NZ so I have look offshore.
Just tried out the modification and to get the Ublox serial modules working in USB mode you have to:
Cut all 3 earth tracks on USD_VDD (1 exposed and 2 hidden under the UBLOX 'tin') then connect USB_VDD to 3.3Volts.
Add a 27ohm (or close to that) resistor to the USB_DP pin and then connect resistor to the USB_DP wire on a USB cable.
Add a 27ohm (or close to that) resistor to the USB_DM pin and then connect resistor to the USB_DM wire on a USB cable.
Connect 5V from USB cable to the Vcc pin of the module
Connect GND pin from USB cable to the GND of the module
I can confirm that doing all the above and not having USB_VDD connected to 3.3Volts causes the USB not to work.
This mod is not recommended at this stage as there are easier ways such as using a USB to serial converter to get the serial modules to work on the Pi's USB port.
Well done Stephen, you've done my mod!!!!!!!!!!!! I still don't think I'm game to try it though.
I do have a heat gun, but I've always used a solder sucker to desolder chips, and it's always been on much bigger chips with through the board pins, so you attack it from the other side.
I guess you apply upward pressure on the chip while heating it, and it pops off when the solder melts. But how easy is it to resolder? With the spacing of those small pads, I can see myself shorting them out.
After Locosys announcement you guys better hurry up and get to production.
Im keen it they hit the spot and will work on my Mac.
Select to expand quoteBSN101 said..
After Locosys announcement you guys better hurry up and get to production.
Im keen it they hit the spot and will work on my Mac.
I don't think any of us have plans to go into production. But Boardsuffer's objective is to make it possible for the average sailor to make their own DIY GPS logger. No complications like a display, just turn it on and wear it,
And it's looking very positive, so far, once a few of us have one running it shouldn't take long to get them approved.
For on the water feedback, there's a few alternatives, gpslogit on a cheap phone, or any other unapproved gps.
I have no plans for production at this stage.Boardsurfris working on pure plug n play - buy the bits, plug them in and start using.
If theUSB dongles (Ublox 7 or Ublox 8) with smaller antennasare approved then this would be great
The only downsides of the Pi is its power consumption and the possibility of corrupting SD card data if your battery runs out while the Pi is on. Making sure you have a big enough battery for your needs is the key there, but it also adds to theoverall size.
I'm looking into two ideas to design a PCB that will most likely need very basic soldering to put it together. At work we have recently been using a budget prototyping PCB service based in china and I could use them to produce bare PCBs in low quantities (min order is only 5 rather than 1000+) .
OPTION 1
Bluetooth sender - Ublox 8 module with large antenna + Bluetooth V2.0 or V4.0 module + battery charger + batteryholder + on/off switch.
This idea would be as small as possible to make mounting options easier.
This will require a phoneloggingapp with a Bluetooth connection(currently not available)to store/view data
or
the PI Zero could log the data whilst being located in a position that doesn't require vision to the sky
OPTION 2
A PI zero HAT (plugs onto a Pi zero) that would have a Ublox 8 module with large antenna + battery monitor + battery charger + battery holder + on/off switch + screen + some buttons. You could install the bits that you want to use.
In its basic form, this would log data, but it would allow a path for software to be developed to display results.
Select to expand quotedecrepit said..
Well done Stephen, you've done my mod!!!!!!!!!!!! I still don't think I'm game to try it though.
I do have a heat gun, but I've always used a solder sucker to desolder chips, and it's always been on much bigger chips with through the board pins, so you attack it from the other side.
I guess you apply upward pressure on the chip while heating it, and it pops off when the solder melts. But how easy is it to resolder? With the spacing of those small pads, I can see myself shorting them out.
Sorry I missed this. The Ublox module came off easily with a heat gun and tweezers - just heat on top and around the sides to melt the solder then gently remove with the tweezers. Then remove the solder from the pads, cut the earth tracks, add new solder paste to the pads and place tin back on. Then heat again until all solder is melted and tin 'flops' into place.
I stuffed it up on my first go as my earth tracks cuts were not wide enough and I applied too much paste, so the solder made an earth short when I heated it up 
So I took it off again, but this time I soldered the tin on with an iron + flux. I needed magnification to see what I was doing.
With regards to the Ublox M8n Gps modules that have been tested alongside other GPS units and performed well, were these cheap Chinese purchased ones from the likes of Ebay
I ask this as there seem to be lots counterfeit/clones Ublox modules available:
www.u-blox.com/en/counterfeit-products-and-u-blox-brand-misuse
www.rcgroups.com/forums/showthread.php?2693310-M8N-GPS-list-of-fake-good-and-original
My gut feeling is all the cheapest ones are clones but assuming they are M8N clones with the latest 3.01 firmware, these still perform ok for our application.
Select to expand quotesrtgumbee said..
Sorry I missed this. The Ublox module came off easily with a heat gun and tweezers - just heat on top and around the sides to melt the solder then gently remove with the tweezers. Then remove the solder from the pads, cut the earth tracks, add new solder paste to the pads and place tin back on. Then heat again until all solder is melted and tin 'flops' into place.
I stuffed it up on my first go as my earth tracks cuts were not wide enough and I applied too much paste, so the solder made an earth short when I heated it up So I took it off again, but this time I soldered the tin on with an iron + flux. I needed magnification to see what I was doing.
Thanks Steven,
I have the serial to usb you suggested on order, again could be a couple of weeks before it arrives. I'll give that a go first, if it doesn't work, I may get brave enough to try the cutting operation.
But what's this solder paste, you talk of? Must be another new fangled device,
Here is my version of a GPS. I am trying for a simple design. No buttons if I can help it, no connectors if I can help it, just an Arduino module and two bluetooth modules. The battery charging and protection circuits are on their way from China at the moment, but I am hoping that I can create a PCB to join all this together, but otherwise stick to using simple modules.
In reality I will need some sort of charging pins, possibly USB connections, and at least one sort of button. I am trying to simplify the design so that I can simplify the waterproofing requirements. I am thinking I can have 4 or 5 pins coming through the box for charging, USB, and some sort of control.
What I am trying to do is get it to log the output from the ublox m8n onto SD card, as well as send it out via one or both bluetooth modules. The intent is that the data is logged on the SD card but also exported to GPS Logit or similar. The tracks can be exported over bluetooth if required to avoid needing to remove the SD card. I think all the smarts and display can be done externally to keep the complexity down.
The second bluetooth module is there to use for some sort of external control, or sending the data to another device if required. They are easy to add, so why not. These things have so many UARTs that you could add a few more GPS modules as well if you really wanted to.
The Arduino is a Teensy 3.6, so its a little bit like fishing with dynamite, but they are cheap and come with built in SD socket. So far I have the GPS spitting out data to both bluetooth modules, and a separate sketch logging data to the SD card. All I need to do is make the time to combine the two to log the GPS data to the SD card.
It will be interesting to see how much processing power all this chews up. I suspect that when I am done most of it will be doing nothing. These things run at 180Mhz and use 80mA. If you slow them down you can cut that down to around 20 or 30mA.
All I can say is the the two M8n Modules I have tested give pretty much identical results and work as they should. They are also programmable in Ucentre and by the GPS-Logit BT test App.
The one I listed earlier in the thread from Ebay is one if these.
Select to expand quotesailquik said..
>>> The one I listed earlier in the thread from Ebay is one if these.
Great that's the one I've got.
Select to expand quotedecrepit said..sailquik said..
>>> The one I listed earlier in the thread from Ebay is one if these.
Great that's the one I've got.
Me too! I bought the one Daffy suggested, and then I bought a Sydney supplied helicopter type one just because I didn't want to wait for the first one to arrive. They should be functionally identical, and the helicopter one just comes in a separate case.
Select to expand quotedecrepit said..
Well that looks a bit harder to modify, have to break into the case first.
No, they are pretty simple. The case is only held together with 4 screws and then comes apart easily. You don't need to even open it though, as the pinouts are well known, but you do need to terminate the wiring somehow. They come with fine pitched connectors, so you need to pull those apart of cut them off and solder on something else.
Good, so we can move forward using the eBay UBLOX GPS modules as past testing has indicated they are good enough to be used AND future testing will most likely confirm this.
Select to expand quotesrtgumbee said..
Good, so we can move forward using the eBay UBLOX GPS modules as past testing has indicated they are good enough to be used AND future testing will most likely confirm this.
what is the recommended config in UCenter for these dongles ?
Select to expand quoteWST said..what is the recommended config in UCenter for these dongles ?
In u-blox 6 (and older) mode NAV-SOL, NAV-VELNED and NAV-DOP should be used and are parsed by the app at the full rate, NAV-SVINFO should be adjusted for 1 Hz.
In u-blox 7 mode NAV-PVT and NAV-DOP should be used and are parsed by the app at the full rate, NAV-SVINFO should be adjusted for 1 Hz.
In u-blox 8 mode NAV-PVT and NAV-DOP should be used and are parsed by the app at the full rate, NAV-SAT should be adjusted for 1 Hz.
Select to expand quotesailquik said..WST said..what is the recommended config in UCenter for these dongles ?
In u-blox 6 (and older) mode NAV-SOL, NAV-VELNED and NAV-DOP should be used and are parsed by the app at the full rate, NAV-SVINFO should be adjusted for 1 Hz.
In u-blox 7 mode NAV-PVT and NAV-DOP should be used and are parsed by the app at the full rate, NAV-SVINFO should be adjusted for 1 Hz.
In u-blox 8 mode NAV-PVT and NAV-DOP should be used and are parsed by the app at the full rate, NAV-SAT should be adjusted for 1 Hz.
thanks a lot I will try it today
Select to expand quotesailquik said..
In u-blox 7 mode NAV-PVT and NAV-DOP should be used and are parsed by the app at the full rate, NAV-SVINFO should be adjusted for 1 Hz.
In u-blox 8 mode NAV-PVT and NAV-DOP should be used and are parsed by the app at the full rate, NAV-SAT should be adjusted for 1 Hz.
Why NAV-DOP? It contains no additional information that is used. The only possibly relevant data point is pDOP, and that is present in NAV-PVT.
Similarly, the NAV-SAT/NAV-SVINFO records are only useful if you use custom software (or ucenter). The number of satellites used is present in NAV-PVT (numSV at offset 23). These records contain information about S/N ratios for each satellite that can be useful, for example when comparing antennas, but this information is not displayed anywhere in GPSResults or GPSAction replay (nor is there any indication that it is used at all).
NAV-PVT contains all the required information, including SPoP (called sAcc, speed accuracy, by ublox).
Select to expand quoteboardsurfr said..
Why NAV-DOP? It contains no additional information that is used. The only possibly relevant data point is pDOP, and that is present in NAV-PVT.
Similarly, the NAV-SAT/NAV-SVINFO records are only useful if you use custom software (or ucenter). The number of satellites used is present in NAV-PVT (numSV at offset 23). These records contain information about S/N ratios for each satellite that can be useful, for example when comparing antennas, but this information is not displayed anywhere in GPSResults or GPSAction replay (nor is there any indication that it is used at all).
NAV-PVT contains all the required information, including SPoP (called sAcc, speed accuracy, by ublox).
Both GPS-Results and GPS-Logit display satellite position,S/N and Sat count. (GPS-Results only displays it if the data is available - as in the position, S/N is in SBN files, but position is not in the SBP files)
This was a quote from an email from Manfred Fuchs. This is how we set up originally, but I have not payed much attention to it since because he adjusted later versions of the test BT GPS-Logit to auto setup ublox ubx output when it connects.
Edit: BT Logit actually only displays sat count and S/N in later versions, not position anymore.
Select to expand quotesrtgumbee said.
You may know and have tried this already but SD cards are fast at dealing with large chunks of data, but not so much with small chunks. If you are writing the data straight to the SD card as it comes in then it could be the SD card's write latency causing problems. SD card write latency is typically 10 to 50ms but is random and sometimes gets up to 250ms. @18hz (55ms) you would most likely have issues, but @ 10hz (100ms) you would most likely have no issue.......until you start analysing large amounts of data and run into issues with the odd large delay (eg 250ms) when the SD card is 'doing its internal cleaning' and your wanted data does not get written, instead it gets over written by the next incoming data sentence.
You metioned holding data in memory eg a FIFO buffer then writing to the SD card, this would be a way of getting around this. You can write to the SD from the buffer all the time and as long as the buffer is big enough it will cope with any long write delays. Just thought I would metion this in case you haven't tried this already.
I just read this again and it struck me that this may explain something I was puzzled by.
.
Roo and Manfred report they have had no problems recording 18Hz ubx without loss in Android phones, but Peter and I have had issues with loss. In my case, the loss was quite regular, being a missed point every 'x' number of points. I just assumed it was becasue of my cheap, inferior phones.
I have always set up the data to record to the SD card in the phone, but it is just as easy to record it to the internal phone memory. Perhaps those not having issues are doing just that and avoiding the SD card write limitation?? Would there be a silimiar latency issue writing to the phone internal memory?
It's and easy experiment to do to confirm this, I just had't thought of it before.
So serial to usb converter arrived to day, so now I have to go back through this thread and figure out what I have to do with it.
So I need a keyboard and battery. Just checked Jaycar and they have a 4000 mah solar rechargeable job on special. Solar charging takes 25hrs so probably won't extend battery life all that much. But it does have a low battery warning light, that could help save the SD card.
Select to expand quotesailquik said..
I just read this again and it struck me that this may explain something I was puzzled by.
.
Roo and Manfred report they have had no problems recording 18Hz ubx without loss in Android phones, but Peter and I have had issues with loss. In my case, the loss was quite regular, being a missed point every 'x' number of points. I just assumed it was becasue of my cheap, inferior phones.
I have always set up the data to record to the SD card in the phone, but it is just as easy to record it to the internal phone memory. Perhaps those not having issues are doing just that and avoiding the SD card write limitation?? Would there be a silimiar latency issue writing to the phone internal memory?
It's and easy experiment to do to confirm this, I just had't thought of it before.
I'm pretty sure I recorded to internal memory, I did not even put an SD card into the last 2 phones that I used for testing.
Recording at 18 Hz does not make sense, anyway. Yes, you will get slightly lower ranges for the error numbers, but the math used to accomplish that isinvalid. For Gaussian error propagation, the errors need to be independent. In other words, you should see plenty of spikes going up one point, down the next, and so on. You can actually see this in many 5 Hz files from Locosys units; but even 5 Hz ublox data often show stronger coupling between neighboring data points. This is similar to what can be seen in 1 Hz GT-31 data (although the time constant is about an order of magnitude lower). Because of the characteristics of the GT-31 data, Gaussian error propagation is NOT used for 1 Hz data in GPSResults.
But the more important reason not to use 18 Hz is that multiple satellite systems can only be tracked at 10 Hz. All else being equal, using more satellites will generally improve accuracy.
Select to expand quotesailquik said..
Both GPS-Results and GPS-Logit display satellite position,S/N and Sat count. (GPS-Results only displays it if the data is available - as in the position, S/N is in SBN files, but position is not in the SBP files)
This was a quote from an email from Manfred Fuchs. This is how we set up originally, but I have not payed much attention to it since because he adjusted later versions of the test BT GPS-Logit to auto setup ublox ubx output when it connects.
Edit: BT Logit actually only displays sat count and S/N in later versions, not position anymore.
Neither SBN nor SBP files contain information about satellite position or S/N ratios (they only contain how many and which sats were used). These have been the recommended (respectively only) file formats since the GT-31, I looked at a few thousand GPS files, but never saw the position and S/N plots (excepting GPSLogit, where the position plots are obvious). Perhaps I should have used NMEA on the GT-31 since it can contain satellite position and S/N ratios 
?
Maybe I caused a bit of confusion when using the "S/N" term. I was referring to what the ublox documentation calls "signal strength (C/N0)", or carrier to noise ratio. This is reported separately for each tracked satellite. For comparing different antennas, chips, electronic setups, etc., descriptive statistics and graphs of these could be quite useful. That probably would require custom software or scripts, though, to do the math and create the graphs.
Satellite info in GPS-Results :
SBN file:
10hz ubx file:
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.
But it seems that the Mac version of GPS-Results doesn't not display this data.
I agree with you that the 10Hz data from two GNSS is probably better than the 18Hz from one GNSS alone.
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.
