All my life I’ve been fixing things! Honda motorbikes, Yamaha Outboard Motors, GRP Boats, Volvo Penta Marine Diesels etc. Then I got into computers when I bought a ZX-81 and taught myself programming. I got a job programming but soon ended up being the “go-to” guru (!) for unsolvable problems. After that, I was “promoted” to Oracle DBA and after learning about those databases, I was once again, fixing stuff.
Looks like I haven’t lost the knack, yet.
Anyway, I’m glad we got that sorted, but it’s just a matter of reading the error messages and working backwards. Usually, the first error you see is the cause of many of those that follow until the compiler gets back on track and the code starts to make sense again. Fix the first error and many of the others will vanish.
However, it’s always good to have an additional pair of eyes, sometimes.
There’s an #ifdef because Peter’s code is different from Pollux Labs original, which was written for some Neopixels, not a screen. Peter changed it to use a screen. If you read the platformio.ini file, you will see quite a few different environments ([end:xxxxx]):
- Nodemcu - which doesn’t define USE_OLED;
- D1_mini - which doesn’t use USE_OLED;
- D1_mini_OLED_17pixels - which does define
USE_OLED as part of the build_flags.
The default environment is the D1_mini.
So, Peter amended the code but some boards look to still use only the Neo pixels – D1_mini and nodemcu – but some boards can use the OLED display – D1_mini_OLED_17pixels – which I assume is Peter’s own board.
If the #ifdef USE_OLED line was missing, then the code would always attempt to create an OLED screen device/class/instance and this would barf on those boards that do not have an OLED.
The lines are probably greyed out due to syntax highlighting in VSCode, or, if VSCode has somehow scanned the platformio.ini file, found your default board etc etc, and determined that USE_OLED is not actually defined. I’m not aware of how the syntax highlighting works in VSCode, sorry.
The #ifdef is not harming your code, it’s protecting it is you inadvertently compile the code for a board without an OLED attached.
In the loop() function, and if USE_OLED was defined, this is displayed when the state machine variable, currentState, is still at the WIFI_INIT stage. Once connected to WiFi, this state changes to START.
In the code for the START state, the OLED is not changed in anyway. The stats is changed to GET_TIME.
In the code for GET_TIME, the OLED display should be cleared, just after Serial Monitor says “Getting the current time (UTC)…” – at this point, the OLED is updated to display “Get UTC Time”. This will repeat until the time is successfully obtained over WiFi. The state will then change to GET_NEXT_PASS.
In this state, GET_NEXT_PASS the OLED should be reading “Get Next ISS Pass” and Serial Monitor should display “Looking up next ISS flyover time…”. This will repeat until the next pass time is successfully fetched from the interwebs over WiFi.
If the next pass time is fetched, only the Serial Monitor is updated with the time from now, and the duration of the next pass. The OLED is not changed.
The state then changed to WAIT_FOR_PASS.
The code for which displays a count down to the next ISS pass, in the Serial Monitor, and on the OLED entitled “Next pass in hh:mm:ss”
And so on and on and on. If your OLED is only showing the “Connecting to WiFi” message, then, if you are using Peter’s original code, the chances are that your board is:
- Not connecting to WiFi;
- Is in a restart loop, because that’s what the code does when it can’t connect.
Cheers,
Norm.
