• RE: Cell reselection with NB-IoT

    @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,


    posted in Network & Coverage
  • RE: Message forwarded multiple times.

    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

    posted in The Thing For IoT Creators
  • Via which IP IoT Creators SCS webhook forwards uplink messages to application callback URL?


    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


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

    Regards, Roland

    posted in The Thing For IoT Creators
  • RE: eDRX in Germany for NB-IoT

    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,

    posted in Network & Coverage
  • RE: quectel nb-iot modem is activated every hour - why? (psm is 10 hours)

    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:


    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,

    posted in Network & Coverage
  • RE: Quectel BC66, How to improve very-first-attachment time
    • 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
    posted in Hardware
  • Quectel BC66, How to improve very-first-attachment time

    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

    posted in Hardware
  • RE: Quectel BG96, Error while trying to ping the UDP Server

    @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,""   //ping UDP server

    Regards, Roland

    posted in The Thing For IoT Creators
  • RE: Ack message from server


    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

    posted in The Thing For IoT Creators
  • RE: Ack message from server

    @David-Netten be aware the both the CoAP/Leul server and the UDP server are hosted on the same IP 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
    # Set OceanConnect CoAP server and port   
    # Activate send message indicator
    # Send Hello World message
    +NSMI: SENT                                                                      
    # Activate receive message indicator 
    # and display received message 
    # Receive downlink message
    +NNMI: 16,"48616C6C6F20766F6E20536572766572"                                     
    # Activate receive message indicator with message display 

    Regards, Roland

    posted in The Thing For IoT Creators