Downlink API dataformat

Lauwie007

I can’t send a downlink via HTTP PUT as described in the API.
I send the data as HEX to the API, which returns true. But the node doesn’t receive data.

When sending the data in base64 format to the API using this url:
*PUT {{base_url}}/m2m/endpoints/{{DeviceId}}/downlinkMsgBase64/0/data
The node does receive data. But it receives the HEX data as ASCII from T-Mobile.

So for example:
I Send base64 ‘AA==‘ (1 bytes)
(Base64 ‘AA==’ translates to HEX ‘00’)
The node receives the ASCI string: ‘00’ (2 bytes)
This should also mean that all downlinks are twice the size.

From the node (written by my colleague )
AT+CSOSEND=0,36,00000363501E01078041E0163C3000000000
OK

+CSONMI: 0,2,00

Downlink data received: 00 (but this is ASCII, which translates to 3030 in HEX)

Is it possible to send the downlink in HEX so that the node receives it in HEX?
Or could this be a error in the modem?

afzal_m

Hey @Lauwie007

If you use our GUI and click on the ‘actions’ button in the ‘devices’ you’ll see that it is possible to send downlink messages in HEX format.

However, the fact thad one needs to select an additional checkbox tells me that you’ll need to some additional things when you use the API as well.

Let me check this with @Yassine-Amraue or @Roalnd-Baldin this Monday and get back to you.

Roland Baldin

@Lauwie007 Hi,

If I send “hi” with

PUT https://iot.netwerk.t-mobile.nl:443/m2m/endpoints/IMEI:867997031341158/downlinkMsg/0/data
and
BODY {
“resourceValue”: “hi”
}

I receive

AT+QISENDEX=1,11,48656c6c6f20576f726c64
OK
SEND OK
+QIURC: “recv”,1
AT+QIRD=1,100
+QIRD: 2
hi
OK

on the device.

Regards, Roland

Lauwie007

Hey Roland,

Thanks for the answer.
I’m wondering. Can I send the resourceValue in HEX instead of ASCII?

My payload is in hex. I want to avoid
HEX2ASCII -> T-Mobile -> Node -> ASCII2HEX

Preferred would be
HEX -> T-Mobile -> Node -> HEX

Roland Baldin

@Lauwie007 For my understanding there is no difference if the function transfers “hi” or “01AB” as value.
Regards, Roland

Stefan de Lange

@Roalnd-Baldin 01AB uses twice the amount of data as hi if it’s received as ASCII

Lauwie007

@Stefan-de-Lange said in Downlink API dataformat:

@Roalnd-Baldin 01AB uses twice the amount of data as hi if it’s received as ASCII

Yes, this is what I mean.
In this case I would need to first encode ‘01AB’ to ASCII before sending it to the API.
But I’m not that familiar with ASCII encoding so I’m not sure if there are edge case scenario’s which don’t work.

If its possible. Sending HEX to the API would be best (as it is also the standard for other networks I have worked with)

Stefan de Lange

@Lauwie007 so basically, you want binary data transfers?

Lauwie007

@Stefan-de-Lange
Yes, that would be great

Lauwie007

@Stefan-de-Lange Hey Stefan,
Do you know if a binary downlink is possible? And how?

Stefan de Lange

@Lauwie007 I don’t know sorry. Maybe t-mobile knows

Lauwie007

@Roalnd-Baldin
Do you know if and how I can send a binary downlink? (see the convo between Stefan and me)

Eric Barten

@Lauwie007 said in Downlink API dataformat:

Downlink data received: 00 (but this is ASCII, which translates to 3030 in HEX)

Your assumption here is wrong @Lauwie007 this is binary the device visualizes the received data for you in HEX so it received 0x00 binary 2 bytes which is what you want to achieve.

+CSONMI: 0,2,00 means I received 2 bytes both all zeros.

Regards,
Eric

Lauwie007

@Eric-Barten said in Downlink API dataformat:

ary the device visualizes the received data for yo

Okay, that my bad.
Thanks for the answer