Knowledge Base
HOME » KNOWLEDGE BASE » FORUM

FSK channel configuration in SX1301

Avatar
Hi,

We are working on a hardware design using a SX1301 concentrator board. In the SX1301 datasheet it says the following about the FSK channel:

"This demodulator offers a very high level of configurability, going well beyond the scope of this document. The demodulator characteristics are essentially the same than the GFSK demodulator implemented on the SX1232 and SX1272 Semtech chips."

We have a legacy proprietary FSK protocol based on the TI CC1101 packet structure, and we have successfully had the SX1276 chip configured to demodulate this format. Now I interpret the text above such that there is a good chance we could also have the SX1301 demodulate this protocol which is needed in our product. Am I correct, is this possible?

But from looking in the source code for lora_gateway and packet_forwarder I can't really figure out how this should be done. It's a real pain that the registers for SX1301 are not publicly available. What does it take to get hold of these? Or is the information we need available, but I just haven't found it.

We will write a customised packet forwarder to handle this channel differently from the LoRa channels.

/Martin Söderström
Avatar
Hi Martin,

Typically, on other products, packet engines are compatible, to the exception of the FEC (absent on Semtech parts), and how the CRC is calculated.

On the SX127x or SX123x families, there is a compatibility mode for CRC. I will try and see if this is available on SX1301, bear with me.

Sebastien
Avatar
Sebastien,

Thanks for looking into this. For your information: for SX1276, the magic modification we had to do to get this working was to modify the CrcWhiteningType bit in register RegPacketConfig1 from 0 to 1 to use IBM CRC implementation with alternate whitening. No major modifications apart from this and sync word stuff to get the pingpong example app to work with our legacy proprietary FSK protocol.

/Martin
Avatar
Okay,

And I see these two settings are also available on line 321 and 322 of loragw_hal.c, so this is promising, I just need to find out the value which would make sense.
Avatar
Yes, I've seen those in the HAL source code as well as the other LGW_FSK_xxx registers in the header file. Without access to register descriptions, though, it's difficult to say the least, to know how to use them. Also, I don't see any register for sync words (from guessing from the register names). Maybe there is no filtering on sync word, but all packets are passed through, or? But then what about sending, should sync words be part of payload? And what about the preamble pattern? As you hear, lots of questions 😊

Anyway, your help here is much appreciated 😊

Avatar
Hi Martin,

The attached picture shows you the options available, it should help.
Concerning the Sync Word, it is absolutely necessary (providing the Byte synchronization for the RAM buffer), and in the code is set through the global_conf.json used by the packet forwarder example application.
As far as Preamble, there is no setting as such

Sebastien
Image Attachments
Capture.JPG
Avatar
Sebastien,

Thank you for the register values. About the sync word, I'm thinking of the sync word within the FSK packet as used by TI CC101 and SX1276 (0 to 8 bytes wide). For SX1276 it is set with registers RegSyncConfig, RegSyncValue1, RegSyncValue2 .. RegSyncValue8. This is explained in section 4.2.10.1 in the SX1276 datasheet. If these do not exist in SX1301, I wonder if the packet reception I'm hoping for can really be accomplished. It's not easy to see how the packet framing would be done in the demodulator. Where would the packet start? Or is SX1301 just using brute force looking for CRC checks over all possible payload length on a bit by bit basis while receiving on the FSK channel. And thereby skipping the sync word since it is not included in what is checksummed.

Can it really be the sync word you are referring to that denotes the start in an FSK packet after a leading preamble? I though that sync word was more about public vs private LoRa network. And in our particular case we are using a four bytes for sync word, not one.

/Martin