Skip to content
Fred Clausen edited this page May 22, 2023 · 4 revisions

Anyone bored, monitor ACARS, and want to preview the ACARS/VDLM/Everything-else-I-can-think-of-related-to-ACARS decoder I've been writing?

  acarsoxide:
      image: ghcr.io/sdr-enthusiasts/acars-oxide:latest
      tty: true
      container_name: acarsoxide
      restart: always
      labels:
        - "autoheal=true"
      devices:
        - /dev/bus/usb:/dev/bus/usb
      environment:
        - TZ=${FEEDER_TZ}
        - AO_VERBOSITY=debug
        - AO_SDR1SERIAL=00012507
        - AO_SDR1FREQS=130.025;130.450;131.125;131.550
        - AO_SDR1DECODING_TYPE=ACARS
      tmpfs:
        - /run:exec,size=64M
        - /var/log

Obviously replace the SERIAL line with what you need, and the freqs line should mirror what is in your acarsdec container.

What I am most curious about is CPU usage and do you feel like Oxide is missing messages acarsdec hears? Basically, is the message rate the same?

Known issues:

  • It supports multiple SDRs! I haven't tested it :(
  • It is only going to print received messages to the console. You will need to docker logs -f acarsoxide to watch what it's doing.
  • Related to above, you cannot feed the data in to any consumers (ACARS Hub, Airframes, etc).
  • There is a bug related to error/crc correction. I haven't looked in to it, but any message that acarsdec is able to correct, oxide cannot yet. The logic is there, it should, but it isn't. I haven't put the mental energy in to it yet.
  • This is only for ACARS. VDLM2 is coming
  • CPU usage is higher than I'd like, especially relative to acarsdec
  • I haven't wrote a readme for this yet. Ask me about any other config options you're curious about...the only relevant one I can think of would be AO_OUTPUT_TO_CONSOLE=true, which will force it to output messages to the console. It will do that, anyway, with AO_VERBOSITY=debug set.
  • I've named this acars-oxide as a nod to using Rust to code this. I took no time on it, I think the name is kinda dumb the more time passes. I'm happy to take suggestions :)

Why have I done this? I appreciate all of the work everyone in this space is doing, but I've found it frustrating not fully understanding the entire stack of ACARS related data. I've also, and again with full respect to all of the people who have spent their time on this, found it frustrating waiting on fixes, working around limitations, or simply trying to sus out what the decoder is telling me in the information. By me taking this on, and fully owning the entire tech stack related to ACARS decoding to consuming it, I can make acars_router and ACARS Hub much better and more powerful.

Just as an example of the "limitations" of the data the current acarsdec decoder puts out, I've discovered that it does full message recomposition, meaning that if it can put a multi-part message together, it does. I'm sure you've seen this in ACARS Hub with things like ATIS messages. You'll see 2 or 3 (or more) parts of the text of an ATIS message, and then a final one with all of the data. As a consumer of the data, specifically ACARS Hub, I think we can mostly all agree that really we only care about the fully assembled message, and yet ACARS Hub shows them all. That's a single example, and I've seen some other things while deep in the code of acarsdec, and I'm sure the deeper I dive in to this, the more I'll find. The communication of that state (and other things the decoder knows about) is either very opaque, or missing entirely.

If I control, and understand, the entire stack, well, ACARS Hub can be better.

Because I feel like I've been pretty negative towards the existing decoders and the work those people have put in to it, I'd like to be really really clear that what they've done is awesome, the only reason ACARS Hub exists is because of them, and the only reason acars-oxide can exist is because I have their work to go on. I'm simply not smart enough to figure out the logic for decoding radio signals. What I am capable of is looking at their work and emulating it. The protocol for the data they chose was likely made during a time we didn't understand what the source data was telling us, and what consumers of that data wanted. That is simply the main limitation.

Lastly, what is in store for Oxide? In no particular order:

  • Create unit testing to ensure I don't introduce bugs that cause Oxide to stop hearing all of the messages it should.
  • Clean up the code base with better variable names. I followed acarsdec's naming...."""conventions"""....just so I could ensure Oxide was doing what acarsdec was.
  • Create a small program to take in data from both acarsdec and Oxide to see if Oxide is missing any messages. This would require multiple SDRs, ideally on the same antenna, but will be valuable data.
  • Formalizing an output format that encapsulates all of the data ACARS Hub, Airframes, and any other consumer could fathomably want. At least, that's the goal. I'll take my queues from Kevin at Airframes, the community, etc. I would love to see a unified format that we all can use, evolve as we learn, etc. I have no interesting in creating another format that may or may not be supported by Airframes, and bespoke only to my purposes with ACARS Hub. Kevin, lets talk :)
  • Related to above, integrate the new format in to ACARS Hub. This will happen in the big rewrite of ACARS Hub, not before, and that project is slowly moving along.
  • Support Airspy as well as RTL-SDRs.
  • Potentially rewrite librtlsdr fully in rust to avoid pitfalls of librtlsdr
  • I am going to spend a lot of time, before adding in VDLM/HFDL decoding, optimizing and reducing CPU usage. I doubt I'll ever be as good as acarsdec, but where oxide is now isn't good enough.
  • Oxide may never get done. Kevin and Airframes are working on their own decoder to do exactly what Oxide does, and I know it'll be a better product. If that's the case, we don't need competition in this space. The progress I've made has been a huge learning process for me, and I feel like even if I stop here, I'm a better Rust programmer (and know more about ACARS!) then I was/did before. That, if I stop before this is done, is good enough for me. Our efforts are better served working together, and I'm happy to let the pros take the reins if that's where we need to be.
Clone this wiki locally