Hi guys,
I receive every day “validate dev-nonce error” and I tried clear data etc… but nothing, now I saw I receive the follow events:
Someone have idea where is the problem?
delete device, and create it again.
I done three time in 3 days, now I saw arrive 2 Join Request and the second Join Request invalid the activation
check endnode all keys, parameters and their sequence format (LSB/MSB) for correct input
I have other 200 same devices connected and I don’t think the problem is on key or LSB/MSB because when it sent JoinAccept i see on chirpstack the actvation tab full.
How far is this device from the gateway?
Seeing two join requests at perhaps the same time on two different frequencies suggests that your end device may be so close to the gateway (in the same room or even on the same bench) that it is overloading the receiver and appearing as a phantom signal on channels additional to the one it is actually transmitted on. If you look at the rxInfo, likely you’ll see the true signal is astoundingly strong with an RSSI of say -40 while the phantom signals are below -100.
The solution in that case is to not test nodes so close to the gateway. If you have to have a setup specifically for this purpose, you can do something like use a resistive dummy load on the test gateway instead of an antenna, though relocating it to the roof or the far end of the building would be better.
Very interesting, the device is about 30 meters away and there are other connected devices nearby.
The situation is real the problem is in production. In the same 5km area I have 200 devices of the same type connected.
That’s odd.
Can you post the rxInfo of a pair of these “duplicate” join requests? It’s important to be able to see all of frequency, and for the same gateway RSSI and microsecond timestamp.
try to replace your endnode with another one.
[
{
"txInfo": {
"frequency": 865300000,
"power": 14,
"modulation": "LORA",
"loRaModulationInfo": {
"bandwidth": 125,
"spreadingFactor": 12,
"codeRate": "4/5",
"polarizationInversion": true
},
"board": 1,
"antenna": 0,
"timing": "DELAY",
"delayTimingInfo": {
"delay": "5s"
},
"context": "MiJ3lA=="
},
"phyPayload": {
"mhdr": {
"mType": "JoinAccept",
"major": "LoRaWANR1"
},
"macPayload": {
"bytes": "6iMeoqtTET8pfhNDYLkRScBYHzvWtcJYA+n0hg=="
},
"mic": "d1fb40a6"
}
},
{
"rxInfo": [
{
"gatewayID": "cnb/AC4IBCo=",
"time": null,
"timeSinceGPSEpoch": "1332753675.179s",
"rssi": -78,
"loRaSNR": 15,
"channel": 6,
"rfChain": 0,
"board": 22,
"antenna": 0,
"location": {
"latitude": 1.635135650634766,
"longitude": 1.036319732666016,
"altitude": 387,
"source": "UNKNOWN",
"accuracy": 0
},
"fineTimestampType": "ENCRYPTED",
"encryptedFineTimestamp": {
"aesKeyIndex": 0,
"encryptedNS": "EO/BmQDnUjkcxKnwkCRlXQ==",
"fpgaID": null
},
"context": "MiJ3lA==",
"uplinkID": "EOjOX1x/RwC8OhWeLQmy+w==",
"crcStatus": "CRC_OK"
}
],
"txInfo": {
"frequency": 868300000,
"modulation": "LORA",
"loRaModulationInfo": {
"bandwidth": 125,
"spreadingFactor": 12,
"codeRate": "4/5",
"polarizationInversion": false
}
},
"phyPayload": {
"mhdr": {
"mType": "JoinRequest",
"major": "LoRaWANR1"
},
"macPayload": {
"joinEUI": "0000000000000709",
"devEUI": "00070900001efcb6",
"devNonce": 43105
},
"mic": "ac9b68db"
}
},
{
"rxInfo": [
{
"gatewayID": "cnb/AC4IBCo=",
"time": null,
"timeSinceGPSEpoch": "1332753675.179s",
"rssi": -118,
"loRaSNR": -13,
"channel": 1,
"rfChain": 0,
"board": 1,
"antenna": 0,
"location": {
"latitude": 1.635135650634766,
"longitude": 1.036319732666016,
"altitude": 387,
"source": "UNKNOWN",
"accuracy": 0
},
"fineTimestampType": "ENCRYPTED",
"encryptedFineTimestamp": {
"aesKeyIndex": 0,
"encryptedNS": "oKSqzgHXFF4ysjyq6ccC+Q==",
"fpgaID": null
},
"context": "MiJ3lA==",
"uplinkID": "Rn8A4mokS1+oVSedjOrs0w==",
"crcStatus": "CRC_OK"
}
],
"txInfo": {
"frequency": 865300000,
"modulation": "LORA",
"loRaModulationInfo": {
"bandwidth": 125,
"spreadingFactor": 12,
"codeRate": "4/5",
"polarizationInversion": false
}
},
"phyPayload": {
"mhdr": {
"mType": "JoinRequest",
"major": "LoRaWANR1"
},
"macPayload": {
"joinEUI": "0000000000000709",
"devEUI": "00070900001efcb6",
"devNonce": 43105
},
"mic": "ac9b68db"
}
}
]
No, I can’t do it. I don’t manage the devices.
ask the one who manages it. for such cases, there must be a replacement fund.
it speeds up and makes troubleshooting easier.
Looking at the rxInfo’s the difference in RSSI’s between -78 and -118 at the same timestamp make it clear the the weaker is actually a phantom signal “invented” by non-linear distortion in the gateway’s receiver chain. Like many phantom signals its pretty far down there near the limit of detection.
What is surprising here is seeing this kind of distortion when the “true” signal is an only moderately strong -78 RSSI vs something closer and stronger more likely to drive an RF stage into compression.
If there’s anything “wrong” here it’s with the RF design or components in the gateway, not the node.
More realistically, either ignore this if things are working despite the error message (Chirpstack seems to be responding to the true signal and discarding the phantom), or else keep the nodes further away from the gateways to avoid these phantom signals.
There’s no need to replace nodes, reset things or any of that - those ideas all reflect misunderstanding of the issue.
Great explanation, thank you.
But the problem is I don’t receive data but the device try every 12 hours join without transmit. In this way I have other 6 sic devices.
That seems like some other problem since Chirpstack appears to be commanding a response to the true signal rather than the phantom one.
It wouldn’t hurt to try moving the nodes further from the gateway to get rid of the phantoms.
Also make sure the gateway is actually returning an ack that is has transmitted. I’d personally try another gateway, but that’s the luxury of having a variety of hardware to play with.
Thanks, the nodes are water meter is too hard move ;). The gateway is Kerlink.
I try to check the logs
Your gateway is reporting two identical uplinks on different frequencies only 8 microseconds apart in end time, which is fundamentally impossible for a single device.
You are suffering from corruption in the RF / signal processing, something that’s typically seen when strong signals drive a stage into non-linear compression, but probably due to a different cause here.
What is odd is that the stronger signal in this instance is only -84 RSSI.
I suspect something is wrong with your gateway, possibly a missing I or Q yielding to imaging around the IF’s center or a bit that’s somehow stuck leading to non-linear behavior even at reasonable signal levels.
It is theoretically possible that the issue could be on the transmit side, either in the baseband and upconversion or possibly an insufficient power supply to the node’s radio, such that it’s actually emitting signal-like energy on two frequencies.
Either way this is a hardware or at most operating environment problem, not apparently a software or protocol one.
Hi,
same issue here - and repositioning of GW oder Node is not possible, any other solutions for that?
Hi all,
have you tried disabling frame count validation? it is in service/device profile…
