The URL you need to use is the “etc/utc” one that @pfeerick is using. The ISS overhead times etc are all in UTC so regardless of where you are in the world, the time you get from the ISS API for your location needs to be compared with the time in UTC.
If you changed to the LA times, you will be UTC-08:00 and will miss the ISS being over your head!
If you do insist in using the LA time zone, you need to add the negative of the “raw_offset” to the “unixtime” you get, so that you can compare your current LA time with the ISS UTC time.
I’m currently pretty close to 0 degrees longitude, and I’m currently in UTC but come March I’ll be in UTC+01:00 without moving!
As the lights come on at startup, we know they work. I’ll see if I can see any reasons for why they don’t come on at overhead time.
The few green blinks at start indicates a valid WiFi connection and you should see “connected” on the monitor.
A failure will show some flashing red blinks, with a fail message on the Serial Monitor.
When the ISS is overhead, you should get a red/blue gradient on the LEDs, but as I don’t have any of those, I can’t test it.
At the start of the pass you should see "“Estimated pass duration xx minutes and xx second(s)”
During the pass, you will see repeated “Pass time remaining: xx minutes and xx second(s)” messages.
After the pass, there will be no message and the LEDs will be off.
Not 100% sure what you mean. Once you extract the unix time from the JSON, you need to extract also the raw_offset, change the sign and add it to the unix time.
That gives you your location (if you used LA instead of URC) in UTC, this value is then able to be compared witth the UTC of the ISS’s next pass.
No library required. I posted the code a bit back in this thread.
Then since you simply want to determine how long it will be until the next pass, you get the current UTC unixtime (seconds since 1970), and subtract the next pass UTC unixtime from it, and voila, you have the number of seconds until the next pass.
Also, what Norman is talking about is different to what you will have had to do in the past for NTP. NTP also reports in UTC if I remember correctly. You would then have to offset that forwards or backwards to match your timezone if you want local time. Plus you may need to take into account daylight savings.
But that is not the case here. The code will determine the next pass correctly as long as all of the below requirements are met:
Your internet/wifi is working
You’ve filled in your latitide/longitude/altitude
The WorldTimeAPI server is up
Since it seems a little more flakey than I would have thought from the commentary in the FAQ, I want to change this code to work with NTP, borrowing some NTP code from the Tasmota project since they are using some more reliable NTP code than included as part of the ESP8266. That should then remove that as a potential issue.
I have it sat on my desk, so I see it trundle through a couple times a day since at the right time of day the ISS goes over about three times 1.5 hours apart.
I suspect there will be an issue with the fact that the code just goes… well, I’ll just start counting down several hours… one second at a time. I suspect each cycle is a fraction more than one second, oled update, RTOS overhead, etc, plus the drift of the ESP8266 itself. But I don’t know what this drift amounts to over the longer delays… perhaps a few seconds? Surely not minutes!
The following is more for Joe, but also to show the thinking process at play… and to spot any gotchas
In the interim, I ~will make~ have made the delay count smarter… “1 second delay minus the time I’ve been in the loop so far”, which would make at least that part as accurate as possible. It looks like without the OLED, there is somewhere 0 and 1 ms overhead in the loop whilst waiting for the next pass… so lets say instead of waiting 1000ms, it waits for 1000.5ms… negligible, right? Turn the OLED support on, and it jumps to extra delay 15-18ms depending on the digits, etc. so that’s 1016ms instead of 1000ms delays. So what does that mean in real world values?
Lets take this example…
Time until flyover (in seconds): 27497
That's 07 hours, 38 minutes and 17 seconds from now
Estimated pass duration will be 01 minutes and 54 second(s)
So, I’ve just calculated that instead of waiting for 1000ms before counting down a second, it takes 1016ms (on average). So what does this calculate out to?
27497 seconds * 1000 = 27497000 milliseconds
27497000 * 1.016 (that's the extra 16 milliseconds per second) = 27936952 milliseconds
Bring it back down to seconds (divide 1000) = 27936.952...
Leaving us with a difference between the two times of 439.952 seconds
That's a whopping 7.3 minutes *longer* than we want to be :-O
And the pass was only "01 minutes and 54 second(s)" long...
Now, having said that… I’m puzzled… I’m pretty sure this code is dumb, real dumb, and can’t figure out that we’re trying to do the light show after it should have finished… and should just do it late. Anyway, lets see what that squirrel leads us…
This was part of the reason I want to change to NTP - as the ESP8266 could then resync NTP more frequently, and track passes via timestamps, thus instead of it being “x seconds until next pass” it would be"next pass with be at X UTC, which is in Y seconds" and keep on track that way.
Thanks! It seems that I can still read/understand code – mind you, it was well written! I’ve seen some real code in my time. Maybe even written some! (In COBOL.)
Yup, that delay(1000) popped right out and bothered me. I was wondering why not just pull the current time in the loop? The millis() counter – at least on the Arduino – is turned off frequently, by digitalWrite(), digitalRead() etc. It’sbsurprising homw many times that interrupts are disabled. Serial does it too.
I think it’s more that it’s an arbitrary delay that does not take into account how long other stuff took to process. For instance, what if there is a wifi hickup between iterations of loop, and it adds another 100ms … that’s 1100ms you’ve waited now, not 1000ms. Stuff like that.
I could obviously fix that by using the elapsedMillis library that I maintain, and basically remove the delays, but that would be gratuitous, no?
I noticed! I finally soldered on the header pins on my first D1 Mini and your code was the first I’ve tried. I don’t have any of the smart pixel things, yet, but the time until pass over is correct. I did get a couple of failures to connect to get the current time - 503 errors, but I tried again after a couple of minutes and all was fine. The internet is a bit flaky methinks!
My current problem is that I have yet to adjust the code to just blink the builtin LEd instead of the pixels stuff - I’ve spent a couple of happy hours refactoring some of the code to my liking! (That’s not a criticism, I much prefer reading code the way I write it as I’m sure you do!)
I’m sure it will be an easy fix. (He said, hopefully)
I never got the cook’s tour. I knew how to work the fryer, so they let me fry. It’s gratifying to me that you’re getting something out of this.
I’m looking into JSON at W3C.
This is important- I’m into telemetry, and parsing websites and stuff is sexy. It would be cool to have a few headlines on my webserver.
When I learned HTML 3.0, I only bought a laminate at Staples and used Google.
When I was done, I had XML, javascript, ASP, CSS, all kinds of crap I never learned. Javascript animated my links. Really like CSS.
W3C is discussing JSON v XML now. Wanted to share.
I’m either going to get a lot better or worse. Let you know.
I can’t imagine what I would do in the first place, so I haven’t done anything.
But the machine says flyover is in 10 hours. NASA says it passes over me around 6pm, which is 6.5 hours from now.
I’m watching it in real time. It’s coming up on Australia now, so it is coming. But I’m 3.5 squares away and it’s 1.5 hours per square, so the actual object is expected in 5.25 eyeballed hours, pretty close to the NASA prediction. It’s not a straight line, so NASA is probably right. I concede to NASA, as far as knowing where the satellite is. My telescope is in Delaware, after all.
I don’t know if you’ve told me how to modify the code to correct for time zone. Seriously- I’ve re–read it all a few times.
It’s weird. I can understand a GC/MS manual. Maybe my bewilderment is a motivation for Arduino. I keep turning a corner and losing my orientation, and I guess I love it. I think the rational response to this level of frustration is to quit. I double down.
Please hang on a little longer.
I’ll fiddle with JSON later. It’s important, but I will have to fiddle with it.
I already have the printed parts. I want to send three as Christmas gifts. The OLED is awesome, but the Neopixel still isn’t lit during operation and I think it’s off by about the Pacific ocean.
I have debug stuff in the .ini file, but I don’t know how to start a debug. Still haven’t read.
The answer to that question is simply you don’t touch it! There is zero reason to change the timezone in this code… everything is sourced and calculated in UTC.
Indeed they are. That’s on the agenda for my next tinkering session on Sunday. Thanks for the hint about Org_01… I’ll try that first.
Maybe, maybe not. I don’t know what you are seeing, but every time I have looked at the notification, it was plausable, and if I couldn’t see it because it was during the downtime, I could hear it because I have a handheld radio capable of picking up the ISS Amateur Radio downlink frequency, and could hear part of the conversation being had with astronauts.
You did enter your latitude and longitude correctly, including the negative sign, if needed? I don’t think you did…
37.25, 121.5 puts you in China, not California. You probably missed the - at the front of 121.5
Well, I couldn’t do yet another blink sketch, could I?
I might do that, if I get any playtime. I’ve just had some bargain Oled displays, the small ones (1.3 inch OLED Display I2C SSH1106 Chip 128 x 64 Pixel I2C display module), from AZ Delivery in Germany, that need “playing” with. (A great company to deal with, weekly bargains where buying 3 of something costs the same as 1. Maybe not good for Australia?
code in my time. Maybe even written some! (In COBOL.)
