Search Result

Hi guys, We are building an IoT device on nRF9160 The main protocol is MQTT and we are using AWS IoT Core as a Cloud provider. MQTT client is based on nRF Connect SDK 2.5.0 mqtt_helper library. We want to use AWS Device Adviser ( https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor.html ) in our tests. Most of the supported tests are green, but we are facing a problem with TLS Expired Server Certificate test ( https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-tests-tls.html#expired-server ) The test always fails, that means the device can connect to a server with an expired certificate. I've attached the test log from AWS Device Adviser Any thoughts on what can be wrong? Missed config options? BR, Alexey devzone.nordicsemi.com/.../log_2D00_events_2D00_viewer_2D00_result.csv

Hi I'm trying to add to my Linux board (RPI4 CM) a cellular connectivity and I thought about using nRF9160 SiP because it's a product I've already used and it's low cost compared to other solutions on the market. The goal here is to ensure the RPI4 CM can communicate with an AMQP broker like RabbitMQ using cellular network instead of WiFi. 1) Is there any Linux driver for the nRF9160 to ensure that the Linux network manager can use this modem to communicate like some Quectel or Sierra Wireless modems? I know Nordic was working on a Linux driver for the nRF7002 SoC, so maybe there's something to the nRF9160 SiP as well? 2) Another alternative would perhaps be to use the SiP nRF9160 with the modem firmware? I'm wondering if it's possible to use the SiP nRF9160 to establish communication with an AMQP broker like RabbitMQ by flashing

Hi there, I'm reaching out regarding the nRF9160 and RRC Mode. We have devices in motion (for example, during highway travel) that attempt to determine their position (via GNSS and MultiCell) while in transit. For both tasks, it's essential that the devices transition to RRC idle mode (currently, we wait with a timeout of 45s for RRC connected → idle) before initiating position determination. However, particularly during travel, it often happens that we don't transition to RRC idle before our timeout. My initial suspicion was that this might be due to cell changes prompted by the change in position. However, upon examining the logs, it became clear that no cell change had occurred. What other reasons could prevent the UE from transitioning to RRC idle? Is there any influence we can exert over this process? (besides RAI with NB-IoT) Since we have no control over the RRC mode transition, what

This happened last month also during debugging of SIM card "data remaining" not updating . I could not use my device for the whole month because the quota was gone in minutes. Now, new month, new quota, I turn my device on, and in under a minute already 24/500 requests gone. I have unmodified Asset Tracker v2. Please advice what to do so I can develop this month. Serial terminal says (until I pulled the plug): %CESQ: 42,2,21,3 +CEREG: 2,"0079","0022352B",7 [00:00:01.557,525] app_event_manager: MODEM_EVT_LTE_CELL_UPDATE +CSCON: 1 +CGEV: ME PDN ACT 0,0 +CNEC_ESM: 50,0 [00:00:03.014,434] app_event_manager: MODEM_EVT_LTE_CONNECTED [00:00:03.015,502] app_event_manager: CLOUD_EVT_CONNECTING %MDMEV: SEARCH STATUS 2 +CEREG: 5,"0079","0022352B",7,,,"00001010","11000001" %XTIME: ,"42507070456021","01" [00:00:03.026,367] app_event_manager: MODEM_EVT_LTE_PSM_UPDATE [00:00:03.026,947] app_event_manager: DATA_EVT_DATE_TIME_OBTAINED [00:00:05.742,126] app_event_manager: CLOUD_EVT_CONFIG_RECEIVED [00:00:05.746,002] app_event_manager: DATA_EVT_CONFIG_SEND [00:00:05.746,948] app_event_manager: CLOUD_EVT_DATA_SEND_QOS [00:00:06.371,154] app_event_manager: CLOUD_EVT_CONNECTED [00:00:06.372,131] app_event_manager: APP_EVT_DATA_GET - Requested data types (MOD_DYN, MOD_STAT, BAT, ENV, LOCATION) [00:00:06.372,802] app_event_manager: LOCATION_MODULE_EVT_ACTIVE [00:00:06.373,443] nrf_cloud_pgps: Storage base:0x75000, size:430080 [00:00:06.381,866] nrf_cloud_pgps: Checking P-GPS header: Schema

Following the guide on developer.nordicsemi.com/.../azure_iot_hub.html I was successfully able to add a device to the enrollment group and then automagically create a device in IoTHub. Excellent! However, upon adding a _second_ device, I get stuck here: $ az iot dps enrollment create --enrollment-id $DEVICE_CN --device-id $DEVICE_CN \ --provisioning-status enabled --resource-group $RESGROUP \ --iot-hubs $IOTHUB_URL --attestation-type x509 \ --certificate-path certs/client-cert.pem --dps-name $DPS \ --allocation-policy static > /dev/null ERROR: {'code': 409201, 'message': 'Enrollment already exists.', 'trackingId': 'opaque-tracking-id'} DEVICE_CN comes from the section "Generate and provision device certificates", where I create the device cert using nrfcredstore on the modem: $ nrfcredstore generate certs/client-csr.der $ openssl req -inform DER -in certs/client-csr.der -outform PEM -out certs/client-csr.pem $ cert_tool.py sign Signing certificate with CN: Signed client certificate saved as certs/client-cert.pem Now, it says "take note of the CN, as it will be required later". The problem is that the CN is always the same, if I

Hi, The function `modem_info_get_fw_version` uses a fixed size buffer `format`: https://github.com/nrfconnect/sdk-nrf/blob/27eb54ef7183af81f3413c31532f1dd242c36e19/lib/modem_info/modem_info.c#L807 The size is defined by `SWVER_FMT_STR_SIZE` which is hardcoded to 23. The following line: sprintf(format, "%%%%SHORTSWVER: %%%d[^\r\n]", buf_size); generates the following string assuming that `buf_size` is 99: "%%SHORTSWVER: %99[^\r\n]" plus a null terminator. This is exactly 23 characters long. This means that the format string can only fit a `buf_size` which is only 1 or 2 digits long. If you pass in `buf_size` larger than this (say 100) then this causes a buffer overflow. My suggestion to fix this is to use `MODEM_INFO_FWVER_SIZE` in the sprintf, not `buf_size`. Thanks, Jeremy

Hi, I am developing an application where the nrf52840dk acts as peripheral device and sends data to nrf52840 of fanstel module. The fanstel nrf52840 acts as an central device. The data is relayed via UART to fanstel nrf9160. A note: I am using fanstel module BLG840F which has nRF52840 and nRF9160. I have used BLE central and peripheral example from nRF52840 sdk with no modification in the central and slight modification for constantly sending data in peripheral. For nrf9160, I have used mqtt example from nRF sdk connect with slight modification where in I added workqueue for UART. The workqueue then post the received data via mqtt. Currently what is happening is when the Fanstel's nRF9160 is publishing the data, the BLE connection is lost between nrf52840dk and Fanstel nrf52840. After the data is published it tries to connect again. This keeps on happening whenever Fanstel's nRF9160 publishes data via

Are there any plans/possibility that the 91X1 GNSS firmware can take advantage of RTCM/RTK correction data for improving positioing. For use with for example: CPOS - Guide to CPOS | Kartverket.no GEODNET

I'm using the MQTT multi service sample to get A-GPS data using MQTT. I want to compare the energyconsumption with REST. I request A-GPS data using the function " nrf_cloud_agps_request_all ()". I use the function below to check what A-GPS data is available to the modem. Before I do the request it prints: "ephe 0x000000, alm 0x0000000, flags 0x00" and then i print again when the LTE-connection goes into RRC idle mode and it prints this: "ephe 0xfffffffe, alm 0xfffffffe, flags 0x3f". So this means that the A-GPS data is received, processed and ready for yse right? The issue is I want to shut down the LTE-connection as soon as I can since I have a very energy sensitive application. Isn't there some way to know exactly when the A-GPS data is received so I can shut down the LTE after? I have tried to detect this with the various

Custom nRF9160 hardware. UART0 over RX/TX-TTL. Updated to MFW 1.3.6. nRF SDK 2.5.2. Two issues: 1) Normal at_client w/ PDN enabled to set APN. LTE Link Monitor, and AT&CFUN=1, then AT&CFUN? gives me all the usual info about serial number, firmware, etc., with the last line being the selected bands, and then the app stops responding to AT commands. Breaking in the debugger says the app is running, idling. 2) In order to get more info on what's wrong: enable modem lib trace (CONFIG_NRF_MODEM_LIB_TRACE=y). Start app, then crash. Temporary breakpoint 1, main () at /.../252-cellular-at-client/src/main.c:30 30 printk("The AT host sample started\n"); Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000758 in ?? () (gdb) Nothing in the map files matches the address. Tried various options, including -S tfm-enable-share-uart to force it to uart0, to no avail. What more can I do? ----- ADDENDUM. For no reason, whatsoever, the modem suddenly started