New SW 5.79 is on Github with next changes :
Speed screen NM big font, 2 digits after dec. point
Add file name option name_date_time_MAC (unique id for ESP-files)
Time out nav-pvt msg -> 10s, then trouble screen (No GPS-messages after 10s)
Check for nav-pvt msg after init gps, NOK -> then trouble screen
Greetings, Jan.
I'm getting that, "server index not found" error when I try to update the firmware, can't find the fix, search on this forum is useless.
Select to expand quotedecrepit said..
I'm getting that, "server index not found" error when I try to update the firmware, can't find the fix, search on this forum is useless.
Update is only possible if you are connected to the internet (connect to your home SSID), so in AP-mode update is not possible. Can this be the problem ? Can you update a older version ?
Greetings, Jan
I don't think so esp & computer are connected to the wifi modem, browser is connected to esp32's URL.
When I browse computer for the file, and either select and open or double click. It doesn't show up in the choose file window. I think that's the problem.
Same thing happens with all versions, that were no problem before.
Could it be a linux update thing????
Not sure if anyone else noticed this but been running an older BN220 unit alongside a BE180 (M10) unit for the last 4+ weeks (27 sessions). Consistently the newer M10 unit shows much better battery life as expected but the distance displayed on the unit (on sleep screen) is considerably less always showing +10% less distance. This is regardless of speed and whether chugging or planning at start. Other stats like 2s/Alpha agree but hr/NM may be affected by this distance glitch??. I keeping forgetting to check distance in realtime as I usually don't stop. The data files however match perfectly using KA72, GPSSeedreader, GPSAR etc and also ballpark Apple Watch so is trivial issue as data itself is fine. Both units running v5.78. Only difference in the configs is the M10 has GPS+GLONAS+GALILEO where the older unit has GPS+GLONAS. Older unit always display correct distance.
Image below: Left, Green/Blue is BN220 and on right blue/red is BE180/M10
Select to expand quoteFlex2 said..
Not sure if anyone else noticed this but been running an older BN220 unit alongside a BE180 (M10) unit for the last 4+ weeks (27 sessions). Consistently the newer M10 unit shows much better battery life as expected but the distance displayed on the unit (on sleep screen) is considerably less always showing +10% less distance. This is regardless of speed and whether chugging or planning at start. Other stats like 2s/Alpha agree but hr/NM may be affected by this distance glitch??. I keeping forgetting to check distance in realtime as I usually don't stop. The data files however match perfectly using KA72, GPSSeedreader, GPSAR etc and also ballpark Apple Watch so is trivial issue as data itself is fine. Both units running v5.78. Only difference in the configs is the M10 has GPS+GLONAS+GALILEO where the older unit has GPS+GLONAS. Older unit always display correct distance.
Image below: Left, Green/Blue is BN220 and on right blue/red is BE180/M10
Can you send me the ubx or gpy files and the configuration from both units ? Total distance is calculated out of the doppler speed, so not from the lat/long coord. Dynamic model indentical for both units ?
Greetings, Jan.
On another M10 difference note.
It seems that at 10hz the latest esp32 firmware has more missed points at 10hz, than the older 5.76. Has anybody else noticed this?
Select to expand quotedecrepit said..
On another M10 difference note.
It seems that at 10hz the latest esp32 firmware has more missed points at 10hz, than the older 5.76. Has anybody else noticed this?
Yep so have I
Select to expand quotedecrepit said..
On another M10 difference note.
It seems that at 10hz the latest esp32 firmware has more missed points at 10hz, than the older 5.76. Has anybody else noticed this?
Yes. The files I have seen from the later than FW V5.76 have an unacceptable number of missed points @10Hz. Changing back to FW V5.76 seems to solve this. Still a few missed points, but order of magnitude less, and acceptable..
From what we have seen, please stick to V5.76 for GPSTC approved devices until further notice.
Also, please adjust the settings in the device FW so the mac address is displayed in the file name. This identifies files from the approved devices.
Select to expand quotesailquik said.. >> Also, please adjust the settings in the device FW so the mac address is displayed in the file name. This identifies files from the approved devices.
It's at the bottom of the config file, it just says, "File_Date_time", choose the option that has MAC in it
I know I've just changed mine.
Select to expand quotesailquik said..decrepit said..
On another M10 difference note.
It seems that at 10hz the latest esp32 firmware has more missed points at 10hz, than the older 5.76. Has anybody else noticed this?
Yes. The files I have seen from the later than FW V5.76 have an unacceptable number of missed points @10Hz. Changing back to FW V5.76 seems to solve this. Still a few missed points, but order of magnitude less, and acceptable..
From what we have seen, please stick to V5.76 for GPSTC approved devices until further notice.
Also, please adjust the settings in the device FW so the mac address is displayed in the file name. This identifies files from the approved devices.
I am working on it, have to do some more testing. How was the configuration, only gpy , or gpy + ubx files written ?
Greetings, Jan
There's a point, I had gpy and ubx, I'll try with just gpy, and see what happens, wind is getting better here, season is just starting to kick in so with any luck it won't take too long to get results
Select to expand quotesailquik said..decrepit said..
On another M10 difference note.
It seems that at 10hz the latest esp32 firmware has more missed points at 10hz, than the older 5.76. Has anybody else noticed this?
Yes. The files I have seen from the later than FW V5.76 have an unacceptable number of missed points @10Hz. Changing back to FW V5.76 seems to solve this. Still a few missed points, but order of magnitude less, and acceptable..
From what we have seen, please stick to V5.76 for GPSTC approved devices until further notice.
Also, please adjust the settings in the device FW so the mac address is displayed in the file name. This identifies files from the approved devices.
what about those of us still running with the BN220 GPS? Are the missing points there as well? I can supply some files if needed.
Select to expand quotewhat about those of us still running with the BN220 GPS? Are the missing points there as well? I can supply some files if needed. se noticed this?
I think it is just an M10 problem, as I have not seen that issue with M8 based units.
But it would be good if someone with M8 based units can report.
My boom unit with an M8 has several missing points.
But I think this is OK, there's nothing over 200ms, which would mean lost data, potentially on a pB run.
The M10 problem had several missing points over 200ms.
M8 @ 10hz Observed time distribution (in ms):
99 4
100 93554
101 4
200 159
M10 @ 10hz latest firmware
Observed time distribution (in ms):
99 1
100 103168
101 1
200 4591
300 1
Select to expand quotesailquik said..what about those of us still running with the BN220 GPS? Are the missing points there as well? I can supply some files if needed. se noticed this?
I think it is just an M10 problem, as I have not seen that issue with M8 based units.
But it would be good if someone with M8 based units can report.
I did just some changes (sw 5.80), and had a short test M10@10 Hz, settings only gpy file on, UBX NAVSAT OFF. No missing points :
File: Ali_M10_2310231721.gpy
No problems reading Ali_M10_2310231721.gpy
Observed time distribution (in ms):
100 20471
0 time errors (0 above 5.0 knots), about 0 missing points
32 filtered points:
SDOP/sAcc 27 points; max speed: 7.0 kn
Acceleration 6 points; max speed: 7.7 kn
Make sure that LOG UBX NAF SAT OFF setting is used. Even if no ubx file is saved, it this setting is on, these messages are send by the gps and processed by the esp. As the message length of NAV SAT is equal to nr of sats in the nav solution, this can possible give a buffer overrun.
I will change the sw, so that this setting is only active when setting the rate @5 Hz are lower and ubx file is on.
Greetings, Jan.
Select to expand quoterp6conrad said..sailquik said..what about those of us still running with the BN220 GPS? Are the missing points there as well? I can supply some files if needed. se noticed this?
I think it is just an M10 problem, as I have not seen that issue with M8 based units.
But it would be good if someone with M8 based units can report.
I did just some changes (sw 5.80), and had a short test M10@10 Hz, settings only gpy file on, UBX NAVSAT OFF. No missing points :
File: Ali_M10_2310231721.gpy
No problems reading Ali_M10_2310231721.gpy
Observed time distribution (in ms):
100 20471
0 time errors (0 above 5.0 knots), about 0 missing points
32 filtered points:
SDOP/sAcc 27 points; max speed: 7.0 kn
Acceleration 6 points; max speed: 7.7 kn
Make sure that LOG UBX NAF SAT OFF setting is used. Even if no ubx file is saved, it this setting is on, these messages are send by the gps and processed by the esp. As the message length of NAV SAT is equal to nr of sats in the nav solution, this can possible give a buffer overrun.
I will change the sw, so that this setting is only active when setting the rate @5 Hz are lower and ubx file is on.
Greetings, Jan.
So if we use the ubx file and the M8 we're still ok?
all my users (inc me) use KA72 to upload so the gpy file isn't supported.
Select to expand quoteRolz said..rp6conrad said..sailquik said..what about those of us still running with the BN220 GPS? Are the missing points there as well? I can supply some files if needed. se noticed this?
I think it is just an M10 problem, as I have not seen that issue with M8 based units.
But it would be good if someone with M8 based units can report.
I did just some changes (sw 5.80), and had a short test M10@10 Hz, settings only gpy file on, UBX NAVSAT OFF. No missing points :
File: Ali_M10_2310231721.gpy
No problems reading Ali_M10_2310231721.gpy
Observed time distribution (in ms):
100 20471
0 time errors (0 above 5.0 knots), about 0 missing points
32 filtered points:
SDOP/sAcc 27 points; max speed: 7.0 kn
Acceleration 6 points; max speed: 7.7 kn
Make sure that LOG UBX NAF SAT OFF setting is used. Even if no ubx file is saved, it this setting is on, these messages are send by the gps and processed by the esp. As the message length of NAV SAT is equal to nr of sats in the nav solution, this can possible give a buffer overrun.
I will change the sw, so that this setting is only active when setting the rate @5 Hz are lower and ubx file is on.
Greetings, Jan.
So if we use the ubx file and the M8 we're still ok?
all my users (inc me) use KA72 to upload so the gpy file isn't supported.
I suggest you set the sample-rate to 5 Hz, as the issue with the M10 is @ 10 Hz. I dont know if 10 Hz is necessary for GPSTC, has to be cleared by the commitee.
Greetings, Jan.
10 hz is not necessary for GPSTC postings. GPSTC still accepts GT-31 postings that are 1 hz. The potential accuracy gain from going from 5 to 10 hz is minimal (typically 0.02 knots for 2 seconds, less for everything else).
I did some research and tests for the M10@10Hz missing points issue. I found this discussion : portal.u-blox.com/s/question/0D52p0000DTO6hlCQD/maxm10-navigation-solutions-missing
The same lost points issue as we have with the M10. Then I checked the GPS Time of the lost points : always exact on the full second !
Points with untypical dt (and speed > 5.0 knots):
1 200 ms at #1400 13:18:22.200 speed: 20.090 sAcc: 0.132
2 200 ms at #3219 13:21:24.200 speed: 28.168 sAcc: 0.142
3 200 ms at #4358 13:23:18.200 speed: 25.381 sAcc: 0.173
4 200 ms at #4417 13:23:24.200 speed: 22.170 sAcc: 0.159
5 200 ms at #4436 13:23:26.200 speed: 20.405 sAcc: 0.163
6 200 ms at #4445 13:23:27.200 speed: 19.689 sAcc: 0.154
7 200 ms at #4464 13:23:29.200 speed: 17.808 sAcc: 0.157
8 200 ms at #4473 13:23:30.200 speed: 16.194 sAcc: 0.156
9 200 ms at #4552 13:23:38.200 speed: 20.035 sAcc: 0.148
10 200 ms at #18220 13:46:30.200 speed: 21.100 sAcc: 0.187
11 200 ms at #18349 13:46:43.200 speed: 6.005 sAcc: 0.192
12 200 ms at #26846 14:00:54.200 speed: 24.611 sAcc: 0.173
13 200 ms at #26905 14:01:00.200 speed: 24.949 sAcc: 0.173
14 200 ms at #27624 14:02:12.200 speed: 27.377 sAcc: 0.181
15 200 ms at #27683 14:02:18.200 speed: 28.061 sAcc: 0.179
16 200 ms at #28642 14:03:54.200 speed: 25.196 sAcc: 0.163
17 200 ms at #28731 14:04:03.200 speed: 27.954 sAcc: 0.183
18 200 ms at #28750 14:04:05.200 speed: 29.169 sAcc: 0.171
19 200 ms at #28759 14:04:06.200 speed: 29.459 sAcc: 0.185
20 200 ms at #28778 14:04:08.200 speed: 29.208 sAcc: 0.171
This also point in the direction that the M10 can't keep up with the 10 Hz, as there is a higher workload on the full second (in the M10!).
As the M9 / M8 does not suffer from this 10 Hz problem, and the ESP sw is identical for decoding the messages, I believe the problem is in the M10.
It seems if you switch to a 2 GNSS setting, the problem should be solved.... So I suggest you change the setting for the M10 to GPS+GLONAS only, and run again some tests @ 10 Hz
Greetings, Jan.
Thanks Jan, I have a feeling that 3 GNSS @ 5Hz will give better overall accuracy than 2 GNSS at 10hz.
I tried yesterday with just gpy format recorded, and didn't make any difference.
I'm going back to 5hz.
Yep. I can confirm from my tests that my M8 Motions and M9 custom unit do not suffer from Missed points with 3 GNSS @ 10Hz. The M9 unit that Manfred made for me does not even miss points at 25Hz on 1 x GNSS (GPS), not that I would bother with 25Hz. 
I ran some tests in the car yesterday on an M10 ESP. FW V5.76
82 missed points out of 9652 @ 10Hz UBX with NAV-SAT on using 3 x GNSS. 23-28 sats being tracked. Mostly around 24-25. Error values for individual points between 0.12 and 0.25, but when sat count is at the higher end it is mostly around 0.15 - 0.16
It made no difference when I turned NAV-SAT off and did another run. So it does not look like the problem is overloading due to NAV-SAT messages being on.
0 missed points out of 8500 @ 10Hz UBX with NAV-SAT on using 2 x GNSS. 17-21 sats tracked, mostly 18-19. Error values on individual points between around 0.12 to 0.25. Mostly under 0.20, but with the higher number of sats it is mostly a bit higher than with the 3 GNSS. I say 'mostly', because the error values does not look to be tied directly to the number of satellites, and is likely as much influenced by the constellation geometry.
I prefer the higher resolution of 10Hz compared with 5Hz when I examining Alphas and my speed tracks so I will continue to use 2 GNSS @ 10Hz. It will also leave NAV-SAT on as I find it very useful for analysis if there are any strange results. The unit is still using around twice or more the number of sats that the Locosys units (GT-31 and GW-52/60) used, so I don't see any issues with accuracy.
I have absolutely no argument with anyone that prefers to use 3 GNSS @5Hz though. 
Picture of this ESP and Motion LCD just for interest:
M10 are underclocked because uBlox's goal was to close the gap with lower power competition. You can now bring them back to normal: content.u-blox.com/sites/default/files/documents/u-bloxM10-with-25Hz-Navigation-UpdateRate_IN_UBX-23006557.pdf
Select to expand quoteJulienLe said..
M10 are underclocked because uBlox's goal was to close the gap with lower power competition. You can now bring them back to normal: content.u-blox.com/sites/default/files/documents/u-bloxM10-with-25Hz-Navigation-UpdateRate_IN_UBX-23006557.pdf
Thanks for sharing this information, completely new to me ! So the default CPU clock rate (120 MHz) can be overclocked to 192 Mhz, but at the cost for a higher current consumption, and it is a irreversible change !
Detailed information how to do it can be found here : content.u-blox.com/sites/default/files/MAX-M10S_IntegrationManual_UBX-20053088.pdf
One has to send a hex ubx message that changes the "otp" memory (one time programmable). After that, the clock rate will be 192 Mhz for ever.
Select to expand quoteDavidRice said..
GPS DIY lessons
Having made a pair recently, with a lot of patient help from Captain Anita, I still managed to make some mistakes which may be helpful to future DIYers.Don't use a medium sized soldering iron with relatively thick cored soldering wire. The Captain was able to do so with the help of very high standard magnifying tools and incredibly steady hands, but I managed to make a mess of several joints, including too much flux, so we had to 'unsolder' them using woven copper tape to soak up the excess solder and flux. The copper tape worked surprisingly well.
Learning: buy a small tip soldering iron and some fine soldering wire for work on electronics (not the plumbing type which has a different type of flux). I also bought from Jaycar a heavy based tool with an LED magnifier and arms to hold small bits in place while soldering them. Only around $29.Learning: the soldered 'bridges' are tricky. Cut a short length of wire and solder that to the three terminals, rather than trying to bridge with solder alone.Don't be too firm pushing the assembled unit into the case. I broke one of the glass reed switches.
Learning: cut a slither off the Lilygo board, the nibs that protrude on the RHS close to the locating holes. A Dremmel tool worked really well. Only cut off a slither (say ? mm) but it made a difference.Before gluing the clear polycarbonate window onto the outside protection box, check the electronics are working - not just by taking it for a drive to check the display functions, but also check it will charge.
Learning: one of my units did not charge because I mistakenly but the ferrite below the battery instead of above. I knew where it had to go but made simple a mistake which meant I had to knock the window off to fix it.
When gluing the window onto the protection box, make sure the joint is well sealed, so the potting epoxy does not seep out. I actually anticipated this and taped around the outside, however, the potting mix still seeped out. I was able to stem this seepage by shoving the plastic surround over the tape, but by this time it was pretty messy.
Learning: paint around the joint with Rustoleum and let if cure before adding the potting mix. You can spray some Rustoleum into a glass jar and then dip the brush into it. This worked well for the second unit.
Don't put a messy, sticky unit in the sun to try and cure it more quickly, even after a couple of days. The potting mix was still just slightly fluid and a small amount seeped out which meant I had to top it up yet again. Learning: be patient, it takes many days to make these units.
Ricey
I understand that you did use epoxy, and fully potting your device? Does de decive still work? I will ask Flex to??. We still have issues with the ones that we have filled up with epoxy.
Select to expand quoteFlex2 said..
Not sure if anyone else noticed this but been running an older BN220 unit alongside a BE180 (M10) unit for the last 4+ weeks (27 sessions). Consistently the newer M10 unit shows much better battery life as expected but the distance displayed on the unit (on sleep screen) is considerably less always showing +10% less distance. This is regardless of speed and whether chugging or planning at start. Other stats like 2s/Alpha agree but hr/NM may be affected by this distance glitch??. I keeping forgetting to check distance in realtime as I usually don't stop. The data files however match perfectly using KA72, GPSSeedreader, GPSAR etc and also ballpark Apple Watch so is trivial issue as data itself is fine. Both units running v5.78. Only difference in the configs is the M10 has GPS+GLONAS+GALILEO where the older unit has GPS+GLONAS. Older unit always display correct distance.
Image below: Left, Green/Blue is BN220 and on right blue/red is BE180/M10
Sorry. The questions not about 5 or 10 hz. Does your devices still work. We (Freezer) have made a couple of device filled with epoxy (see older posts). First 2 freezes, latest ones does work for a while. One won't charge anymore. It looks like the wires are disrupting the magnetic field. So I drilled some holes to reach the wire from the battery. I manage to solder a second battery to the wires. And yes the device came back to live. It can be switch on and off, Happy :-).
But one day later the screen is half black?? And no response on switching on or off. Strange
We can't really explain why this is happening so we're a bit reluctant to use epoxy resin again. Maybe we should use PU resin but that's not logical because epoxy is used often for potting electronics.
any thoughts?
