Support for FSK modulation

TTN Network and Services The Things Stack v3
1

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:

_FSK
_FSK1749×65 5.46 KB

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:

2023-05-26 (4)
2023-05-26 (4)1908×126 9.69 KB 

...
"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?

2

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.

3

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.

4

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?

5

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.

7

As I finally got FSK going, I will provide an update here:

  • TTN/S does not setup any channels for DR6 / DR7.
  • Forcing a device to send an uplink on the DR6 channel completely works (even though Adrian mentioned this should be dropped), but for more info see this discussion.
  • Forcing a device to send an uplink on the DR7 = FSK channel does not really work; it is received by the gateway but silently dropped before it makes its way to the LNS / device console.

Now I am interested: do others think that there should be an option to enable FSK? For example, as in the linked discussion, I have this scenario:

  • School has over 100 devices sending at very fast interval (private LNS, no FUP) - these are sensors required by law to be monitored, so these will not be modified.
  • I have some extra sensor boxes or student projects in school, suffering a respectable packet loss due to the crowded airspace from school’s sensors. Not a problem w.r.t. the lost data, but annoying for students when they’re actively using them & learning.

Would it be a good idea to move my boxes / student projects to the FSK channel, if it were a possibility?

1 Like
8

Given that it’s transparent to them, why not.

Although in the larger scheme of things, if the air sensors are that disruptive they are likely doing it at every school that uses that system, creating a series of ISM interference zones across NL.

Given that you are a subject matter expert of the highest order, as well as using FSK if it does the job for student work, I’d write a few bullet points on the matter to the crazies running the settings.

9

CO2 rates are not going to change dramatically in a couple of minutes so there is no need for very fast intervals. Once every 10 minutes should be plenty with may-be an additional uplink if there is a sudden large change for some reason.

Even private LNSses should restrict airtime to what is required as they are not the only users of the spectrum. Specifically when using Long Range technology the users need to behave responsibly.

Are the transmissions visible in the gateway console on TTN? If not, what is in the gateway log on the gateway itself?

1 Like
10

I know, I know all of this, of course. The 70 of them uplink only once every 10 minutes, it’s not that bad, I really don’t lose that many packets, I am also happy to fight some of my bosses if need be just as I did to get my gateway back online. Instead, I’m trying to spark a conversation about the use of DR7 similar to the one about DR6.

Yep, they are in the TTN gateway console!

By the way - I can tell you that in a classroom, this can definitely be the case! Thirty sweaty students are definitely able to double the CO2 concentration in under 15 minutes.

11

So they’re just not making it to the application? Can you check the frequency used for FSK is included in the list of frequencies for the device? Or explicitly add it just to test?

12

Yes. Since FSK is on 868.8MHz and close only to RX2 window frequency and it’s 10 times faster than SF7BW125 and in different modulation it’s like having extra 10 channels. In contrast SF7BW250 is not attractive to the network since it’s on the middle of mandatory - join - frequencies. So twice the speed but annoying to the three mandatory channels.

FSK seems fine.

You can receive downlinks with FSK? I fail with SF7BW250.

13

As the FSK channel uses 868.8 MHz, I manually tried adding it to the Network settings > Factory preset frequencies. This however appears to result in bugged behaviour, as I now miss >90% of uplinks on the device console (they always appear in gateway console). However, when it does work, the LNS sends a LinkAdrReq to disable channel 4 (867.1 MHz) and enabling my 9th ‘custom’ channel. I haven’t managed to successfully return a LinkAdrAns yet however… and still, FSK uplinks are dropped, although to be slightly fair, if they coded it very well, they ‘know’ this channel is not yet enabled due to the missing LinkAdrAns.

15:18:28.695 > RLB_PRO: PHY:  Frequency = 868.300 MHz, TX = 16 dBm
15:18:28.700 > RLB_PRO: LoRa: SF = 7, BW = 250.0 kHz, CR = 4/5, IQ: D
15:18:33.687 > RLB_PRO: Opening Rx1 window (37 ms timeout)... <-- Rx Delay end 
15:18:33.724 > RLB_PRO: Closing Rx1 window
15:18:33.727 > RLB_PRO: Downlink (AFCntDown = 1) encoded:
15:18:33.731 > RLB_PRO: 00000000: 49 00 00 00 00 01 19 1b 0b 26 01 00 00 00 00 0c  I........&......
15:18:33.737 > RLB_PRO: 00000010: 60 19 1b 0b 26 90 01 00 df dd 13 d1 c2 7d c0 dd  `...&........}..
14

No need to fight them, we’ll write to them explaining the stupidity.

Sure that’s not the person at the front talking lots?

As Jac suggests and many other vendors do, send at a reasonable interval and have a delta change value for when the needle moves faster than normal.

Or for me, string a set of readings together so you still get 10 minute reading intervals but don’t send them - what a waste of battery to be told that the situation is as expected.

15

None of your answers tell anything about your opinion on FSK though, which is what I asked for :wink:

16

This ???

17

Right, wasn’t very clear to me

1 Like