3 ms·
I have a Pi2 that runs Dump1090 for ADS-B just fine. Though I haven't tried any other SDR related tasks on it.
by ZanyProgrammer 11y ago
I have a Pi2 that runs Dump1090 for ADS-B just fine. Though I haven't tried any other SDR related tasks on it.
- throwaway7767 11y agoI am using the core i5 setup for TETRA receiving (2MHz sampling rate/1MHz bandwidth, tuning into 4 different channels in that range each with 64 subchannels). The whole pipeline runs just fine, but I would not be able to run a second pipeline for 4 more channels without faster hardware or a second machine. Largely this is because it's an inefficient proof-of-concept implementation, but in my experience it takes a lot of work to convert such a thing into a performant receiver.
- MrBra 11y agoDoes your proof of concept cover unencrypting it, too?
- throwaway7767 11y agoNo, I'm not aware of any projects that successfully crack TETRA encryption. That said, all the TETRA traffic around here is unencrypted, including the police and emergency services (surprising to me). The rumour I heard was that it was originally encrypted but they disabled it because key management was a pain in the ass. I'm basing my stuff on SQ5BPF's work, who added the (purposefully) missing bits in osmocom's osmo-tetra project: https://github.com/sq5bpf https://github.com/sq5bpf It works, but the code is not pretty and it's a really long pipeline of shell pipes and FIFOs. I'm working on simplifying the whole thing, I've already written a minimal replacement for telive. Hopefully I can change the pipeline from: GRC tuner flowgraph -> simdemod2.py (pi/4 CQPSK demodulator) -> float_to_bits (pi/4 float to byte-per-bit stream) -> tetra-rx -> telive to: tuner.py (combined tuner, pi/4 CQPSK demodulator and pi/4 float to byte-per-bit stream) -> tetra-rx -> tetrarec.py (telive replacement)