I have one that still works fine. The battery in the other from the start discharged faster during sleep mode, and slowly got worse over time. But the problem with this one now, is that it no longer recognises the SD card, so it no longer displays any speed info, or stores tracks.
Could this also be a potting problem? Elmo potted them, I don't think he used epoxy.
It was epoxy resin which I used
www.eparency.com.au/products/eparency-soft-ultra-flexible-resin.
I've noticed recently when charging it'll show 100% but when I take the units of the charger the charge can drop back down to around 80 something percent dependent on how long its been on charge for.
Select to expand quoteelmo said..
It was epoxy resin which I used
www.eparency.com.au/products/eparency-soft-ultra-flexible-resin.
I've noticed recently when charging it'll show 100% but when I take the units of the charger the charge can drop back down to around 80 something percent dependent on how long its been on charge for.
Thank you both for your response.
yes the sd card (failed) is a issue we have seen to.
The charging proces i recognize to, but thats technical not an issue. The display, displays the actual voltages the esp sees. When charging it sees the charging voltage (4.2v = 100%). That's indeed a little confusing (you have to know this). It's not like a phone that displays the battery voltage and/or charging progress.
interesting, you used a flexibel epoxy. I didnt know this exists. But I understand that the devices still work expect one has the sd card fail issue. That could be our thoughts that the epoxy creeps between the contacts :-|.
Select to expand quoteBigBoss said..elmo said..
It was epoxy resin which I used
www.eparency.com.au/products/eparency-soft-ultra-flexible-resin.
I've noticed recently when charging it'll show 100% but when I take the units of the charger the charge can drop back down to around 80 something percent dependent on how long its been on charge for.
Thank you both for your response.
yes the sd card (failed) is a issue we have seen to.
The charging proces i recognize to, but thats technical not an issue. The display, displays the actual voltages the esp sees. When charging it sees the charging voltage (4.2v = 100%). That's indeed a little confusing (you have to know this). It's not like a phone that displays the battery voltage and/or charging progress.
interesting, you used a flexibel epoxy. I didnt know this exists. But I understand that the devices still work expect one has the sd card fail issue. That could be our thoughts that the epoxy creeps between the contacts :-|.
Epoxy definitely doesn't 'creep' between contacts. The earliest potted example of this ESP was in Sep
'21 (page 5 in this thread) and still works fine despite extreme abuse and a lot of use. All SD failures for me (2) have been water ingress caused by me failing to put leash mount and drilling into the epoxy near SD card to secure a leash support. It took a few months before they started glitching, could dry them out in rice bath and they would start working but eventually became unusable. Like Elmo I used a Flex epoxy (chosen as cheapest on Ebay www.ebay.com.au/itm/402568052077?hash=item5dbaecfd6d:g:ZTIAAOSw8n9hVlOs&amdata=enc%3AAQAIAAAAwKaM7J6UguutJfAlOc7Qq4J1gguTfkAo8YIaCaS2FiQeYBv76bibi9Cph4YMwxZZw%2FIDcWGobuemONJAEQxvsk1wjoJzQ8KZ7qGoV4a6DTPS2fLM4emFEaCzuPbsoypQlb9dDjnLwU72OBxRH8as%2FxnfaBIx%2BFRI7CuEOQNlFfGwM2gotznIDdqETlOgI7frcXSvjq45NE59bhKZCp9ZCjmrqR%2B2VkyyVfnKdsZ5oBxj1FzM7q%2B9BEy9XXaVAY2HBQ%3D%3D%7Ctkp%3ABk9SR7DN8LLxYg)
There is a new SW 5.80 update on Github with next changes :
Changes SW5.80
Extended choice for sample rate : add 4 Hz and 8 Hz
extended choices for GNSS
M10 4GNSS : GPS+GLONAS+GALILEO+BEIDOU, max 4Hz or lost points....
M10 3GNSS : GPS+GALILEO+BEIDOU_B1C : 8Hz possible with no lost points (default = GPS+GALILEO+BEIDOU_B1L )
M10 3GNSS : GPS+GALILEO+GLONAS, max 5Hz or lost points....
M10 2GNSS : GPS+GLONAS or GPS+GALILEO : 10Hz possible with no lost points
Sample_rate limited in function of GNSS settings (M10)
Some Wifi AP bug fixes
The "lost points" issue is caused by a combination from multiple GNSS @ 10 Hz. The M10 is capable of 10 Hz, but then you have to choose max 2 GNSS simultanous. With 3 GNSS, sample rate should be set on 5 Hz or 8 Hz. This is now limited in the SW, so the sample rate is set to the max rate depending on the GNSS setting.
Greetings, Jan.
I love 8hz, I was using it ages ago, but trouble is you can't compare with files that are 5hz or 10Hz.
So for me that limits it's use, but I'll certainly try it, sounds like a great solution.
Thanks again Jan.
Jan, can you specify which exact M10 chips you used for your max hz rate / dropped point analysis? There may well be differences between different suppliers. For the M8, the original u-blox chips were unable to handle 3 GNSS at faster rates, but the Beitian chips had no problem. One suspected cause was that the u-blox chips ran the firmware from Flash, which is (apparently) slower than the ROM that the Beitian chips used. I think some chips (not the Beitians) allowed updating the firmware and then possibly switched from using ROM to using Flash.
Also, did you look at the number of satellites used when using 8 Hz on M10? At some point above 5 Hz, the M9 and M10s limit how much satellites they use (to 18, I think). This could negate any possible accuracy gains from the slightly higher hz rates.
All tests were done with a Beitian BE182 with the ublox M10050 chip. Readout : Ublox SW-version : ROM SPG 5.10 (7b202e)
Ublox HW-version : 000A0000
It looks like the M10 has internal no restrictions for GNSS settings and baudrate. I could set 10 Hz in combination with 4 GNSS. Satellites in nav solution maxed out to 32 (hardware limit I guess) in that case. For 3 GNSS, max sats was 24 - 26. For 2 GNSS, max sats were 18 - 20.
The specification for the M10 (content.u-blox.com/sites/default/files/MAX-M10S_DataSheet_UBX-20035208.pdf) has next max values :
But garantueed fix rate is then minimum 98%. The high performance setting was not used.
A recent note about the high performance gives slightly better values for the default setting.(content.u-blox.com/sites/default/files/documents/u-bloxM10-with-25Hz-Navigation-UpdateRate_IN_UBX-23006557.pdf).
My advice, If one really need the 10 Hz, go with the 2 GNSS setting. Alternative, go for the M9 (Beitian BK range).
Greetings, Jan.
I would suggest to re-visit the automatic limits on hz rates for multiple satellite systems.While I understand the rational behind the current approach, there are quite a few things that need to be considered.
The first thing is that using 3 satellite systems at 10 Hz worked quite well on the Beitian M8 chips. It seems somewhat unlikely that tracking 3 GNSS systems has gottenworsein the M10 chips. The u-blox documentation has always stated that the limit for 3 GNSS systems on M8 was 3 hz. But this apparently was caused by firmware running from Flash, which does not happen anymore on M10 chips.
The recent u-blox document that you posted a link to basically says "our previous numbers were too pessimistic". They simply increased all numbers, without changing anything in firmware, and the new numbers also apply to previously sold M10 chips. The have the "configuration required" footnote, but they primarily suggest to limit what messages are sent, and to increase the baud rate (although they also give instructions on how to overclock the GPS chip).
u-blox gives one useful hint about dropped points: that the GPS may not be able to calculate a fix if there are too many satellites to track. They specifically point to Asia, where this may occur due to the large number of Beidou satellites. But this means that other regions of the world with fewer satellites in vieware less likely tohave problems. Therefore, basing hard limits on tests in one region of the world may in effect handicap other regions.
The other question is what the actual problems, when they occur, look like. Often, these are single dropped points every 100 points, or even more rarely. Such single dropped points cause absolutely no problemsin speed calculations. If you believe that more data points are better, then having 99 points at 10 hz, with one missing point, is definitely better than having 50 points at 5 hz, with no missing point. But if the GPS drops multiple points in a row instead of single points, then a lower rate without dropped points would be better.
I did a test using a couple of M10s (Beitian BE220) and an M8 (BN220) for comparison to check for lost points. Here are the results from today:
M8, 10 hz, 3 GNSS: 2 missing points in 69,400 points (about 1 every hour)
M10, 10 hz, 3 GNSS: 117 missing points in 44,000 points (about 1 every 3-4 minutes)
M10, 5 hz, 4 GNSS: 0 missing points in 39,841 points
The largest observed time difference was 200 ms. Most of the 2 h test was on top of my van in a big parking lot with no obstructions and sunny skies, about 30 minutes were driving. With 3 GNSS systems, the units used 24-24 satellites; with 4 system, 29-30 (max. 31). The 4 GNSS setup was using an Openlog-based logger. Number of points don't match because the second unit's battery died, and the 5 hz unit was switched on a bit earlier.
Based on this test, running the M10 with 4 GNSS systems at 5 hz is perfectly fine, and limiting the rate to 4 hz is too conservative.
Select to expand quoteboardsurfr said..
I would suggest to re-visit the automatic limits on hz rates for multiple satellite systems.While I understand the rational behind the current approach, there are quite a few things that need to be considered.
The first thing is that using 3 satellite systems at 10 Hz worked quite well on the Beitian M8 chips. It seems somewhat unlikely that tracking 3 GNSS systems has gottenworsein the M10 chips. The u-blox documentation has always stated that the limit for 3 GNSS systems on M8 was 3 hz. But this apparently was caused by firmware running from Flash, which does not happen anymore on M10 chips.
The recent u-blox document that you posted a link to basically says "our previous numbers were too pessimistic". They simply increased all numbers, without changing anything in firmware, and the new numbers also apply to previously sold M10 chips. The have the "configuration required" footnote, but they primarily suggest to limit what messages are sent, and to increase the baud rate (although they also give instructions on how to overclock the GPS chip).
u-blox gives one useful hint about dropped points: that the GPS may not be able to calculate a fix if there are too many satellites to track. They specifically point to Asia, where this may occur due to the large number of Beidou satellites. But this means that other regions of the world with fewer satellites in vieware less likely tohave problems. Therefore, basing hard limits on tests in one region of the world may in effect handicap other regions.
The other question is what the actual problems, when they occur, look like. Often, these are single dropped points every 100 points, or even more rarely. Such single dropped points cause absolutely no problemsin speed calculations. If you believe that more data points are better, then having 99 points at 10 hz, with one missing point, is definitely better than having 50 points at 5 hz, with no missing point. But if the GPS drops multiple points in a row instead of single points, then a lower rate without dropped points would be better.
I did a test using a couple of M10s (Beitian BE220) and an M8 (BN220) for comparison to check for lost points. Here are the results from today:
M8, 10 hz, 3 GNSS: 2 missing points in 69,400 points (about 1 every hour)
M10, 10 hz, 3 GNSS: 117 missing points in 44,000 points (about 1 every 3-4 minutes)
M10, 5 hz, 4 GNSS: 0 missing points in 39,841 points
The largest observed time difference was 200 ms. Most of the 2 h test was on top of my van in a big parking lot with no obstructions and sunny skies, about 30 minutes were driving. With 3 GNSS systems, the units used 24-24 satellites; with 4 system, 29-30 (max. 31). The 4 GNSS setup was using an Openlog-based logger. Number of points don't match because the second unit's battery died, and the 5 hz unit was switched on a bit earlier.
Based on this test, running the M10 with 4 GNSS systems at 5 hz is perfectly fine, and limiting the rate to 4 hz is too conservative.
I will take this in account for the next update. For those who want to experiment with higher sample_rates, you can always "override" the max sample_rate settings by directly editing the config.txt file : download the config.txt, then change the sample_rate in the txt file, upload the file again. As long as you don't change the configuration over the webserver ("Submit"), the max limits will not interfere.
Greetings, Jan.
Select to expand quoterp6conrad said..
For those who want to experiment with higher sample_rates, you can always "override" the max sample_rate settings by directly editing the config.txt file : download the config.txt, then change the sample_rate in the txt file, upload the file again. As long as you don't change the configuration over the webserver ("Submit"), the max limits will not interfere.
Greetings, Jan.
Thanks for pointing that out, Jan. The web interface is so darn convenient that I completely forgot that the config file can be edited.
Thought I was going to see how the 8hz change worked, but it didn't "stick", when it reboots it's still on 5hz.
It will go below 5hz, but won't go over 5hz.
So I've read the instructions, and altered by downloading the config file. But I won't know if it's worked, until my next sail.
The limits for the sample rate depends on the GNSS settings :
In the c-file ota_server.h :
if((config.ublox_type==M10_9600BD)|(config.ublox_type==M10_38400BD)) {//limit sample rate for 3/4 GNSS M10, prevent lost points
if((server.arg("gnss").toInt()==3)&(server.arg("sample_rate").toInt()>5)){ doc["sample_rate"] = 5;}//gnss 3 = GPS + GLONAS + GALILEO
if((server.arg("gnss").toInt()==4)&(server.arg("sample_rate").toInt()>8)){ doc["sample_rate"] = 8;}//gnss 4 = GPS + GALILEO + BEIDOU_B1C
if((server.arg("gnss").toInt()==5)&(server.arg("sample_rate").toInt()>4)){ doc["sample_rate"] = 4;}GNSS 5 = GPS + GALILEO + GLONAS + BEIDOU
}
So, there is only a limit setting for the M10 :
For GNSS setting "GPS + GLONAS + GALILEO", the limit is 5 Hz
For GNSS setting "GPS + GALILEO + BEIDOU_B1C", the limit is 8 Hz
For GNSS setting "GPS + GALILEO + GLONAS + BEIDOU_B1C", the limit is 4 Hz
For GNSS setting "GPS + GLONAS ", the limit is 10 Hz
For GNSS setting "GPS + GALILEO ", the limit is 10 Hz
As these limits are only set when you "SUBMIT" the configuration over the webserver, it is still possible to change the sample rate directly in the config.txt file. So, first download the config.txt, then change "sample_rate": 10, save and upload the file again.
Greetings, Jan.
Thanks again Jan, so I've got, GPS + Glonas + Galileo @ 8hz now, I'll give it a good test and see how many points I loose.
Select to expand quoterp6conrad said..
The limits for the sample rate depends on the GNSS settings :
In the c-file ota_server.h :
if((config.ublox_type==M10_9600BD)|(config.ublox_type==M10_38400BD)) {//limit sample rate for 3/4 GNSS M10, prevent lost points
if((server.arg("gnss").toInt()==3)&(server.arg("sample_rate").toInt()>5)){ doc["sample_rate"] = 5;}//gnss 3 = GPS + GLONAS + GALILEO
if((server.arg("gnss").toInt()==4)&(server.arg("sample_rate").toInt()>8)){ doc["sample_rate"] = 8;}//gnss 4 = GPS + GALILEO + BEIDOU_B1C
if((server.arg("gnss").toInt()==5)&(server.arg("sample_rate").toInt()>4)){ doc["sample_rate"] = 4;}GNSS 5 = GPS + GALILEO + GLONAS + BEIDOU
}
So, there is only a limit setting for the M10 :
For GNSS setting "GPS + GLONAS + GALILEO", the limit is 5 Hz
For GNSS setting "GPS + GALILEO + BEIDOU_B1C", the limit is 8 Hz
For GNSS setting "GPS + GALILEO + GLONAS + BEIDOU_B1C", the limit is 4 Hz
For GNSS setting "GPS + GLONAS ", the limit is 10 Hz
For GNSS setting "GPS + GALILEO ", the limit is 10 Hz
As these limits are only set when you "SUBMIT" the configuration over the webserver, it is still possible to change the sample rate directly in the config.txt file. So, first download the config.txt, then change "sample_rate": 10, save and upload the file again.
Greetings, Jan.
I'm testing another batch of M10 chips (Beitian BE180), and it definitely looks like using conservative rate limits is a good idea. In a little battery endurance test today, I got long dropouts in both chips I was using after 4 respectively 7 hours. Both chips were configured to use 4 GNSS systems at 5 Hz. One had three large gaps without data, of 2, 20, and 2778 seconds, all after about 4 hours. The other one had a 3-minute gap after about 7 hours. In addition, both chips had one gap of 600 ms (2 missing points).
The timing is likely to be misleading, since the test had long stationary periods, and a couple of drives after 4 and 5 hours. Satellite visibility varied a lot, and was best in the stationary period between 4 and 5 hours, where one chip did not record any points. When I started driving again, both chips reported around 26-30 satellites being used. This indicates that the dropout was due to too many visible satellites. Here's a screen shots from points at the end of the large gap:
It definitely looks like the GPS chip stopped getting a solution because it had too many satellites to choose from.
On the water, this could happen much sooner, since the GPS has a better view of the sky than during most of my test.
I'm a bit surprised by this result. I have not seen such long dropouts before (except during long swims 
). It also illustrates that the result of tests may vary quite a bit based on satellite visibility, which varies by day, time, and geographic location. To avoid possibly loosing a top speed run during a speed session, it's probably better to stay away from using 4 GNSS systems when using M10 chips.
I find it interesting, and somewhat puzzling, that the M9 module (NEO-M9N-00B) is specified to run up to 25Hz on up to 4 concurrent GNSS (see M9N specs below), but the newer model M10 is only capable of 4 or 5Hz on 4 x GNSS. Of course, it does not necessarily mean they won't miss points ever at those Hz rates.. but the one I have does not seem to miss points @20Hz on 3 x GNSS (GPS+GLO+GAL), although a few more tests are needed to confirm.
It would appear that Manfred Fuchs is using M9 in his 'live results' units at Luderitz (@20Hz) The test unit he sent to me uses a Mateksys M9N 5883 Module, but a search for that yielded very few hits for availability. Most say 'discontinued'.
I there a suitable M9 based module still readily available to use in the ESP? Anyone tried it?
From: content.u-blox.com/sites/default/files/NEO-M9N-00B_DataSheet_UBX-19014285.pdf
1.2 PerformanceParameterReceiver type
SpecificationMulti-constellation GNSS standard precision receiver
NEO-M9N-00B - Data sheet
Keep in mind that the M9 chips need about 70% more power than the M10s. For anyone who sometimes forgets to recharge the GPS, or does long sessions, that can be much more relevant than any potential accuracy gains. For 2 boom mounted M8 units, the 5x10 numbers typically differ by only 0.03 knots, so there's not a lot to gain. Nautis and hours differ even less. Alphas can differ more, but that's because one of the GPS units actually has to travel further if there's a curve in the middle.
Other question
I log Ubx, gpy and gpx files on the esp32. I only use gpy to upload to gps-speed surfing. Eh why do I log the ubx file to ? :-) it's big and the logging uses power (not much) and space (not a problem). But still. I can't answer my own question :-). Here someone?
Select to expand quoteBigBoss said..
Other question
I log Ubx, gpy and gpx files on the esp32. I only use gpy to upload to gps-speed surfing. Eh why do I log the ubx file to ? :-) it's big and the logging uses power (not much) and space (not a problem). But still. I can't answer my own question :-). Here someone?
I just log UBX. Only really because it will open in all the software programmes I use, and I can log Nav-Sat as well which I find useful in analysis and trouble shooting.
Select to expand quoteJulienLe said..
M10 isn't the successor to M9. It's two different branches.
Ah. Thanks. I see now that M8, M9 and M10 are concurrent products.
Select to expand quoterp6conrad said..
The Beitian bk series has the M9140 chip, and are reasonable priced (20?).
Which of those Beitian BK M9 options do you recommend for the ESP? (Power usage not an issue). Advantages and disadvantages? Features that are better for us? (on board memory and /or Battery? Flash? Compass? etc?)
Ahh, I also just realised that the Beitian BN seem to the the M8 series, The BK seems to be the M9 series and the BE seem to be the M10 series. Learning curve going on here. 
I just assembled the logger (still without case and charge controller) without much knowledge of anything, so I just want to say great work Konrad! I just have a few questions (sorry if they are stupid):
- Whenever I turn the T5 off and on again, I seem to have to upload the .bin file again? Is that normal? Is it possible to have it stored on the SD and "autoupload" on a reset?
- How do you use the cal_bat to calibrate the battery? I did not use the recommended LIPO as it has not arrived yet, but used a battery of defect Locosys GW52 (LP 481928 0.93Wh). As I also have not yet received the charge controller, I wanted to charge via USB, but it does not seem to work (battery % does not increase). Do I need to do something to enable charging via USB?
Select to expand quoteBigBoss said..
it's big and the logging uses power (not much) and space (not a problem). But still. I can't answer my own question :-). Here someone?
Power use for logging is minimal. The peak current when writing to SD card can be quite substantial - numbers range from 80 mA to 200 mA as much. But current SD cards support write speeds of at least 10 megabyte per second. When writing a 10 hz ubx file, the data rate is 1 kilobyte per second, or about 0.01% (1 /10,000th) of that rate. So more than 99.9% of the time, the card is not being written to. The Openlog, a simple SD card logger that includes a microchip, has a resting current of 2 mA. The current use from writing the ubx file is probably below 1 or 2 mA. For comparison, the GPS chip uses around 25 mA, and the ESP board a bit more than that.
Space is not an issue, either. A 32 GB card will hold about 9000 hours of 10 hz UBX files. With 300 sessions per year, each 2 hours long, you'd need 15 years to fill up the card, assuming you never delete a file. But if you're still worried, you could always log to GPY files 
.
Select to expand quoteDONNERWETTER said..
- Whenever I turn the T5 off and on again, I seem to have to upload the .bin file again? Is that normal?
No, something is wrong. No clue what that is, maybe Jan has an idea.Select to expand quoteDONNERWETTER said..
- How do you use the cal_bat to calibrate the battery? I did not use the recommended LIPO as it has not arrived yet, but used a battery of defect Locosys GW52 (LP 481928 0.93Wh). As I also have not yet received the charge controller, I wanted to charge via USB, but it does not seem to work (battery % does not increase). Do I need to do something to enable charging via USB?
When you buy a Lipo battery, it usually includes electronics required for charging. Those you should be able to just plug in (after verifying that the polarity is correct - some batteries have the + and - wires switched).
But for batteries used in devices, the charging bits are often included on the motherboard, and not part of the battery. I did encounter this a bunch of years ago when I tried to replace the battery in a GT-31.
In one of the first units I built, I ran into another problem that caused the battery plug to not work anymore (I think I blew up some protection circuitry). Jan suggested to connect the battery directly to the battery pin and ground instead, and that still worked.
Select to expand quoteDONNERWETTER said..
- Whenever I turn the T5 off and on again, I seem to have to upload the .bin file again? Is that normal? Is it possible to have it stored on the SD and "autoupload" on a reset?
If you loaded the OTA firmware and then used that to load jans software if the board losses power it drops the soft ware out of memory. It must write it to a volatile memory.
You can write jans software to the non volatile memory as well the same way as the OTA program and then it will survive a power loss.
Select to expand quoteboardsurfr said..
When you buy a Lipo battery, it usually includes electronics required for charging. Those you should be able to just plug in (after verifying that the polarity is correct - some batteries have the + and - wires switched).
But for batteries used in devices, the charging bits are often included on the motherboard, and not part of the battery. I did encounter this a bunch of years ago when I tried to replace the battery in a GT-31.
In one of the first units I built, I ran into another problem that caused the battery plug to not work anymore (I think I blew up some protection circuitry). Jan suggested to connect the battery directly to the battery pin and ground instead, and that still worked.
The battery of the GW52 also seems to have some electronics on it, from picture it looks really similar to the one that Jan recommends, just smaller. I connected it now to the battery Pin and now it seems to be charging.
