You shouldn’t be using confirmed messages on TTN, and really not on LoRaWAN in general.
You also shouldn’t base a thesis on uncontrolled air conditions at a given instant in time.
That or controlled lab circumstances are actually the only sort of thing that would have any true validity. Maybe you’d prefer to transmit into a resistive dummy load.
Show the actual contents of the downlink packet from the gateway raw traffic page, and show it as text, not a picture.
What’s in the overview image you posted isn’t any valid sequence of MAC commands in an obvious encoding, so we need to see the actual raw packet in base64 or hex or already broken down form, that’s being pushed back towards the node.
Yes, I was wondering about that too. I hope the protocols help. I don’t know what to do anymore. Same node (hardware) but with OTAA activation works without problems.
I can’t dig into this fully at the moment, but what I think I’m seeing is some astoundingly huge amount of downlink configuration items, possibly even self-repeating ones, all crammed into a packet of absurd size. Given that they don’t fit in the fopts, they’re sent instead as a payload on port 0, which also means that they get encrypted with the network key and aren’t recognizeable in cleartext as they’d be if a smaller number of items were sent in the fopts.
It’s entirely possible that’s breaking LMICs parsing.
I notice far too many of your uplinks have the frame count zero: is it possible your sketch is crashing and rebooting?
You should probably try an absolute vanilla example sketch for TTN ABP in your region.
But again, the tests you’re actually trying to run on don’t belong on TTN at all, and for your finding to be repeatable they’d have to use simulated circumstances - transmitting into a dummy load, etc. Any attempts to consider actual network performance would have to be based on a theoretical model, since you can’t permissibly collect enough real world data to factor out uncontrolled variations.
Forget the background. The introduction by me was well intended, but now we have more discussion to that as i inspected. I will stop my tests and switch to calculations.
But, the problem remains that with ABP not working with the " absolute vanilla example sketch for TTN ABP" from MCCI LMIC(.
I have just done a test against a ChirpStack instance. When ADR is enabled in the code, it also switches to SF12 after first uplink, but when i disabled ADR (Example code with the only change that i add LMIC_setAdrMode(0);), the problem does not occur! Same code with TTN, problem exists.
You’re still showing an illegal repeat of frame count 0.
You need to figure out why that’s happening and fix it.
I would watch the serial monitor and see if your node is crashing and restarting.
Also you may want to disable “reset frame counters”; I could imagine ways in which trying to non-compliantly waive that part of the LoRaWAN spec could actually be contributing to that absurd stackup of multiple MAC commands.
But… if you have chirpstack, and you’re only sending dummy data anyway, why does interaction with TTN matter to you? It’s possible you’re hitting an unexpected case bug in the TTN stack - but the fact remains that what you’re doing is not normal usage - or all sorts of people would be hitting it.
Not what I asked - have you added the extra frequencies - if you look at your screen shot you’ll see there is a button for it. The Network Server won’t know the device knows the full 8 channels which is why it is trying to send those settings.
The Network Server won’t know that the device is set to 1s which is why it is trying to send that setting.
Are u sure? Help text says, its only needed if the device use non default frequencies, but i have insert the frequencies = no change.
OTAA works fine. >120.000 Messages i the last 6 Months from 6 nodes. Same hardware, same software, but ABP makes problems
With ABP still the same problem with TTN v3. After first uplink with SF7, the device switches to SF12. Same code had worked with v2 and with chirpstack it still works. I can’t make sense of it.
The platformio.ini references v3.3.0, which is/was pretty compliant but not much different in compile size than v4.1.1 but there are changes to the channel handling.
That said, my original hand built devices of ProMini + RFM95 were built with a much older Classic LMIC (matthijskooijman’s) and setup with ABP. Two are in the garden (somewhere) but migrated over from v2 to v3 without issue.
I’m not sure about some of the add-on’s in your main.c, particularly the saving keys to NVM - not really required for something that’s meant to be on all the time &/or is technically session-less. I’d strongly advise using the vanilla ABP example that comes with v4, but please change the uplink interval to >300s so if it’s left running, it’s FUP friendly.
It is kind of hard to keep straight what’s going on from the description and the discussion. However, nothing in the V4 LMIC will prevent it from listening to downlink mac commands in response to class A uplinks.
The description suggests that you are getting a downlink, but that’s kind of irrelevant, because you can override all that after it’s all done.
Why do you not call LMIC_setDrTxPow() right before each uplink, to force the data rate you want? The LMIC always will honor the most recent setting. As long as you wait until the previous uplink is complete – which may take a while, if there are mac downlinks after the initial uplink – that call will override anything the network tells you. Use LMIC_queryTxReady() to determine whether the LMIC is ready to accept another uplink. Pattern is something like this. Sorry that I have no time to test.
if (LMIC_queryTxReady()) {
// force the datarate we want; check for success
bit_t fSuccess;
fSuccess = LMIC_setDrTxpow(desiredDr, KEEP_TXPOW);
if (! fSuccess) {
Serial.println("setDrTxpow failed!");
while (1)
/* loop forever */;
}
lmic_tx_error_t txError;
txError = LMIC_setTxData2_strict(port, data, nData, /* confirmed */ 0);
if (txError != LMIC_ERROR_SUCCESS) {
Serial.print("LMIC transmit rejected, error code "); Serial.println(txError);
while (1)
/* loop forever */;
}
}
As always, when debugging, it’s important to check all APIs to see if an error is returned. Also, bear in mind that these APIs have changed between classic LMIC, V3.3, and V4. The above example is for V4; but the error codes and so forth may not be defined in earlier versions, and the APIs won’t always return useful error codes if they fail.
But earlier in the thread they got an absurd run-on sentence of multiple stacked MAC commands that had somehow been queued up (perhaps because they were previously ignored, and maybe some interaction with ignoring frame count resets allowed that).
Which unfortunately is long enough that it’s sent as port 0 traffic encrypted with the network key rather than in fopts, so we can’t know exactly what it contains, though there was an earlier log file that gave some of the details.
It wouldn’t be hard in concept to imagine LMIC - especially on a '328 - choking on that as it’s likely outside of test cases. What would happen with an equivalent length of legitimate, repeating MAC commands is perhaps something that could be tested.
But where that downlink comes from is likely itself some sort of unusual case in the server triggered by “shouldn’t happen” behavior not of the node stack per se, but of how it’s being (ab)used in the poster’s desire to do atypical and unnecessary on-air transmissions to “research” something that they should simply be modeling or testing into a dummy load in the lab.
Well, I was perhaps being over-precise. It is always listening during the receive windows. The radio may not catch the packet; if caught, the LMIC will look at the packet. It may not act, but that’s a different question. This is true in both OTAA and ABP scenarios.
Which unfortunately is long enough that it’s sent as port 0 traffic encrypted with the network key rather than in fopts, so we can’t know exactly what it contains, though there was an earlier log file that gave some of the details.
It’s pretty easy to decode this if you have the network key. There are several online or offline decoders that will help with this. For ABP, you have the network key, so… why not decode?
Okay turns out it was easier to grep these out of the earlier posted logfile than I thought.
And in looking through them, the “repetition” I was seeing in an earlier hasty attempt was because it’s adding all the additional channels it doesn’t know if the node already knows about.
And most of these do look like they’re getting responded to by the node.
In my mind question then becomes if as a side effect of implementing the intent of one of them LMIC coincidentally or even in a spec-mandated fashion goes to DR0.
And the answer is, of course, that’s exactly what a MACCommand.LinkADRReq does! Only it’s not obvious because the logfile is only breaking out the enabled channels portion of it, and not the data rate and power command portion…
The heart of the matter is that LoRaWAN doesn’t make it possible to set the channel map, without also commanding the node’s datarate and transmit power. In a way, the spec makes a bit of ADR mandatory regardless if one wants it or not.
But TTN may not yet have a good “ADR link model” for a node it’s still trying to basically configure (and one that’s not requesting ADR anyway) and so just be playing it safe with DR0.
