Hello there,

For one of our applications it is desirable to switch from ABP LoRaWAN packet sending to sending data with FSK, and back again. Ideally all with the same LoRaWan-RAK4630.h library, if possible.

Any advice on how to proceed this way?

Hello Charles,

Do you mean
a) Use FSK with LoRaWAN?
b) Switch from LoRaWAN to LoRa P2P using FSK and back?

Hello Bernd,

The latter case, switching from LoRaWAN to LoRa P2P using FSK and back.

I have a node that occasionally has to send a high-bandwidth payload that could greatly benefit from dropping to the 50 kbps FSK scheme and back again as needed, do you think this is possible?

Hi Charles,

It should be possible, as long as you do not switch between the two modes while one mode is active. One thing I never tried is using LoRa FSK mode.

Just out of my head (need to verify)

  • Send packet over LoRaWan
  • wait for TX finished callback
  • switch LoRa transceiver to FSK mode
  • send packet over P2P using FSK
  • switch LoRa transceiver back to LoRa mode (not sure if library does this automatically)

I am not sure if the SX126x-Arduino library supports that. Even I ported it from some existing Insight/Semtech code, I never tried to switch between LoRa (used by LoRaWan) and FSK (P2P mode).

Thanks again for your reply Bernd. I’ll do some experimenting to see how to go about this, good to know it’s feasible in theory!

FYI I believe I was able to get FSK working with just a few tweaks to the LoRaP2P example in the arduino library examples. It’s lossy, bytes are easily corrupted (“hello” becomes “heblo” pretty often), but it works!

Here’s what I had to change on the RX side:

	Radio.SetRxConfig(MODEM_FSK, //LoRa or FSK
	250000, //Bandwidth
	50000, //datarate
	0, //coderate
	250000, //badwidthAfc
	8, //preambleLen
	8, //symbTimeout
	0, //fixedLen,
  0, //payloadLen,
  0, //CRC on
  0, //freq hopping on
  0, //freq hop period
  0, //IQ inversion
  true); //continous reception mode (class C)

And the TX side:

Radio.SetTxConfig(MODEM_FSK, //LoRa or FSK
  10, //power
  1000, //fdev
  250000, //bandwidth
  50000, //datarate
  0, //coderate
  8, //preamblelen
  0, //fixedLen,
  0, //crcOn,
  0, //freq hopping on
  0, //freq hop period
  0, //IQ inversion
  100); //timeout
1 Like

Strange, I used P2P with LoRa before and had no such problems.
Maybe it needs a kind of handshake between sender and receiver and enabling CRC.
send packet with CRC on
wait for ACK
get packet with CRC false
send no ACK
ACK timeout
resend packet with CRC on
Wait for ACK
get packet with CRC correct
send ACK
received ACK

Maybe this can help.