Hello,
We are making some Lora based device for US and stuck at some point.
We are using Lora1276 module from NiceRF.
We are using STM32L073 microcontroller and Lora1276 and sends data over TTN.
We had used this microcontroller board and this Lora shield and it sends data over TTN successfully.
We made our own PCB with same uC and Lora1276 and it is able to send activation data over TTN but further, it is don’t see downlinks/uplinks.
Please guide.
So, you’re seeing the full activation? That is: Join Request and Join Accept, and after that the node is not sending a new Join Request? Did you validate that the node is even sending uplinks?
This is what I see on TTN console.
what gateway do you use ?
I am using a Multitech Gateway installed just at my desk.
the node send one join request and that is not answered, like Arjan said that’s not a full activation
Yes, its not fully activated.
So where is the issue. Is it a hardware issue or software.
Device is sending activation messages again and again but no response.
Check the gateway traffic page for response packets.
Make sure to keep at least 8 feet between a node and gateway to prevent cross talk caused by strong RF signals. (Which can cause the gateway to receive uplinks on a different channel, resulting in a reply on a channel on which the node does not listen for an answer)
I have kept the Gateway at 20 feet distance still not working.
I have been searching thouroughly for this weird LMIC phenomenon too. We are also struggling in getting our data transmitted after an activation.
A debug of our gateway is shown below.
We can clearly see the tx of an unknown device D0025685, starting with a fcnt of 46037) before getting activated.
The real activation goes on and on, without any uplink of data as seen in the screenshot from the console over here:
If some one has on idea on how to resolve this issue, I can always upload the code from the MCU to throw an eye upon.
Thanks in advance for reacting.
What brand gateway with which packet forwarder are you using?
Hi Jac,
just as you have explained some time ago and well documented in https://www.thethingsnetwork.org/docs/gateways/rak831/
So it is the poly packet forwarder from LMIC.
I am really struggling with this one, although various lorawan deployments made with other devices and gateways.
I guess it can be in the CC code of the node, which is an Arduino based MCU.
We are working on the following project:
/*
senseBox:home - Citizen Sensingplatform
Version: lorav2.0.0
Date: 2018-09-11
Homepage: https://www.sensebox.de https://www.opensensemap.org
Author: Reedu GmbH & Co. KG
Note: Sketch for senseBox:home LoRa MCU Edition
Model: homeV2lora
Email: support@sensebox.de
Code is in the public domain.
https://github.com/sensebox/node-sketch-templater
*/
This morning still the same result : many activations without any uplink. The strange thing is the node transmits its join request as follows:
Nov 19 10:07:20 KUL-TD-mobilegateway ttn-gateway[896]: INFO: Received pkt from mote: D0025685 (fcnt=46037)
Nov 19 10:07:20 KUL-TD-mobilegateway ttn-gateway[896]: JSON up: {“rxpk”:[{“tmst”:2793609124,“chan”:0,“rfch”:1,“freq”:868.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF9BW125”,“codr”:“4/5”,“lsnr”:7.8,“rssi”:-99,“size”:23,“data”:“AIVWAtB+1bNwQQnf6b/c/QB/3HFRDt0=”}]}
Thanks for having a look Jac.
Are you really sure that the first line is your node?
It seems your gateway does not know how to decode a Join Request, and then shows a false frame counter and false DevAddr, assuming it was an uplink. In reality, AIVWAtB+1bNwQQnf6b/c/QB/3HFRDt0= is indeed a Join Request, for AppEUI 70B3D57ED0025685 and DevEUI 00FDDCBFE9DF0941.
(An OTAA Join Request does not include a frame counter, nor a DevAddr. Also, a D0025685 DevAddr is not a TTN device.)
There is a 5 or 6 seconds delay between a Join Request and the transmission of a Join Accept. While the details for a Join Accept might be forwarded to the gateway a bit earlier than the scheduled transmission time, there’s usually really a few seconds delay after the request, which is not shown in the above screenshot of the 19:24:50 logs. I’m not sure if that means something. I guess the last line is indeed the Join Accept for the first line. If it does not match the output in TTN Console, then you could paste the “data” in the online decoder to check.
For LMIC, see also LMiC does not receive Join Accept - #7 by I-Connect.
(Thanks for not posting a screenshot of the log file in your last post! Text is much better for logs, if only to copy details.)
Thanks Arjan for the explanation,
unfortunately still the same : my gateway (RAK831 in house) is RX/TX-ing its join requests and accepts (verified with https://runkit.io/avbentem/lorawan-packet-decoder/branches/master), but no uplinks received in the RX1 (RX2?) window immediately after the join accept, atlhough the LMIC error tolerance has been set.
Though, about after about an hour, I got the uplink… Strange things going on, but I keep on searching. Must me something with the voids in the Arduino code.
The lora packets after this join are well decoded:
Assuming base64-encoded packet
QMEvASaABgABuGt2jbHgiK4=
Message Type = Data
PHYPayload = 40C12F012680060001B86B768DB1E088AE
( PHYPayload = MHDR[1] | MACPayload[…] | MIC[4] )
MHDR = 40
MACPayload = C12F012680060001B86B768D
MIC = B1E088AE (from packet)
= B1E088AE (expected, assuming 32 bits frame counter with MSB 0000)
( MACPayload = FHDR | FPort | FRMPayload )
FHDR = C12F0126800600
FPort = 01
FRMPayload = B86B768D (from packet, encrypted)
= 93764715 (decrypted)
( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
DevAddr = 26012FC1 (Big Endian)
FCtrl = 80
FCnt = 0006 (Big Endian)
FOpts =
Message Type = Unconfirmed Data Up
Direction = up
FCnt = 6 (from packet, 16 bits)
= 6 (32 bits, assuming MSB 0x0000)
FCtrl.ACK = false
FCtrl.ADR = true
Issue solved Arjan,
apparently the RAK gateway is not sending the uplinks fast enough when reveiving ‘the join permission’ from the TTN network server.
I tried another gateway (a lorank8) and immediately after the ‘join accept’, the uplinks came in right away after 2 ms.
Reason why the RAK is reacting so slow, has not been traced. Conclusion, it is not the timing of LMIC on the node, but a packet forwarder timing issue on the gateway.
Referring to the TTIG problems : TTIG does not support downlinks when not frequently receiving uplinks?
This is likely a case of getting lucky in randomness, or at most a complete transmit failure.
Gateway timing would be unlikely to be at fault, as the downlink RX1 for a join is quite long after the uplink - there is plenty of time.
Please be careful not to mix up the terms uplink and downlink however - what you are calling uplinks are actually downlinks. Uplinks are node to network, downlinks are network to node.
Additionally a RAK831 is just a concentrator card. If something is going wrong with a gateway built around one, the greatest likelihood is that it is a software or configuration issue, not a concentrator issue.
Conclusion, it is not the timing of LMIC on the node, but a packet forwarder timing issue on the gateway.
That is most likely mistaken.
Note that when adjusting timing on a node, there are two parts - how early it starts receiving, and how long. If you make it start earlier without also making it receive longer, it’s quite likely to miss a packet if the clock is not wrong.
Some versions of LMiC don’t do a good job of setting the “how long to listen for” value, especially as it is split across multiple registers.
If you really want to understand this, probe around on the RAK 831 and find one of the pins that matches transmission mode - forget which it is, but it’s more accessible on that than pretty much any other gateway. Modify your node code to set a GPIO high when it starts receiving, and low again when it gives up. Put one probe on that node signal and trigger on it, put the other on gateway and now you can see the actual timing matchup with no guesswork.