Question about the FHSS example code for SX127x

[danielfu11]

Hi,

In SX127x_Transmit_FHSS.ino example code, I see that the code explicitly sets the carrier frequency when a packet is successfully transmitted. However in SX127x_Receive_FHSS.ino, I do not see the code setting the frequency when a packet is successfully received.

I have two questions:

1. Why does the MCU need to set carrier frequency when a packet is successfully transmitted? I don't see where this was mentioned in the SX1276 datasheet
2. If this is needed, why is this not also done in the receive code?

Thanks, and please let me know if I need to further clarify my question

[jgromes]

Those are some good questions. It's been a while since FHSS for SX127x has been added ,so just to make sure we didn't break it in the mantime I tested it and it works as-is. I'm also not the original author of the FHSS implementation (which was @nseidle), so the answers are just my guesses as to what is going on:

1. I think the goal there is to always start from the same frequency. I'm not sure whether this is strictly needed (though when trying transmission without this, it didn't work, so maybe it is needed).
2. The modulation used is still LoRa, which has very high immunity to frequency offset between the transmitter and the receiver, up to 25% of the signal bandwidth IIRC. So my guess here is that the receiver is able to receive the data even when it is on the wrong channel. I added the switch to the home channel to the receive code, and it did not change the behavior, it works either way. Though for consistency we could consider adding it.

I could be wrong on both counts here though.

Also, since FHSS is working on SX127x (as I was able t oconfirm), I will convert this to a discussion instead.

[danielfu11]

Thanks for the reply! I think I did not present my question clear enough, explained under nseidle's reply below

[nseidle]

1. Maybe I'm missing something but if TX and RX on different frequencies, nothing works! Both TX and RX have to start on the same frequency.

2. Again, I must be confused because the RX freq is set here to match the TX freq.

If you're referring to what happens after a transmission is complete: yes, the RX and TX must return to a known good freq (ie, the carrier freq or... what's it called in WiFi, the coordination channel?). This is because if the RX unit fails to receive the signal, it will fail to hop and the TX will be ahead in the hop table, and on a different freq than the RX. By returning to the carrier freq, transmissions and re-transmissions can flow even if a packet is dropped.

This leads to more challenges, ie, FCC bans the transmission on any one channel for more than 400ms (over every 10s? every 20s?) so one approach is to transmit a small amount on the carrier freq (channel 0) that just sets the sort for the TX/RX hop tables, and data is actually transmitted on channel 1, channel 2, etc.

Hope this helps! Happy hopping!

[danielfu11]

Thanks for the reply!

If you're referring to what happens after a transmission is complete: yes, the RX and TX must return to a known good freq

Yep, that is what I am referring to. My confusion comes from the fact that while the TX example does indeed return to known good freq, the RX example does not - it only seems to put the chip into receive mode.

Maybe I am misunderstanding how the receive example code works?

[nseidle]

Does the example work as expected? The the RX does change freq, just at a different spot. We may be getting lucky with a wrap around condition.

[jgromes]

It does work - although it is kind of strange that channels[radio.getFHSSChannel() % numberOfChannels] is used as the "home" channel instead of channels[0].