Global Moderators

@FrancoisD ,
Cell reselection is natively supported by the NB-IoT network, there is nothing to be done at the module level to enable this feature.

Best regards,

Ronan

@Gijs-Mos
I checked the UDP logs for your device and I agree. Your device doesn’t send the messages twice.

If your application end-point doesn’t return to our platform within 1 second we go into a re-try loop to re-deliver the message. We re-try max. 5 times. Every minute ones. If within the period of re-trieng additional messages from other devices arrive they are put into the same post request and delivered as an additional element of the “reports” array. But in this case you would see different serialNumbers and timestamps.

Is it possible that your callback returns sometimes slower than 1 second. In this case our platform would re-deliver the message a second time.

I saw cases where the application end-point didn’t publish the message into a queue for asynchronous processing. It processed the message directly and stored it away into a DB. Sometimes the DB blocked. By the this the response time was bad and the messages have been delivered a second time.

Regards, Roland

Hi,

many users ask via which IP address IoT Creators SCS forwards received uplink messages to the registered application callback URL:

IoT Creators SCS forwards the uplink messages to your application callback URL via one of the two IPs

• 18.195.119.162
• 18.195.17.174

Hope this helps you to configure the IP whitelists of your application.

Regards, Roland

@lorenz
Dear Lorenz,
Thanks a lot for the feedback and I’m glad to see eDRX is delivering its promise on energy saving!
Another tip maybe: please consider setting your preferred Periodic TAU Timer to save further energy.
This can be done without setting any PSM activity timer with the CPSMS command, with a TAU-timer of up to 310 hours.
To enable Long-Periodic TAU without PSM, use value “11100000” for parameter <Requested_Active-Time>.
Best regards,
Ronan

Hi Lorenz,

from the log in one of your previous posts it is pretty obvious, that your module is loosing its connection periodically.

What is really weird, is the fact, the the connection losses sometimes happen at times at which the module should be in PSM (e.g. reconnect 3:48 am). That suggests that the module is not even entering PSM, although the appropriate timers have been assigned by the network. You could check this by activating the URC:

AT+NPSMR=1

which provides indication for entering/leaving PSM. If the module is indeed entering PSM, this is a clear indication, that the detachment is initiated by the module, as the network would not be able to detach a module gracefully during PSM.

It is hard to say what is going on here without a trace from either the module or the network, but this is definitely erroneous behavior. There is no mechanism in the network which is causing periodic detachments, except for missing TAUs, and they seem to be fine.
However, what can be ruled out is the scan for the HPLMN in roaming, as this would not interrupt PSM and the interval for this scan is larger than 1 hour in the DT NB-IoT network. Furthermore, it would not cause a connection loss, or at least not on a correctly working module.

Unfortunately, the log does not tell whether the signal quality has changed during the test. Initially a very good signal was observed, but for the following data events the signal quality is queried too early to provide meaningful values. Maybe you can adjust your script to query the signal quality right after the +CEREG: 5,… and +NSOSTR URCs, which should always yield meaningful values.

For further troubleshooting you can collect traces on the module and send them for inspection to Quectel via your distributor. To get a dedicated support ticket for an investigation on the network side you would have to contact 1nce.

Best regards,
Thorsten

• Before activating radio module Set APN with AT+QCGDEFCONT rather than **AT+CGDCONT
• Set frequency band explicity with AT+QBAND
• Configure first APN, fequency band and mobile operator ID before switching on automatic attachment

As you know the very-first-attachment to the network can take multiple minutes. Sometimes this creates problems in the production process.

Out of this reasons we are looking for possible measures to improve the very-first-attachment time.

Regards, Roland

@Rasyid Do you have a valid network connection ?

For Quectel BG96 you can verify the network connection with the following AT commands

AT+CGPADDR                    //check IP address
AT+CGATT?                     //check if attached to network
AT+COPS?                      //check current set MNO
AT+COPS=?                     //scan network for mobile operators
AT+CGDCONT?                   //check APN
AT+QPING=1,"172.27.131.100"   //ping UDP server

Regards, Roland

@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

​

@David-Netten be aware the both the CoAP/Leul server and the UDP server are hosted on the same IP 172.27.131.100. But the port of the CoAP/Leul server is 5683 and the port of the UDP server is 15683.

CoAP/Leul is special CoAP flaviour from Huawei. Some of the Huawei chipset such as HiSilicon which are used e.g. in ublox N211 or Quectel BC95 support it.

The AT commands for the Quectel BC95 to send and receive messages via CoAP/Leul looks like the following:

# Read current configuration
AT+UCOAP?

# Set OceanConnect CoAP server and port   
AT+NCDP="172.27.131.100",5683

# Activate send message indicator
AT+NSMI=1

# Send Hello World message
AT+NMGS=11,"48656c6c6f20576f726c64"

+NSMI: SENT                                                                      

# Activate receive message indicator 
# and display received message 
AT+NNMI=1 
                                                                                 
# Receive downlink message
+NNMI: 16,"48616C6C6F20766F6E20536572766572"                                     

# Activate receive message indicator with message display 
AT+NNMI=2
+NNMI     
                                                                       
AT+NMGR
16,"48616C6C6F20766F6E20536572766572"                                   

Regards, Roland