That will be the next platform but is a couple of weeks away. We need to refine some things with this client and do some work around MLAT first.
New Plane Finder Sharing Client - Beta Thread
- Thread starter Lee Armstrong
- Start date
- Status
That will be the next platform but is a couple of weeks away. We need to refine some things with this client and do some work around MLAT first.
jepolch
Senior Member
The old script was /etc/init.d/pfstart.sh. Everything's working fine here. I reboot my Pi at 2:30 am with a cron job.
ab cd
Senior Member
Format of 2 microSD cards and fresh install completed on both RPis.
Configured both: Beast, port 30005.
Now PFClient Beta on both RPis up & running.
That's great thanks, if both receivers are at the same location we'd rather only 1 was feeding us as if they both decode the same packets wrongly we get it from 2 and not 1! We use other location receiver to verify certain bits of info.
RTL's using Dump1090 especially are notorious for sending us spurious data!
RTL's using Dump1090 especially are notorious for sending us spurious data!
Whatever you configured it to as it too supported most of the formats Dump1090 can output. We always recommend connecting to one of the raw outputs, 30005 for example and especially NOT 30003.
The new client has a drastically lower CPU and memory usage as this was a big concern for many. We now have a client with much lower CPU than our competitors too!
The new client has a drastically lower CPU and memory usage as this was a big concern for many. We now have a client with much lower CPU than our competitors too!
radiostationx
Active Member
Hi Lee,
Is there a reliable way to combine outputs from 2 Raspberry Pi units when using pfclient ?
The website most refer to is from fellow planeplotter user David Taylor http://www.satsignal.eu/raspberry-pi/dump1090.html
On this page there are some instructions to combine the 2 rpi units by firstly using one as primary and one as secondary ,then using this command on the primary rpi
nc -d <secondary ip address> 30005 | nc 127.0.0.1 30004 &
This could be run by cron also.
I think it works by injecting the output from dump1090 unit 2 into dump1090 unit 1 then combining the signals somehow.
I wondered if this is the way to go if users had more than 1 unit at their location.
What do you think ? Will this be okay with pf client ?
I have another rpi that I would like to use.
Regards,
Mike
Last edited:
Combining is something we don't directly support but if it got into our client as a single feed that would be much better. Our system will actively look for 2 clients from the same site and disable one soon.
If you are simply after better coverage I would recommend buying a proper ADS-B receiver. They are infinitely better than these RTL devices, there is a reason they are so cheap!
If you are simply after better coverage I would recommend buying a proper ADS-B receiver. They are infinitely better than these RTL devices, there is a reason they are so cheap!
caius
Active Member
Just had a look at the old config file and it was set to use 30003, probably because the installation instructions for the last client suggested it was the least CPU intensive. It seems that didn't account for the overhead of producing that output in the first place!
Regarding joining 2 feeds, the method above should work. An alternative is to use the program called modesmixer2, which can accept inputs and outputs in most formats.
Regarding joining 2 feeds, the method above should work. An alternative is to use the program called modesmixer2, which can accept inputs and outputs in most formats.
radiostationx
Active Member
My cpu usage is 25% dump1090, 7.5% pf client, between 0.3 and 1.3% other radar feeder services.
I installed new client after disabling the old one first.
I installed new client after disabling the old one first.
Modesmixer yes is probably a good idea and the best for joining feeds.
Also your CPU usage is not what we've seen in testing, are they both connecting to raw data feeds or 30003 format?
Also your CPU usage is not what we've seen in testing, are they both connecting to raw data feeds or 30003 format?
ab cd
Senior Member
Although both of my receivers (DVB-T Dongles) are located at same place, but they use two independent antennas, and are connected to independent RPIs, and their feeds are not mixed with each other at any stage before reaching Planefinder, the chances of both decoding the same packet wrongly are very low. In theory you can treat my two receivers as one is mine, the other my neighbor's
Last edited:
I also have multiple receivers on independent antennas and independent RPIs, much as @ab cd mentioned above.
I just noticed these log entries of on two of the three devices: "Data upload failed with error: 'Client not authenticated - no access - contact [email protected]' "
Is this a result of your system disabling the additional clients at my location?
It's certainly your call on whether you want the additional data but I would think having the same data received and decoded by multiple, independent systems would lead to more accuracy rather than less. If you only want the information from one device at a location I want to make sure it's the best of the group that is sending the data. The highest performing device captures about 30% more positions than the next best and nearly 60% more than the lowest of the three. The two that are giving me the error above are the two best performing devices.
I just noticed these log entries of on two of the three devices: "Data upload failed with error: 'Client not authenticated - no access - contact [email protected]' "
Is this a result of your system disabling the additional clients at my location?
It's certainly your call on whether you want the additional data but I would think having the same data received and decoded by multiple, independent systems would lead to more accuracy rather than less. If you only want the information from one device at a location I want to make sure it's the best of the group that is sending the data. The highest performing device captures about 30% more positions than the next best and nearly 60% more than the lowest of the three. The two that are giving me the error above are the two best performing devices.
I suspect this is the case yes. As you know Dump1090 has a habit it seems of being a little happy setting emergency squawks amongst other things. We seem to notice this more from RTL sites than anything else. Having 2-3 RTL's in the same location seems to defeat some of the checks we can put in place to verify this information. We never seem to get spurious data from non RTL sites.
If you want to combine, something like modesmixer as mentioned above is a good option.
Are all the clients on that Pi all talking to raw data ports?
On the rare occasion that I have seen emergency squawks it has only been on one of the three receivers. I have never seen a false emergency squawk from more than one of the receivers. To me, the two not showing an emergency squawk would negate the false reading of the one that did show it.
My goal is to get you the best data possible. To that end I will disable the pfclient on the two lower performing devices. Let me know if you change your mind and want it from all three.
Thanks for the reply. The issue we have is that we don't know if you are sharing the antenna, or even sharing the same Dump1090 output between two clients (which I know you are not). We are the first people to find out when "dodgy" data gets uploaded to the server as a lot of people notice so we need to protect against that.
The short term solution is to use ModeSMixer to combine into a single feed too our client. In the future we will possibly have an option to connect to multiple data streams so that we can sanity check it ourselves on the client. I don't have a date for this yet as other platforms are first.
Also as a note to all, we have an issue with 30003 data which we are looking into at the moment. Therefore if you use this you will see an error in the log saying we have disabled uploads. If you still want to upload and are not one of the people troubleshooting the issue with us I would suggest switching to one of the raw data formats.
Thanks,
Lee
- Status
