dump1090
dump1090 copied to clipboard
flightaware
SoapyRemote support
Hi, it will be nice to have soapy remote support. So the RTL-SDR dongle can be shared with more software.
As you mentioned, it is old branch. Maybe somebody knows why it is not merged.
Just never got cleaned up to the point where it was ready, and I forget what the reason I was looking at it was..
The old branch is a reasonable starting point if someone wants to clean it up / test it / submit a PR
I'll second Soapy support. I'm moving away from RTL dongles and onto SDRplay hardware which is a little more robust with their 14-bit ADC (while still being reasonably affordable). My issue is that my antennas sit 30 feet from a runway and I must turn the gain down to almost 0 so I don't get overpowered.. which kills the receive distance to just a few miles. The better dynamic range of 14-bit helps.
The end idea being that the RSPduo is one device that can do both UAT (dump978-fa already supports SoapySDR and seems to work OK) and dump1090-fa (which.. I'll try the old branch.. but .. its old).
I have built on work by @mutability ( January 2019, soapysdr branch) to add SoapySDR support, including support for SDRPlay devices. It's been opened as pull request #209. I'm happy to work with code reviewers on this.
The only device I have available to me right now is the SDRPlay RSPdx and I have tested with this device.
These are things that I think need particular review:
- I'm unsure of why Modes.gain was divided by 10 in the Jan 2019 work. Still needed? Is that needed for RTL-SDR devices only? If so, anybody know what SoapySDRDevice_getHardwareKey() returns for RTL-SDR? (This is printed to stdout as
soapy: hardware key is ....) - The FIFO work probably needs to be reviewed. I copied what I saw in other sdr_*.c implementations.
- Similarly, it would be helpful to review if outbuf->sampleTimestamp is being calculcated correctly. I am not fully confident that it's going to be correct for all devices.
Additionally, I don't have a RSPduo, but I have noticed in SoapySDRPlay3 code that it appears unlikely that RSPduo can support the 2.4 MHz sample rate. Someone can correct me if I am wrong, but it seems dump1090 only demodulates a 2.4 MHz sample rate, so RSPduo may not be supportable.
Additionally, I don't have a RSPduo, but I have noticed in SoapySDRPlay3 code that it appears unlikely that RSPduo can support the 2.4 MHz sample rate. Someone can correct me if I am wrong, but it seems dump1090 only demodulates a 2.4 MHz sample rate, so RSPduo may not be supportable.
I have the RSPduo. If operated in single-tuner mode (whether you use Tuner 1 or Tuner 2), then the sample rate can be 2-10Mhz and the IF bandwidth can be 200khz-8Mhz.
If operated in dual-tuner mode, then: the first application that uses the device is designated "master" (again, Tuner 1 or Tuner 2 can be chosen). The sample rate can be 6Mhz or 8Mhz, and the IF bandwidth can be 200khz-1.536Mhz. The second application which uses the device, MUST use the same sample rate as the master.
The RSP people have their own dump1090 which seems to be working OK in dual-tuner mode for me.. However, they forked it years ago and is missing a lot of the newer features (and even some basic features [e.g. very terse output in the JSON output file]). Let me know if I can assist.
@rcarsey1 Thanks. If you're up for it, you can try out #209 and see if it works with your RSPduo in single-tuner mode.
i just tried #209 with the RSPduo (the RSP1A worked OK too as expected). In single-tuner mode, it looks like it works as expected for the "Tuner 1 50 ohm" antenna.
For the "Tuner 2 50 ohm" antenna, I was receiving no data. Not sure why that would be.. the dump1090 published by the RSP folks works OK on either antenna. I did notice that for "Tuber 2 50 ohm", the bandwidth was set to 200khz and sample rate to 2.0Mhz .. logic bug somewhere?
In dual-tuner mode, as expected, it failed because its not using either 6 or 8Mhz.. which are the only two valid ones for dual tuner mode.
I did notice that for "Tuber 2 50 ohm", the bandwidth was set to 200khz and sample rate to 2.0Mhz .. logic bug somewhere?
@rcarsey1 You really specified 'Tuner...' rather than 'Tuber...' with --antenna? First I would definitely confirm that there was no typo in the antenna identifier string. If no typo, then I don't know, it's difficult for me to pinpoint why it's behaving differently for the Tuner 1 antenna vs the Tuner 2 antenna without having the device on hand to step through it with a debugger. If I had the device on hand, the approach I would take is start looking at the behavior of the functions in Settings.cpp of the SoapySDRPlay3 library to figure out why it's insisting on 200khz bandwidth and 2.0MHz sample rate for the second antenna.
Another thing I would check is if the SoapySDRPlay3 thinks it's operating in dual-tuner mode rather than single-tuner mode when the second tuner antenna is in use because we know that it won't work whenever SoapySDRPlay3 thinks it's operating in dual-tuner mode.
Thank you for trying it out. Good news that it works with Tuner 1!
typo in my posting here. I'm a bit new to SoapySDR, so it might take me absurdly long to figure out what is going on. I can offer you a SSH login into my machine if you'd like to spend some time looking at it. As far as I can tell, it shouldn't make any difference which tuner/antenna is selected while in single-tuner mode (thats what the datasheet indicates; and RSP's own dump1090 works OK on either tuner).
In the meantime, if you'd like that login to mess around with the RSP1A and RSPduo, shoot me a line at [email protected].
#209 has been merged (with some tweaks) to the dev branch.
Is there anything else in this issue that still needs looking at?
From my perspective this can be closed now but if @rcarsey1 is available to test with the RSP1A and the RSPduo (in single tuner mode), that might be a good additional test.