I have two built at the same time. One now at 95 the other 68.

Select to expand quote

decrepit said..
I have 2 units here, built at the same time, same firmware. one discharges quicker than the other. But both last about a month before charging needed. Then the good one will be around 50% the other could be about 30%.
So there are variations, but 1 week sounds wrong. I wonder if you have crook batteries?

yeah bit strange that my 3 and then one of my other team mates who build one himself also got the dodgy batteries...
Will review my AliExpress purchases to hopefully line up the good one.

Is the % reading affected by the battery calibration?
Or the full charge state?
Could this be the reason for the differences?
Otherwise it's likely due to battery variations.

Select to expand quote

decrepit said..
Is the % reading affected by the battery calibration?
Or the full charge state?
Could this be the reason for the differences?
Otherwise it's likely due to battery variations.

Yes, the % reading is affected by the battery calibration. With a perfect calibration, one should read 99% with a full charged battery (4.2V). Not 100%, as in the sw 100% is always the max value. The battery charging itselfs is not influenced with the bat calibration : there is a "battery charging chip" on the board, which regulates the charging. This chip will charge very precise to 4.2 V, with a current limit of 500 mA.
The reason for differences in discharge rate is difficult to say. Best to measure the sleep current before potting. And measure the max log time with a full charged battery, so you have an idea of the real battery capacity.
With a complete discharge, the protection chip in the lipo battery will cut the power. So no more wake up every 21600 s, no refresh of the screen. But it is still possible to load the battery : the logger will boot then ! Important : the charge current has to be higher then the "boot current" !! If not, the logger will be stucked in a "bootloop". I changed the SW a time ago to minimize the "boot current" : the logger will go to sleep directly after boot if the voltage is too low.
To be on the safe side : charge your logger when it is lower then 20%.

Cal_bat for the one at 68% is 1.70
Cal_bat for the one at 95% is 1.75

Here are some M8 vs. M10 comparison results that surprised me:


This is from a test drive on a street with trees on both side, so the signal is a bit noisy. Both M8 units show a lot of spikes, while the M10 is very smooth. Seems that the improvements are quite remarkable! This is just a small section from the drive, but it is very typical.
I think the M10 is a big improvement over the M8, and not just with regards to using less battery. The u-blox website claims for the M10:
"features advanced jamming, s****ing, and RF interference mitigation, as well as Super-S technology to boost performance in weak signal environments"

The lower power usage is really nice, though. This logger is Openlog-based, and the Openlog uses only ~5 mA. With the M10 current dropping from ~80 mA to ~ 45 mA @ 5 Hz, this means almost double the battery life. With an ESP32 logger and a display, the difference will be a bit smaller, but it's still good for those long distance days (and those who forget to recharge their devices ).

I have an M10 on order.
Not sure what I'll do with it, I'm thinking an arm esp32 unit. But maybe bag it instead of fully sealing it.
It will be interesting to compare an arm M10 to a head M8

In the graph I had posted above, I compared an Openlog M10 to two ESP32 M8s. The M10 looked much better, but in theory, that could have been partly due to Openlog (less RF interference, or similar). So I repeated the test today with an M10 in an ESP logger, an M10 in an Openlog, and two ESP M8 loggers. Here's a screen shot from an area with poor GPS signal (trees close to the street):


Both M8 loggers show a lot more noise than the two M10 loggers, which are quite similar to each other. So it's not the different logger, it's indeed the chips. The error estimates values (sAcc) are about 3-fold higher for the M8 chips in this region.

We don't usually windsurf between trees, so here is a look at a section where there were no trees nearby (a big parking lot):

Here, the differences are much smaller, and all GPS chips give pretty smooth data. Error values are closer, too, but a little better for the M10s. But while the M8 chips are quite good, the M10s are definitely better.

Very interesting observations Peter. Good work.
I assume those tests were also at 5Hz?

Yes, it's 5 Hz. Keep in mind that the sAcc values are useful, but also have their limitations. Here's one region from the track where the GPS signal was so distorted that even the M10 data got jittery:

For the last selected point, the speed for the first M10 (3rd set of columns) is off by about 2.5 knots, but the sAcc value is just 0.428. Outliers this big should be extremely rare - that's a six sigma deviation, which would be expected only once in 300,000 points. It's an example that the errors don't always follow a normal distribution, something that has been observed many times before.

I've decided to use the esp32 that wouldn't stay asleep, for an M10 armband test unit.
It's very simple at the moment, just battery M10 and esp32 held together by sticky tape.
1st car test looks good. All on the dashboard with good skyview.

Files and colors:
Decreps_2307021107.gpy - blue boom unit
2307021109_decrep.gpy - red boom unit
Arm_2307021109.gpy - green M10 proto
1st M10 test run 2 July.ubx - magenta DIY logger



I'm not seeing any difference in the speed graph at high resolution like Jan did, apart from the odd spike in the boom units


My Diy Logger and the M10 unit is very close. M10 is blue Diy is red

Select to expand quote

decrepit said..
I have 2 units here, built at the same time, same firmware. one discharges quicker than the other. But both last about a month before charging needed. Then the good one will be around 50% the other could be about 30%.
So there are variations, but 1 week sounds wrong. I wonder if you have crook batteries?

I built two new units in March this year. Same components and calibration as one I built a year earlier. Both of the new units discharge more quickly than the old one, Both newer ones were charged early this week and one is still at 100% while the other is down to 77%.

Select to expand quote

rp6conrad said..
A new SW 5.76 with next changes is available on Github :
Changes SW5.76
Sleeptime 3000s -> 21600s
nav_sat timeout 2000 ms -> 4000 ms
add 1h to speed screen, setting 9
bugfix wifiAP screen : name SoftAP
shutdown screen : Saving your session or Go back to sleep
Autodetect GPS only once, then saved in EEPROM, can be changed over the webserver (configuration), only set AUTODETECT again !
Added support for the ublox M9 (Beitian BK180/220 /280), logging@20Hz + 4 gnss simultan
@Bigboss :
My favourite is still the M10 (Beitian BE180 / BE220 / BE280), lowest current consumption, and 10 Hz is more then needed for our purposes. Standard, I always use the 5 Hz setting.
The size of the antenna has no big influence on the error, or the nr of sats (my experience).
Greetings, Jan.

loving the new text on the screens. That will make it so much easier for new users

Its been a few weeks, one of mine has very consistently dropped to 59 percent. The other one dropped fast to 28 percent but over the last few days its been changing between 21 and 31 percent. Temperature maybe?

Alternative for the reed switch : a RVS-switch with build in LED + silicone protection :
nl.aliexpress.com/item/1005001683893211.html?spm=a2g0o.order_list.order_list_main.16.3d7879d2eFsEwC&gatewayAdapt=glo2nld
nl.aliexpress.com/item/1005002233734339.html?spm=a2g0o.detail.1000023.8.17ea1Kd21Kd2bA&gatewayAdapt=glo2nld
I will build one with this switch and test how it performs.
Greetings, Jan.

Select to expand quote

rp6conrad said..
Alternative for the reed switch : a RVS-switch with build in LED + silicone protection :
nl.aliexpress.com/item/1005001683893211.html?spm=a2g0o.order_list.order_list_main.16.3d7879d2eFsEwC&gatewayAdapt=glo2nld
nl.aliexpress.com/item/1005002233734339.html?spm=a2g0o.detail.1000023.8.17ea1Kd21Kd2bA&gatewayAdapt=glo2nld
I will build one with this switch and test how it performs.
Greetings, Jan.

Thats look like a very big button! But would you use it as a read switch or an actual on/off button? I'd get longer life out of my units (the ones that only stay charged for a week).

Seems to be a push button, not an on/off switch. I don't think the reed switches have anything to do with the battery issues, though. My units in GoPro housings that have mechanical switches instead of reed switches show the same problem with the battery in some units draining much faster than in others when not in use. Was thinking to make some potted units, but may just stick with waterproof housings instead, where I can use the on/off buttons on the boards, and replace batteries.

Select to expand quote

boardsurfr said..
Seems to be a push button, not an on/off switch. I don't think the reed switches have anything to do with the battery issues, though. My units in GoPro housings that have mechanical switches instead of reed switches show the same problem with the battery in some units draining much faster than in others when not in use. Was thinking to make some potted units, but may just stick with waterproof housings instead, where I can use the on/off buttons on the boards, and replace batteries.

no no, def not saying reed switches are the cause of battery issue... I'm thinking either dodgy batteries or somewhere my build process is the cause...

Select to expand quote

Rolz said..
no no, def not saying reed switches are the cause of battery issue... I'm thinking either dodgy batteries or somewhere my build process is the cause...

May well be the batteries. I had a 1100 mA battery plugged in overnight. It started charging at 0.47 A, so should have been done in a couple of hours. This morning, it still was charging at 0.16 A. Something is not as it should be.

Another SW update is now on Github : SW5.77
Another contributor, Avo Prykk has done some good work !
Change list :
### Changes SW5.77 (mainly by avoprykk)
#### Fixed:
* OTA_Server firmware upload page javascript.
* GPS_Data changed BUFFER_SIZE from 10000 to 9500 as for fitting into 1.5M Image partition.
* Some compiler errors about types.
#### Changed:
* E_paper>
* Display unified row heights macros, changes in screens accordingly
* ESP-GPS logo size to 24x24
* Moved time, gps and battery for all screens to bottom row infobar.
* New screen for GPS initialization.
main.cpp> Ublox initialization moved after Wifi connections closed.
#### New:
* Partial code for OTA autoupload, dev status yet.
M9 15Hz support
* Added support to PlatformIO and partially for ESP-IDF (CMakefile.txt), thats why Rtos.ino moved to main.cpp. Wrapper module: github.com/aivoprykk/ESP-GPS-Wrapper
* Filename Rtos.h -> Definitions.h
* Added ESP_functions.h with general functions
* Bugfix Short_push for speed_field choice
* Added field 9 : Run-AVG, Alfa, NM, 1 hour
* Bugfix bat%@boot

Stat screen with info-bar example :



Greetings, Jan !

^ Like.

Select to expand quote

remery said..
^ Like.

And me

Jan, the longer time between sleep screen refreshing in the latest versions makes it difficult to tell when your unit is charged. Would it be possible to increase the screen refreshing rate during charging? It is not good to overcharge and risks overheating.

Select to expand quote

Windxtasy said..
Jan, the longer time between sleep screen refreshing in the latest versions makes it difficult to tell when your unit is charged. Would it be possible to increase the screen refreshing rate during charging? It is not good to overcharge and risks overheating.

You have a point, when charging the update rate of 4h is way too long. Although overcharging is not the issue because the charging chip on the board will prevent this, and the protection chip on the lipo itselfs is the second security.
But I have a idea which will optimize the update rate : checking the bat. voltage every 2000s, but only update the screen is there is a minimal change in the charging state. As the screen update needs the most power (1.5s), this will still optimize shelf life..
Greetings, Jan.

Select to expand quote

rp6conrad said..

Windxtasy said..
Jan, the longer time between sleep screen refreshing in the latest versions makes it difficult to tell when your unit is charged. Would it be possible to increase the screen refreshing rate during charging? It is not good to overcharge and risks overheating.

You have a point, when charging the update rate of 4h is way too long. Although overcharging is not the issue because the charging chip on the board will prevent this, and the protection chip on the lipo itselfs is the second security.
But I have a idea which will optimize the update rate : checking the bat. voltage every 2000s, but only update the screen is there is a minimal change in the charging state. As the screen update needs the most power (1.5s), this will still optimize shelf life..
Greetings, Jan.

Thankyou

I just updated a couple of units to 5.77 (from 5.75 and earlier). Most of the (cumulative) changes are great. But I get the impression that the minimum speed to start logging is now linked to the stat screen speed. If that is correct, I suggest to decouple that, and make a separate preference for "start logging" speed.
Here's why: When I sail, I typically want to see the stat screens when I am not planing. A minimum speed between 5 and 10 knots works great for that, depending on what gear I'm on.

But I often want to start logging when ready to go out. I learned this after loosing several sessions where the GPS did not record anything - sometimes because of user error, sometimes because the GPS acted up (e.g. hung when starting up). I also want to make sure I have the right speed screens selected, since I sometimes change them.
With a min speed to start logging of 1 or 2 knots, I can just wave the GPS around a bit. With higher min speeds, that does not work anymore.

Will be fixed in the next update : start_logging_speed will be a separat configuration.
Greetings, Jan.

Has anyone ever tried to calculate the VMG?
en.m.wikipedia.org/wiki/Velocity_made_good
It's mainly used in sailing, but in IQ foil racing it is interesting as well. As there is no wind direction input, the only thing to use is the statistics of speed and direction, assuming the wind is constant. I think this is also how the polar plots are calculating the wind direction.

So gathering some data from the runs would enable one to calculate the VMG right? The more runs,.the more accurate the VMG will become.

Anyone experience with VMG calculations? Are there more things to consider? It should not be too difficult to keep track of this in the ESP-GPS. Looking forward for some feedback on this.

Select to expand quote

Freezer said..
Has anyone ever tried to calculate the VMG?
en.m.wikipedia.org/wiki/Velocity_made_good
It's mainly used in sailing, but in IQ foil racing it is interesting as well. As there is no wind direction input, the only thing to use is the statistics of speed and direction, assuming the wind is constant. I think this is also how the polar plots are calculating the wind direction.

So gathering some data from the runs would enable one to calculate the VMG right? The more runs,.the more accurate the VMG will become.

Anyone experience with VMG calculations? Are there more things to consider? It should not be too difficult to keep track of this in the ESP-GPS. Looking forward for some feedback on this.

To calculate the VMG, you need to know the actual wind direction. It is a challenge to calculate this out of the gps data. GPS speedreader has a algoritm that makes this "polar plot", and the wind direction is then calculated. I guess it looks for a symmetrical distribution, which then gives the wind direction. The more runs, the more accurate. Maybe Peter can tell more about this.
Greetings, Jan.

GPSAR has VMG graphs. Outside of racing, I'm not sure what the point is. I often look at polar plots, though, which show quite well well what angles to the wind I'm getting (using the "Straight line" speeds, though, to eliminate speeds during jibes and tacks).

The wind direction is calculated by balancing the graph so it looks like a butterfly. Sometimes, it comes out wrong by 180 degrees, but since we usually know the difference between a N and S wind, that can be adjusted with the slider on top. If you go upwind a lot better or harder on one tack than the other, or only jibe on one side and tack on the other, the estimated wind direction can be off, too.