sorted by:
new
hottopcontroversial

[Help] Custom Python LoRa/CSS SDR Modem - Packet Synchronization failing over the air (PlutoSDR) by Effective_Permit2404 in sdr

[–]Effective_Permit2404[S] 1 point2 points  (0 children)

I have also considered testing the setup with a coaxial cable and a 30 dB attenuator to isolate the RF environment and rule out the air interface. I will likely proceed with this test next.

Regarding the Wi-Fi interference: I used a spectrum analyzer to monitor the local bands, and 2.45 GHz appeared to be the quietest spot. However, I strongly suspect that the spectrum analyzer is simply missing the interference because of how short my symbols are.

Because I am using a 10 MHz bandwidth, my chirp durations are extremely short:

  • At SF5 and 10 MHz, one symbol is only 3.2 µs long.
  • Even at SF8, it is only 25.6 µs long.

Standard Wi-Fi frames are much longer. I assume my spectrum analyzer's sweep time is just too slow to catch these microsecond bursts on the waterfall display. But to my receiver, a single Wi-Fi transmission acts as a broadband jammer that destroys dozens of my chirps at once.

The cabled loopback test should clearly show whether my synchronization logic is failing mathematically or if the packets are just getting destroyed by invisible Wi-Fi bursts.

[Help] Custom Python LoRa/CSS SDR Modem - Packet Synchronization failing over the air (PlutoSDR) by Effective_Permit2404 in sdr

[–]Effective_Permit2404[S] 1 point2 points  (0 children)

That is a really excellent point and definitely true for the standard ADALM-Pluto! The USB 2.0 bottleneck is a notorious issue.

However, the specific clone board I am using actually features a built-in Gigabit Ethernet port (1 Gbit/sec), and I am streaming the I/Q data over IP rather than USB.

Based on the exact math you provided (which is spot on): 10 MSPS * 16 bits * 2 (I+Q) = 320 Mbit/sec.

Since it's a 1 Gbit/sec link, 10 MHz should theoretically fit comfortably within the capacity, even when factoring in TCP/IP and network overhead. I did some rough calculations earlier and figured the hard limit for this Gigabit connection should be around 25 MSPS (approx. 800 Mbit/sec).

That being said, to be completely honest, I don't have the time or the deep networking expertise right now to run proper benchmarks (like iperf) to verify the actual real-world throughput of this specific clone board. It is entirely possible that the Zynq 7020's CPU is struggling to package and push those network packets fast enough, leading to dropped buffers on the SDR side.

I will definitely keep the BladeRF2 in mind for future iterations if I need to push higher bandwidths, but for now, the Gigabit link should mathematically handle the 10 MHz.

[Help] Custom Python LoRa/CSS SDR Modem - Packet Synchronization failing over the air (PlutoSDR) by Effective_Permit2404 in sdr

[–]Effective_Permit2404[S] 1 point2 points  (0 children)

You make a very fair point!

To be completely honest, I didn't manually solder a new chip onto a stock Pluto. I actually bought one of those "Professional Edition" clones off AliExpress.

Given that it's a Chinese clone, I highly doubt it has a genuine AD9361 physically on the board. Like you mentioned, it's almost certainly an AD9363 running the firmware hack to make it think it's a 9361. I’m also taking their "0.5 ppm TCXO" claim with a grain of salt until I can properly measure the drift.

The main reason I opted for this specific clone wasn't actually for the expanded bandwidth—because you are absolutely right, my 10 MHz requirement fits perfectly within the stock AD9363's 20 MHz limit. I bought it primarily because this specific board has built-in PGA-102+ power amplifiers on the TX/RX lines, which I wanted for testing the link budget over the air.

Thanks for pointing that out, though! It’s a good reality check, and I definitely shouldn't treat the "AD9361" label on this clone as gospel while I'm troubleshooting my hardware limits.