My wishlist for feeder software development

[hansp]

Following another post on how our data is used, or not used, on FR24 I thought it might be an idea to write down what I think would be useful features in future versions of the feeder software for RBPi. After all, a lot of users spend a great deal of money and time trying to set up the best feeders possible, it is then ungratifying to not see any improvement on local coverage. So, here I go!

• Improve the local view via dump1090. The mutability version is old and featureless and lacks a lot of functions that can be found in other versions. It requires feeders (users) to install other software to analyze their own data quality.
• Replace old NTPD with timesyncd. A lot of RBPi feeders have clocks that are not synced because proper services are not enabled. This render MLAT timestamp useless. The feeder setup script should enable NTP sync using systemd-timesyncd. The problem is described here. Also since location is given when installing feeder correct time and localization should be set for the RBPi.
• Enable autogain or gain adjustment. Working with gain adjustment can give great improvement of the data quality. This is however a task that requires skills in using SSH and writing in configuration files. Enable an option to adjust gain in the dump1090 interface.
• Add graphs or indications to dump1090. To improve data feed quality FR24 should give an indication to users if their reception needs adjustment. It can for example be an indication if a high percent of the signals are oversaturating the feeder or if there is a significant change in message rate/range.
• Give an indication if data supplied for MLAT is not of useable quality and if this is not adjusted turn of MLAT feeder for the station.
• Local history. A fun thing would be if the tracks recieved by your feeder could be stored and searchable locally, to be able to display on local dump1090 interface. No matter the quality this would also help in analyzing how to improve your feeders reception.

A lot of these features can be achieved by installing other software and by working with the files but since the majority of feeders do no more than building an in image from FR24, and leave it at that, a lot of data is sent to FR24 that is of poor quality. Also many users who would like to improve their feeders do not know how - adding these options to a local interface (you already have :8754!) can make things better for all of us. Although F-feeders for sure are important for coverage, all T-feeders must have some role to play when supplying all this data for a commercial service. So work with us, please.

Best regards, Hans

[hansp]

...or at least have a default dump1090 that displays location and range-rings. You already have my coordinates so why not use them? Please?

[wiedehopf]

As i mentioned before .... fr24feed does internal ntp without changing the system clock.

[MrMac]

Mlat does not use NTP or any other timestamp once the signal is inside the Rpi due to the USB bus latency. It can only use the rolling clock timestamp from the DVBT stick. This relative timestamp is evaluated based on ADSB-aircraft transmissions so it can be used in conjunction with the absolute sync produced by the F-receivers (where the FPGA timestamps the arrived signals using GPS clock precision).

So no changes to NTP or any addition of GPS will change the useability (or non-useability) of T-feeder mlat contributions.

/M