Rolz, better of downloading GPY file,and analizing through GPS Speedreader, files way smaller. My filesnormally about ~1Mb take around 10 sec to download.
Rob, the unit will consume some power as it still updates the screen (I believe t does anyway), if sitting idle for a couple of weeks slam it on the charger before you go out.
I cant use the gpy format as it's not recognised on ka72 and that is where we need to upload our tracks.
hey all... having an issue with downloading ubx files larger than 8MB it seems to reboot my device...
Also anyone else noticing wifi speed is really slow or is that just me?
I did some tests today, and it seems that there is a reboot with large files (10 MB worked here, 18 MB forces a reboot after 2 min). I could be the watchdog (60s), I am not sure yet. With FTP (WinSCP), the download from the 18 MB file went well, although it took 4 minutes.
Can you give it a try with FTP ?
ftp worked! thank you!
Any reason why wifi speed is so slow?
Older versions of the T5 e-paper had a blue LED which was always on. Current consumption was >1.5 mA in deepsleep. The newer version are without LED, these only needs 0.5 mA in deepsleep. Wake up to refresh the screen is now every 3000 s.
The battery correction has a minor influence to the loss % /day. I guess it is the battery itself, or a older version with blue LED.
I recharge my loggers every month or so when not in use. Do not let them run completely flat, as this is not good for the lipo.
Greetings, Jan.
These versions of the T5 have no blue LED.
So charge to 100% then recharge ever month?
I cant use the gpy format as it's not recognised on ka72 and that is where we need to upload our tracks.
How come?
The GSTC preferred method is to use GPSSpeedreader.
Some more words about file formats :
For every datapoint (1 Hz = 1 datapoint/s, 10 Hz = 10 datapoints/s) :
gpx format = 160 bytes, always limited to 1 Hz !
ubx format = 100 bytes (native ublox NAV-PVT sentence)
oao format = 52 bytes (motion format, not open source, not supported in the ESP-GPS)
sbp format = 32 bytes (GW60 locosys format)
gpy format = 20 bytes+ every 30s a 32 bytes frame (new open source format )
For KA72, sbp format is accepted !
If you want the NAV_SAT messages in the ubx file, the filesize will be even 50% to 100% larger !
So my advice :
Go for 5 Hz, unless you absolutely need 10 Hz !
Switch off NAV_SAT msg in the ubx, unless you need it !
Go for gpy files, unless you need a KA72 compatible format
Go for sbp files, for uploading to KA72.
Go for ubx, if necessary.
Only use gpx as nothing else would work, as the datarate is limited to 1 Hz !
(there is still a bug in the gpx format with the time format, will be fixed in the next update).
Greetings, Jan.
I cant use the gpy format as it's not recognised on ka72 and that is where we need to upload our tracks.
How come?
The GSTC preferred method is to use GPSSpeedreader.
For the Burrum Windfest competition it was held on KA72 ![]()
Hey one of my devices cracked a sad and now says "Config fail!" and boots up without connecting to my wifi and goes to loggin mode and the sail an board icons have been replaced with Starboard and Gaastra.
Should I just go into AP mode and copy over the config.txt file from the other device that is going ok?
That was a bit odd. Uploading the config.txt from the working unit didn't affect the problem one. So I opened the problem one in AP mode and looked at the config file, the wifi details seemed to be default with a wifi password ending in .UBX. So I changed the wifi details to home and was then able to open bother units in separate chrome tabs and just copied the details over to the dodgy one, rebooting and they are both good.
I was just hoping to adjust the battery decay on each unit so they were about the same. Now I have one at 1.75 and the other at 1.70.
My potting experiment failed. I had 2 working devices before potting and after a few days the first one failed and a couple of days later also the other one failed.
First I removed the lid and drilled some holes to check the reed switch. I had some problems with these at a device created for Anton but when I measured the resistance it was clearly still working. Then I drilled a few holes to check the voltages. I am able to measure the lipo voltage 4.07V at the 2x 3.3V pins and 5.2V on the 5V and Vbat pins. The GPS does not get it's voltage. The screen does not seem to refresh anymore. So I think it is the board itself. If it was the display I should be able to connect or see the GPS lights coming on or measure voltage on the GPS.
So I started to remove the 3D printed housing (sawing and cutting), and although it looks interesting it does not reveal anything worrying or disturbing.
The pouring epoxy is from mr.boat UV Ultra clear 75. Fully cures after 7 days at 20degC according spec. After 1 day I could still place the frame and sqeeze it a bit. After 2-3 days it felt solid as a rock. It does not get warm. No bubbles form. From these slow curing pouring epoxies I also don't expect mechanical stress. Nevertheless since I have 2 devices failing relatively short after each other it's not likely a coincidence.
Any tips for the next one? To rule out mechanical stress I could add some silicon or hot glue over the microcontroller on the PCB before pouring with epoxy.
Let me know if you have any (bad) experiences with pouring epoxy on these devices. Any help is appreciated.


Not able to salvage anything here. But for debugging I might be able to reach the connections.
I am able to measure the lipo voltage 4.07V at the 2x 3.3V pins and 5.2V on the 5V and Vbat pins. The GPS does not get it's voltage. The screen does not seem to refresh anymore. So I think it is the board itself. If it was the display I should be able to connect or see the GPS lights coming on or measure voltage on the GPS.
Let me know if you have any (bad) experiences with pouring epoxy on these devices. Any help is appreciated.


Not able to salvage anything here. But for debugging I might be able to reach the connections.
On the 3.3 V pins, the normal voltage is 3.3+/-0.1V, so that you measure there 4.07 V is not normal. On the 5V/Vbat , without USB or inductive charging active, you should measure the bat voltage. 5.2 V is rather strange, as the max lipo voltage is 4.2V.
No clue what is going on, but these measurements are certainly out of the normal range. Could you measure the voltage between RST and GND. Should be a solid 3.3V, if it is low, the ESP32 will not boot.
I am able to measure the lipo voltage 4.07V at the 2x 3.3V pins and 5.2V on the 5V and Vbat pins. The GPS does not get it's voltage. The screen does not seem to refresh anymore. So I think it is the board itself. If it was the display I should be able to connect or see the GPS lights coming on or measure voltage on the GPS.
Let me know if you have any (bad) experiences with pouring epoxy on these devices. Any help is appreciated.


Not able to salvage anything here. But for debugging I might be able to reach the connections.
On the 3.3 V pins, the normal voltage is 3.3+/-0.1V, so that you measure there 4.07 V is not normal. On the 5V/Vbat , without USB or inductive charging active, you should measure the bat voltage. 5.2 V is rather strange, as the max lipo voltage is 4.2V.
No clue what is going on, but these measurements are certainly out of the normal range. Could you measure the voltage between RST and GND. Should be a solid 3.3V, if it is low, the ESP32 will not boot.
I just checked the voltages one of the units that is still under construction (BN screen). When I have the board switched on and "waiting for speed" the display indicates a Bat:4.17V on screen. When I measure the two 3.3V pins they measure 4.09V. When I measure the 5V it shows 5.15 and the VBAT measures 5.17V. So it is quite comparable with the broken unit. The only difference is the GPIO39, that one measures on the working unit 4.09V while on the broken unit it is 0.75V, while switching nicely to 0V when the magnet is near.
The weirdest thing, the device came back to life after laying a while in the sun. I tried running and it started logging and then froze again. Not sure it was the temperature or the light. Tried it once more in the sun and did boot again! But also then just was able to capture 2 runs before freezing. After that no life for quite some time, so tried to put it in the fridge. That did not help. After putting it in the sun again for 15 minutes it booted again. Then connected to the ip adres, changed the wifi settings to a mobile hotspot, flashed the firmware once to a BN type (false) and it booted, the again to the correct B74 type.and would reboot. The tried the reed switch and switched off properly and was also able to switch on again. Now running for various runs without problems. Changing the config settings also just works. So for now 1 unit recovered. Unfortunately I destroyed the 3D housing so cannot connect the strap anymore. The other unit is still dead...

The weirdest thing, the device came back to life after laying a while in the sun. I tried running and it started logging and then froze again. Not sure it was the temperature or the light. Tried it once more in the sun and did boot again! But also then just was able to capture 2 runs before freezing. After that no life for quite some time, so tried to put it in the fridge. That did not help. After putting it in the sun again for 15 minutes it booted again. Then connected to the ip adres, changed the wifi settings to a mobile hotspot, flashed the firmware once to a BN type (false) and it booted, the again to the correct B74 type.and would reboot. The tried the reed switch and switched off properly and was also able to switch on again. Now running for various runs without problems. Changing the config settings also just works. So for now 1 unit recovered. Unfortunately I destroyed the 3D housing so cannot connect the strap anymore. The other unit is still dead...

Too bad, cheered too soon. It is dead again. The sun has set, so will give it another go tomorrow. Not sure yet what is triggering this...
Yes weird!!
Just a thought, if the resin shrinks a little bit as it sets, maybe that's opened a connection somewhere, expansion from sun warmth reconnects it?
Great community project! I saw Rolz's unit at Burrum Windfest, it's a really nice product.
However the teething problems and quality control issues encountered by some of the participants highlight how difficult it is to always get a consistent product.
This puts the Motion's /Julien's journey into perspective
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
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
Recognize all the points you make and remind me of the journey we all had. Yes, we could write it all down, but would we read the full discription before we start getting our hands dirty? Not me, although it could be very handy some times
. I do watch YouTube videos before I start any sort of new/learning activity, so we might want to give that a try. It reminds me that I did start on a PowerPoint with photos of every step with some pictures. It usually helps to visualize the whole process.
hey @Jan, reading your DIY-gps_Build_instruction on github I think ur diagram on where resistor is in the wrong spot...

your previously diagram had it like this...

Doesn't matter which way round resistor and LED go.
It's a 2 component series cct limiting voltage and current through the LED, that happens either orientation.
Doesn't matter which way round resistor and LED go.
It's a 2 component series cct limiting voltage and current through the LED, that happens either orientation.
Jan's circuit diagram looks right to me. GPIO39 is configured as a pull up input pin in Jan's code. So, it's disconnected state will be 3.3V. When reed switch shorts out it's terminals (with a magnet), the GPIO39 pin is then pulled down to ground, and current will be able to flow from GPI039 (GND), to 3.3V (electron flow) via the resistor and LED.
Electronics symbols are in conventional current. So, sometimes they cause confusion. Nb/ All diodes only allow current to flow one way. In electron flow terminology, that is from cathode to anode. In conventional current terminology, it's the other way round.
I had some interesting issues with one of my units recently. I got errors with downloaded GPY files, but the UBX files from the same sessions where fine. Same unit and firmware version that I had used for multiple sessions without problems. Upgraded the firmware to 5.74, and the problem persisted.
Trying to nail down the cause, I took the SD card and plugged it into the computer - now the GPY files were fine. After that, transferring the files again through the web interface also worked without problems, with the newly downloaded files perfectly readable.
Not quite sure what happened here. Could be an issue with the SD card connection, or the ESP memory, or something completely different. The ESP memory is well know to occasionally cause problems, often seen when the units don't boot up anymore.
This is an example why file formats with internal checksums are preferable. Both GPY and UBX files have checksums for every record, but SBP files do not, so corrupted records in SBP files cannot easily be detected.
There is a new SW update on Github : github.com/RP6conrad/ESP-GPS-Logger/blob/master/README.md
Changes SW5.75
Bugfix date-time format gpx files
Bugfix .txt file M8/M10 serial nr
Added TROUBLE screen if no ubx message for longer then 2000 ms
Added SPEED2 screen with giant Font (Simon Design)
Filesizes always in MB
Override watchtdog_task0 when downloading (large) files
Added SD Free space Mb in Boot screen
Boot screens changes by Simon, ESP-GPS logo added
Added actual SW version & Type of e-paper to Firmware page
Added future fly logo (basti)
Greetings, Jan.
There is a new SW update on Github : github.com/RP6conrad/ESP-GPS-Logger/blob/master/README.md
Changes SW5.75
Bugfix date-time format gpx files
Bugfix .txt file M8/M10 serial nr
Added TROUBLE screen if no ubx message for longer then 2000 ms
Added SPEED2 screen with giant Font (Simon Design)
Filesizes always in MB
Override watchtdog_task0 when downloading (large) files
Added SD Free space Mb in Boot screen
Boot screens changes by Simon, ESP-GPS logo added
Added actual SW version & Type of e-paper to Firmware page
Added future fly logo (basti)
Greetings, Jan.
new boot screens look great! :)
hey @Jan, reading your DIY-gps_Build_instruction on github I think ur diagram on where resistor is in the wrong spot...
This post and the responses made me realize how little I know about basic electronics, so I ordered a little ESP32 kit with lots of little experiments and a detailed tutorial. The second chapter had a trivial little circuit with a button and an LED, which worked. But the circuit had two resistors for the switch, and had the switch hooked up to both ground and 3.3V, quite different from the simple direct hookup of the reed switch. Measured some current for different configurations, and the resistors are not needed (make no difference), and neither is the 3.3 V connection if the pin is used in pull-up mode. I guess they probably just copied the circuit setup from older tutorials for simpler chips that did not have pull-up and pull-down resistors.
I went to ChatGPT for explanations, and it explained everything quite well. In the end, the unnecessary extra parts in the tutorial diagram helped me understand the use of input pins better. I probably could have done some Google searches instead, but found asking ChatGPT quite a bit more efficient. So now, I actually understand jn1's explanation
.
I'm currently looking into making a smaller ESP32 logger, either with a smaller paper display or without a display (as backup or for sessions that I just want to log). Has anyone played around with the Lilygo chips that have a smaller screen? Or maybe made a simple ESP32 logger using Python?
hey @Jan, reading your DIY-gps_Build_instruction on github I think ur diagram on where resistor is in the wrong spot...
This post and the responses made me realize how little I know about basic electronics, so I ordered a little ESP32 kit with lots of little experiments and a detailed tutorial. The second chapter had a trivial little circuit with a button and an LED, which worked. But the circuit had two resistors for the switch, and had the switch hooked up to both ground and 3.3V, quite different from the simple direct hookup of the reed switch. Measured some current for different configurations, and the resistors are not needed (make no difference), and neither is the 3.3 V connection if the pin is used in pull-up mode. I guess they probably just copied the circuit setup from older tutorials for simpler chips that did not have pull-up and pull-down resistors.
I went to ChatGPT for explanations, and it explained everything quite well. In the end, the unnecessary extra parts in the tutorial diagram helped me understand the use of input pins better. I probably could have done some Google searches instead, but found asking ChatGPT quite a bit more efficient. So now, I actually understand jn1's explanation
.
I'm currently looking into making a smaller ESP32 logger, either with a smaller paper display or without a display (as backup or for sessions that I just want to log). Has anyone played around with the Lilygo chips that have a smaller screen? Or maybe made a simple ESP32 logger using Python?
Currently in the code there is support for the GDEH015OC1 1.54" screen. Jeff Turner has experimented with this.
I think Rolz has experimented with the 2.66" screen. Both are present in the code. I haven't tried them myself.
The LilyGo Watch should work as well as it basically uses the same platform (ESP32+epaper), but probably requires some tinkering. Not sure if all IOs are available..
Another candidate could be the Lilygo T-display : www.lilygo.cc/products/lilygo%C2%AE-ttgo-t-display-1-14-inch-lcd-esp32-control-board
This board has no SD-card interface, but you can connect (solder) a SD-card module. Maybe the internal flash (version 16 MB) can be used for storing the logs (SPIFFS), but here some testing is needed to see if the logging speed is fast enough.
If you search for a ESP32 board, these demands are necessary :
Current deepsleep max 1 mA
4 Free pins for GPS : Tx, Rx, 2* Power
4 Free pins for SD-card interface
Free pins for Reed switch
If you want to use python, the complete sw has to be written again. More important, make sure you have a python library for the used screen. Execution of Python is a lot slower then C++, so there could be other issues rising.
A excellent book about electronics : The art of electronics, by Paul Horowitz !
Greetings, Jan.
Thanks, Jan and Freezer.
4 Free pins for GPS : Tx, Rx, 2* Power
Have you tried running M10 chips with just one power line? My BE220 uses 28 mA, the BE250 29 mA, vs. 50 mA for the BN220.
If you want to use python, the complete sw has to be written again. More important, make sure you have a python library for the used screen. Execution of Python is a lot slower then C++, so there could be other issues rising.
For a logger without a display, the code is pretty trivial, and examples of ftp and web servers to get the data are easy to find. For me, Python is (mostly) fun, while using C/C+ is painful. For displays, getting Python libs could be an issue, though. Seems the 1.54 in e-paper display does not have Python examples.
As for speed, pure logging is trivial, and display tasks will be executed from (compiled C) libraries. We're looking at 10 updates per second on a computer that runs at around 100 MHz. Even if you assume slowdown by a factor of 100 due to interpreted code, we're still at 100,000 operations per data cycle. That could be a problem for naive (N-squared) alpha code, to give an example, but otherwise should be plenty.
The bigger issue may be RAM and garbage collection. Running even simple code shows only about 50 kb free RAM, so a simple "python typical" approach of using lists of objects would have no chance to calculate 1 hour speeds. Should be fun to find out which combination of arrays, using Flash memory, and code optimizations is needed. The garbage collection is also a bit amusing, since Python uses rather primitive reference counting. A bit reminiscent of the early Java days where circular references would lead to memory leaks. Our software code still carries lots of remnants that had to be added 20+ years back to eliminate these leaks.