softlora: a pure-Python LoRa PHY decoder + TinyGS SDR ground station

Hi all,

I wanted to share a project I've been working on this summer as part of
Google Summer of Code 2026 with LibreCube: a pure-Python LoRa physical-layer
receiver (softlora) and an SDR-based TinyGS ground station (tinygs).

softlora decodes LoRa packets from IQ recordings or live SDR streams using
only NumPy/SciPy. Synchronization implements the three-stage CFO/STO estimator in [1], and I ported gr-lora_sdr's frame_sync block as an alternative front-end. It's
tested on synthetic AWGN sweeps, over-the-air captures, and real satellite
passes (SF7-12).

Links:

  Project write-up:            https://studhamza.github.io/hamza-folio/projects/LoRa_tinygs/

  softlora (LoRa PHY decoder): https://gitlab.com/librecube/lib/python-softlora
  tinygs (ground station):     https://gitlab.com/librecube/lib/python-tinygs

Happy to answer questions and get feedback. :)

[1] M. Xhonneux, O. Afisiadis, D. Bol, and J. Louveaux, "A Low-Complexity
    LoRa Synchronization Algorithm Robust to Sampling Time Offsets," IEEE
    Internet of Things Journal, 2021. https://arxiv.org/abs/1912.11344

Cheers,
Hamza Sayed

Re: browser use?

Hi Don, sure, since we even embed it on our gnuradio.org website, we're kind of aware :) No, seriously, thanks for bringing it up. Marc, of pysdr.org and iqengine.org fame wrote that *specifically* to make classroom beginner teaching and individual experimentation easier. Best, Marcus On 2026-09-14 6:23 PM, Don Latham wrote: > I assume the group has found https://gnuradioworld.com <https://gnuradioworld.com/> > Any comments? Useful for us beginners?

browser use?

I assume the group has found  https://gnuradioworld.com

Any comments? Useful for us beginners?

Function arg checking

I was checking some code[1], and found some null pointer deref and other precondition issues.

One interesting pattern was when the use happens in a constructor initializer list, but then the actual check is done in the constructor body.

Any opinions on what pattern should be used, here? One way is to simply move the usage below the check. But that prevents the compiler from enforcing e.g. that d_ted is initialized before d_interp, which uses d_ted, is initialized.

Another way is this:

$ git diff
diff --git a/gr-digital/lib/symbol_sync_ff_impl.cc b/gr-digital/lib/symbol_sync_ff_impl.cc
index 82b5a8036..dbc68a4f1 100644
--- a/gr-digital/lib/symbol_sync_ff_impl.cc
+++ b/gr-digital/lib/symbol_sync_ff_impl.cc
@@ -47,6 +47,15 @@ symbol_sync_ff::sptr symbol_sync_ff::make(enum ted_type detector_type,
                                                           taps);
 }
 
+template <typename C, typename F>
+auto check(C c, F f)
+{
+    if (!c()) {
+        throw std::runtime_error("bleh");
+    }
+    return f();
+}
+
 symbol_sync_ff_impl::symbol_sync_ff_impl(enum ted_type detector_type,
                                          const float sps,
                                          const float loop_bw,
@@ -69,7 +78,11 @@ symbol_sync_ff_impl::symbol_sync_ff_impl(enum ted_type detector_type,
               damping_factor,
               ted_gain),
       d_interp(interpolating_resampler_fff::make(
-          interp_type, d_ted->needs_derivative(), n_filters, taps)),
+          interp_type,
+          check([this] { return d_ted != nullptr; },
+                [this] { return d_ted->needs_derivative(); }),
+          n_filters,
+          taps)),
       d_inst_output_period(sps / static_cast<float>(osps)),
       d_inst_clock_period(sps),
       d_avg_clock_period(sps),

But introducing such a pattern is a bigger stylistic change, and seems like it should be "blessed" as a good pattern before spreading.

This also applies to other UB stuff like glfsr_source_b_impl.cc which shift left by a potentially UB-triggering value before it bounds checks it (also it should not allow 64 exactly, and probably instead needs to special case it).

Opinions?

[1] Well, truth be told I'm asking LLM to "find bugs and UB".

--

typedef struct me_s {
 char name[]      = { "Thomas Habets" };
 char email[]     = { "thomas@habets.se" };
 char kernel[]    = { "Linux" };
 char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt" };
 char pgp[] = { "9907 8698 8A24 F52F 1C2E  87F6 39A4 9EEA 460A 0169" };
 char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;

how can I change blocks to run this script for hackrf card

Hello,

I like to change voltage oscillator according to this tread, so that I can run hackrf card, sweep need to be 50-70e6 

https://lists.gnu.org/archive/html/discuss-gnuradio/2016-04/msg00495.html

Thanks, Robin

Re: GRCon26 Standard Pricing Extended Through Friday

REMINDER - tomorrow, Friday 4 September is the last day to register at standard prices. 

Look forward to seeing everyone there!

On Mon, Aug 31, 2026 at 8:22 AM Josh Morman (GNU Radio) <jmorman@gnuradio.org> wrote:

We realized we missed sending a reminder that GRCon26 registration prices were about to increase, so we’re extending standard registration pricing through Friday to give everyone a little more time.

If you’ve been planning to join us in Raleigh, now is a great time to register.

GRCon26 is shaping up to be an outstanding week (schedule), with:

• 14 workshops/tutorials covering a wide range of GNU Radio, SDR, and wireless topics
• An outstanding keynote lineup
• An amazing slate of technical talks from across the community
• A packed expo hall with both longtime and new sponsors and exhibitors
• Plenty of social events, networking, and opportunities to connect with the GNU Radio community and industry
• Capture the Flag contest
• Amateur Radio Exams
• AERPAW Demo on Friday!!

We’re incredibly excited about this year’s program and hope you’ll join us at NC State University in Raleigh.

Registration: https://tickets.gnuradio.org/grcon26/

All the info: https://events.gnuradio.org/event/28/

Standard pricing is available through Friday - please register before the prices go up!

We look forward to seeing you at GRCon26!

- The GNU Radio Conference Organizers

GRCon26 Standard Pricing Extended Through Friday

We realized we missed sending a reminder that GRCon26 registration prices were about to increase, so we’re extending standard registration pricing through Friday to give everyone a little more time.

If you’ve been planning to join us in Raleigh, now is a great time to register.

GRCon26 is shaping up to be an outstanding week (schedule), with:

• 14 workshops/tutorials covering a wide range of GNU Radio, SDR, and wireless topics
• An outstanding keynote lineup
• An amazing slate of technical talks from across the community
• A packed expo hall with both longtime and new sponsors and exhibitors
• Plenty of social events, networking, and opportunities to connect with the GNU Radio community and industry
• Capture the Flag contest
• Amateur Radio Exams
• AERPAW Demo on Friday!!

We’re incredibly excited about this year’s program and hope you’ll join us at NC State University in Raleigh.

Registration: https://tickets.gnuradio.org/grcon26/

All the info: https://events.gnuradio.org/event/28/

Standard pricing is available through Friday - please register before the prices go up!

We look forward to seeing you at GRCon26!

- The GNU Radio Conference Organizers