Select to expand quotejn1 said..>>>Did you try the pull up resister hack ?. (did you understand what I was talking about ?)
Nup and sort of. But I do now, so will give it a go.
Well as soon as I retrieve my components from the factory.
The voltages that you have measured are acceptable, and the small variations are not suspicious. So I believe the extra pull up will not solve the problem. It is more likely that the ESP32 is the root cause.
If this was a commercial/safety product and working with assurance levels, dealing with a customer etc, then I would replace the micro. But, as it's a personal project, I want to save $$$, the environment etc, then I like to tinker first 
Select to expand quoterp6conrad said..
You could measure the voltage between gpio 39 and gnd, should be a steady 3.3 vdc. If there was waterintrusion in the pushbutton 39, current leakage is possible. You can always remove the pushbutton.
Greetings, Jan.
I had one unit that was doing weird things like being very hard to turn off and I think there were other problems but I can't remember what the other problems were. After advice from Jan I removed the push button switch and that solved the problem, even though the unit had nor been in the water yet. There was nothing to lose.
I would try removing the pushbutton switch before replacing the ESP 32.
At the moment I'm trying to figure out AP mode. Waricle and I managed it a week or so ago, but now I can't remember the user ID
nothing I've tried with ESP32 works, upper case, lower case or a combination. And the only instructions I can find about it, only mention the password. I think I'm looking in the wrong place, but it would be good to know what it is!
The AP password is.... "password" !
You can find it hardcoded in Rtos5.ino, line 488 :
const char *soft_ap_ssid = "ESP32AP"; //accespoint ssid
const char *soft_ap_password = "password"; //accespoint password
Only FTP will work in AP-mode, you can't flash (OTA) a new version over AP.
Greetings, Jan.
OK, silly old fart mode again!!!!!!
was trying to connect with browser, that's only for firmware updates! an FTP client has to be used, no matter which mode your in.
Select to expand quoteWindxtasy said..>>> I would try removing the pushbutton switch before replacing the ESP 32.
I've removed the 2 little ones, bit early to tell, but it's seems to behaving better now. I'll leave it on all night and see what happens.
Bat is 0n 3.99, if it only drops a tad, I think we're onto something.
nup didn't work, just come back to it on battery 3.89, so it's been on for a while.
This is good work. Once you all have figured out the bugs and fixed them and tested the results up the gazoo, I'm kind of hoping a standard design, construction, and firmware emerges that we can all benefit from. (And maybe purchase.) Crowd R&D is the best.
I don't think anybody is going down the road to make and sell.
The design is now very good, maybe the boom attachment could be improved, lacky bands seem a bit primitive.
Apart from one apparently faulty ESP32 unit, the problems I'm having are mainly because it's my first go at these devices.
We probably do need a standard test regime, so they can be approved for GPSTC use, without having to send multiple files in for approval.
Now in the "Official Beitian Store", the Beitian BN xxx GPS modules are dead cheap (<4?) . You can only order 1/type. But you could order different types, I have tried BN180, BN220, BN280. BN357 is rather big (35 mm), never tried it.
nl.aliexpress.com/item/1005004405692761.html?spm=a2g0o.store_pc_groupList.0.0.565f3f571XMSuE&pdp_ext_f=%7B%22sku_id%22%3A%2212000029066488485%22%2C%22ship_from%22%3A%22%22%7D&gps-id=pcStoreJustForYou&scm=1007.23125.137358.0&scm_id=1007.23125.137358.0&scm-url=1007.23125.137358.0&pvid=bc793a7a-fe71-4208-ad82-0787cb54fecb&gatewayAdapt=glo2nld
Greetings, Jan.
Here's another mystery.
1sec fairly synchronised SAcc pulses on highway doing 80km/hr.
8 units on dash, magenta, red, green and grey don't seem to as affected.
But black and blue are almost in lock step.
As the screen refresh rate is also 1hz, I suspect internal interference. Alby told me to keep the wires short, but I only cut the beitian wires in half. There's still a loop between display and antenna. It will be interesting to see if the results above have any relation to where these loops are.
Be back later, if anything looks conclusive.
I doubt that the screen refresh is a cause for this behaviour. This refresh is not synchronized with the GPS-data in the SW, so it is rather strange that for both units that the missed datapoint is exactly on xx.0 sec. As both units have this issue, it is more likely in the beitain data.
In the SW, freeRTOS (real time operation system) is used. The screen job and the gps-data is in two different "threads". Every ms, each thread gets processor time.
You can test this out by switching the beitians, to see which part is causing this.
Greetings, Jan.
Thanks Jan,
I'm not that worried by the odd missed point at 10hz, I guess it is strange that 2 units do it at exactly the same time. It's more the synchronised SAcc pulses that's caught my interest.
My initial investigation doesn't support my theory, some units with wires under the display have no pulses, and a unit with the extra wire alongside the display does have them.
Switching beitians is the next obvious step, I'll get back with results. a bit later, I think we are busy the next few days.
Another note of warning!
Looks like I've fried one of the units I took for a test the other day. It was fine before the test drive, but now has the same symptoms as the one that turns on randomly.
I wasn't using an earthing strap and handled the board, I think one of the chips got a dose of static.
Mike I have 7 units to be verified how many tests do the GPSTC require. I have used a mini motion to do the verification. Also who wants to view the results?
There's no cut and dried number. In theory one long test should be enough.
We know the capabilities of these things, we really just need to check, nothing unexpected is going on.
But we may need to ask for more if there's something ambiguous.
So a unit on each boom and a motion in a good position, on the head or upper arm if sailing, or all 7 on a dashboard with a motion. making sure they all have the best sky view they can.
This won't give optimum results, because of limited skyview, but if they are all comparable, that's a good indication things are fine.
Send them either to GPSTC via the contact button, or to me
Select to expand quotedecrepit said..
Another note of warning!
Looks like I've fried one of the units I took for a test the other day. It was fine before the test drive, but now has the same symptoms as the one that turns on randomly.
I wasn't using an earthing strap and handled the board, I think one of the chips got a dose of static.
Maybe there is a issue with the GPIO12 (reed switch for extra functions). I found out that this GPIO12@boot also set the voltage for the flash ! This means when the reed switch is activated @ boot, the voltage for the flash is 3.3VDC instead of 1.8VDC. Maybe this can damage the flash. See here : docs.espressif.com/projects/esptool/en/latest/esp32/espefuse/set-flash-voltage-cmd.html?highlight=gpio12
My advice : do not use the extra reed switch ! There is a SW-work around, but I have to figure it out.
Greetings, Jan.
So no pre approval prior to epoxying the units? Can be an issue if we epoxy then a data issue is found due to shifting wires etc. I have tested the units with motion in there current state not epoxied seems all good so might not be an issue. Did have one board the 8th for your info that is corrupt and no good, message was Fatal Error on MD5 on the compile, tried a couple things to rectify removed GPIO12 didn't work, also Jan gave a couple solution still no joy so for future reference best to order a spare board just in case.
Boz, I think we can do a pre approval, that's what I'm trying for with my test runs in the car. If you aren't in a hurry to pot, see how I go.
But we should do a quick check after potting to see nothing got changed.
Select to expand quoterp6conrad said.. Maybe there is a issue with the GPIO12 (reed switch for extra functions). I found out that this GPIO12@boot also set the voltage for the flash ! This means when the reed switch is activated @ boot, the voltage for the flash is 3.3VDC instead of 1.8VDC. Maybe this can damage the flash. See here : docs.espressif.com/projects/esptool/en/latest/esp32/espefuse/set-flash-voltage-cmd.html?highlight=gpio12
My advice : do not use the extra reed switch ! There is a SW-work around, but I have to figure it out.
Greetings, Jan.
Thanks Jan,
I've yet to figure out what that does, I can't see me using it, so I'm happy to disconnect it. But in our set up it shouldn't get activated at boot unless a huge magnet is used. We are using small button niobium magnets, that have to be fairly precisely positioned
Select to expand quotedecrepit said..
Another note of warning!
Looks like I've fried one of the units I took for a test the other day. It was fine before the test drive, but now has the same symptoms as the one that turns on randomly.
I wasn't using an earthing strap and handled the board, I think one of the chips got a dose of static.
Could be static, but also could be just bad luck. The reports of ESP32 boards going bad say that sometimes happens after months of use with finished gizmos (where static is no issue), although earlier failures seem to be more common.
static damage can have a very delayed effect. just weakens the chip without destroying it, then with use it succumbs.
replaced the defective Lilygos, one worked great the other had bad SAcc and low sats. I stuffed around all day, swapping things over, but bad always stayed with the same Lillygo. I concluded I must have done something wrong.
Measured Antenna voltage to find it was less than 2.5v. Silly old forgetful fart had left the 25,26,27 strap off. Jan did say somewhere that the Bietian required more omph that one connection could supply. I just proved it, installing the links brought voltage up greater than 2.9 volts.
Results now good, getting over 20sats behind the vehicle windscreen and SAcc numbers significantly less than 0.5 most of the time.
There is a update of the sw with next changes :
* SW 5.54
* Added extra Board / Sail logo's, design by Hans Scholten
* Added variable to config.txt : "stat_speed":2, // speed less then 2 m/s -> stat screens
* Filenr depends now from existing .txt files !! Bug if only log OAO files was active should be ok now...
* Shutdown screen : add type of E-paper (in case you forgot...)
* Webserver can now download and delete files from the SD-card !!!
* Contribution from Triton_dm on github !!
Files can be found here : github.com/RP6conrad/ESP-GPS-Logger
You can now dowload files over the webserver or FTP (contribution of Triton DM). Printscreen of the webserverpage :
Greetings, Jan.
