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
Hi Tonygo2
I’ve just received my Presto, so am very pleased to see all the work you and others have put into really useful applications. I want to edit your code to pick up the UK National Grid stats at https://grid.iamkate.com/
I note you are in Leicester - good to know - so am I - I help run Leicester Hackspace:
cheers
Tony
I’ve updated your code so it just shows the coloured circles on the map - slightly smaller than previous, and not the lat and long lines. I’ve moved the map display to before the ‘pointers’ loop, and only clear the display below y=320, so that the circles stay on the map while the text gets cleared.
I’m impressed at what a nice display it creates.
Hi tony1tf
The PRESTO is a really useful board and the display is fantastic. The only problem is that all the pins have been used up. I found these two I2C boards very useful:
IO Expander Breakout
Qw/ST Pad (I2C Game Controller)
allowing loads of ‘normal’ IO access.
Have fun with your new board.
I’ve not visited the Hackspace. Perhaps we should meet up sometime?
Tony
Hi both,
have you ever considered the SparkFun I2C Multiplexer to connect even more devices (via the Presto’s I2C connector) and get rid of connectivity limitations of the presto board?
Via I2C to dupont wires you could again connect some more components, right? Thus, you could daisychain a lot of more stuff, like sensors, buzzers, actors, etc. One input, 8 more outputs…