search

dndx / pitot

A customizable aviation information receiver
GNU General Public License v3.0
16 stars 4 forks source link

Implement FIS-B buffering when device is sleeping #8

Closed dndx closed 7 years ago

dndx commented 7 years ago

This feature should help conserving iPad battery greatly on long trips.

Idea:

  1. Save the last 8192 FIS-B uplink messages in memory. Given that each of them are around 438 bytes long, this should use around 438 * 8192 = 3.4 MB of memory.
  2. When sending to a client, monitor the "destination unreachable" response (currently they are just silently ignored).
  3. Once a "destination unreachable" message has been seen, stop sending all messages except the heartbeat.
  4. If the heartbeat send was a success, which means the device is no longer sleeping, replay the buffered FIS-B messages to that client and resume normal operation.

This is considerably simpler than what Stratux does (using seprate PING packets) and theoretically should work just as well. However, this should be confirmed.

D35Bonanza commented 7 years ago

The FIS-b data is not always on transmitting Weather, try are keep the lastest datset in memory or write it to disk. You could also just write the datasets to disk in /tmp until new dataset arrive. The weather data comes from NOAA aviation weather, when they update it is tricked to FIS-b data output after verified.

dndx commented 7 years ago

@D35Bonanza Yes, I did meant save the latest entries in memory and purge out old ones once the buffer became full, see above.

My observation is that weather uplinks are not generated very frequently (once every few seconds) so 8192 messages should be more than enough even with multiple UAT tower receiving simultaneously. ) Keeping the buffer size small also helps us clear it through the Wifi interface once the client comes back online quicker.

Stratux uses 25000 per client which in my opinion is way too much and likely anything after an hour or so will be stale data.

It doesn't really had to be inside the filesystem, given that Pi has enourmous amount of memory that Pitot is not utilizing right now. Also, the /tmp on Pitot image is actually ramdisk as well :)