sco1 / skyportal Goto Github PK

Splitting up the original code.py megascript into its components for easier reasoning about. 7aaf1d0 started the process by mostly attacking the low hanging fruit, though some bits are still a bit entangled.

• Compartmentalize the display logic, likely into a base Skyportal class?
• Wrap the networking logic for each API into discrete handlers, incorporating the the initialization logic & any recurring tasks that need to be done

OpenSky can provide the aircraft categories in its response, so we can theoretically have different sprite sheets for different kinds of aircraft (e.g. general aviation, helicopters, airliners).

when i tryed this project ive gotten everything to work but generating a map i changed the cordanates in the skyportal_config.py but im stuck with the default map

Once a release is published, it would be helpful to bundle only the files that need to be transferred over into a single release artifact so a user can just copy it over.

Additionally, a step to compile the skyportal directory to MPY is not required but would fun to do anyway, probably as a separate artifact (I think these can then go into /lib?)

See: https://github.com/adafruit/circuitpython/tree/main/mpy-cross#micropython-cross-compiler and https://pypi.org/project/mpy-cross/

Obviously beggars can't be choosers when using a free API but OpenSky's response time & uptime have been rough recently. It would probably be worthwhile to explore supporting other APIs to drop in as replacement options in the event that the current downtime continues.

From a quick search we have a few options:

• (Free) ADSB.lol: https://api.adsb.lol/docs
• (Free-ish) FlightAware : https://www.flightaware.com/commercial/aeroapi
• (Not Free) ADS-B Exchange: https://www.adsbexchange.com
• (Not Free) Flightradar: https://www.flightradar24.com/commercial-services/data-services

Starting with v3.0 of the adafruit_requests library, a connection session is required to manage the on-device network sessions rather than being able to utilize the top-level get method of the module. The internals will been updated by #23, which vendors in v3.2.4 (I think) & updates the get calls appropriately.

There doesn't seem to be a good method for getting the PyPortal's internal session, so it's just yoinked from the internal PyPortal.network._wifi.requests attribute which I'm mostly comfortable with, but I'm not super happy with having to pass this on a fun winding journey through displaylib if we need to generate a map tile from the API & might be worth refactoring this flow.

The current sprite sheet only maps to 45 degree orientations, it would be nice to bump up this resolution to maybe 30 or 15 degrees?

At some point recently I seemed to have broken the screenshotting capability:

Traceback (most recent call last):
  File "code.py", line 81, in <module>
  File "skyportal/displaylib.py", line 534, in process_touch
  File "skyportal/displaylib.py", line 171, in check_fire
  File "skyportal/displaylib.py", line 94, in take_screenshot
  File "adafruit_bitmapsaver.py", line 161, in save_pixels
  File "adafruit_bitmapsaver.py", line 159, in save_pixels
  File "adafruit_bitmapsaver.py", line 107, in _write_pixels
MemoryError: memory allocation failed, allocating 2048 bytes

Checking the memory stats before saving the bitmap seems to show there's plenty of memory left, even before manually GCing:

Free 23408 Alloc 192976
GC Free 25232 Alloc 191152

So I'm not sure where the issue lies.

Rather than needing to manually generate full sprite sheets for every icon at set rotation intervals, it would be nice if we could just have a base icon and have it either rotated on-device, or have a programmatic way to pre-build the sheets. I think I'm leaning towards the latter.

Currently the main loop is just one task: checking OpenSky and then sleeping. I haven't checked yet but I'm assuming this sleep also blocks other functionality (e.g. touchscreen interaction), so will need to investigate how to accommodate this while keeping the refresh loop alive & on time.

stuck on "waiting for data api"

CircuitPython v9.0 was released earlier this month. Scanning the changes there doesn't seem to be much, if anything, to address from the currently targeted version (v8.2).

Since we do have a touchscreen, what kinds of things could be added?

• Show aircraft information (Priority)
• Screenshot button
• Visualize aircraft track

The PyPortal is available in a larger form factor, the PyPortal Titano, which has a 3.5" diagonal 320x480 screen vs. the original PyPortal's 3.2" 240x320 screen. I believe the relevant internals are otherwise unchanged but would have to adjust the generated map and check on the UI elements.

This is deferred until I end up buying one, so currently no planned completion date.

open sky just says waiting for opensky in the top corner not displaying any aircraft

In CircuitPython we plan to update the version of macos used to build mpy-cross, as macos 11 runners are deprecated and due for removal. At the same time, we renamed the binary, removing the macos version number specifier: adafruit/circuitpython#9329

This change will probably first roll out in circuitpython 9.0.6 and circuitpython 9.1.0-beta.3.

Based on code search, this change will likely affect this project.

I'm assuming the faux enum lookup is wrong. Probably also for ADSB.lol since the proxy is passing the category value straight through.

Right now we're just being lazy and taking the API response (UTC), but would be better to get the TZ offset from our specified grid and convert

Phone pictures look terrible, would like to have the capability to take a screenshot directly from the device