Executing task in folder ISS_Aler_WeMos: C:\Users\joema.platformio\penv\Scripts\pio.exe device monitor <
— Available filters and text transformations: colorize, debug, default, direct, esp8266_exception_decoder, hexlify, log2file, nocontrol, printable, send_on_enter, time
— More details at Redirecting...
— Available ports:
— 1: COM1 ‘Communications Port (COM1)’
— 2: COM4 ‘Intel(R) Active Management Technology - SOL (COM4)’
— 3: COM8 ‘USB-SERIAL CH340 (COM8)’
— 4: COM21 ‘USB-SERIAL CH340 (COM21)’
— Enter port index or full name:
into your loop(s) which take more than around 1 second. For example, this loop delays half a second each time, so after two iterations, you will probably get reset:
while (WiFi.status() != WL_CONNECTED)
{
delay(500);
Serial.print(".");
}
you would need to add the above code to “feed the dog” into the loop to prevent it taking too long if the WiFi is not quick enough.
Apparently, this board also needs to yield() regularly to allow the WiFi to work.
Sorry if this is too vague, I still haven’t done any ESP8266 work yet.
You are still getting reset by the watch dog. Also, once connected to WiFi, you should yield() in loops and any places where the code is “doing a lot of work” otherwise, the WiFi processing will stop.
The ESP8266 has, I believe, a single CPU to handle your code, the WiFi etc while the ESP32 handles your code separately from the background stuff like the WiFi.
I’ve edited you post to fix the stack trce formatting. Please use three backticks to format code etc, thanks.
This stacktrace shows you’re still stuck in setup() with that while loop of checking the status() and doing a digitalWrite.
while (WiFi.status() == WL_CONNECTED)
{
digitalWrite(LED_BUILTIN, HIGH);
}
this will block the entire time you’re connected to WiFi and does not do what you want! If you are connected you call digitalWrite a million times with HIGH while not feeding the watchdog and blocking further execution, but if you’re not connected, you break out of the while loop, while not setting the built-in LED to LOW to indicate the other state. You should implement this “turn LED on/off if connected to WiFi” check periodically in the loop() as one single if statement (or ternary expression) as I’ve explained in ESP32 WiFi Yes, ESP8266 No - #2 by maxgerhardt, or even much better, use the WiFi event hooks! See example and lib code.
I’ll give you a pass since you did mention that you haven’t done any ESP8266 work, but that code will not reset the watchdog whatsoever, since delay is called, which itself feeds the watchdog
It’s the current version of the code…
while (WiFi.status() == WL_CONNECTED)
{
digitalWrite(LED_BUILTIN, HIGH);
}
that is guaranteed to fail every time, because there is zero attempt to feed the watchdog. A mere yield() would probably suffice, but if that problem were fixed, there is the minor issue that the code would never continue to the loop… the test should have been done in the main loop, and been an if/else test. not a while loop.
Yes, indeed… delays of 1-2 milliseconds inherently yield() to the underlying RTOS… giving it a chance to manage the wifi stack, satisfy the watchdog , etc…
As long as you write non-blocking code, and scatter the odd delay or yield() where you think there could be slowdowns, the ESP8266 is easy to work with…
You should use ``` before and after code snippets of any length, compile log snippets, stack traces, etc… basically anywhere there are characters the forum software could missinterpret as formatting. Forum software also generally won’t preserve spacing, so the mono-spaced (i.e. characters and whitepace are the same size) content won’t be formatted/displayed correctly. Plus when formatted correctly, long code or log snippets are put in their own scrolling region, making the post easier to read.
Whilst the ESP8266 and ESP32 have their own idiosyncrasies compared to the ever reliable Arduino Uno, the only major rule of thumb is to never write code that blocks setup() or loop() for more than a second or so… without using a yield() or a short delay (1-2 milliseconds is usually) to give the underlying RTOS (real time operating system) control again so it can do any tasks it needs to do.
This applies to the ESP8266 more than the ESP32, since the ESP8266 only has one processor core, which must manage the wifi AND your program, whereas the ESP32 has two processor cores, and by default the wifi/bt runs on one, and your code on the other.
Okay cool- it is now outputting to serial what it says is the number of seconds until the ISS flyover- but it’s wrong.
But NASA is also apparently wrong:
This shows a flyover RIGHT NOW.
But this:
shows the ISS hitting the horn of Africa as we speak.
I have my long/lat correct, and I filled in the correct time zone in the API…
Not sure what you mean… thhat is for the ESP32 and the ESP8266… and the Wemos D1 Mini is nothing specially… it’s just a ESP8266 with a given form factor.
What timezone are those times in? The ‘realtime’ status page says GMT, perhaps these are GMT also? If they are local time it will make things confusing… i.e. that page for me shows Sunday is
Sun Nov 22, 6:26 PM 3 min 20° 13° above WNW 18° above N
if it shows the same for you, it’s probably GMT, otherwise, possibly a headache…