3 ms·

Pretty commendable. Code graph shows active development frequency on Sat and Sunday and >7pm on weekdays, a serious labor of love side-project with 1K+ commits,

by on_ 11y ago

Pretty commendable. Code graph shows active development frequency on Sat and Sunday and >7pm on weekdays, a serious labor of love side-project with 1K+ commits, what amounts to a single contributor, and you only have one branch, ballsy, I like it. I have a SDR and a Raspberry Pi. Do you think it would be capable of running ShinySDR?

privong 11y ago
> I have a SDR and a Raspberry Pi. Do you think it would be capable of running ShinySDR? This issue[0], though specifically discussing the BeagleBone Black, suggests it might suffer on a pi (based on a quick comparison of their specs). [0] https://github.com/kpreid/shinysdr/issues/17 https://github.com/kpreid/shinysdr/issues/17
- throwaway7767 11y ago
  SDR is notoriously CPU-heavy if you're doing anything beyond the really simple stuff. I quickly gave up on using my Pi for SDR and moved to a mid-range mobile Core i5 which is a lot more capable, but even that is starting to strain and I might need to split the processing to a couple of machines in the future. Looking forward to trying this when I get home.
  - 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 ago
      I 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 ago
        Does your proof of concept cover unencrypting it, too?
        throwaway7767 11y ago
        No, 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)

by on_ 11y ago

privong 11y ago

> I have a SDR and a Raspberry Pi. Do you think it would be capable of running ShinySDR? This issue[0], though specifically discussing the BeagleBone Black, suggests it might suffer on a pi (based on a quick comparison of their specs). [0] https://github.com/kpreid/shinysdr/issues/17 https://github.com/kpreid/shinysdr/issues/17

throwaway7767 11y ago
SDR is notoriously CPU-heavy if you're doing anything beyond the really simple stuff. I quickly gave up on using my Pi for SDR and moved to a mid-range mobile Core i5 which is a lot more capable, but even that is starting to strain and I might need to split the processing to a couple of machines in the future. Looking forward to trying this when I get home.
- 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 ago
    I 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 ago
      Does your proof of concept cover unencrypting it, too?
      - throwaway7767 11y ago
        No, 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)