Hi Håken!
That sounds very exciting! I haven't had time to look at your source code, I'd especially
be interested in your synchronization methods and your choice of LDPC codes (we're deep
into the "short code length for limited latency" vs "code effectiveness" tradeoff area here!)
You're using ChaCha20, which is a stream cipher, right? That's interesting because if you
lose a single ciphertext block, say, to a single uncorrectable bit error after FEC, then
you need a way of continuing to work. How does that work? Do you keep multiple Key/Nonce
pairs around and round-robin between a larger number of ChaCha20 instances, to give you
some leeway to continue to decode OPUS while the receiving end asks for a keystream
reinitialization?
To kick off a bit more discussion, let me quickly answer your questions to the best of my
abilities:
1. *Channel modeling:* Are the GNU Radio fading channel models
(Rayleigh/Rician)
representative of real-world mobile conditions, or should I expect
different results
on-air?
They are what they say on the box :) It's hard to say whether Rayleigh or Rician fading
describes the channels you are aiming at. Intercontinental HF links are different than
indoors 5.8 GHz channels!
So, you need to define your use case first.
2. *LDPC implementation:* I'm using hard-decision decoding for simplicity. For
those
who've implemented soft-decision LDPC in GNU Radio, what's the practical
performance
gain (measured, not theoretical)?
That depends on very many factors, mostly on decoder design, block length and maximum
iteration count.
I'm assuming you're just using the belief propagation sum-product decoder that is in
gr-fec? That does do soft decoding, you'd need to pass in soft-bit RX values, though.
It's really been a while since I thought about FSKs higher than 2-FSK (that aren't
differnetial).
Gut feeling here says that 4-FSK it's a pretty suboptimal use of signal power.
I suspect that the first thing you'd do is drop the FSK approach there, and go for a
modulation scheme that allows for soft-bits where, at least in AWGN, the entropy per bit
is a bit better behaved? But I'm really swimming dangerously close to the edge of my
channel decoder knowledge there.
3. *Frequency offset:* The ±1 kHz sensitivity is possible concerning.
Is it? What carrier frequencies are you aiming at? What are your
synchronization options?
Let's start with some back-of-envelop calculations here: You're aiming at a 8000 b/s rate,
using a r=2/3 code that's 12000 b/s code, using 8-FSK, that's 4 kSym/s.
Unless you're overly wasteful with your FSK spacing, that's a rather narrow channel, and
tolerating 1/4 of the symbol rate as frequency offset is rather phenomenally good!
Hence, recommendation to describe your current frequency synchronization in more detail.
You're clearly doing something (else much less than a quarter-symbol rate frequency error
should lead to breakdowns) right already!
Has anyone
implemented effective AFC for FSK in GNU Radio? Recommendations for
libraries or
approaches?
Depends on what you're currently doing, and what your framing, pilot, preamble, and system
synchronization structure (is this just one-way? Or can both ends agree on corrections?) are.
4. *Performance validation:* How do simulation results typically compare to
hardware
testing in your experience?
I think you'll realize that the only possible answer to this is "it depends" :D
> What factors cause the biggest discrepancies?
The things you don't expect :) Sorry! This is a bit broad. As said, synchronization and
system aspects are often more relevant than textbook knowledge would suggest, but I
clearly don't know what background you're doing this from, and hence, what you've covered
already.
Best,
Marcus
