nRF9160 DK - Asset Tracker Application - Connect to EMEA nRF Cloud?

[Kevin Kotinkar]

Hi,

I am testing the nRF9160 DK and used the asset tracker application with the IBasis SIM.
Application works fine under CAT M1 network (IBasis SIM is roaming on o2/Telefonica in Germany), but I can't connect to the MQTT broker / nRF cloud on NB-IoT.
(Modem is attached on NB-IoT, signal level (RSRP, RSRQ) is good).

Most likely, this is due to latency issues, as MQTT runs on TCP, which already fairly heavy for NB IoT.

Secondly, I noticed that the application uses a NRF cloud / MQTT server in the US (east coast, Virgina).
Domain: a2n7tk1kp18wix-ats.iot.us-east-1.amazonaws.com

I can connect to MQTT brokers nearby in Europe on NB-IoT (used for example the MQTT sample application), TCP connection was stable enough to support MQTT.
Question is hence, is there a server/gateway for the nRF cloud MQTT broker in Europe or other regions than US East?

Thanks.

BR
Kevin

[Albrecht Markus Schellenberger]

Hello again Kevin,

My apologies for the delayed answer. It took me some time double-checking this internally.

TCP is not always supported in NB-IoT networks, and that is generally a known issue in some networks in Germany.

But we might need modem traces here to find the root cause of the issue, as we are not sure what the root cause could be.

I don’t know if this is something you wanna try, but you can follow this guide to do so.

Thanks and regards,

Markus

[Kevin Kotinkar]

Hi Markus,

Sorry, I didn't get to that earlier, but I have just looked at what things I need to do. Currently, everything is prepared for the modem tracing, I am using the asset tracker v1.

However, it seems modem traces are on the first COM port, same as my application log. On the nRF9160 DK, this seems to be UART1 (within Zephyr called UART0?), nRF91 UART2 (within Zephyr called UART1) is disabled on the DK (DTS file states: /* Disable UART1, because it is used by default in TF-M */).

It seems as if I need to flip more than just one switch.
What is the recommended setup, naturally I want to keep my application UART console?

ADDING: Does it not cause issues if the modem trace + application logs & AT command interface are on the same COM port?

BR
Kevin

[Kevin Kotinkar]

Hi Markus,

I figured it out how to redirected the logging and Zephyr console to the RTT backend.
The AT command handler is still on the first COM port, which is also the modem trace port.

I did capture 2 traces (+ application log of failing scenario in NBIOT), one working with CATM, the other one failing the MQTT connect in NBIOT (the modem is registered to NBIOT though). Find the files attached.

The trace files (RAW format) are relatively small, so I am not sure if I did everything correctly. Please advise if something is wrong.

Please let me know if the modem team does find something interesting in the logs (use the CAT M trace to cross compare if you like to).

Thanks and best regards,
Kevin

trace-2021-08-06T09-16-18.114Z_CATM.bin

trace-2021-08-06T09-28-10.019Z_NBIOT.bin

Fullscreen NB_IOT_APP_LOG.txt Download

00> *** Booting Zephyr OS build v2.6.0-rc1-ncs1  ***
00> 
00> [00:00:00.244,232] <inf> asset_tracker: Asset tracker started
00> [00:00:00.244,628] <inf> watchdog: Watchdog timeout installed. Timeout: 60000
00> [00:00:00.245,056] <inf> watchdog: Watchdog started
00> [00:00:00.254,455] <dbg> nrf_cloud_transport.allocate_and_copy_client_id: client_id = nrf-352656106651436
00> [00:00:00.258,911] <dbg> nrf_cloud_transport.nct_settings_set: Settings key: p_sesh, size: 4
00> [00:00:00.259,399] <dbg> nrf_cloud_transport.nct_settings_set: Read setting val: 1
00> [00:00:00.263,702] <dbg> nrf_cloud_transport.nct_topics_populate: accepted_topic: nrf-352656106651436/shadow/get/accepted
00> [00:00:00.264,251] <dbg> nrf_cloud_transport.nct_topics_populate: rejected_topic: $aws/things/nrf-352656106651436/shadow/get/rejected
00> [00:00:00.264,801] <dbg> nrf_cloud_transport.nct_topics_populate: update_delta_topic: $aws/things/nrf-352656106651436/shadow/update/delta
00> [00:00:00.265,380] <[00:00:14.504,028] <dbg> nrf_cloud_transport.nct_connect: IPv4 address: 34.232.204.81
00> [00:00:14.504,486] <dbg> nrf_cloud_transport.nct_mqtt_connect: MQTT clean session flag: 0
00> [00:00:15.637,054] <inf> asset_tracker: DATE_TIME_OBTAINED_NTP
00> [00:01:22.950,653] <dbg> nrf_cloud_transport.nct_mqtt_connect: mqtt_connect failed -104
00> [00:01:22.951,141] <err> nrf_cloud: nRF cloud connect failed -104
00> [00:01:22.951,538] <dbg> nrf_cloud.api_event_handler: NRF_CLOUD_EVT_TRANSPORT_CONNECTING
00> [00:01:22.952,362] <err> nrf_cloud: nRF cloud connect failed -5
00> [00:01:22.952,758] <inf> asset_tracker: CLOUD_EVT_CONNECTING
00> [00:01:22.953,094] <err> asset_tracker: Failed to connect to cloud, error -5
00> [00:01:22.953,521] <err> asset_tracker: Device will reboot in 300 seconds
00> [00:01:22.954,833] <err> asset_tracker: LTE link disconnect
00> [00:01:23.479,675] <inf> asset_tracker: LTE cell changed: Cell ID: -1, Tracking area: -1
00> [00:01:23.789,276] <inf> asset_tracker: RRC mode: Idle
00> [00:01:24.138,214] <err> asset_tracker: Shutdown modem