Everytime I send uplink with DR6 in EU aka: SF7BW250 TTN asks for DR5 aka SF7BW125

Hello there.

Every time I send an uplink in my TTN gateway with DR6 - SF7BW250 - I receive a MAC command with payload 0350FF0001

03 is ADR command. Next byte 50 binary: 01010000 means that the MSB nibble is 0101 decimal value 5, so DR5 aka SF7BW125.

Using SF7BW250 I realized that it’s used only on one frequency: 868.3. Not so useful. Twice the speed but 8 times less channels - 4 time more collisions than SF7BW125 in 8 channels.

So DR6 is not welcome in LoRaWAN? Better to use it in special cases? Same goes with FSK?

Yes - at least for TTN, yes and yes.

AFAIK, the original chipsets couldn’t do DR6 so …

1 Like

Thanks.

The chipsets of concentrators?

FSK is five times faster than DR5, so it seems it has some benefits.

I think it was the radios but Jeff will go in to detail

Simple overview of what SF’s (and thereby DR’s) are supported by the silicon: Original Conc baseband chipsets - SX1301 & 1308 derivative SF7-12, with 1st Gen node devices (introduced 1-2 years before the concentrators were available) SX127x mirroring this (72,76*,77,78). Later variants for both platforms introducing SF5/6 support (e.g. SX1303, SX1262 etc.) (For completeness 128x node devices for 2.4GHz).

Specialist derivatives/later products e.g. the LR… family for e.g. location based service implementations also potentially support lower SF’s. (With some LLCC68 dropping higher SF support depending on BW!)

TTN long pre-dates the latter offerings and so SF7-12 support de facto for the Community use, though for private deployments of TTS you might look at SF5/6 support (& FSK). To maintain compatability and to avoid community fragmentation stick with the existing standard.

One explaination I heard some years ago wrt choice of SF support was that the LoRa coding implementation (a digital system) added a benefitial coding gain (approx 7-20db equivalent) to classic legacy modulations pushing closer to the Shannon limit but with an obvious silicon overhead, adding to device cost. As the cost was inherent in the schema due to need for similar on chip infrastructure was a fixed amount irrespective of chosen SF; with an additional overhead down to memory, which scaled with SF. It was decided that the min SF commercially viable was SF7, with >SF12 leading to too large a device for little extra perceived benefit and with lower throughput. The codec maths scales ok and so SF6 SF5 and indeed SF13 ‘could’ be implemented but judged not viable.

With later generation devices the process tech allows for lower proportionate LoRa ‘digits’ area and lower cost per die of the LoRa infrastructure overhead, making SF5 & 6 a worthwhile addition for those closer range (possibly in building) networks that can derive useful application benefit, especially in the face of potentially increased throughput they support.

(*) IIRC SX1276 supported a form of SF6 implementation but this is not compatible with later generations(#), and is NOT backward/forward compatible, and I personally have never seen it used in anger in a deployed system.

(#) See 6.1.1.1 SF considerations from the SX1261/62 DS rev 1.2 2019 (GIYF). Note well it also cautions that for reliable detections at these SF’s and associated DR’s you should use a longer pramble and more symbols which of course moves us even further from a common platform implementation and standard for use on the community!

Note before anyone calls out why are you talking SF when discussion largely around DR - I would note that DR’s are somewhat regional dependent and any lack of support is basically largely a function of what SF’s the underlying silicon is designed to support.

Did this quickly largely from memory, and a bit rusty on details, so there may be gaps/errors! If in doubt check Datasheets! :wink:

Update: just seen Nicks comment/question re radios - took me a while to type up initial response as muxing with family supper prep! :wink: - more a baseband issue than ‘radio’ per se as the radio bit is largely down to seperate FE’s for for Conc implementation and its the codec/modem bit of the integrated node devices which handles the SF and hence DR implementations. The radio portions impact more on the RF behaviour (image/co-channel/adjacent channel rejection, noise performance, raw RF sensitivity etc.), and by the time we are into evaluation bulk SF/DR performance, capabilities and characteristics the RF sections have largely done their stuff (AGC/frequency offsets and feedback, control loops and XO/TCXO perfomance and adjustments not withstanding).

1 Like

I disagree on this part. While it is true that DR6 (note that this all assumes EU868-style datarates, not SF as pointed out by Jeff) is only ‘defined’ for one channel and therefore may be less favourable, there are very few users of this datarate and given the very short time-on-air, may be a very good option for practical use. However, collisions are still four times more likely for a denser network (1/2 of the airtime but 1/8th of the channels), so keep that in mind.
The main reason why I disagree however, is that ADR simply is only defined for DR0-DR5 (insert missing link to spec/docs), hence when you have ADR enabled, TTN will steer to DR5. So that has nothing to do with DR6 not being welcome, it’s simply a matter of the ADR algorithm. The same applies to using FSK, which I’m actively trying to get going in RadioLib (yes, this is the third website where we cross paths, it’s me, hi) - so far, it’s not clear to me whether TTN allows FSK.
In the end: use DR6 as you wish, but it only “works” with ADR disabled.

@Jeff-UK that was a gem. Thank you. As the title says DR6 for EU aka SF7BW250. I understood the difference between DR and SF when I read the regional parameters and FSK. Before that I thought it was a different naming scheme.

I disagree. ADR algorithm on TTN knows that I transmit two times faster but it wants two times slower. Probably because of compatibility and less collisions as explained and I think we all agree.

Also to my undestanding, since the BW is twice, I suppose there is more crosstalk bettween channels? One day mistakenly used US frequencies for my node. When the node was centimeters close to the EU GW the message was received although node was transmitting on US frequency.

Yes maybe I will keep SF7BW250. It’s about by blind ADR version. My mobile node transmits at faster rate when it’s close to a GW without ADR. The problem is that I have to hope that the GW supports SF7BW250. But FSK seems way more better. My main problem is that SlimLoRa fails to catch the downlink. So maybe I will scrap this.

Nice thing to cross paths :stuck_out_tongue:, nice to meet you again. Maybe I will also try to use FSK, since it’s five times faster and the collisions are around the same with DR4.

All I knows is that a major vendor said their device supported DR6 which the worlds largest Defence Contractor purchased from me for a pilot project but it turns out the vendor had got it wrong and it didn’t support DR6. If it had, I’d not be typing this because I’d be on a warm beach contemplating another dive &/or a steak & cocktail and I’d not even be aware of this thread because minions so far down the food chain would be handling it.

As to if TTN can support DR6, :man_shrugging:

So, to paraphrase, DR6 is all good but the LNS will never enable it.

Is that not the same as saying, we do like you Mr DR6, you are very welcome. But we will NEVER ask you to participate. We won’t / can’t say why, but you will never be used …

Seems pretty unwelcome to me!

Not so fast, because I just said I disagree. Here is the Semtech recommended implementation (which, AFAIK, is what TTN and Chirpstack use): it explicitly states that it does not incorporate SF7BW250 and FSK. Which means that it it is simply ‘hardcoded’ to steer to DR5 and is unable to keep your device on DR6.

As to why the ADR algorithm isn’t updated to include these additional datarates: I’m not sure whether that has to do with compatibility, making sure that no device crashes because of physical inability to use DR6/7, or whether that is because it really isn’t welcome. My guess would be the former, and I think DR6 is welcome.

I think it can’t be welcome without having an option to tell the LNS a device is DR6 compatible. AFAIK there is no such option in the current code base and as a result DR6 can’t be used without causing issues for the majority of devices using old chipsets.

All gateways I know of, starting with the really old ones from 2015, should be listening on 868.3 with SF7 and BW250. This has been in the TTN supplied gateway configuration since day 1.

As mentioned, the increased bandwidth will cause interference on both 868.1 and 868.5 MHz.

IMHO best to stay away from these settings for the community network.

I think Bill Murray & Scarlett Johansson may have intervened here.

Overall, to me, it seems we understand that however attractive, DR6 isn’t on the cards for LoRaWAN on TTN/TTI.

I was slightly advocating for the devil: all Dutch schools are enforced by law to monitor CO2 levels, and as ours are monitored through LW, as a result my boxes suffer a considerable packet loss around school. The CO2 sensors are connected to some BS corporate LNS (they literally unplugged my TTN gateway’s ethernet cable to connect their gateway) and they’re cranking away at a not very considerable interval. Hence I was trying to see what the thoughts are on DR6, as I thought it may help mitigate the problem a bit.

This however is a very good argument - you won me over.

As FSK is a different modulation and doesn’t overlap with an existing frequency, that looks to be the better choice. But I’ll have to see if it works at all first…

At Ichthus College - that’s brave indeed.

TBH, I think if it’s become a legal requirement, unless that is a demonstrable harm to student, I’d just leave them to it - fighting The Man is a losing game.

But mysteriously deploying your own monitors, given any local expertise in the town regarding environmental monitoring, that compares and contrasts any “official” data, well …

But mostly, don’t. Do something that doesn’t have career ending teeth at the end of the path.

1 Like

I’m not fighting my bosses on their CO2 sensors, I was thinking about having my own boxes use DR6 to avoid losing packets to the CO2 sensors. But I rest my case :wink:

Ah, simples, send current value with two or more delta values (a byte), like forward error correction (whatever that is), but in reverse.

So 21.3, -0.21 (aka 21.07), +0.1 (aka 21.17).

With the McCloud™️ MegaCalc temperature format, not available in the OptimisedToDeathFormat.com, two decimal places, add 200degC - provides 2dp with range from +455 to -200℃ in just one integer, 16 unsigned bits should be enough for anyone, certainly 640KB is more than enough for anyone.

So 21.3 = 22130, then -21, then 10 - four bytes, current plus last two readings.

Two prior readings usually covers it - you’d be unlucky to lose three packets in a row.

And with TotalRecall™️, if you’ve lost any uplinks, you can always ask (nicely) for a range of fCnt’s to be resent, using the aforementioned MegaCalc calculations. The CleverFirmware™️ will send in appropriate sized chunks. Just make sure you follow FUP on downlinks …

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.