FlightAware Discussions

dump1090 --phase-enhance option


#21

It’s an “I didn’t implement that yet” :wink: The ModeA/C decoder (like the original ModeS one) is written specifically for 2MHz so will need rewriting for 2.4MHz. ModeA/C isn’t particularly interesting to me so I didn’t get around to doing that yet.


#22

Just a FYI, Im running a dongle on a windows desktop. When I added --phase-enhance or --oversample dump1090 stopped working. With phase I would get an error that says Dump1090 stopped and just wouldn’t start with oversample.


#23

OK. I did not understand the ModeA/C decoder was also specific to the sampling frequency, but now when you think about it, it is pretty obvious.

It is not important to me either, I enabled it just “because it was there”, and noticed I don’t get any ModeA/C messages with the oversampling dump1090.

The performance of my receivers seems to be slightly better with oversampling dump1090, but I don’t have enough data so say how much.
Other than the missing modeac messages, the oversampling dump1090 works just like the MalcolmRobb versio I was usine earlier.

-Paavo


#24

Do you use enable-agc option?


#25

I’m running adsbscope on a Windows workstation and trying to pull data from dump1090 running on my Piaware Raspberry Pi. I’ve narrowed the problem down to “–net-beast”. When I add it to the dump1090 PROG ARGS and restart dump1090, things start to break. Here’s my config:


PROG_ARGS="--phase-enhance --quiet --net --net-ro-size 500 --net-ro-rate 5 --net-beast --net-ro-port 31001 --net-buffer 5"


With these args in place, adsbscope gets data from the Pi, but then I get this result from ‘piaware-status’:


dump1090 is running.
faup1090 is not running.
piaware is running.
no program appears to be listening for connections on port 30005.
dump1090 is listening for connections on port 10001.
piaware is NOT connected to port 10001.
piaware is connected to FlightAware.
got 'couldn't open socket: connection refused'
maybe dump1090 is NOT producing data on port 30005.
maybe dump1090 is producing data on port 10001.


Apparently --net-beast is necessary to provide data in the Beast format for adsbscope. I tried --net-bo-port 31001 but got the same breakage and the data didn’t get to adsbscope in the right format.

Is --net-beast not compatible with Piaware? Or is the issue with dump1090 Ver 1.09.0608.14?


#26

dump1090 will listen on only one port for a particular type of connection.
By default, that is port 30005 for Beast-format connections.

When you specify “–net-beast --net-ro-port 31001” or equivalently “–net-bo-port 31001” you are changing the port for Beast-format data to 31001.
dump1090 will no longer listen on 30005.

However, I wouldn’t expect that to actually hurt in your case because piaware will be using data on port 10001 (the FATSV port) anyway and it looks like you are using the FlightAware-provided version of dump1090 that provides this natively. When you say that things break, do they really break as in “data doesn’t get sent”, or do you just see piaware-status saying there’s nothing on 30005?

The simplest thing here, though, is not to touch the dump1090 options; instead, configure adsbscope to talk to port 30005. The data is already being produced in the format it wants, you just need to point it at the right port.


#27

oh - looking at this again - maybe it’s a piaware bug, I’m not sure if it will try to connect to 10001 if there’s nothing apparently on 30005.
(There’s no reason not to try, but, well, design error - the whole “I’m going to look at netstat” thing smells a bit)


#28

dump1090 will listen on only one port for a particular type of connection.
By default, that is port 30005 for Beast-format connections.

I am not sure that the --net-beast option by itself disables listening for Beast connections on 30005. I thought --net-beast option just changed the protocol on the --net-ro-port, wherever that port is located. The following capture was taken from my production Pi. Obviously there are a couple of connections (Beast format) to TCP port 30005. dump1090 is still listening to port 30002, the default TCP AVR protocol, raw output, listen port. I suspect that my port 30002 output would now be using Beast rather than AVR. I have not tried connecting to port 30002 so have not tested it. If dump1090 will only listen on one port for a particular protocol, what protocol would my port 30002 now be? I find calling the ro port a “raw” output when it is configured for AVR protocol, by default, an uncomfortable choice of words. My idea of a “raw” protocol is binary, not some USASCII encoded data stream.

root@RpiBplus:~# ps -ef | grep [d]ump1090
root 1858 1 28 Dec09 ? 09:18:08 ./dump1090 --oversample --phase-enhance --fix --interactive --net –net-beast --net-ro-size 500 --mlat --net-ro-rate 5 --net-buffer 5 --lat -27.5 --lon 152.9
root@RpiBplus:~#

root@RpiBplus:~# netstat -antp | grep 3000
tcp 0 0 0.0.0.0:30001 0.0.0.0:* LISTEN 1858/dump1090
tcp 0 0 0.0.0.0:30002 0.0.0.0:* LISTEN 1858/dump1090
tcp 0 0 0.0.0.0:30003 0.0.0.0:* LISTEN 1858/dump1090
tcp 0 0 0.0.0.0:30004 0.0.0.0:* LISTEN 1858/dump1090
tcp 0 0 0.0.0.0:30005 0.0.0.0:* LISTEN 1858/dump1090
tcp 0 0 127.0.0.1:30005 127.0.0.1:56230 ESTABLISHED 1858/dump1090
**tcp 0 162 10.161.3.144:30005 10.161.0.6:1470 ESTABLISHED 1858/dump1090 **
tcp 0 0 127.0.0.1:30003 127.0.0.1:44397 ESTABLISHED 1858/dump1090
tcp 0 0 127.0.0.1:56226 127.0.0.1:30005 ESTABLISHED 2093/modesmixer2
**tcp 0 0 127.0.0.1:30005 127.0.0.1:56221 ESTABLISHED 1858/dump1090 **
**tcp 0 0 127.0.0.1:56230 127.0.0.1:30005 ESTABLISHED 2113/faup1090 **
**tcp 32 0 127.0.0.1:30005 127.0.0.1:56226 ESTABLISHED 1858/dump1090
tcp 0 0 127.0.0.1:56221 127.0.0.1:30005 ESTABLISHED 2023/ppup1090 **
tcp 0 0 127.0.0.1:44397 127.0.0.1:30003 ESTABLISHED 2092/fr24feed_arm-r
root@RpiBplus:~#


#29

I don’t know how to put it any more clearly than I already did:

–net-beast is really only there for legacy compatibility, all it does is make --net-ro-port behave like --net-bo-port.

If you specify --net-beast but do not specify --net-ro-port then it does nothing.



        } else if (!strcmp(argv[j],"--net-beast")) {
            Modes.beast = 1;
// ...
        } else if (!strcmp(argv[j],"--net-ro-port") && more) {
            if (Modes.beast) // Required for legacy backward compatibility
                {Modes.net_output_beast_port = atoi(argv++j]);;}
            else
                {Modes.net_output_raw_port = atoi(argv++j]);}


There is really no reason to ever use --net-beast any more. It’s only there at all so that existing (very old, by now) installs that use it don’t break.


#30

It’s “raw” as opposed to “processed” - the SBS output, for example, is processed - decoding of the ADS-B message has been done.

It made sense back where there was only one “raw” protocol supported, I think :slight_smile:


#31

If you specify --net-beast but do not specify --net-ro-port then it does nothing.

Thanks for the clarification re --net-beast use in isolation. That is the bit I was missing.


#32

Why didn’t you use 2.88MHz sample rate? That would be exactly 1:10 from the internal rate and would probably “fit” nicer than frequencies that are not integers. That would be a true decimation rather than down-sampling.

That’s similar with digital audio - a 192kHz SR signal plays better at downsampled 48kHz than at 44.1kHz. Similarly, a DSD signal that is 64x44.1kHz plays better at 88.2kHz than at 96kHz.

Other trick from audio is dithering (noise shaping) - adding random noise at the decoding stage improves the conversion.


#33

Hardware limitation, the RTL2832 will not run reliably at 2.88MHz. Also at 2.88MHz the bit length would be pretty messy. See my very old post above.


#34

The FA Pro Stick (yellow) that I have seems to work OK right now at 3.2MHz with CubicSDR (Windows) decoding FM stereo 106.9MHz.
Also 2.88HMz option works fine.

Probably lower quality dongles won’t work (I might have one generic around to test) but… isn’t a way at least to do two different samplerates? Is that affecting only MLAT?

LE: Installed the generic 820T2 dongle, Zdiag it’s drivers, and… works at 2.88MHz and 3.2MHz. Rush’s Limelight sounds great :wink:


#35

It’s bursts of randomly dropped samples. Nothing that would be audible with WBFM. Some dongles are worse than others, there’s no particular pattern I found. Yes, it mostly only affects mlat timing; but with some dongles they drop so much data (and/or hang entirely) that it starts to affect message rates. rtl_test is a good starting point for seeing the problem.

But the code’s there if you want to rebuild it to work at 2.88 and experiment for yourself.


#36

Wait. The FA servers don’t care of the SR of the signals they get?


#37

There’s a timestamp field in the Beast format (a 12MHz clock) that mlat cares about and you’d need to adjust how that is computed in dump1090 if you change the sample rate; otherwise nothing on the piaware side cares about the sample rate.