I would like to be able to manually exchange MAC request and response from my MKRWAN 1310 and TTN - by using a TTIG. I am testing this by sending a MAC command “LinkCheckReq” on port 0, CID 0x02 - by issuing:
AT+SENDB=0:02
The problem is that my MKRWAN seems not to receive any answer back from TTN.
While looking at the TTN console endpoint live-data - I can see that the LinkCheckReq is received and a LinkCheckAns is enqued. I can even see that a downlink is scheduled successfully, immediately after receival of the MAC command (as this is expected in this scenario):
However while looking at the gateway live-data - I cannot see any forward downlink to the endpoint.
I have verified that my mkrwan can receive application downlinks - as when i manually schedule a downlink with a payload from the console then I am able to receive it successfully.
Can anybody kindly put me in the right direction here, understanding what I am doing wrong?
Just to confirm: with an application downlink, you do see an additional gateway live data message that it’s being transmitted, which you don’t see here?
And you did see the MAC request coming from the node picked up by this gateway, right? And this is the only gateway listed in the uplink report for the node?
Thank you for your reply - as it made me realize that I didn´t have a clear distinction between the application and live-data output in the console.
While performing an application downlink, I can see an entry in the application live data:
And also an entry in the gateway live data:
However when MAC-related downlink is triggered, this is not shown in the application live-data but it is shown in the gateway live-data - and I assume this is obviously by-design.
But my problem still stand - the MKRWAN seems to receive and ACK back the MAC-downlink - but I cannot see any data received in the buffer… any thoughts on what I could verify next?
That’s key information - before it sounded like you were suspecting the downlink wasn’t transmitted, but this seems to indicate that it is.
A bare MAC command downlink wouldn’t have any data in an application level buffer. This is network-level housekeeping traffic for the device’s LoRaWAN stack alone - there’s no “message” there for custom code. Think of it like how your phone is often interacting with the mobile providers towers, but it only chimes when someone sends you an SMS or email that has end-user content.
To see it, you’d need to find some sort of event monitoring interface or make a custom version of the code where you’ve drilled some new holes in the abstraction model between the LoRaWAN stack and the rest of your firmware. If I recall on that board these actually run on distinct chips - your main sketch on the primary processor, and the stack on the Murata module.
What’s the actual goal that makes this MAC command exchange seem useful? Does the devices LoRaWAN stack offer any sort of query of link state, that might be inclusive of both this and what it’s learning through ADR?
Thank you again for a well formulated reply - it helped confirming my suspicions and better qualify the challenge I stand with
My end goal is to get current datetime from TTN and update the onboard RTC accordingly.
For the purpose I´d like to issue a DeviceTimeReq MAC command (i.e. 0x0D as according to 1.0.3 specification) and process the DeviceTimeAns back.
I started testing with LinkCheckReq since it has been there since the first lorawan specification to remove any unnecessary complexity while I am investigating on how to exchange MAC request / responses with TTN
Modifying the MKRWAN firmware is a bit over my head without the help of someone more experienced than me on the topic - do you see any other viable alternative on how I could reach my goal?
As explained, yes, it is by design - the console just shows us the uplinks, not the housekeeping going on under the hood.
I’m sure the acknowledge packets were used to verify the flow of information - but just incase you weren’t aware, confirmed messages in either direction are restricted to 10 a day under the fair use policy and the community strives to make them very infrequent - one a week if not one a fortnight.
Sadly I rather familiar with the MKR WAN library and I can confirm that you will need to work on that to get it to poll the Murata module for more info. I can have a quick look later on if you can even ask the Murata module for the MAC commands using the current version of the firmware - plural given there is the v2 that is in permanent beta.
It may just be simpler to arrange an integration that when the device sends an uplink, every so often it sends back the time in a downlink - after a bit of testing I find I can usually get it to within a couple of seconds on actual time.
But then that begs the question, why do you need the time? It’s not good to try to send to a clock schedule - TR007 Good Practise guidelines recommend some random ‘jitter’ plus or minus a few tens of seconds on the uplink period. And if you need the time of a sensor reading you should be able with testing to figure out how long it takes to get the reading and send it in an uplink which ends up with multiple timestamps, all usually within about 100ms of each other!
