@robski I have noticed when I use the m5burner and embed my details it connects quickly. However the use case is that the wifi details are not know before hand and can change at any time. So that does not seem to be an option.
@ajb2k3 thanks for the info its something I can work around in programming, just not optimal for user.
I am designing a GPS disciplined oscillator and the goal is for a short-term stability to be better than 1 part per 10 to the 9th cycles. The uBlox GPS has 2 counter inputs. Approximately every second (1 measurement cycle) the GPS reports the count and the time of the last rising and falling edges on the counter inputs. These are reported to the nanosecond (10 to the -9 seconds). By subtracting the previous count and rising edge time from the current measurement you will get the number of counts and the time difference. From this you can calculate the frequency to approximately 1 part in 10 to the 9th. In the actual implementation you do this over a period of hundreds of seconds. In the example I gave the single precision calculation was in error by over 46 milliseconds. In a 1 second measurement this is approximately a 4.6% error! The problem arises because you are adding a very large number (5.31316281 x 10 to the 5th) to a very small number (657346 x 10 to the -4) and you need a result accurate to 9 decimal places not 1 decimal place. In the actual calculation these numbers were first scaled by a factor of 1000 and 1000000000 respectively so they were even larger numbers to start with. This code runs fine on a Pyboard with their double precision code. I would prefer to use a Core2 unit which has a much nicer display and form factor than the Pyboard and its display.
I believe the effort to create this new image is as simple as changing 1 definition to tell the compiler to compile code for double precision instead of single precision. If you interested here is a link to an individual who did this for the PI Pico. https://forums.raspberrypi.com/viewtopic.php?t=319525 For someone with the correct tools, knowledge and the source it appears to be a relatively easy task. Tools and knowledge I don’t have. In this case most of the effort would be in making people aware of the other firmware image and making it available for download.
Yes the baud rate is correct. The characters are not random. They appear to be a CRC error and it is being sent in hex rather than ASCII.
Anyway, I found that if I loaded the ESP32 generic binary file then it works. At least I can get to a Micropython REPL prompt. Of course, this version is probably going to me missing the libraries that I will need. I guess I will have to build my own binary version.
So I tried help("modules") to get the list of all modules. Turns out there is a reference to "_uasyncio" but the object looks like it is only a shell of a module. It has references to a Task class and TaskQueue class but no functions. An attempt to use _uasyncio confirms this. Sigh.
