@Hans-Liefting: Can you please send me the IMEI of your device to support@iotcreators.com? I will check the logs to understand when uplink and downlink messages are received and when downlink messages are sent by the udp server.

Regards, Roland

Last comment …

This is valid only for non eDRX downlink messages. eDRX messages are sent directly into the network and will be buffered by the mobile network until the device is available.

Unfortunately I don’t know how long the downlink message is buffered by the mobile Telekom network 😞

Regards, Roland

@Ederuiter @afzal_m
Thanks.
We were thinking in that direction (sending version)
Another reason why I asked is that since I started sending downlinks to a (devkit) device for testing purposes, the device now is extremely slow in sending messages. It takes minutes, sometimes hours to send a single message (uplink).
Could that be linked to not “collecting” the downlink messages?

Hello guys

@Yassine-Amraue : thank you for explaining that there is a GUI and an API user. I’ve been banging my head trying to send a downlink message via API and always getting an ‘unauthorized’ error. But after registering a callback URL for the API user as well I can now send downlink messages via API to my device. Thanks again.

@magnatron : I am using a SIM7020 based device and previously via API sent downlink messages are getting delivered to it as soon as the device sends an uplink message.

Thanks
Felix

Hey @afzal_m,

Thanks for explaining. This helps.

Please consider making this a protocol when sending out emails about service interruptions (planned or not).

And please let us know what will happen with the sent data: Will devices need to send it again or will it arrive at our application after the update was successful?

Once we know this, we can tell our customers what to expect and how to act on degraded functionality,

Currently the API supports the following for functions/URLs to send downlink messages to the device

downlinkMsg/0/data
Sends regular queued downlink messages to device when uplink is received.

downlinkMsgBase64/0/data
Sends queued binary data blob message to device when an uplink is received. The function expects base64 encoded payload from the applaction as input into this function. Before the message is sent to the device it is decoded back to binary and sent to the device.

downlinkMsgDrx/0/data
Same like downlinkMsg/0/data but without queuing.

downlinkMsgBase64Drx/0/data
Same like downlinkMsgBase64/0/data but without queuing.

@Eric-Barten said in Downlink API dataformat:

ary the device visualizes the received data for yo

Okay, that my bad.
Thanks for the answer

@David-Netten

Hi David,

you are right, that the UDP server of IoT Creators doesn’t send back an acknowledgment for a received messages.

BUT: The CoAP/Leul server of IoT Creators acknowledges a received messages with a “2.05 Content” acknowlegment.

Be aware that CoAP/Leul is the Huawei flavor of CoAP and it is supported by Huawei chipset such as HiSilicon which are used in moduls such ublox N211 or Quectel BC95.

For many customers it is not enough to have an acknowledgment between the device and the IoT middleware. The implement an asynchronous acknowledgment between the application and the device on the basis of a downlink message. If you would need the asynchnronous application acknowledgment it wouldn’t make a difference between CoAP/Leul and pure UDP.

Regards, Roland

​

@Yosiel

That is great. Just reach out when you need assistance again. 🙂

@afzal_m Yes, I tried it few minutes before you wrote here 🙂 and it works!

Thank you very much, we can continue in our small project…

Thanks. We’re checking again. Get back to you soon…

I found the problem, I use an arduino leonardo with a dragino nbiot shield. For incomming/outgoing messages i use SoftwareSerial.h, to change the tx/rx pins to pins 10/11.

I fixed the problem by using the normal rx/tx pins and it works. Hence the library seems to be my problem.

Hope this helps anyone.

There is no option to query the status of a downlink message. Buffering of downlink messages may occur on different places in our solution it is hard to give an clear response to such a request due to the asynchronous nature of the protocols.

Note: after sending an uplink message we will try to downlink all buffered messages.

@sopwafel You could, but be aware of using PSM and expected latency. Your device might be sleeping again before it had the chance to receive a downlink message. I don’t know if it’s possible to use in combination with the T-Mobile CDP but you might want to take a look at LWM2M and CoAP. These protocols have acknowledgements build in.

The term “latency” relates to one-way, downlink or uplink communication. It does not include the time needed to establish a connection between the server and the device. If the device is in power saving mode, it will only receive or send data after it wakes up. According to measurements on current test setups with pre-commercial radio modules, data transmissions typically exhibit a latency of less than a second. In scenarios involving deployments in poor coverage areas, latency may increase up to 7-10 seconds. That said, NB-IoT technology is continuously being enhanced, so current figures are expected to improve with successive releases of the specification.

NB-IoT supports bidirectional communication, but the more common direction is uplink transmission. Only half-duplex is supported, i.e. uplink and downlink don’t take part simultaneously.

UL peak rate up to 230 kbps DL peak rate up to 250 kbps

Please note that these are not the datarates meanwhile. Current datarates are maximum 20Kbps UL/DL due to single tone transmission.

Does it also work for @trick2011 now?