Usage with the latest FSK codec2 demodulator

[scd31]

Hello!

First off, thanks for this project! I've written my own version of the TX side from the ground up to use the FIFO buffers on the si4463, eliminating the RS232 overhead. I've also slightly modified the downlink side to take out the de-RS232ing code. I'm easily pushing 500kbps - the maximum the si4463 can support.

I'm interested in updating the FSK demodulator with the latest one in the codec2 repository. I've noticed it's not a drop-in replacement - it doesn't work out of the box - and am curious why. Maybe this is a question for that repo, as my understanding is the version shipped with wenet is just an older version of that (why has it changed?)

The reason I want to update is because the current 4-FSK demodulator doesn't appear to work right. I'm able to get the codec2 4-FSK demodulator working to some extent, though it drops packets. The 2-FSK demodulator doesn't work at all. I'd like to get that working so I can debug what's going on when it's put into 4-FSK mode.

Once I get 4FSK working, I hope to push 1mbps - the maximum the si4463 can support.

Thanks again for this project!

[scd31]

I just gave it another try because I wanted to be a bit more specific about the problem.

In 2-FSK mode, I'm getting many missing packets, just like in 4-FSK mode. Note that I get very few packet errors from drs232 - it looks like the preamble is getting too mangled for it to even detect there's a packet in the first place. Also, I'm admittedly only oversampling by 4x, but this isn't a problem for the wenet demodulator.

The spectrum/FFT plot doesn't look anything like with the demodulator shipped with wenet. It doesn't resemble a 2-FSK signal at all.

[darksidelemm]

Hi!

Great to see some development work happening on Wenet, all I've really had time to do recently is receiver web interface improvements.

I'm not entirely surprised there's differences in the upstream repository. I know there was a lot of work done to calculate LLRs for 4FSK, and I'm guessing there were changes to 2FSK as well. It would be worthwhile rebasing Wenet to the latest decoder for sure, but I haven't really had time, and the current system has been working so well that I haven't really had the impetus to do it.

Transmitting without the RS232 framing is certainly a good improvement, what would be good is a drop-in replacement for drs232_ldpc which can be called in the startup scripts as an option.

As for transmit, I think it would be better to be able to do this directly from the RPi's SPI interface rather than going via a microcontroller (perhaps with an external C/rust program?), as it would allow existing transmit systems to be upgraded. I believe @fsphil did some work on this using the RFM98W module.

Cheers, Mark

[scd31]

Hi @darksidelemm ,

I can probably submit a PR at some point to add the non-dr232 version of the LDPC decoder.

I'm only using a microcontroller temporarily - I have some PCBs coming in the mail that connects the RF4463F30 directly to the SPI bus of the Pi. I agree that that's a much nicer solution. Porting the code should be very easy - it's all written in Rust so it should just be a matter of copying some files around.

I should also mention that I don't think any of my TX changes will be very useful for this project, at least in their current form. It's all basically a big monolith that I'm using to do everything for my balloon (at least, on the comms side). That said, it wouldn't be too hard to rip out some of it, essentially replacing the TX side of wenet. You can check it out here: https://gitlab.scd31.com/stephen/balloon-tx-monolith

I'll see if I can get the codec2 demodulator working.

Thanks!

[scd31]

Hi again @darksidelemm ,

Do you have any thoughts on how much of a hit to my link budget it would be if I used another si4463 chip for demodulation? I'd still use the LDPC codes but I know they work better with soft demodulation, which the si4463 doesn't support. I do have a second module but I lack the required RF gear to take measurements myself.

[darksidelemm]

Unsure exactly, but probably a few dB. I'd go with the SDR approach for better visibility of what's going on too...

[drowe67]

Hi @scd31 - saw your direct message to me. It's hard to say what the issue is from the information provided. You've also made a lot of changes. Suspect it's some sort of config/set up/integration issue. Some suggestions:

1. Move the latest FSK code to this repo and make sure all the ctests work (I'm presuming their are still tests for the fsk modem in this repo).
2. Work at the test frame and command line tool fsk_mod/fsk_demod level, rather than with integrated applications.
3. Try to get the uncoded test frames working first, then enable the FEC.
4. Go back the the vanilla framing, get that working first.

[scd31]

Thanks! I'll give those a try.

Also wanted to mention it looks like there's a 6db difference between soft and hard LDPC decoding. Combined with the likely inferior performance of the si4463 receiver it seems like it's not worth pursuing using the same module for reception.