Yesterday my first delivery of parts came. The Openlog and a USB to serial converter. The size of these things was a bit of a surprise. When I was younger I could solder 0.1" header pins in near darkness. But be warned 0.1" is a lot smaller than it was 30 years ago. If you are over 50 you will need some +3 reading glasses and a bright light.
So I spent 30 minutes reading the getting started guide to the "openlog" and then another 30 minutes soldering some headers on to the tiny boards. I formatted a micro SD to Fat32, popped it in the open log and powered it up.
I was happy to see that the logger wrote a little config file on the SD card.
Contents of file:
9600,26,3,0,1,1,0
baud,escape,esc#,mode,verb,echo,ignoreRX
So I've looked through some old data and found an 8hz file. NAVPVT @10hz plus NAVSAT at 1hz. it was only half an hour but no missed points.
File: yunderup 18 oct v3 8hz + sat.ubx
Observed time distribution (in ms):
124 1619
125 13919
126 1619
3238 time errors (0 above 5.0 knots), about 0 missing points
10993 filtered points:
Low speed 10993 points; max speed: 0.6 kn
Filters were applied
Start: 18/10/2018 01:24:30.124 end: 18/10/2018 02:00:14.749
Assumed wind direction: 256 degrees
Files and colors:
yunderup 18 oct v3 8hz + sat.ubx - blue
Writing results to temp file '/tmp/GPSReader18022883375616326963.html'
And another longer one (about 4 hours) with one missing point, but there's apparently a problem with 125ms it has a lot at 124 and 126
File: Fangys 18 0ct v3 8hz + sat.ubx
Observed time distribution (in ms):
124 11297
125 73330
126 11296
250 1
Points with untypical dt (and speed > 5.0 knots):
>>>> I've deleted the individual reports there were too many of them
22594 time errors (4214 above 5.0 knots), about 1 missing points
Added 1 missing points
62895 filtered points:
Low speed 62892 points; max speed: 0.6 kn
Acceleration 3 points; max speed: 3.8 kn
Filters were applied
Start: 18/10/2018 02:54:32.500 end: 18/10/2018 06:14:23.124
Assumed wind direction: 256 degrees
Files and colors:
Fangys 18 0ct v3 8hz + sat.ubx - blue
Writing results to temp file '/tmp/GPSReader1137307106436792983.html'
So I don't see why we aren't using 8hz, it's more reliable even with NAVSAT data thrown in.
Select to expand quotetbwonder said..
>>>The size of these things was a bit of a surprise. When I was younger I could solder 0.1" header pins in near darkness. But be warned 0.1" is a lot smaller than it was 30 years ago. If you are over 50 you will need some +3 reading glasses and a bright light.
Yep, that's one of the first things I found!Select to expand quote
>> I formatted a micro SD to Fat32, popped it in the open log and powered it up.
There's evidence to suggest you get better results using "SDFormater" instead of the native OS formatterSelect to expand quote
I was happy to see that the logger wrote a little config file on the SD card.
Contents of file:
9600,26,3,0,1,1,0
baud,escape,esc#,mode,verb,echo,ignoreRX
This is my config file
19200,26,254,0,1,1,0
baud,escape,esc#,mode,verb,echo,ignoreRX
So it's thought higher baud rates is need to handle all the data, and a higher escape number to prevent accidental triggering
Select to expand quotedecrepit said..
So I've looked through some old data and found an 8hz file. NAVPVT @10hz plus NAVSAT at 1hz. it was only half an hour but no missed points.
So I don't see why we aren't using 8hz, it's more reliable even with NAVSAT data thrown in.
There is no reason not to as far as I can see. The only reason I have not tried it is the constraints in GPS-Logit that only give the options of 1hz, 2Hz, 5Hz, 10Hz and 18Hz.
It is logical to use the highest Hz rate that you can get with no missed points.
But I also agree with Boardsurfr that with high Hz devices (5Hz +?), I can't see why we should not just 'interpolate' single missed points. Any difference would be insignificant.
Select to expand quotedecrepit said..
So I don't see why we aren't using 8hz, it's more reliable even with NAVSAT data thrown in.
There is no reason not to as far as I can see. The only reason I have not tried it is the constraints in GPS-Logit that only give the options of 1hz, 2Hz, 5Hz, 10Hz and 18Hz.
It is logical to use the highest Hz rate that you can get with no missed points.
But I also agree with Boardsurfr that with high Hz devices (5Hz +?), I can't see why we should not just 'interpolate' single missed points. Any difference would be insignificant.
My Beitian GPS board arrived yesterday. Before attempting any programming I connected the 4 wires to my logger to see what would happen. I took it outside for a few minutes. The blue and red leds flashed on the GPS board, which I assumed was a good sign.
The logger had written a text file to the usb card. The file contained loads of random looking stuff but in amongst it all I could see "33" and "151", which are my lat and long position. So with no set up of either logger or gps board, it is possible to record GPS data to a USB card.
Next step was to program the GPS board. This requires U-Center, which can be downloaded from the Ublox website.
Unfortunately this is a complex program and it is not immediately obvious what you need to do. My USB to serial board worked perfectly, I was able to click "connect" in U-Centre and see my GPS without any com port issues.
During programming the GPS received power from the computer and did not need the battery connected.
It makes life easier if the GPS can get satellite reception during the programing as it makes it easier to see what is going on.
The steps in U-Centre:
1 - Click connect button and select com port
2 - View > Packet Console - this lets you see what is going on.
3 - View > Configuration View. Here you can change the following:
MSG (messages) to 01-07 NAV-PVT
GNSS (GNSS Config) - to whatever systems you which to use
PRT (Ports) - UART1 protcol in and out UBX
RATE (Rates) - set to 100ms (for 10 hz logging)
After changing each parameter, click the "send" button and then once complete select CFG (Configuration) to save the current configuration and then click "send" again.
After these changes the logger will still write a text file after each session. However if the .txt file is renamed to .ubx it can be opened by GPSSpeedReader.
So the whole process probably took about 4 hours. 2 hours of that was scratching my head trying to figure out how U-Centre works.
Total cost was AU$77. $9 of that was the Serial to USB converter which is only needed for programming.
Here it is all stuffed into an old Gopro case ready for action.
If you ordered everything from China and you had to buy a battery, a charger and a waterproof go pro case then I think you could make something like this for around AU$70
Select to expand quotetbwonder said..
After these changes the logger will still write a text file after each session. However if the .txt file is renamed to .ubx it can be opened by GPSSpeedReader.
No need to rename the file. Speedreader knows that .txt files are from Openlogs with ublox GPS units 
. It will even offer to copy the files from the micro SD card to your computer, and suggest a name that shows the current date, for you.
It will be interesting to see if the GPS drops points if you use 3 GNSS systems. Speedreader tells you in the "Messages" window that is typically hidden behind the main window, but can always be brought to the front using the "View" menu.
If you get dropped points, try using the CFG-NAV5X message to set the minimum CNO level to somewhere between 25 and 28. That seems to make a bit of a difference. Julien said he uses this (or something similar) on the Motion.
I have done bit more testing.
Initially I was using a baud rate of 9600 which is the default. At 8 hz logging I was getting zero missed points. At 10hz logging I was getting perhaps 15 missed points per minute.
I struggled a bit with U-Center to change the baud rate but finally managed to change it to 19200. Surprisingly now I am getting zero missed points at 10hz.
I went for a walk with my device (Blue) and a mini motion (Red). Held a few inches apart and as steady as I could.
This image covers about 25 seconds of walking. It is incredible how the two devices follow each other. My device was tracking about 23 sats and the Motion around 13, which is reflected in my errors being a little lower.
There were some sections where the correlation was not this good. Under trees the Motion struggled more and at other times the Motions results appeared more smoothed.
It will be interesting to do some on the water testing.
That's amazing 0 at 10hz with an openlog, but maybe a longer test could see some appear.
But looks like you have a great device for $70!
Select to expand quotejirvin4505 said..
Is there a shopping list with links to sites to buy from?
These are the bits I bought.
core-electronics.com.au/sparkfun-openlog.html
core-electronics.com.au/cp2104-usb-to-serial-adapter-carrier.html
Then search ebay for "BN-880 GPS" they are about AU$40 for local Australian stock, or about $20 if you can wait for one to come from China.
Then you will need a battery and some way of charging it. But you can use an old battery from a camera or similar (3.7V Li-on)
You will also need some thin wire to connect things up.
Browsing my files the other day, I found my list, but this is from 2018, and may be a bit outdated.
GPS
UBLOX NEO-M8N HMC5983 GPS Module GYGPSV5-NEO For Pixhawk APM
www.ebay.com.au/i/232265962742?ul_noapp=true
Sold by nyplatform (79637)99.6% positive Feedback
Approx. AU $40.46
+ AU $19.23 postage
(Note the bietian BN 880 is a better choice)
openlogger
SparkFun OpenLog DEV-13712
core-electronics.com.au/search/?q=sparkfun%20openlog%20%09dev-13712
$20.38 AUD, inc GST + postage! Shipping:
$6.95 Standard (2-4 days, tracked)
$8.95 Express (Overnight*, tracked)
$3 Economy Post* (3-7 days, no tracking)
FREE Pickup (Newcastle only)
Jaycar
Serial to USB converter.
Arduino Compatible USB to Serial Adaptor Module
CAT.NO: XC4464
A mini-USB to 6-pin serial port module used to communicate with Arduino boards and modules.
$19.95
The pins labeled BLK and GRN correspond to the colored wires on the FTDI cable. The black wire on the FTDI cable is GND, green is DTR. Use these BLK and GRN pins to align the FTDI basic board with your Arduino target.
------------------------------
enclosure.
CAT.NO: HB6005
Jiffy Box - Clear - 83 x 54 x 31mm. Note I had to modify this to fit battery.
$2.95
PCB VERO 95x/5mm 0.9mm holes HP9540 $4.50. 1 piece cut in half
2 X changeover switch CAT.NO: SS0834 $1.50 each. (Note I only used this so I could easily swap between adjust and use mode, not necessary if you aren't experimenting)
Plus one on/off switch
Header
SGL VRT 40way P=2.54mm $0.95
Lipo cell from core electronics
14500 Rechargeable Li-Ion Battery 800mAh 3.7V Solder Tag $10.95
------------
Battery management. from AliExpress
6W 5V UPS mobile power Diy Board Charger & Step-up DC DC Converter Module for 3.7V 18650 lithium battery
Model Number: DD05CVSB_5V
Brand Name: eletechsup
Supply Voltage: DC 4.6-8V
-------------
3.7V 4.2V 3A Li-ion Lithium Battery Charger Over Charge Discharge Overcurrent Protection Board for 18650 TP4056 DD05CVSA
Supply Voltage: DC 2.4-4.5V
Model Number: DD04CPMA
Brand Name: eletechsup $ 1.32
______________________________-
And here's the wiring diagram, without the programming serial to usb module
Why not use the Beltian BN-220? The 880 has some features we don't seem to need.
Is an active antenna any real advantage? 
As I understand it, they just amplify the received signal a bit. Do the commercial GPS's use Active antenna? Generally, sat reception is pretty good on the water.
Ah yes. One i saw on amazon does have a smaller antenna, but it is not attached to the Module so i guess one could use a larger one.
This one seem to be the same size antenna and it appear to be built on:
www.amazon.com.au/Beitian-BN-220-Module-3-6V-5-5V-Built/dp/B086PM5LTW/ref=pd_day0_4?pd_rd_w=fwX3i&pf_rd_p=1b47318f-807b-4d2b-bf91-b76a34a92ae4&pf_rd_r=N55J9ERMNSW4HN3CRE5E&pd_rd_r=79e7da04-8bd3-49f0-938f-2a4ba49efc02&pd_rd_wg=krbY4&pd_rd_i=B086PM5LTW&psc=1
It's not that I would begrudge paying $10 more, I just wondered if there would be anything gained with the BN880?
Select to expand quotetbwonder said..
There were some sections where the correlation was not this good. Under trees the Motion struggled more and at other times the Motions results appeared more smoothed.
Under trees, Motion shouldn't even log a thing. The threshold's high to avoid having any uncertain speed record. I'll remove this in the near future because users end up thinking the device isn't working well at times.
On the other hand, you shouldn't have any less than 18 sats on average. Send me your log please.
Select to expand quotesailquik said..
Is an active antenna any real advantage? As I understand it, they just amplify the received signal a bit. Do the commercial GPS's use Active antenna? Generally, sat reception is pretty good on the water.
I get very similar results with a BN280 (passive antenna, 4x25x25) and an BN880 (active antenna, 2x25x25). I'd guess that they added an extra amplifier to the Beitian chips with passive antennas so the signals the GPS engine sees are very similar.
The original u-blox GPS chips generally require an active antenna. Using those with a passive antenna gives a very weak signals and very few satellites being tracked.
I have also gotten decent results with smaller antennas, but never quantified that. I think the effects would be subtle, and mostly limited to situations where the GPS signal is weaker for some reason. One place where this is obvious is testing in a house, where active and bigger antennas get a fix much quicker, and track more satellites. For windsurfing, this would probably be most relevant when the arm band moves to the GPS is not facing up anymore.
Select to expand quotetbwonder said..
I struggled a bit with U-Center to change the baud rate but finally managed to change it to 19200. Surprisingly now I am getting zero missed points at 10hz.
I vaguely recall Mike also reporting that 19200 would be the best rate for one of his prototypes. The reason was that at higher rates, the timing of the signals is more likely to get out of sync. Always nice to see results confirmed independently!Select to expand quotetbwonder said..
I went for a walk with my device (Blue) and a mini motion (Red). Held a few inches apart and as steady as I could.
This image covers about 25 seconds of walking. It is incredible how the two devices follow each other. My device was tracking about 23 sats and the Motion around 13, which is reflected in my errors being a little lower.
Such differences can easily arise from when you used a GPS unit the last time. A unit that was just used a few minutes ago will often get more satellites faster that a unit that has been off for more than 30 minutes. With longer time frames, the differences can be even larger.
You can track that in U-center by looking at the NAV-PVT messages in the message window. With 3 GNSS systems enabled, I have satellite numbers go up for ~ 30 minutes before stabilizing. It's always a good idea to switch the GPS units on at least 15 minutes before you want to compare the data, and let them have a clear view of the sky.
BTW, I have made some progress getting rid off dropped points with the Sparkfun SAM-M8 and the USB M8 units. One of the things I learned was that you absolutely have to turn off output to UART. The default baud rate setting on most GPS chips is 9600, which is insufficient to allow transfer of 10 NAV-PVT packets (each 100 bytes) per second. Interestingly, I even got dropouts when recording at only 5 Hz. It seems that communication through all ports goes through the same bottleneck (a single communication thread, or perhaps even a single processor), so all communication is can be affected if one port is too slow. The BN chips are a bit better here because they use 38400 as the default for the UART port. But the problems with the BN chips are also more obvious since we use an UART port for communication.
Perhaps yesterdays test was a little unfair on the mini motion as it was a cold start for that session. I checked my sailing logs from the mini motion and generally it is tracking 17 or 18 sats.
So today it was a 1 hour stationary test. Both units sitting on the ground with a clear view of the sky. Perhaps not as clear as you might get on the water. But as good as possible in suburbia.
Below is a 20 second sample, apart from the first 2 or 3 minutes the entire hour looks much the same.
Not much point in telling you which colour is which device.
The BM-880 tracked between 20 and 25 sats
The mini motion tracked between 16 and 18 sats
Neither device missed a single point in approx 46,000
The highest 2 second peak recorded during the hour was 0.15 kt
Couldn't really hope for a better result.
I don't see much point in spending more on better GPS chips - This BN-880 is a winner!
Select to expand quotetbwonder said..
... Not much point in telling you which colour is which device.
The BM-880 tracked between 20 and 25 sats
The mini motion tracked between 16 and 18 sats
Looks pretty good for a stationary test. The closeness of the accuracy curves shows that Julien's approach of throwing out the worst satellites does not hurt at all - he gets the same accuracy with fewer satellites.
In previous discussions, someone mentioned that you sometimes see dropped points while surfing, even is there are none in stationary tests. I think that's also what I saw in my first windsurf tests with the SAM-M8. When surfing, the satellites the GPS sees sometimes change, and you may get more noise, especially in turns. That's when requiring a higher signal-to-noise ratio (CNO) can be helpful.
For fun, I started looking a bit into GPS algorithms. It seems that selecting the best subset of satellites to use is a non-trivial problem (journals.sagepub.com/doi/full/10.1177/1550147720929620) that can be quite time consuming. In stationary tests, the satellites change quite slowly. When we windsurf, we tend to block some satellites with body parts, and change the signal intensity of others by changing the orientation of the GPS antenna. So when we turn and change direction, the optimal satellite selection will change. Finding the next set of satellites to use could possibly take to long from time to time, and lead to dropped points. If so, that would be another argument for wearing the GPS on top of your head, Mike -style , rather than on the arm.
Select to expand quotetbwonder said..
The BM-880 tracked between 20 and 25 sats
The mini motion tracked between 16 and 18 sats
Neither device missed a single point in approx 46,000
I was inspired to do a stationary 1Hr test comparison of Mini Motion and Manfred's GPS-Logit BT GPS, both at 10Hz.
With the Logit BT GPS I usually get a few missed points @ 10Hz when sailing. It will be interesting to see if that is any different in a stationary test.
I am also curios to compare the data file size. I know the 'Logit ubx file will be a lot larger and it also has the Nav-Sat sentence as well (@ 1Hz) which add a LOT of data.
Andrew, what was the size of your 1hr, PVT only, 10Hz file?
my artemis openlog arrived to day, I need a USB-C cable to connect to it,
But here's the config file it printed to card. A bit more complicated to the standard openlog! Apparently I can configure it by editing this file, but I think I'll wait for the cable and use the arduino IDE. That process is better dovcumented
sizeOfSettings=128
olaIdentifier=279
nextSerialLogNumber=1
nextDataLogNumber=1
usBetweenReadings=100000
logMaxRate=0
enableRTC=1
enableIMU=1
enableSD=1
enableTerminalOutput=1
logDate=1
logTime=1
logData=1
logSerial=1
logIMUAccel=1
logIMUGyro=1
logIMUMag=1
logIMUTemp=1
logRTC=1
logHertz=1
getRTCfromGPS=0
correctForDST=0
americanDateStyle=1
hour24Style=1
serialTerminalBaudRate=115200
serialLogBaudRate=9600
showHelperText=1
logA11=0
logA12=0
logA13=0
logA32=0
logAnalogVoltages=1
localUTCOffset=0
printDebugMessages=0
powerDownQwiicBusBetweenReads=0
qwiicBusMaxSpeed=100000
qwiicBusPowerUpDelayMs=250
printMeasurementCount=0
enablePwrLedDuringSleep=1
logVIN=0
openNewLogFilesAfter=0
vinCorrectionFactor=1.47
useGPIO32ForStopLogging=0
qwiicBusPullUps=1
outputSerial=0
zmodemStartDelay=20
enableLowBatteryDetection=0
lowBatteryThreshold=3.40
frequentFileAccessTimestamps=0
useGPIO11ForTrigger=0
fallingEdgeTrigger=1
imuAccDLPF=0
imuGyroDLPF=0
imuAccFSS=0
imuAccDLPFBW=7
imuGyroFSS=0
imuGyroDLPFBW=7
Mike, this is the setting file for the standard logging firmware. It will log from the build-in sensors, and automatically recognize dozens of compatible sensors, including the Sparkfun u-blox GPS units. But it will only generate text files, not .ubx files. For those, you need different firmware. The GNSS firmware that is linked to in the Sparkfun tutorial will work with the Sparkfun M9 chips, but not with the M8.
If you got the Sparkfun M9 chip and an antenna for it, you don't need the Arduino IDE. You can download the GNSS firmware binary and install it using a utility program from the Sparkfun site. That's much easier than compiling the software in the Arduino IDE (the biggest issue being that you have to figure out how to find all required libraries, and which versions of these libraries you need - depending on the firmware, the newest version does not always work!).
If you want to go the Arduino IDE way, I can just zip up my Arduino folder, which contains my modified sources and the libraries, and send it to you. I still find using the Arduino IDE a bit painful, though. If you have a Sparkfun M8 chip, I can also make a binary of my firmware that you can install with the Sparkfun utility.
Note that all the Sparkfun firmware assumes you use a Sparkfun GPS chip with a Quiic (I2C) connection. If you'd want to use the Openlog Artemis with a Beitian chip, you have to (a) solder and (b) modify the firmware. But if you solder, you might as well use the cheaper original Openlog.
Select to expand quoteboardsurfr said..>>>. But if you solder, you might as well use the cheaper original Openlog.
Thanks Peter, I was thinking of trying to get 10hz out of DY 1, just replacing the standard openlog with the artemis. But now Andrew has somehow managed to do that with a standard openlog, it all seems a bit of a waste of time. But now I think I'll try swapping the old logomatic for the artemis, it will make a smaller package and maybe chew up less current. So yep soldering is the order of the day, and I'll turn off all the other stuff and just use the serial pins. I like that this chip includes battery management. So just the 880, battery and logger needed.
With the chip having an 18?a sleep mode may not even need an on/off switch.
To use the 880, you definitely will have to change the firmware. Everything in the firmware assumes you are connection through the Quiic port. I regard this as a non-trivial change, since you will have to change both the libraries used (which are in C++) and the firmware code (which is C). For reference, it took me a day or two for each of the changes that I regard as comparatively trivial, spending a few hours in the evening each day.
I don't have any plans to do any modifications to the firmware to support the serial port. Of all the ports that the u-blox chips support, the serial port is probably the worst. If I'd make any changes to support logging from other ports with the OLA, it would be the USB port.
If you want to get started with the Openlog Artemis, I strongly suggest that you get a Sparkfun SAM-M8 chip or an M9 chip with external active antenna. Hooking the BN chips up to the OLA will have you face an uphill battle where you don't know yet how tall the hill is.
Although there might be one potential alternative, if you still have a decent Neo-M8 chip around. You could hook up a Quiic cable to the I2C (DDC) pins, and then plug the cable into the OLA. You'd have to figure out how to deal with power, but that might be as simple as connecting two other lines in the I2C cable.
Select to expand quoteboardsurfr said..
To use the 880, you definitely will have to change the firmware.
I think that statement is wrong (I would have edited the post but can't anymore). The standard firmware seems to log data coming in over the serial port, just like the original Openlog. So switching loggers, like you had planned, might be a simple exercise after all.
Also, it seems using the USB port in the OLA to log data from a GPS connected through USB does not work. The problem is that USB always requires a controller and one or more devices. When hooking up to U-center or the Arduino IDE, the computer is the controller. That means the OLA and the GPS units are both devices, and devices only can talk to a controller, not to another device. So logging with a USB GPS would only work with something like the Pi Zero or a phone with OTG support. I just ordered the Sparkfun M9 chip with the U.FL connector. Should arrive in a couple of days. Now if only the warmer weather would arrive for some on-the-water testing! I'm just not ready to jump into 5 C water yet.
