Request : Documentation

[LieBtrau]

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 :

1. Fancy header. This seems to add extra data after the packet, so it's actually a footer. I have no clue what the use of the fancy header is.
2. Channel selection : first & second seems to select left or right audio channel. Analytical seems to send (identical?) data on both channels. Is the data identical?

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

[xdsopl]

Fancy Header:

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.

Channel Selection:

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

Operation Mode:

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 code
• medium protection: 128 bytes using a 1/2-rate code
• normal protection: 170 bytes using a 2/3-rate code

This allows us to communicate up to 85 bytes over difficult channels and up to 170 bytes with better channels.

COFDMTV Website:

Improving the COFDMTV page is on my TODO list.

[LieBtrau]

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:

1. PhaseShiftKeying<4... -> PhaseShiftKeying<8...
2. mod_bits = 2; -> mod_bits = 3;

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

[xdsopl]

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.