Here's a picture that shows how well the logger fits into a $10 GoPro 8 housing:

The button on the housing of the side presses a push switch, which is glued onto a 3-d printed internal frame. It's allows switching on/off and between displays. The camera is mounted to the top part of a 3D printed boom mount for illustration (which needs a few refinements).

The housing is a bit too small for the wireless charging coil I got, but charging by cable is possible and easy enough. The 1100 mAh battery I used is good for a few sessions (it lasted 11 hours in a test). The housing is big enough for larger batteries, but I picked this one because it came with the right connectors.

Pretty excited about this. The display looks fantastic. The waterproof housing Flex developed looks fantastic, but the GoPro housing gets around having to deal with the waterproofing stuff that has kept Flex and Anita busy for a while . It's great to see others building units, and sharing their experiences and tips. It's wonderful that this is an open source project now. I'm sure it's just a question of time until we see configurable screens similar to the Motion (I like the "last run" speed display, for example). Big thanks to Jan for developing this!

Select to expand quote

boardsurfr said..
Here's a picture that shows how well the logger fits into a $10 GoPro 8 housing:

The button on the housing of the side presses a push switch, which is glued onto a 3-d printed internal frame. It's allows switching on/off and between displays. The camera is mounted to the top part of a 3D printed boom mount for illustration (which needs a few refinements).

The housing is a bit too small for the wireless charging coil I got, but charging by cable is possible and easy enough. The 1100 mAh battery I used is good for a few sessions (it lasted 11 hours in a test). The housing is big enough for larger batteries, but I picked this one because it came with the right connectors.

Pretty excited about this. The display looks fantastic. The waterproof housing Flex developed looks fantastic, but the GoPro housing gets around having to deal with the waterproofing stuff that has kept Flex and Anita busy for a while . It's great to see others building units, and sharing their experiences and tips. It's wonderful that this is an open source project now. I'm sure it's just a question of time until we see configurable screens similar to the Motion (I like the "last run" speed display, for example). Big thanks to Jan for developing this!

Very nice!

Fantastic to see what's happening with this collaboration. As peter says, now it's open source it can only get better.

Today time to remove the internals again and make the 3D printed housing more waterproof. Since PLA is leaky by nature, I will use 2k DD lacquer to seal the inside of the housing including the lid.
very small amount needed, so ~10gr lacquer and ~3gr hardner.
Nice to see that the surface becomes really smooth and shiny.
1 beta housing (test) and 1 final housing set to dry.
I have put them on the left side. They are printed from the right side up so the right side is good and strong by nature but the left side has "overhang" glitches and any additional lacquer can now enter the caverns.

The lacquer result is excellent, very nice coating. Added the 3M VHB 5952 tape on the plexiglass and pushed it into place. Also the edges stick a bit so it should not leak and the seal should remain flexible for pressure differences.
After putting all electronics back, it still fits nicely. It was already tight before but it still fits snug.
Now comes the scary part. The waterproof test... first static ??

I have now three different Beitian GPS modules in test : BN180, BN220 and BN280. (dim. 18, 22 and 28 mm). They all have the identical chip (M8030), but a different ceramic antenna. The BN280 has a magnetic compass (I2C, not used). But the firmware is also different !
The BN280 has next startup-output :
$GNTXT,01,01,02,u-blox AG - www.u-blox.com*4E
$GNTXT,01,01,02,HW UBX-M8030 00080000*60
$GNTXT,01,01,02,ROM CORE 3.01 (107888)*2B
$GNTXT,01,01,02,FWVER=SPG 3.01*46
$GNTXT,01,01,02,PROTVER=18.00*11
$GNTXT,01,01,02,GPS;GLO;GAL;BDS*77
$GNTXT,01,01,02,SBAS;IMES;QZSS*49
$GNTXT,01,01,02,GNSS OTP=GPS;GLO*37
The BN220 startup :
$GNTXT,01,01,02,u-blox AG - www.u-blox.com*4E
$GNTXT,01,01,02,HW UBX-M8030 00080000*60
$GNTXT,01,01,02,ROM CORE 3.01 (107888)*2B
$GNTXT,01,01,02,FWVER=SPG 3.01*46
$GNTXT,01,01,02,PROTVER=18.00*11
$GNTXT,01,01,02,GPS;GLO;GAL;BDS*77
$GNTXT,01,01,02,SBAS;IMES;QZSS*49
$GNTXT,01,01,02,GNSS OTP=GPS;GLO*37
The BN180 startup :
$GNTXT,01,01,02,u-blox AG - www.u-blox.com*4E
$GNTXT,01,01,02,HW UBX-M80xx 00080000 *43
$GNTXT,01,01,02,ROM CORE 2.01 (75331) Oct 29 2013 13:28:17*4A
$GNTXT,01,01,02,PROTVER 15.00*01
$GNTXT,01,01,02,GNSS OTP: GPS GLO, SEL: GPS GLO*67
$GNTXT,01,01,02,ANTSUPERV=AC SD PDoS SR*3E
The important difference here is the setting for used GNSS : ROM CORE 2.01 has no support for the Galileo system :
content.u-blox.com/sites/default/files/GNSS-FW2.01_ReleaseNotes_%28UBX-13004697%29.pdf
content.u-blox.com/sites/default/files/GNSS-FW3.01_ReleaseNotes_%28UBX-16000319%29_Public.pdf
Now the big question : Is there a better accuracy with the setting of the 3.01 firmware (+ Galileo) ?
Is it possible to upgrade the firmware from a Beitian BN module ?
(for those who want to check their own GPS : just read out the serial messages from the GPS-logger @ startup, the serial output from the GPS is directly copied to the T5 board).

Greetings, Jan.

I have all 3 of them in use as well. Haven't changed anything as it just worked. Would be interesting to see what a firmware update would bring if possible. the BN180 does not store the location so it always does a cold start. I can imagine this would be an issue for in the car driving through tunnels etc, but on the water, once having enough satellites it should be just fine. Perhaps when submergedan signal is lost, it will take a while to get back again.

I'm now working on a graphical stat screen showing the runs over time. The width of the bars are decreasing to maximize the available space. Maximum number is 43 (width=3 pixels) from that moment the new run is added on the right and the oldest disappears getting a scrolling effect.
It looks nice and usefull. Should be configurable what figure to show (2s, 10s, 500m, alpha, etc.)
I also woul like to indicate above what the top5 rankings are though numbers 1-5 on top of the bar.

Especially for changing conditions or experimenting with gear you should be able to notice the difference. Perhaps a line with a moving average might help as well. Not sure if I need to split starboard tacks from port tacks. Speed runs usually go in 1 direction...

Since it is open-source now it would be nice to collect the wishes/requests and see who will work on what... should those discussions be on Github itself?

Select to expand quote

Freezer said..
The lacquer result is excellent, very nice coating. Added the 3M VHB 5952 tape on the plexiglass and pushed it into place. Also the edges stick a bit so it should not leak and the seal should remain flexible for pressure differences.
After putting all electronics back, it still fits nicely. It was already tight before but it still fits snug.
Now comes the scary part. The waterproof test... first static ??

I would suggest a submersion test without the electronics just in case...

After 2hrs in a bucket, forced submerged. Opened it and I found some micro drops.
Then I went over to the pool for a dynamic splash test (nice to be on holiday). Jumped in helding it in my arm. Moving it quit a bit under water an sat for 50 seconds on the bottom at 2m depth.
Good test, but results are sad. Quite a bit of water in the case. Similar to what Flex saw with his casing. I will have a closer look at the seal construction. Will put some lacquer there as well to make that part also more smooth. Or redesign the part to make a wider rubber gasket as seal. Can't use this without my Paqua now. I don'twant to fill it up with resin... ??

maybe smear the seal with vaseline, then do a test. that will tell you if the seal is the problem

Select to expand quote

Freezer said..
I have all 3 of them in use as well. Haven't changed anything as it just worked. Would be interesting to see what a firmware update would bring if possible. the BN180 does not store the location so it always does a cold start. I can imagine this would be an issue for in the car driving through tunnels etc, but on the water, once having enough satellites it should be just fine.

The problem is that it can take longer to get all the required data. The shortest possible time to get the almanac data is 12.5 minutes. That's for one GPS system, with a clear line of sight to most satellites. I have seen cases where it took about an hour to get a proper fix after a cold start, so I would suggest to stay away from the BN180. With any chip, if you have not used your GPS for a few weeks, start it up at least 30 minutes before hitting the water.

Select to expand quote

Freezer said..
Perhaps when submergedan signal is lost, it will take a while to get back again.

No, the data are in volatile memory. Only turning the chip off will loose them.

Select to expand quote

Freezer said..
After 2hrs in a bucket, forced submerged. Opened it and I found some micro drops.
Then I went over to the pool for a dynamic splash test (nice to be on holiday). Jumped in helding it in my arm. Moving it quit a bit under water an sat for 50 seconds on the bottom at 2m depth.
Good test, but results are sad. Quite a bit of water in the case. Similar to what Flex saw with his casing. I will have a closer look at the seal construction. Will put some lacquer there as well to make that part also more smooth. Or redesign the part to make a wider rubber gasket as seal. Can't use this without my Paqua now. I don'twant to fill it up with resin... ??

Good to see results from different people, even if they are not as hoped for. Perhaps the seal is the issue, as Mike suggests. Not sure a bit of vaseline would really help that, though, since pressure from a crash (or jump into the pool) may just blast a little channel through the vaseline.
Part of the problem may well be that the 3 printed cases from filament printers just give the illusion of being solid. In reality, they are just a tightly woven 3-dimensional mesh, with lots and lots of little holes and channels in between. Filling each of these holes will be nearly impossible. Just think of how easy it is to get pinholes when laminating and top coating - any pin hole will become a problem over time. Even if you'd manage to get a perfect seal, you'd still have to worry about the two material expanding and contracting differently during temperature changes, which would introduce new holes over time.

As Flex had suggested before, maybe using an SLA/DLP 3D printer that basically builds an epoxy shell would work better than a filament printer. Or design a geometrically simpler housing and laminate it with glass and expoxy, leaving just the center of the screen free of laminate. You'd have to make a new housing if you ever would want to open it, but at least you could reuse all the electronics.

Select to expand quote

Freezer said..
I'm now working on a graphical stat screen showing the runs over time. The width of the bars are decreasing to maximize the available space. Maximum number is 43 (width=3 pixels) from that moment the new run is added on the right and the oldest disappears getting a scrolling effect.
It looks nice and usefull. Should be configurable what figure to show (2s, 10s, 500m, alpha, etc.)
I also woul like to indicate above what the top5 rankings are though numbers 1-5 on top of the bar.

Especially for changing conditions or experimenting with gear you should be able to notice the difference. Perhaps a line with a moving average might help as well. Not sure if I need to split starboard tacks from port tacks. Speed runs usually go in 1 direction...

Since it is open-source now it would be nice to collect the wishes/requests and see who will work on what... should those discussions be on Github itself?

I like graphics . I thought some graphics would also be nice for the "alpha in progress" display to show separation and distance.

With all these added bells and whistles, it will become important to less users decide what they want to see - both while on a run, and when in the "rotating screen mode" below the minimum speed limit (which should also be adjustable). For discussing the details of how to implement that, GitHub would be great.

The "Bar_graph" is now integrated in the latest SW version 5.50. Source code and compiled bin files are available on github : github.com/RP6conrad/ESP-GPS-Logger
The scale is variable, start from 0 - 24. Speed can be in km/h or knots. Max nr. of bars is 42, so you can see the latest 42 runs.
In the directory "Bin_files", you can download the correct file for your E-paper (now BN or B74). The bar_graph is Stat_screen 7, in the config.txt you can set the desired screens. There is a new template for the config.txt on the repository.
Greetings, Jan.

Select to expand quote

rp6conrad said..
The "Bar_graph" is now integrated in the latest SW version 5.50. Source code and compiled bin files are available on github : github.com/RP6conrad/ESP-GPS-Logger
The scale is variable, start from 0 - 24. Speed can be in km/h or knots. Max nr. of bars is 42, so you can see the latest 42 runs.
In the directory "Bin_files", you can download the correct file for your E-paper (now BN or B74). The bar_graph is Stat_screen 7, in the config.txt you can set the desired screens. There is a new template for the config.txt on the repository.
Greetings, Jan.

Great, I'm now working displaying the track, run or alpha as boardsurfr suggested. Until now I haven't spent a lot of time in the calculations, but if I want to plot something on x-y wile having access to lat-lon, I needed to study again....
I managed to create a home point "o" and then place the x at the right distance in xy distance. Will scale it automatically based on the data anda full trace. Not sure if the whole track is possible in the memory. Preferably with indicators where the highest speeds were achieved. Anyway, this is the (next) beginning...
Nice to have some time off and dive into these things ????

well Alby's started something here. He's got a group of us doing bulk orders for parts. Should be fun!

Select to expand quote

Freezer said..
Great, I'm now working displaying the track, run or alpha as boardsurfr suggested. Until now I haven't spent a lot of time in the calculations, but if I want to plot something on x-y wile having access to lat-lon, I needed to study again....
I managed to create a home point "o" and then place the x at the right distance in xy distance. Will scale it automatically based on the data anda full trace. Not sure if the whole track is possible in the memory. Preferably with indicators where the highest speeds were achieved. Anyway, this is the (next) beginning...
Nice to have some time off and dive into these things ????

I did not mean to see the entire track. I have several different GPS units that can do this, and it's a function I never use on the water. But what would be useful is some kind of graphics while in an alpha run that show (1) how far the legs are apart, and (2) the distance traveled on the second leg. I think the bar you're showing already does the second thing, and there are numbers for how far the legs are apart (?). But human brains usually can understand graphs more quickly than numbers. Here's a little drawing to illustrate:

The text labels are longer than they should be on the screen, and the current speed should also be shown.
As for the drawing, use the shortcut K888 has posted to get x and y positions once for each point, and save them. Subtract the position of the first point with a good fix, then you can use int32s to store at 0.1 mm precision, just like the distances for speed calculation.

Nice work Freeze and Jan. Got 5.5 working, there are a few syntax errors in the latest config.txt which may trip up some (think I have suggested the corrections in the github correctly). I like how you can now select the various (numerous) stats screens as you prefer in the order you want. The logos and contact info are nice in the sleep screen.... The new bar graph display works well. Its minor but the fix to get the timestamp on the file correct means the date on Freezers sleep screen is -1 day out for us in Oz.

Select to expand quote

Freezer said..
the BN180 does not store the location so it always does a cold start.

I have been looking at 3 different BN220 chips I have that vary quite a bit in how fast they get a fix, and how quickly the number of satellites goes up. Based on what I have seen so far, it seems that the satellite data are only stored in BBR (battery back RAM), not in flash. The only thing that seems to be stored in flash are the settings. Theoretically, that does matter, since any changes made to the settings are not saved. The only time it makes a difference is if you'd change something that is not explicitly set at startup using u-center. The BN180 appears to have a battery, too, so saving to BBR should work if the battery still works.

That said, one of my BN220s has a dead battery (I bought it years ago and never used it), and this one has a much harder time finding satellites every time. In theory, it should need only 12 minutes, but in reality, the effect seems to last much longer. I have the suspicion that the battery on one of the two units I bought just a few weeks ago is also dead, but will need to try running it for longer, since the battery charging is very slow.

There are two possible arguments against using a BN180: (1) it cannot use 3 satellite systems at the same time, and (2) the chips may be older, which would make it more likely that they arrive with dead batteries. Neither of these is an "absolute killer", since placing the GPS in the open where it has good reception for 20 minutes should get a usable signal, and the current firmware uses only 2 GNSS systems, anyway. But it is quite possible that future firmware versions will use 3 GNSS systems (by default or by config flag) since that gives better accuracy (needs more data but very likely), and BN180 systems would not support that. With a dead battery, they'll also produce quite poor results for the first 10-20 minutes (and possibly longer) if you switch the GPS on just before going onto the water.

Upgrading the software for the BN chips, if it is possible, would likely create problems, since the updated firmware would be in Flash rather than in ROM. This limits rates, since running the firmware from Flash is slower than from ROM. I have a few original u-blox chips and ripoffs that show this problem, and cannot reliably record at 5 Hz with 3 GNSS systems, something the BN220 and BN880 can do just fine.

My BN180 has a battery, and the times for a GPS fix are 60s to 120s. With a hot start, this is less then 20s. The BN280/BN220 is a bit faster, mostly <60s. I noticed that the sw version of the BN180 was still ROM 2, without Galileo support. The BN220 has ROM 3. Another interesting remark is in the ublox "manual" for the ROM 3. There is stated that with Galileo, the rate is max 3 Hz when executed from flash !
content.u-blox.com/sites/default/files/GNSS-FW3.01_ReleaseNotes_%28UBX-16000319%29_Public.pdf
4.12 Navigation rate The recommended maximum navigation rate supported is 5 Hz for standard multi-GNSS operation (GPS + SBAS + GLONASS + QZSS) and 10 Hz for single GNSS operation. When Galileo is enabled, then the maximum navigation rate when executed from flash is 3 Hz.
I do al the settings of the Ublox @ boot of the ESP-GPS logger, so they are not saved in flash. If you want to check your ROM version, you can read out the serial messages @ startup (Arduino terminal or another serial terminal ). The startup output of the ublox is then visible and the ROM version is in the message.

I have a feeling that, the 5HZ max navigation rate is with more than the NAVPT sentence selected.

Select to expand quote

rp6conrad said..
When Galileo is enabled, then the maximum navigation rate when executed from flash is 3 Hz.

The key here is the "when executed from Flash". As I said, running the firmware from ROM, which is what usually happens with BN units, is faster, and the units have no problem logging with Galileo at 5 Hz. I have other u-blox units where the firmware runs from flash, and they are not reliable at 5 Hz. Quite disappointing, since they here at least 2x as expensive as the Beitians.

Select to expand quote

decrepit said..
I have a feeling that, the 5HZ max navigation rate is with more than the NAVPT sentence selected.

Mike, there are three separate limits: 1. calculation speed, 2. serial bandwidth, and 3. logger speed and memory. When we see that sentences are missing or corrupted only when more sentences, like NAV_SAT, are added, the problem occurs in points 2. and 3. That was especially an issue with the Openlog. The Motions and ESP32 loggers have much more powerful processors and a ton more memory, so #3 is usually not an issue. The necessary bandwidth is easy to calculate; the ESP32 firmware uses 19,200 kb, so it would be expected to start having problems if you'd add NAV-SAT at 10 Hz (which requires a firmware change if you want to see the sentence in the logs). It would also be at the limit when logging just NAV-PVT at 18 Hz.

If you can log without problems from 1 GNSS, but get dropped or corrupted points with 3, then it's a calculation speed issue. Running firmware from flash, for example after updating the firmware, makes this worse. More GNSS systems means more satellite, which increases the amount of number crunshing needed to get a solution. It's quite likely that this goes up with the square of the number of satellites tracked, so 20 satellites take 4x as long as 10 satellites. Too much, and a solution cannot be calculated in the 100 or 200 milliseconds available at 10 resp. 5 Hz. That's why u-blox limits the number of satellites at high rates in the M9 chips, and why Julien limits them in the Motion.

Select to expand quote

rp6conrad said..
My BN180 has a battery, and the times for a GPS fix are 60s to 120s. With a hot start, this is less then 20s. The BN280/BN220 is a bit faster, mostly

Larger antennas means better signal to noise ratios, so the units with the larger antennas get the first fix faster. With the first two ESP32 loggers I built, I noticed quite a bit of difference in how quickly they get a fix, and how many satellites they track if the reception is not great (e.g. in indoor or balcony tests). Turns out that one of them gets a better signal than the other. Here's the C/NO plot from the better one:

C/NO levels are around 30. Not a single record was lost over ~ 90 minutes at 5 Hz (with NAV-SAT every 10th cycle).

For the other GPS chip that has a harder time getting a fix and often tracks fewer satellites, here's the plot (exactly the same time, units placed right next to each other):


For this unit, the C/NO levels are ~3-5 db lower. Note that this is on a log scale, that means the actual signal-to-noise ratio is 10-fold worse. The effect is quite dramatic: the first unit had no problem tracking Galileo satellites in this test, and tracked ~ 20 satellites (indoors). The second unit would occasionally see Galileo satellites, but was never able to download the almanac, and thus never got a fix on Galileo satellites during the 10-hour test. It got stuck at tracking ~ 12 satellites.

To get the images above, I modified the firmware so that if would log NAV-SAT sentences (the original logs only NAV-PVT, even if you configure the chip to send other messages). I also added config flags to use either 2 or 3 sat systems, and to log NAV-SAT sentences I'll put the change up on my fork on Github after cleaning the code up a bit.

It was a bit surprising that the second chip never got a fix on Galileo. I found a reference on the u-blox site that the firmware contains an almanac that, while not up-to-date, still can be useful to give the chip an idea where the satellites are, which helps in speeding up the first fix. Perhaps this almanac (in the 3.0.1 firmware "copy" in the BN chips) contains only GPS and Glonass data, but not Galileo. That would explain why the chips has a harder time getting a fix on Galileo. In the chip that had a fix on Galileo satellites, the C/NO levels are comparable for the different GNSS systems.

Select to expand quote

boardsurfr said..

Freezer said..
Great, I'm now working displaying the track, run or alpha as boardsurfr suggested. Until now I haven't spent a lot of time in the calculations, but if I want to plot something on x-y wile having access to lat-lon, I needed to study again....
I managed to create a home point "o" and then place the x at the right distance in xy distance. Will scale it automatically based on the data anda full trace. Not sure if the whole track is possible in the memory. Preferably with indicators where the highest speeds were achieved. Anyway, this is the (next) beginning...
Nice to have some time off and dive into these things ????

I did not mean to see the entire track. I have several different GPS units that can do this, and it's a function I never use on the water. But what would be useful is some kind of graphics while in an alpha run that show (1) how far the legs are apart, and (2) the distance traveled on the second leg. I think the bar you're showing already does the second thing, and there are numbers for how far the legs are apart (?). But human brains usually can understand graphs more quickly than numbers. Here's a little drawing to illustrate:

The text labels are longer than they should be on the screen, and the current speed should also be shown.
As for the drawing, use the shortcut K888 has posted to get x and y positions once for each point, and save them. Subtract the position of the first point with a good fix, then you can use int32s to store at 0.1 mm precision, just like the distances for speed calculation.

I like where your going with this idea to keep it visual. Another visual alternative would be to create a visual, like the Star Wars Targeting Computer that Luke "switched off!!" . You only need to know whether you're pointing too high or too low and what the closing distance is. You could just have a block that sits centrally on the screen if you are going to make the target distance and moves further off to the side if you are off track. The box gets bigger as you approach the 250m on the second leg and flashes when you get there, or a big X if you don't. This would just let you glance at the screen and see if you're on the right track.

Select to expand quote

boardsurfr said..
Here's a picture that shows how well the logger fits into a $10 GoPro 8 housing:

The button on the housing of the side presses a push switch, which is glued onto a 3-d printed internal frame. It's allows switching on/off and between displays. The camera is mounted to the top part of a 3D printed boom mount for illustration (which needs a few refinements).

Would you consider sharing the 3D printer file for the internal frame?

Select to expand quote

lwalker said..

boardsurfr said..
Here's a picture that shows how well the logger fits into a $10 GoPro 8 housing:

The button on the housing of the side presses a push switch, which is glued onto a 3-d printed internal frame. It's allows switching on/off and between displays. The camera is mounted to the top part of a 3D printed boom mount for illustration (which needs a few refinements).

Would you consider sharing the 3D printer file for the internal frame?

I put the 3D files for the internal frame in my fork of Jan's repository at github.com/prichterich/ESP-GPS-Logger/tree/master/3D_files

There are two different insets for covers - one for horizontal spacers and one for vertical spacers. Different housings may place them a bit differently, so you may need to adjust the design. I included both Wings3D files for easier editing, and .stl files for other 3D programs. The design can certainly be improved, it's the first thing I ever designed for 3D printing. For example, removing the printing support structures can be a bit of a PITA.

A few warnings: GoPro housings sometimes open in crashes! I have lost a GoPro this way. I now use housings that have a secondary lock, like shown in the picture. I accidentally used another housing that just had a simple latch in my last test, and noticed water drops inside the housing after just a few runs (and crashes), which cut the session short. In this case, the logger survived without problems, perhaps because I had painted most contacts with conformal silicon coating and saw the water and fog in the housing right away.
GoPro housings can also start to get leaky as they age. Over the years, I have also replaced a few GoPro housings that started to let water in after a while.

Note that the internal frame is designed for a 1100 mAh battery that's 7.8 mm thick. There's plenty of space for a larger battery, but you may have to modify the design if it is thicker. Here's a link for the batteries I used: www.amazon.com/gp/product/B0867KDMY7/r

Here's another very simplistic frame for using the logger with a waterproof armband:

I've tried this in one session, with the logger being double-bagged inside a "waterproof" armband, and reading speeds on the water was no problem. The displays are just great for outdoors.

In general, I plan to use the loggers with boom and/or helmet mounts, but I'll be windsurfing in the Dominican Republic soon. I don't want to deal with putting the boom mounts onto the rental gear every day -the boom diameter may be wrong for the mounts, and
I'd probably forget to take them off in the evening. It's so darn warm there that I doubt I want to use a helmet, so having an armband option should be good. I can fit one of my approved Openlog loggers into the same armband if I want to post to GPSTC, and get some validation data.

A new SW 5.51 update is available on github. If you have a Beitian BN220 / 280 with the ROM version 3.01 (firmware ublox M8N), it is now possible to switch on GALILEO gnss.(Default for Beitian is GPS + GLONAS). Unfortunately, the older ROM version 2.01 does not support this. In the config.txt is a parameter added : "gnss":3.
This setting will try to switch on GPS + GLONAS + GALILEO. The first test show that the nr of received satellites is higher with Galileo added (good reception : more then 20 sats).
Other changes :
* SW 5.51
* new run detection, min speed of 5 m/s
* max nr of stat screens change to 9
* bugfix Log_to_SD() before set speed to 0 with bad reception, checksum ubx was not correct with speed 0 !!!
* Added config.gnss : set for 3 gnss possible, works only with ublox ROM 3.0 !
* Check for GNSS setting : ubx msg MON_GNSS
* Add setting GNSS in txt file @ end of session

Greetings, Jan.

Select to expand quote

rp6conrad said..
* bugfix Log_to_SD() before set speed to 0 with bad reception, checksum ubx was not correct with speed 0 !!!

Just 2 days ago, I wrote some Python code to read UBX files and noticed that some of your test tracks contained bad checksums.

I was going to mention it but it sounds like you've probably fixed it now. :)