[Luca Bertoldo]

I’m asking about LW 1.1 because reading in “LoRaWAN™ 1.1 Specification” at page 44 they say:
“This MAC command is only available if the device is activated on a LoRaWAN1.1 compatible Network Server. LoRaWAN1.0 servers do not implement this MAC command.”

Going through you answer, you say also: “The AT firmware will update the RTC when a device time MAC command is received.” I’m not sure about how does it works…

At page 44 of “LoRaWAN™ 1.1 Specification” they describe:
“With the DeviceTimeReq command, an end-device may request from the network the current network date and time. The request has no payload.

With the DeviceTimeAns command, the Network Server provides the network date and time to the end device.”

So it seems to be a Device To Network direction task. Isn’t it? Should be available some other new AT commands to enable/disabile and parametrize this time synchronization service on device side?

Thanks,
Luca

[Luca Bertoldo]

I’ll get the current date and time in term of UTC seconds using AT command.
How to get 0.1 seconds resolution? I would like to be synchronized till the guaranteed accuracy.

I’m working with Class-C devices.
You wrote that DeviceTimeReq/Ans MAC commands will be released within LW 1.0.3. So, we have not to wait for LW 1.1 release. Isn’t it?

Thanks,
Luca

[Luca Bertoldo]

Is there anybody can answer to my question above?
Can you give me also a more accurate expected date for the LW 1.1 availability next year?

Thanks a lot,
Luca

[Luca Bertoldo]

When the LW 1.1 will be available on xDot/mDot side, how can I figure out to get the time/date at application level?

I immagine to operate with a Network server compliant with LW 1.1.
In this case, can I suppose to have new AT commands to get date&time from the module?

What about the accuracy that can I expect?

Thanks,
Luca

[Luca Bertoldo]

Is it LW 1.03 or LW 1.1 support in roadmap?
More or less… do you know when they should be available?

Thanks,
Luca

[Luca Bertoldo]

Thanks Jason.
I try to repeat what I understood, just to check my comprehension:
– Multitech doesn’t implement The App Layer clock sync at Network Server side (inside the GW I suppose)
– The FW of mDOT/xDOT is not compliant with LoRaWAN 1.1 so it doesn’t implement DeviceTimeReq MAC command
– You suggest to implement this service at application level, above xDOT/mDOT AT firmware and above LoRaWAN Network Server

Can you confirm my understanding?

Thanks,
Luca

[Luca Bertoldo]

Thanks for clarification.

Luca

[Luca Bertoldo]

So you are saying that there is no way to detect when the first application packet come, if it reports FCNT=0, because it is also the default value reported by AT+DLC command after a module reset.
Isn’t it?

[Luca Bertoldo]

No Jason. I’m talking about the first application packet.
I’m sending it, so I’m sure.
Also, as I wrote, if I use AT+RECV I can get it even if the receive counter (AT+DLC) reports 0.

[Luca Bertoldo]

I used a terminal like realterm so I can receive binary data… and I receive the packet only before the first 0 value.

As I wrote above, I can’t use the SD mode to get the rx packets.

Thanks,
Luca

[Luca Bertoldo]

I installed the last release fw:
MultiTech xDot
Firmware : 3.1.0-mbed161
Library : 3.1.0-mbed161
MTS-Lora : 3.1.0

The problem still be present. Did you take a look to this topic?

[Luca Bertoldo]

Ok, thanks.
In any case, at this time I can’t use the serial passthrough because I can’t identify where a frame starts and where it ends.
To work in this way I should introduce a frame structure at application level… that I would like to avoid in order to minimize the packets dimension.

Is there any other way to identify the limits of a frame in serial mode?

Other things: if I work with AT+RECV command, how can I detect a new frame RX event?
I mean… AT+RECV still reports the last frame received by the node but I’m not able to identify if it is already read or if it is a new one. Is there any way to identify new frame RX event?

[Luca Bertoldo]

See the following additional example.
I sent the following byte sequence: 0x41, 0x00, 0x42

Following what I can see using AT command on console:

at+rxo=0

OK
at+recv
410042

OK
at+rxo=1

OK
at+recv
A

OK

[Author]

Posts