Open LieBtrau opened 6 months ago
The Fancy Header
was in fact a header (in time) while implementing and testing and we moved it to the end of the transmission later. But because it is meant to be seen in a spectrum analyzer, and a waterfall plot usually shows the oldest spectrum on the bottom and the newest on the top, the Fancy Header
is in fact on top of the signal:
https://youtu.be/0jtzA3alpuw?si=HGekAQE749nJps1l&t=201
Well, the name stuck. Guess that settles it then.
The option to choose an Analytical
channel is meant to be used with IQ signals:
https://en.wikipedia.org/wiki/In-phase_and_quadrature_components#I/Q_data
We don't do the Hilbert transform there and rely on the analytical properties of the IQ signal, so it has two channels: the In-phase and the Quadrature components. You can get that for example from a Tayloe detector:
https://www.youtube.com/watch?v=JuuKF1RFvBM
Because we wanted a signal that always has a fixed duration of one second, we decided to only change the code rate:
strong
protection: 85 bytes using a 1/3-rate codemedium
protection: 128 bytes using a 1/2-rate codenormal
protection: 170 bytes using a 2/3-rate codeThis allows us to communicate up to 85 bytes over difficult channels and up to 170 bytes with better channels.
Improving the COFDMTV page is on my TODO list.
Hi, Thanks for letting me know. In the mean time, I've been experimenting with the Rattlegram modem. I can now encode and decode packets on an ESP32. Other tests suggest that the code can be run in real-time on the ESP32. firmware test ESP32
The Rattlegram modem in this repository is compatible to the short-branch in the aicodix/modem repository. Both repositories differ quite a bit when it comes to encoding symbols. Without documentation in the code, it takes quite some time to figure out what's actually happening. Having two different versions of the code that are functionally compatible helps in understanding what is going on under the hood.
I would like to try out Rattlegram with 8PSK instead of 4PSK being used now. That means making changes in the encoder and decoder:
Demodulation of the header works (mode and callsign decoded), but it results in payload decoding error. The master branch supports both 4PSK and 8PSK, so it must be possible.
What am I forgetting? Does it have to do with the cons_cols and cons_rows? It's not clear to me what these variables do.
Regards,
Christoph
If the number of OFDM symbols stays the same, you have much more bits, this means you are creating buffer overflows. You need to increase the buffer sizes and choose a larger Polar code accordingly. Look in the next branch. The code there is the best I have released at the moment and supports QAM16 and QAM64. It should be easier to understand too.
Hello,
I experimented with the Rattlegram app, sending data to a computer running the command line version of the Rattlegram modem. This works fine.
The app has some settings which are unclear to me :
The operating mode is not a setting. It's selected automatically based on the number of data bytes in the packet (0, 85, 128). What is the difference between strong, medium and normal protection? Does it change the modulation as well (QPSK, 8PSK) or does it only have an impact on the error checking/correcting info? A page such as cofdmtv, but for the "short" branch of the modem would be really helpful to get a better grasp of what's happening under the hood.
Regards,
Christoph