I can start dump1090-fa with --modeac in DECODER_OPTIONS.
Then I can watch Mode-A/C only transponders, too, with
view1090-fa --modeac
Any idea how I can write this to disk? The Mode-A/C only data is not contained in http://localhost:8080/aircraft.json.
Those data have no position and you don’t know which aircraft it is either.
I’m not sure there are even any aircraft left operating Mode A/C only transponders in Germany.
To give an actual answer:
Have you check the basestation output via TCP?
You could do this:
nc localhost 30003 > lots_of_data.txt
Not sure how that would be useful, but the data is saved.
I’m pretty sure most of the Mode A/C aircraft you see are actually just messages from ModeS transponders which are usually ignored.
Aviation transponder interrogation modes - Wikipedia :
One of the features of Mode S transponders is that they are backwards compatible; an aircraft equipped with a Mode S transponder can still be used to send replies to Mode A or C interrogations. This feature can be activated by a specific type of interrogation sequence called inter-mode.(Wikipedia:Citation needed - Wikipedia)* ]
@obj Do you know if any radars are still interrogating Mode A/C?
I suppose they are, otherwise the message rate shouldn’t go up when switching to --modeac but it does.
There won’t be any Mode A/C data in that output.
Sure, plenty; there’s lots of older GA aircraft that are A/C only.
But for the amount of messages seen, they must be interrogating in a way that ModeS transponders respond to as well.
Maybe that can’t be avoided i guess?
Seems it would reduce congestion on 1090 MHz quite a bit though if ModeAC was killed off.
I know that Mode A/C has no positions as long I don’t setup an MLAT-calculator that gets fed only from stations in my control area.
Of course there are many planes that send Mode A/C.
I once hacked mutability’s dump1090 to include fake mode S hex numbers (“FF” + Squawk) into aircraft.json. But I don’t know what happens If I modify dump1090-fa. I don’t want to flood FA with fake mode-S data accidentally.
Do the AVR and beast outputs include mode-ac?
If the beat output contains Mode A/C messages,
you can run mutability in net-only mode and forward the beast data from dump1090-fa.
Then you can modify what you want and it won’t be a problem.
Planeplotter can do some kind of triangulation of mode A/C messages, but it’s hard to get working reliably since it requires accurately knowing the location of radar heads and their rotation rates.
Since I think dump1090 used to use the lower bandwidth decoder to decode mode A/C, I didn’t find it worth the trade off of reduced Mode S reception performance.
Yes.
This was true in the past but there is a 2.4MHz demodulator for A/C in dump1090-fa now.
I have to correct myself. It was Malcolm Robb’s version.
Oh nice. Does it have any impact on mode S decoding, or is it just an increased CPU overhead to process it?
Thanks for the suggestions. It works.
/usr/bin/socat -T 300 -u TCP:localhost:30005 → my modified dump1090
Just more CPU, it shouldn’t affect mode S at all.
Here’s an interesting list of Mode-A/C squawk codes:
No, it doesn’t work. It’s not that easy.
A Mode-A is only a Mode-A if there’s no matching Mode-S data.
“view1090 --modeac” does it right. So I added code to view1090 to write detected Mode-A to a database. That seems to work.