jgromes / RadioLib

Universal wireless communication library for embedded devices
https://jgromes.github.io/RadioLib/
MIT License
1.6k stars 400 forks source link

FSK communication between SX1268 and SX1278 does not work. #123

Closed lillefyr closed 4 years ago

lillefyr commented 4 years ago

Data from an ESP32 Lolin D32 with a SX1268 attached transmitted with FSK to an Arduino Uno with LoraHat SX1278 does not arrive (Using LoRa transmission, data arrives fine)

Transmit code SX126x_Transmit_FSK_lolin_d32_ok_minimal.ino.txt

Receive code SX127x_Receive_FSK_LoRaHat_ok_minimal.ino.txt

Dump of the output from the two devices. in "TypeDef.h" uncommented

define RADIOLIB_DEBUG

define RADIOLIB_VERBOSE

FSK_communication_problem.txt

To Reproduce Two sketches attached. Hardware specific, thought only for the pin setting.

Expected behavior Data sent from ESP32 to Arduino Uno should arrive

Additional info

jgromes commented 4 years ago

I'm aware of this, FSK transmissions are incompatible between SX127x and SX126x at the moment. I think there's something that's not configured correctly on either side, but figuring out what exactly would require recording a transmission from both chips (using the same FSK parameters) and thorough examination of the recording - something which is unfortunately above my skill level.

My guess would be whitening (since SX127x datasheet doesn't specify the initial whitening value) or preamble (since there's a bit of ambiguity in SX126x docs whether preamble length is programmed in bits or bytes).

lillefyr commented 4 years ago

Further tests show that SX1268 <--> SX1268 FSK communication works fine. A note of the current limitation could be added to the example code, stating that at present FSK can not be received by boards with SX1278 (as FossaSat-1B&2 uses SX1268)

jgromes commented 4 years ago

I'm not sure that's necessary, communication accross different modules isn't guaranteed.

It did give me an idea though, perhaps we could try other FSK modules (CC1101 or RF69 for example) to see if those can communicate with SX127x/6x.

jgromes commented 4 years ago

My guess would be whitening

Looks like my initial hunch was correct, if both SX127x and SX126x are set to NRZ encoding (setEncoding(0)), then FSK communication works fine. Also, the default Gauss filter bandwidth-time product is set to 0.3 on SX127x, it must be set to 0.5.

I'll change the default BT value and keep investigating, to see if we can get FSK with whitening working,

lillefyr commented 4 years ago

I added setEncoding(0) after setSyncWord in both examples above. The Gauss filter was already 0.5. I further tried to swap so SX1268 was receiver and SX1278 was transmitter. In both cases, no FSK communication occurred. It is not possible to set the same bandwidth for the two modules. Is that the problem?

jgromes commented 4 years ago

Those examples have quite narrow frequency deviation (5 kHz), are you using TCXOs on both ends? If you have just standard crystal oscillators, you might be a few kHz off, which is enough to stop you from receiving. I suggest to adjust carrier frequency on tx or rx to compensate, or to use higher frequency deviation.

It is not possible to set the same bandwidth for the two modules

That's just the receiver filter bandwidth. the actual signal bandwidth is determined by frequency deviation.

I'm currently bruteforcing all 65536 possible initial whitener values on SX126x (since as usual, there's nothing helpful in Semtech docs and what was posted here is provably false, 0x100 doesn't work). Got a few matches (0x1FF, 0x3FF etc.) but will keep testing.

EDIT: Oops, forgot the whitening LSFR is only 9 bits wide. In that case, the actual initial whitener value for SX127x is 0x1FF.

jgromes commented 4 years ago

Furhter testing shows that when using 0x1FF as the initial whitening value on SX126x, FSK works for 7x-to-6x and vice versa. I'll push commits addressing the issue shortly, so from now on, using the default beginFSK() with no additional changes will be enough to get 6x/7x FSK link started.

jgromes commented 4 years ago

It seems like the issue is resolved now, feel free to reopen later if there are any other problems.