ary the device visualizes the received data for yo
Okay, that my bad.
Thanks for the answer
@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)
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
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:
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 )
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?
We are using a number of test SIM cards and noticed that IMEI is leading (we expected the IMSI to be leading).
Now we are still in a test phase and it is not that important, however we are looking at live deployments as well.
For real customers
How do we block a customer? Using the IMEI only disables the device itself and does not disable the SIM card and its connectivity. So how does it work within TMO?