I would like to receive some suggestions (including “cannot be done”) on real-time filtering of data that my RPi based FA logger is uploading. I am interested in being alerted if a particular aircraft has been detected by the ADS-B receiver. Any suggestions on “pseudo-code” (not process flow :))? I would like to limit the filtering only to the data received by FA at my device in near real-time. Eventually, I would have a “settings” file where the aircraft properties would be kept/updated for administrative use.
Reading from log files would not be my desirable initial attempt. Long term goal is to have a pop-up on my Home Automation dashboard much like (although a more deterministic technique for obvious reasons) the ISS overhead alert.
Can’t be done via the API - there’s no option to get data only from your feed.
You can monitor realtime data from your raspberry pi at port 30003 (see similar question here: Log of Aircraft Type / Operator? ) - though instead of monitoring for the tail, you’ll be looking for the hex id of the desired aircraft’s transponder.
There are some API methods where you can search through aircraft in a geographically defined region, but, polling it on a near-realtime basis would get expensive pretty quickly.
Thanks a bunch! I’ll definitely run this code with some minor edits.
In the interim reading your code, it appears that I was on the wrong track having done the following earlier today:
rsync pull from another RPi (every minute in lieu of some inotify or watch operation)
read the JSON data (that’s all I have been able to accomplish today)
Since I’m using an older RPi2, I did not want to upset the processing in that environment. Prefer to the processing on a separate machine before I establish the near real-time processing. FA already complains that the CPU load is high on this older RPi!
Your code works like a charm - norsync for me anymore. I wills stick to your http method.
BTW, do you have a reference for the following attributes that are present in the data: nucp, seen and rssi? (Perhaps, I’m being lazy here, I apologize in advance).
Off the top of my head, no. Sorry. But check the dump1090-mutability project on Github and you can probably figure out what those variables represent. Good luck.
I used the urllib module to receive the JSON response (for aircraft). I rely on a “configParser” file for my settings where I have the flights (of interest) stored. It is holding up to some extent (tested with AAL and SWA but these, of course, are not the flights of interest).
I am in the middle of testing the SMTPHandler for the logging module. Thread blocking is not an issue for me given the fact that there will probably be less than five flights a day that filter through. But presently I am hunting/pecking my way through the Gmail parameters (for TLS/SSL) using the SMTPHandler. Right now I do not want to get too carried away by all the possibilities (Twilo, IFTTT, and so much more). I want to stay with the basic Python standard library modules to keep it simple. But of course, your SMTP method would be a fall-back if the manhours start taking a toll.
As soon as I have something for review, I’ll send you a GitHub link. Given what I have learnt from you, I should be able to do something with a Node-RED equivalent in due course.
NUCP is a measure of how accurate the GPS information is. This is used as an area of containment for each plane for Air Traffic Controllers purposes. Not too useful for plane tracking.
SEEN is the number of seconds since the last message seen. After 60 seconds of not seeing another message a plane is removed from the active plane JSON list.
RSSI is the Relative Signal Strength Indicator. RSSI closer to 0 dB are strong signals and -40 dB are weak signals. This isn’t an absolute measurement like dBm.
