Just read this thread from start to finish. Great work everyone for putting this together and by all accounts it is going from strength to strength. Time to order some parts I think...

@Alhop : Join the club ! Don't hesitate to ask for help here if you get stuck ! Read the manuals (see readme on the github) before order the parts !

Another day, another update ! As already mentioned, some changes for the NAV-SAT, some bugfixes, option filenaming....
SW 5.67
NAV SAT not with polling, but over cfg msg @ 10% rate of NAV PVT, configurable.
NAV SAT for M10 added @ 10% rate of NAV PVT, configurable
removed timeshift iTow NAV SAT
Added extra option filenaming
Some changes to header SBP
correction time bug in sleep screen
reset 30 min / 60 min bar if speed drops<2m/s for 120s (screen best 0.5h / 1h)

Greetings, Jan.
github.com/RP6conrad/ESP-GPS-Logger/tree/master

Pity you're not getting paid for all this coding Jan!

Select to expand quote

Alhop said..
Just read this thread from start to finish. Great work everyone for putting this together and by all accounts it is going from strength to strength. Time to order some parts I think...

My advice at the moment is to see how the cheap M10s work out, they could be a better option to the Beitian M8s.

Then decide if you are going with boom units or arm units.
Obviously Boom units have to be sealed, but an arm unit can be in a pouch, this gives you the option of changing stuff.
It also means you don't have to stuff around with wireless chargers and wifi.

Heed the antistatic precautions when building. I suspect I caused some problems by not being rigorous enough

Select to expand quote

elmo said..
The date issue is only on the sleep screen so no real issue performance wise

Also can be out on the stat screens. I use that on the water to know when to come in so I still make it to Happy Hour at the pub.

I use +8 for Western Australia, but the time and date can vary by anything. Sometimes one device is correct while the other is out by decades, with a time unrelated to anything.

G'day Jan,
The date formats on the file names appears to have a glitch with the dates coming up as randoms.







On another note the sleep screen now has posted the time and date when I shut it down with satelite coverage so that looks ok.

Great fun yesterday, gave the NM a bit of a tickle again, so handy to have that feature.

Select to expand quote

elmo said..
G'day Jan,
The date formats on the file names appears to have a glitch with the dates coming up as randoms.







On another note the sleep screen now has posted the time and date when I shut it down with satelite coverage so that looks ok.

Great fun yesterday, gave the NM a bit of a tickle again, so handy to have that feature.

On another note the sleep screen now has posted the time and date when I shut it down with satelite coverage so that looks ok.


yeh.strange.
indeed the sleepscreen displays the right time. But in operation not. Operation screen. Look at the real-time (16:49) and the time on the screen of the gps



Sleepscreen:

Time is right (shut off

@Bigboss : You are wright, in this screen there is still a bug. Will fix it with the next update. How about the filenaming with date_time_file, is this correct on your logger ?
@Elmo : Were you on the SW 5.67, or on a previous version ?
Greetings, Jan.

5.67 Jan

Yesterday one of mine started with the correct date but the other decided that 1964 was a good year! They were both on the boom and in the open when started.

Both of mine were all good, random isn't meant to happen with software.
But the NAV Sat worked a treat.



I haven't got around to seeing what happens to the inside unit in a gybe, that can wait till I have more time.

I can confirm that the random date issue switches between units. I'll be make sure they are both facing up when I turn them on today.

Select to expand quote

remery said..
I can confirm that the random date issue switches between units. I'll be make sure they are both facing up when I turn them on today.

my dates/times when downloading matches up with my other gps, but on the display it's like 45min ahead... initially I thought it was maybe dst added on but when I checked my watch it's wasn't exactly an hour ahead... was very strange.

Today I laid the boom flat on the ground with the DIY-GPS facing up before turning on, and both of them started with the correct time and date.

Select to expand quote

remery said..
Today I laid the boom flat on the ground with the DIY-GPS facing up before turning on, and both of them started with the correct time and date.

I normally start my gpss on the car dashboard when I'm putting my wettie on, that way they have time to grab sats, before sailing.
A habit I got into with the old units that had a very slow start.

Select to expand quote

rp6conrad said..
@Bigboss : You are wright, in this screen there is still a bug. Will fix it with the next update. How about the filenaming with date_time_file, is this correct on your logger ?
@Elmo : Were you on the SW 5.67, or on a previous version ?
Greetings, Jan.

_AndresBN280_1407180940.ubx

dit is de naam van de file. Oh .. this is the name of the file.

A new update is ready, with following changes :

SW 5.68
Analog bat measurement to function()
ESP32 time is now local time, min 5 sats visible !!
Add check for nav pvt valid flags time&date before setting the time (thanks Peter!)
Check for plausible year when GPS time is set (>=2023)
Removed timelib.h, only sys.time.h needed
Fix time_bug in different screens
Add Ubx ID M8(ROM3 necessary,5 byte ID), saved in .txt
Add Ubx ID M10(6 byte ID), saved in .txt
Add Class GPS_NAV_INFO + Evaluation last 16 NAV_SAT msg in log file .txt
Add navDOP msg to ubx file, if nav_Sat is active (for analysing data)

I hope the time-bug is solved with this one, if not let me know ! Some info about how it should work :
1. When there is a fix, and the NAV_PVT msg sets the flags for correct Time/Date, the time on the ESP32 is set, with the offset from the config.timezone.
2. When the minimal log_speed is exceeded, the File names are created with the actual "Local" timestamp, from the ESP32, this is Start session.
3. When ending the session, the files are closed, and get the "Local" timestamp (last time file changed). This is the timestamp you see in the webserver.
4. When downloading, most browsers give a new timestamp to the files. Filename never change !

For evaluating CNO levels (signal to noise ratio from Sats), following info from the last 10 NAV_SAT is now in the .txt file (actually averages from al sats used in the navigation, and then again average over 10 msg).

23.688 km/h avg 5_best_runs
29.557 km/h 11:50:52 Run: 2 S10 CNO Max: 46 Avg: 38 Min: 25 nr Sat: 24
26.692 km/h 11:54:20 Run: 5 S10 CNO Max: 47 Avg: 37 Min: 23 nr Sat: 21
24.450 km/h 11:51:39 Run: 3 S10 CNO Max: 46 Avg: 37 Min: 21 nr Sat: 23
21.915 km/h 11:48:42 Run: 1 S10 CNO Max: 46 Avg: 38 Min: 24 nr Sat: 23
15.827 km/h 11:53:39 Run: 4 S10 CNO Max: 46 Avg: 37 Min: 19 nr Sat: 21

Greetings, Jan.

Thank you.

FWIW, C/N0 is the carrier-to-noise density ratio.

How C/N0 differs from signal-to-noise ratio is described in the article below. Pretty geeky and most people probably needn't know there is a difference.

Still, I thought it might be worth a share for anyone interested.

www.insidegnss.com/auto/novdec10-Solutions.pdf

Just to make you aware, the GPX file is not legal for posting to the GPSTC. Typically GPX files don't carry the accuracy data we need of files checking.

Time bugs keep follow me, I noticed that in the SW5.68 the gpy files are not correct anymore... With changing from MakeTime() to mktime(), I forgot to adjust the offset from 1970 to 1900... No worrys, GPS_speedreader direct gives me the hint, it will be fixed with the next update.
Now for the good news, the cheap Ali M10 arrived today, and I did a short evaluation :
First issue : the colorcoding on the connector was wrong.
Second issue : The native baudrate is 38400, so SW has to be adapted.
I decided to go out for a battle between : Mateksys M10, Ali_M10, Beitian BN280 ROM3 and Beitian BN280 ROM2. Just a cardrive with the 4 loggers under the windshield. If anyone is interested in the data, give me a PM.
Settings : 5Hz, ubx with NAV_SAT, GPS+GLONAS+GALILEO (not for the ROM2, only GPS + GLONAS)
I was impressed, for me the Ali M10 is the winner, with the lowest sAcc values !










Greetings, Jan.

Select to expand quote

rp6conrad said..
Time bugs keep follow me, I noticed that in the SW5.68 the gpy files are not correct anymore... With changing from MakeTime() to mktime(), I forgot to adjust the offset from 1970 to 1900... No worrys, GPS_speedreader direct gives me the hint, it will be fixed with the next update.
Now for the good news, the cheap Ali M10 arrived today, and I did a short evaluation :
First issue : the colorcoding on the connector was wrong.
Second issue : The native baudrate is 38400, so SW has to be adapted.
I decided to go out for a battle between : Mateksys M10, Ali_M10, Beitian BN280 ROM3 and Beitian BN280 ROM2. Just a cardrive with the 4 loggers under the windshield. If anyone is interested in the data, give me a PM.
Settings : 5Hz, ubx with NAV_SAT, GPS+GLONAS+GALILEO (not for the ROM2, only GPS + GLONAS)
I was impressed, for me the Ali M10 is the winner, with the lowest sAcc values !










Greetings, Jan.

Great stuf Jan. Experiments pay off! I'm expecting 4 parts this week as well. Looking forward to the tiny M10... Making smaller cases with smaller receivers and smaller batteries. I've ordered now also lipo 102540 such it fits next to the receiver and does not need stacking. It is still 1300mah. With the power reduction of the M10 still better than a 2000mAh with a BN280/BN220. Switching to thinner lipo only makes sense if the receiver is also slim enough. 8mm would be nice (802540) for the size but then only 850mah left... Should be still plenty time for a full afternoon, not sure about a day though...

Select to expand quote

Freezer said..
It is still 1300mah. With the power reduction of the M10 still better than a 2000mAh with a BN280/BN220.

Not sure about that. My impression was that the ESP needs about the same amount of current as the BN220, each around 50 mA. If the M10 uses 20 mA, run time would be slightly shorter with a 1300 mAh battery. That said, I'm using 1300 mAh batteries with the BN220, and battery life is fine for 2-3 typical sessions without recharging.

Select to expand quote

rp6conrad said..
Time bugs keep follow me, I noticed that in the SW5.68 the gpy files are not correct anymore... With changing from MakeTime() to mktime(), I forgot to adjust the offset from 1970 to 1900... No worrys, GPS_speedreader direct gives me the hint, it will be fixed with the next update.
Now for the good news, the cheap Ali M10 arrived today, and I did a short evaluation :
First issue : the colorcoding on the connector was wrong.
Second issue : The native baudrate is 38400, so SW has to be adapted.
I decided to go out for a battle between : Mateksys M10, Ali_M10, Beitian BN280 ROM3 and Beitian BN280 ROM2. Just a cardrive with the 4 loggers under the windshield. If anyone is interested in the data, give me a PM.
Settings : 5Hz, ubx with NAV_SAT, GPS+GLONAS+GALILEO (not for the ROM2, only GPS + GLONAS)
I was impressed, for me the Ali M10 is the winner, with the lowest sAcc values !










Greetings, Jan.

Nice work. Looking at the speed graph, there's very little noise visible. Looks like you did the test drive on open roads with very little tree or housing next to the street? Differences tend to be larger if you drive in wooded areas, although there's a big random element that comes into play then.

sAcc is a good first indicator, but it would be good to also look at actual observed speed differences. For that, the more GPS units you use, the better. 7 is a good number .

One of the promising things about the M10 is to also track Beidou. Does that work with both M10 chips?

I gave 5.68 a go today. The stat screen showed the correct time. On shutdown the standby screen showed the correct date and time (time was behind about 2 minutes, maybe the time it took to shut down.).

Filename and timestamp matched nicely .... remery_2301111044.sbp ... 2023-01-11 11:07:56

I also noticed that starting, connecting to wifi, downloading, then switching off, doesn't clear the standby screen results from the last session... clever.

A couple of very low priority suggestions for typos.
Standby screen
Alp: to Alph:
Mile: to NM:

Stat screen
Dis: to Dist:

I did some current measurements @3V :
Beitian BN180 / BN220 M8 : 48 mA
Ali M10 : 24 mA
Mateksys Max M10 : 13 mA !
There is still another extreme small M10 ordered, from the same supplier :
nl.aliexpress.com/item/1005004305942499.html?spm=a2g0o.order_list.order_list_main.11.54c779d2mmsDzs&gatewayAdapt=glo2nld

The battle was done on a road with some trees, but in winter, they have no leafs now.
@Boardsurfer : GPS+GLONAS+BEIDOU can set with M8-ROM3, and with M10, 3 options now in the config. With a short test here, it seems that GPS+GLONAS+GALILEO received the most sats.
@Remery : Will take your proposals in next update.
Greetings, Jan.

New update :
SW 5.69
Change baudrate for M10 to 38400 bd, #define ALI_M10 in rtos5.h
Bugfix for gpy file : MakeTime -> mktime, offset from 1970 -> 1900, month -1 !!!
Option for other wake-up GPIO with #define in rtos5.h
Add type e-paper to .txt file
Some text in e-paper adapted : Mile ->NM, Alf->Alph, Dis->Dist
github.com/RP6conrad/ESP-GPS-Logger

Greetings, Jan.

Jan, one change I noticed with 5.69 is that the countdown at the beginning is a lot slower than before (when at home but not logging into wifi). Is that intentional?

Version 5.69 looked good today. But the stat screen time was behind by a couple of hours and the standby screen date was 1982. Awesome! That was the year I started windsurfing.

1980 for me