In previous post of this series I have been comparing the specs of various Sub-GHz transceiver ICs. In this part, the goal is to let different transceiver ICs of different brands communicate. In this part, I will let a HopeRF RFM69 module, which appears a rebranded SemTech part, close to the SX1231H, communicate with a SiLabs Si4432. Of each module I have 433 MHz and 868 MHz variants.

Of these modules I have most experience with the RFM69, aka Semtech SX123x. The Silabs Si4432 is, as far as my research goes, also sold by HopeRF under the name RFM22. As far as the RFM69 goes, configure frequency, bitrate, frequency deviation and bandwidth filter. Set it in packet mode and select the desired modulation, and we’re ready to go.

My first steps on the Si4332 module was to transmit and receive data between two Si4332 modules. At their default bitrate, everything works fine. The problem I mentioned in my previous attempt at the Si4332 turned out to be a stupid bug. When I looked at the code again, it was screaming at me. I only wrote one byte to the FIFO. No wonder I was only able to receive one byte! Duh!

That aside, trying to configure it at a different bitrate, by setting bitrate, frequency deviation and bandwidth filter, as I would do on the SX1231, results in nothing being received. It turned out, configuring the Si4332 takes some additional steps. There are a few Clock Recovery registers that need to be set with values derived from what is set to the bitrate, frequency deviation and bandwidth filter registers. After setting those, I could communicate at any desired bitrate.

So, can we send packets between an Si4332 and an SX1231 yet? Nope… that won’t work yet. At first, looking at the transmissions with an RTL-SDR, it seemed the Si4332 was transmitting at about 11 kHz too low at the 433 MHz band and 22 kHz too low at the 868 MHz band. To solve this issue, I had a look at the Crystal Oscillator Load Capacitance register. As this is a no-brand AliExpress module, there is of course no datasheet. And even if there were a datasheet, they hardly ever mention details about the used crystal. So I went with trial and error to find a value that will fix this offset. I wrote 0x69 to register 0x09, and the tuning issue was corrected.

Now, can we communicate yet? Nope.. not yet. The SX1231 would just set the timeout bit in the status register and do nothing. This issue was resolved by increasing the value in the RXTIMEOUT2 register, which I has set to 0x10 for communicating between SX1231 modules, to a higher value. For now I have set it to 0x40. I guess it can be lower, but for now, this value works.

As for the Si4332 I had to disable the transmission header, which was set to two bytes by default. Details, details. Also, the Si4332 has four different CRC options, and it was set to CRC-16-IBM, while the SX1231 has only one CRC option: CCIT. But even setting the Si4332 to use CCIT CRC, didn’t make it receive anything. But when I disabled CRC on both modules, they can receive each others packets.

I guess many things can be tuned and tweaked, but as a proof of concept, it works.