Support for FSK modulation

Hey, I’m experimenting with TTN right now and stumbled upon the following behavior:

I wanted to find out how far TTN supports FSK modulated packets. When I send a properly pre-matted join request it is forwarded as expected by my TTIG gateway. In the history I see the following:

And in the details:

...
"raw_payload": "AAAAAAAAAAAAlt0F0H7Vs3BbS7tQD9g=",
"payload": {
    "m_hdr": {},
    "mic": "u1AP2A==",
    "join_request_payload": {
        "join_eui": "0000000000000000",
        "dev_eui": "70B3D57ED005DD96",
        "dev_nonce": "4B5B"
    }
},
"settings": {
    "data_rate": {
        "fsk": {
            "bit_rate": 50000
        }
    },
    "frequency": "868800000",
    "timestamp": 3798740240,
    "time": "2023-05-25T22:21:15.225883960Z"
},
...       

Unfortunately, this join request is apparently not forwarded to the network server and remains unheard.

As a test I sent the same join message (even with the same nonce) with LoRa modulation. This is also forwarded by the gateway:

...
"raw_payload": "AAAAAAAAAAAAlt0F0H7Vs3BbS7tQD9g=",
"payload": {
    "m_hdr": {},
    "mic": "u1AP2A==",
    "join_request_payload": {
        "join_eui": "0000000000000000",
        "dev_eui": "70B3D57ED005DD96",
        "dev_nonce": "4B5B"
    }
},
"settings": {
    "data_rate": {
        "lora": {
            "bandwidth": 125000,
            "spreading_factor": 7,
            "coding_rate": "4/5"
        }
    },
    "frequency": "868100000",
    "timestamp": 1963148731,
    "time": "2023-05-25T23:02:14.616158008Z"
},
...  

I can see in the live data of the end device how the join request is accepted and in the log of the gateway how an uplink message arrives. Everything works as expected.

My question is now. Are FSK modulated packets currently supported or is there a bug?

Please check Regional Parameters specification for your region as to whether or not the FSK data rate is supported for Joins.

Note: As I recall, in all regions, FSK is an optional data rate, and as such, not supported for Join. So your test is meaningless. To test FSK data rates, allow device to Join, then set up suitable (region-specific) channels that support this optional data rate, allow TTN to configure those channels on the end-device using the appropriate MAC commands, then specify static ADR settings and select the FSK data rate for transmission, allow TTN to configure that using LinkADRReq, and when that is done, your end-device will transmit an uplink using FSK, at which point you will have the answer to your question.

Join Requests in the EU868 region must come via the 3 default channels (868.1MHz, 868.3MHz or 868.5Mhz). The default channels support only SF7 to SF12 LoRa modulations, at 125KHz.

Since your join request arrives via an extra channel (868.8MHz), it is dropped by the Network Server, as your end device is not allowed to use that particular frequency for joins.

Thank you for the two responses. I did not realize that a join is only possible on these three channels.

But after the successful join I should be able to send FSK modulated messages?

It looks to me like this is not possible even after a successful join. No FSK modulated messages are forwarded.

Is it possible that there is a bug in The Things Network Stack?

In order for the end device to allowed to use FSK or the 250KHz LoRa modulation, after it has joined, there needs to be a channel setup sequence between the end device and the LNS. The end device cannot unilateral create and use a channel - the LNS is the authority over which channels have to be used for transmission.

If you would send uplinks over the 868.8MHz channel using the FSK modulation, the LNS would drop them as the 868.8MHz channel is not recognized as a channel through which the end device is allowed to send uplinks.

We currently do not do this setup for the FSK or the 250 KHz channel, as they require additional downlinks during session initialization and they are generally not used, as users prefer to do ADR over the 8 125KHz LoRa modulated channels.