Combining GNSS and CoAP client in nRF Connect SDK — GNSS fix not read, CoAP request not sent

[Arun538]

Hi Nordic team,

I’m working on an nRF9151 DK with nRF Connect SDK v3.0.0.
My goal is to send GNSS latitude/longitude data to a CoAP server.

• The GNSS sample works fine → I get correct coordinates.

• The CoAP client sample works fine → I can send POST requests and get responses from my server.

• But when I combine both in one project, I get no GNSS fix and no CoAP messages are sent.

I only see: 

<inf> coap_client_sample: Starting GNSS + CoAP client
<inf> coap_client_sample: Bringing network interface up
<inf> coap_client_sample: Waiting for network connectivity

• Is there a specific order required for modem/LTE/GNSS init when used with CoAP?

• Any debugging tips to see why GNSS events never trigger and CoAP never sends?

Additional info

• Board: nRF9151 DK

• SDK: nRF Connect SDK v3.0.0

• Both examples work independently

• Using IPv6 CoAP server

Any guidance or example on how to properly combine GNSS fix + CoAP POST would be greatly appreciated.

Regards 

Arun

[dejans]

Hi Arun,

Can you describe your setup and provide complete application log?

Best regards,
Dejan

[Arun538]

Hi, thanks for the quick response.

Here’s my setup:

• Board: nRF9151 DK

• SDK: nRF Connect SDK v3.0.0

• SIM/network: Jio NB-IoT (India)

• Server: IPv6 CoAP server at dev-iot.imsafe.app:5683

• Environment: Tested outdoors, GNSS works when I run the standalone GNSS sample.

Here is the complete application log from boot:

*** Booting nRF Connect SDK v3.0.0 ***
*** Using Zephyr OS v4.0.99 ***
[00:00:00.305] <inf> coap_client_sample: Starting GNSS + CoAP client
[00:00:00.312] <inf> coap_client_sample: Bringing network interface up
[00:00:00.320] <inf> coap_client_sample: Waiting for network connectivity
+CEREG: 2,"C094","00482492",9
+CSCON: 1
+CEREG: 5,"C094","00482492",9,,,"11100000","11100000"
+CEDRXP: 5,"1001","1001","0011"
<no further GNSS or CoAP activity>

When I run the GNSS sample alone → I get fixes.
When I run the CoAP client alone → I get responses from the server.
When I combine them → neither GNSS events nor CoAP requests happen.

My goal is:
To get latitude & longitude from the nRF9151’s GNSS and send that data via CoAP POST to my server.

Regards

Arun

[dejans]

Hi Arun,

With regard to use of A-GNSS or P-GPS you can look at the following samples:
nRF Cloud Multi Service 
Modem Shell
Location
GNSS

Best regards,
Dejan

[Arun538]

Hi Dejan,

I have already tested the standard GNSS example, but I’m unable to get a valid fix while walking. The fix works reliably only when the device is stationary outdoors. It seems that the GNSS is struggling to maintain continuous tracking while in motion.

Could you please clarify if the nRF91 GNSS is expected to work reliably while walking or during motion? If so, is there a recommended configuration or mode to enable continuous tracking while moving?

Best regards,
Arun

[dejans]

Hi Arun,

Constant speed movement should not pose a challenge to GNSS. There seems to be something else that is creating interference in your case. If there is no degraded sky view while walking, the problem might be caused by the placement of your DK while walking. Did you place your DK close to the laptop while walking? If yes, that is mostly likely causing no-fix situation.

Best regards,
Dejan

[Arun538]

Hi Dejan,

Ok, I will test the device without the laptop as you suggested.
I also wanted to confirm one more thing — my DK is enclosed in an ABS 3D-printed case, and I usually keep the device in my pant pocket or in a bag while walking. In that setup, is it still possible to get a GNSS fix, or will the enclosure and placement affect the signal reception?

Best regards,
Arun

[dejans]

Hi Arun,

Which material is this 3D-printed case made of?

Best regards,
Dejan

[Arun538]

Hi Dejan,

The case is made of Acrylonitrile Butadiene Styrene(ABS) material, printed using a standard 3D printer.

Best regards,

Arun

[dejans]

Hi Arun, 

You can do your own tests. When testing, ensure that there is no interference from the laptop. First scenario would be to walk with your device in the open sky. Second scenario would be to walk the same route with your device in the pocket (or in a bag) enclosed in described casing. I assume you have already provided results for the second scenario. There you got very poor C/No level of 25 dB-Hz. This is almost as if your device is indoors. I would expect that you get better result if device is in open sky environment and not enclosed in a casing.

Best regards,
Dejan