Maybe this helps: I’m doing a manual gc.collect() every time after doing a REST call and parsing JSON. It seems on these small Micro Python machines automatic garbage collection on its own is not sufficient.
1 Like
Alexander, very useful input - thanks for that.
I recorded and visualised the memory consumption per API get order and it constantly eats 832 bytes per request… The magenta colored memory graph can be seen in the lower part of the screen.
Surprisingly, the PICO seems to clean and free-up the memory automatically when it goes down, which can be seen by the very linear magenta colored sawtooth wave.
And even more surprisingly it still runs without any break-ups during the process over and over again - even after a few thousand readings…
Thus, I conclude the memory consumption per API get order would not be the root cause of the crash problems…but good thing is that we now have some clarity on the PICO’s memory management.
Anyways, I will implement some memory cleaning algorithms, which kick-in when the memory consumption vector becomes to significant in order to always keep the system in shape…this is always useful to monitor the general memory consumption of the PICO and always clean up things to prevent memory issues and thus possible crashes due to that…
I just figured out that a new error dropped in, which causes the program to crash:
“ValueError: HTTP error: BadStatusLine:”
This again goes back to the HTTP connection, so it’s definitively a networking issue. I need to include those errors again to the general error handling mechanism, ignore it and go over into the retry routine…
…I have had this run over night without any issues and thousands of API readings… don’t know wether this memory readings do have influence, but it never ran so long error free…
Well done! That is fantastic.
Tony, this is primarily your long-lat-calcuation ;)
I am about to double-check if it is really true that the ISS does not fly over Canada, Scandinavia, and most of Russia & China - or whether there is a problem in putting the long-lat-coordinates properly on the map…
My crop of the map shows more northern hemisphere than southern - not many quakes in the far south!. The ISS tracks look evenly spaced about the equator.
This is the latest ISS track from NASA
It does not appear to go very far N or S. Looks very like your track.
Tony, I did a real-time comparison and I may say, that your long-lat-algorithm is actually pretty good and within acceptable tolerances - taken into consideration that your algorithm is manually adjusted on a quite small map…
This is what the esa currently shows about the ISS’ position
longitude: 38.8W
latitude: 51,2N
This is what the ISS API I use returns
longitude: 38.8903W
latitude: 51,0158N
And this is how the geo-location is placed on the map with your algorithm
I for one would say that this is an absolute acceptable positioning…thanks for the algorithm logic. I will go more into your mapping details, as I probably would also use a full screen map and then of course the positioning needs adjustments…
The problem is to find a free map with overlap at both ends of the International Date Line and to crop it very close the the IDL. You really need the equator to be shown or can get a good estimate by placing it on the Galapagos Islands West of Ecuador. You then adjust the value of the N/S factor until you can hit London accurately with its Latitude. Once that is correct the Greenwich Meridian is through London and it is easy to find the E/W adjustment factor to hit the IDL at both ends. I’m still looking for a better map.
The IDL has so may twists and turns you are not sure exactly where 180 degs E or W is.
The logo shake deserves a round of applause !! Well done :D
Thank you. The idea came to me after seeing some videos of supermarkets in Japan while a quake was taking place.
1 Like