• RE: Message forwarded multiple times.

    @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

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

    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

    posted in The Thing For IoT Creators
  • RE: Can the starterkit connect to any public tcp endpoint or only to the iotcreators endpoint?

    For NB-IoT we have an UDP adapter. So with NB-IoT you’ll need to use APN cdp.iot.t-mobile.nl which will allow you to send device data to 172.27.131.100.

    To retrieve the device data in your back-end/cloud server/iot platform, you’ll need to create an HTTP integration.

    If you use the sim-card for LTE-M or 2G, you’ll need another APN: m2m.public.nl. By doing this, the device will get a public IP address just like any other device on the open internet. This means that you can send device data directly to your own server while using LTE-M or 2G.

    Hope this helps!

    posted in Network & Coverage
  • RE: Can the starterkit connect to any public tcp endpoint or only to the iotcreators endpoint?

    You can only send traffic to our server and we can help you with the HTTP integration to your environment.

    2G and LTE-M are accessible. Pls use APN m2m.public.nl and you’ll get a public IP address. By doing this, you can send data to any destination.

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

    Regards, Roland

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

    @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

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

    posted in The Thing For IoT Creators
  • RE: quectel nb-iot modem is activated every hour - why? (psm is 10 hours)

    Hi Lorenz,

    one of the reasons for the unexpected behavior you described could be the fact that your device performs a periodic Tracking Area Update (TAU). You can read about it here and here (click on 3GPP Connectivity --> Power Saving Features --> Tracking Area Updates.

    I’m not an expert on this, but it seems to me that TAU is active on your module, but please double-check. Look here for more details.

    TAU timer on most of NB-IoT networks in DT footprint lays between min. 1 h - 310 h. If this value was changed by you to 0, our network will automatically change it back to the minimum value of 1 hr.
    You have a possibility of adjusting this value/extending the timer, as our network supports a dynamic TAU, meaning it will accept the value proposed by your UE as long as it fits into the 1-310 h window.

    posted in Network & Coverage