Is it possible to capture TCAS events and relevant intruder/own data with PiAware? If so any information/direction would be greatly appreciated.
dump1090-fa will emit TCAS RA messages broadcast via Comm-B (BDS 3,0) or ADS-B (type 28 subtype 2) in the raw data feed (and piaware will upload them); there’s currently no code in dump1090 or piaware to decode these further, so you’d need to roll your own code there.
It’ll also capture the TCAS air-to-air messages exchanged in normal operation but doesn’t decode them further and I believe you’re only seeing half of that conversation anyway (other half is on 1030MHz)
The only valid TCAS RA messages i’ve found were in DF16 messages.
Maybe some planes send it in DF20/21 but so far nothing coherent … only noise / errors.
I’ve built in a very rough functionality into my readsb branch to output TCAS RA messages to a csv and json for each day when using these command line options
--write-json-globe-index --write-globe-history /var/globe_history
The info on acas ra if any was logged for today would be in
(see some pointers here: GitHub - wiedehopf/tar1090: Provides an improved webinterface for use with ADS-B decoders readsb / dump1090-fa)
In case you’re interested in this code that prints something at least somewhat human readable: readsb/json_out.c at dev · wiedehopf/readsb · GitHub
It likely has errors in it but so far the output seems to make sense to me.
The best information i found available was this: https://mode-s.org/decode/book-the_1090mhz_riddle-junzi_sun.pdf
This can fill in a bit of how those RAs are actually announced to the pilots: https://www.faa.gov/documentlibrary/media/advisory_circular/tcas%20ii%20v7.1%20intro%20booklet.pdf
Example output of the code:
2021-03-23,16:42:48.0,498488,DF:,16,MV/MB:,30C20200000000, 50.432273, 15.192208, 3200,ft, 31,fpm,ARA:,1100001,RAT:,0,MTE:,0,RAC:,1000, not below,RA: Climb, 2021-03-23,16:42:48.1,49d086,DF:,16,MV/MB:,30E00100000000, 50.427758, 15.200550, 2850,ft, 1024,fpm,ARA:,1110000,RAT:,0,MTE:,0,RAC:,0100, not above,RA: Level Off,
Really you need the tracks to look at to make sense of it that’s why emitting the files is limited to that mode that records them as well.
Not sure if you can use what i just mentioned but it at least might give you a few pointers to write your own code.
DF17 TC=28 that sounds interesting, i’d have to see if i can find the format anywhere, it’s only mentioned briefly in https://mode-s.org/decode/book-the_1090mhz_riddle-junzi_sun.pdf
I’ll have to see if i can get a sample message, maybe the ARA block of bits is the same … then i’d just need to find the offset.
@fh2level I’m not sure when the aircraft use which format so i might be missing any number of RA messages in my code for logging that stuff.
The interpretation to something human readable in my code might be wrong.
Also i’ve made some choices to bring the text in line with cockpit annunciations of the most recent TCAS version.
For example the RA could be of the type “reduce climb” or “reduce descent” but i’ve chosen to go with the corresponding annunciation which is just “level off”.
AIUI DF16 is the “live” cooperation between TCAS systems and not necessarily the final RA.
We definitely do see RAs in DF20/21 (with BDS3,0) but it’s not as common as the ADS-B announcements. Here are a couple of examples (MB payload):
2 commb_acas_ra 30A001254809D0 2 commb_acas_ra 30400200000000
This is much more common than the Comm-B variant.
Here’s some sample data if you want to play with it (this is the ME payload of the DF17 message).
I haven’t looked at whether these are particularly interesting at all…
80 es_acas_ra E2A001254809D0 43 es_acas_ra E2E001054809D0 39 es_acas_ra E2A001054809D0 38 es_acas_ra E2E001254809D0 38 es_acas_ra E28000268070D0 32 es_acas_ra E2A00000000000 31 es_acas_ra E28000068070D0 23 es_acas_ra E2A00028F043AD
ES: E2A001254809D0 ARA: single threat, preventative, downward sense RAC: do not pass above Threat: Mode S hexid 520274 RA terminated
seems plausible, anyway. (Actually heard that one via both Comm-B and ADS-B)
So i’ve seen decodes from both conflict aircraft which absolutely make sense on DF16 including a Clear of Conflict at the end of the event.
Apart from not having threat info it seems to be very similar to the DF20/21.
There is the RA bit that is not always set for DF16, so in that case it’s not really an RA yet i believe but will already have RAC as in not above and not below.
So i’m pretty confident the final RA also is at least in some cases sent via DF16.
Is that decoded using GitHub - junzis/pyModeS: Python decoder for Mode S and ADS-B signals ?
It’s very cliche that a significant number of RAs i’ve seen have been SWA climbing with higher than usual climb rates
2021-03-24,10:54:33.7,aab0ba,DF:,17,bytes:,E2E000069ED3C8, 31.545181, -82.520896,37400,ft, 2048,fpm,ARA:,1110000,RAT:,0,MTE:,0,RAC:,0000, , RA: Level Off, 2021-03-24,10:55:10.2,aab0ba,DF:,17,bytes:,E2E000069ED3C8, 31.592257, -82.584998,37500,ft, -128,fpm,ARA:,1110000,RAT:,0,MTE:,0,RAC:,0000, , RA: Level Off, 2021-03-24,10:55:11.1,aab0ba,DF:,17,bytes:,E2E000269ED3C8, 31.593430, -82.586598,37500,ft, -128,fpm,ARA:,1110000,RAT:,1,MTE:,0,RAC:,0000, , Clear of Conflict; RA: Level Off,
No, it’s just from a python script I put together a couple of years ago… Let me see if I can release it (it’s an internal FA tool)
Don’t sweat it … pretty sure the format is similar to the MB format will just have to see if the thread is formatted similarly.
And that format is well documented in that pdf i linked before.
Otherwise it would have been very unlikely that i got something as fast as i did that makes sense, as in repeated message, aircraft did in fact level off before going to the full flight level.
Should be an identical format except for the first 8 bits (BDS code vs. ME typecode) IIRC
Yep seems plausible:
2021-03-24,12:33:33.9,a4ad17,DF:,17,bytes:,E2E000068C2838, 34.039490, -77.926810,37350,ft, 3584,fpm,ARA:,1110000,RAT:,0,MTE:,0,RAC:,0000,,TTI:,01, , RA: Level Off; threat hexid: a30a0e, 2021-03-24,12:33:33.9,a30a0e,DF:,17,bytes:,E2C2020692B45C, 33.957458, -77.940879,39000,ft, 64,fpm,ARA:,1100001,RAT:,0,MTE:,0,RAC:,1000,,TTI:,01, not below, RA: Climb; threat hexid: a4ad17,
Also didn’t get any DF16 in this instance.
Wow, thank you everyone for the discussions. Very interesting and is helping my understanding. Sorry for the noob questions. Been using piaware for a long while now but haven’t gotten more in-depth lately.
Any suggestions or maybe even something glaringly obvious that I have missed on how to save the RAW data to disk?
If the TCAS info is in the RAW I may have someone that can assist me in decoding the data.
@wiedehopf I will checkout your github, just messed up my pi playing with another script so I have to get up in the attic to fix it.
It will save a file for every day with lines that look like the examples i posted.
These include the bytes for the data section which is the most relevant part in this case.
If you want a different output you will have to modify the logACASInfoShort() function to do what you want. That will require at least some understanding of C code.
But a word of caution: RAs aren’t that common so likely the files will just be empty for your local receiver.
You’re asking for something very specific, nothing “easy to use” exists for it.
Very much appreciated, got readsb up and running well see if I get anything. I am within range of a major US airport which doesn’t have a ton of RA’s but maybe some.
Understand that I am asking for something specific so again I appreciate your help as I have not been able to get a clear understanding of options until now.
Does the file i mentioned exist, the acas.csv?
If it does then it should be working.
It will become acas.csv.gz after the UTC day changes for archival purposes so be aware of that.
The file does exist and I captured one TCAS encounter last night.
So i presume you also have tar1090 running?
You can look at this:
you can also specify &startTime=13:30&endTime=13:45
That way you can look at the traces of the two hex ids in that have the encounter.
If the acas.csv isn’t enough for whatever you do check out acas.json it has the current aircraft state in all its detail.
The globe_history directory will grow, hopefully not too fast you’ll have to remove old data yourself if necessary due to space.
That is awesome! thank you
I have the files saving to my NAS so I should be able to collect for a while.
You can click on the traces to move the planes to that time, there is some plan functionality that doesn’t really work well yet with more than one plane.
But more importantly you can enable track labels with K.