Still don’t know , why APP server downlinks are a problem , my application server from the moment receives data from two network servers, it can choose which one to send downlinks. i won’t send application downlinks in both of them
No, it cannot.
Network servers send downlinks based on their own decisision, in addition to yours.
What you want to do is simply not allowed in LoRaWan, end of story
This are MAC downlinks, not APP downlinks, if one of the network servers don’t sent MAC downlinks, no problem, end of story
Still wrong.
At a protocol level, application and MAC downlinks have to share the same frame count series.
And as explained before, you cannot stop TTN V3 from sending its own housekeeping downlinks.
Registering a node on multiple LoRaWan networks is simply not allowed; you really need to read the protocol documentation before you try to tell those of us who actually have read it, how you think it works.
Maybe, in order to enable the network server diversity i’m looking for. there should be the chance to avoid these downlink MAC commands, this is my point of view, maybe i’m not a purist, because i’m trying to figure out how to improve the LORA coverage
There are plenty of alternate ideas (in fact I’ve implemented my own) but those are LoRaWan.
TTN is a LoRaWan network, and this is the TTN forum.
If you want to use TTN, you have to implement actual LoRaWan, not YouRaWan or even MyRaWan, no matter how much better those may be.
Yes, the only alternate nowadays for IOT commercial , and countrywide it is NB-IOT/LTE-CAT-M1
Not true; LoRaWan is only one of the ways of taking advantage of LoRa modulation; granted, it’s the only one which is on topic here.
Country wide, and deep indoor?, really ?
Anyway thank you for the rich discussion, i’ve learnt a lot!, have good night
@roman
Using console I have set RX1 delay to 1 because the device uses 1 second too. Because I set it 1 I expect that MAC state will not try to set the device to 1. Such behavior suggests that MAC is not “accepting the setting as a fact” but that it feels that it should force the device to 1.
The current behavior is confirmed in the name of the setting “–mac-settings.desired-rx1-delay” where “desired” is the word. I would expect set not request and though control over the mac settings.
remko@DESKTOP-RLF1S9G:~/ttn-lw-stack$ ./ttn-lw-cli device get geocaching gc-10 --mac-settings.rx1-delay --mac-settings.desired-rx1-delay
{
"ids": {
"device_id": "gc-10",
"application_ids": {
"application_id": "geocaching"
},
"dev_eui": "AF5EE00000009C03",
"dev_addr": "260B204B"
},
"created_at": "2021-02-18T13:27:47.737Z",
"updated_at": "2021-02-25T20:03:48.897103376Z",
"network_server_address": "eu1.cloud.thethings.network",
"mac_settings": {
"rx1_delay": {
"value": 1
}
}
}
If not configured for device:
mac-settings.rx1-delayis assumed to be1as per the specmac-settings.desired-rx1-delayis assumed to be5on our networks
So given your device NS reads the MAC settings as:
Device is using RX delay of 1 by default, but RX delay of 5 is desired - send RxTimingSetupReq to make device use RX delay of 5.
If you want your device to use RX delay value of 1, please set mac-settings.desired-rx1-delay to 1
@roman I followed your advice but I see always a downlink message scheduled.
Unsure what is happening and what to do to stop it.
Can you explain?
"data": {
"@type": "type.googleapis.com/ttn.lorawan.v3.DownlinkMessage",
"raw_payload": "YEsgCyaBAwAGgK5iqQ==",
"payload": {
"m_hdr": {
"m_type": "UNCONFIRMED_DOWN"
},
"mic": "gK5iqQ==",
"mac_payload": {
"f_hdr": {
"dev_addr": "260B204B",
"f_ctrl": {
"adr": true
},
"f_cnt": 3,
"f_opts": "Bg=="
},
"full_f_cnt": 3
}
},Your log shows a “Device Status Request” enqueued, and if you decode the base64 f_opts that’s exactly what was sent, the singular byte 0x06. There are no ADR data rate or power adjustment commands, or RX window timing change commands in that downlink, and it seems to be have been scheduled in your desired 1-second RX1.
At present devices registered on V3 are absolutely required to understand and answer the device status request as described in the LoRaWan specification.
Devices that can’t do that must not be used on V3.
(Do also note that while it’s been explained how you can request to keep an RX1 with V3, you need to also keep in mind that the reason V3 goes to a longer downlink delay is to give more allowance for infrastructure delays both in gateway backhaul and in more complex routing between infrastructure pieces - if downlinks don’t get back to the gateway in time to be transmitted, then the 1-second setting is not going to be usable)
Curious to see if MCCI_LoRaWAN_LMIC_library does support device status. For now, I let this rest and focus on more important topics that came with the pile of work that was introduced with the introduction of V3.
Since they’ve expended quite a bit of effort working through LoRaWan compliance tests it should; if it doesn’t it’s well within their goals and worth raising with them - though do check for any existing issues or threads in their support before creating a new one.
Of course device status request can only work when the code is running on top of a hardware port correct enough for downlink timing to work; eg, it’s a library issue if it doesn’t work on their reference feather or Catena platform, while it’s a port issue if it merely fails on an unofficial target where downlink itself is not yet working reliably.
I have searched everywhere to see how to set up for AU915 devices using ABP.
The instructions above (and on the guide) says:
The Advanced settings must be set on registration.
Changing these settings later may not work.
The Frame counter width is probably 32 bit
The RX1 Delay is 1 second
The RX1 Data Rate Offset is 0
The device probably resets frame counters
The RX2 Data Rate Index for EU868 devices coming from v2 is 3
The RX2 Frequency for EU868 devices coming from v2 is 869525000
The Factory Preset Frequencies for EU868 devices coming from v2 are:
for all devices:
868100000, 868300000, 868500000
for devices that use 8 channels
867100000, 867300000, 867500000, 867700000, 867900000
(in addition to the 3 channels above )
but I have AU915 so have no idea what to put into RX2 data rate and RX2 frequency. Would be useful to us newbies to explaln where to find these options. Is RX2 data rate the same as Spreading Factor?
The answer is already in your question. They can be found in the console when adding a new ABP device: in section Network layer expand Advanced settings to reveal the advanced settings parameters.
I have 1 device that I set up on V3 using ABP on AU915 a couple of months ago to try V3 . I defined the 8 AU915 frequencies when I created the device in the V3 console and had no downlinks. Recently I’ve noticed that I’m seeing a downlink for every uplink. The V3 console expands it out to 35 “new channel request enqueued” messages for:
“frequency”: “915200000”
“channel_index”: 1, “frequency”: “915400000”
all the way up to
“channel_index”: 35, “frequency”: “922200000”
It’s one way to push everyone to OTAA. I’m not going to type in 36 frequencies in the advanced settings so that I can use ABP.
But if you ask nicely, a tool may come along that does that for you, or you could add a feature request to the GitHub repro …