Nrf9160 Network (LTE-M) issue on custom board

[JackFitton]

Hello,

I am currently having an issue with my custom board.

I am getting CEREG 4. it is difficult to tell from the documentation if this is:

4 – Subscribe unsolicited result codes +CEREG: <stat>[,[<tac>],[<ci>],[<AcT>][,,[,[<Active-Time>],[<Periodic-TAU-ext>]]]]

or

4 – Unknown (for example, out of Evolved Terrestrial Radio Access Network (E-UTRAN) coverage)

I have ran the same program on the nRF9160DK and it runs perfectly and connects. I have tried running the AT client but as the J-link is over RTT rather than serial I cant find a way to send AT commands to the chip - is this possible?

It is also possible it is my matching network. Is there a way for me to test this besides using a VNA?

Board files:

Thank you in advance

Edit:

Running modem firmware 1.3.6

SDK 2.5.0

Chip: SICA-B1A-R

[JackFitton]

I have tried enabling

CONFIG_NRF_MODEM_LIB_TRACE=y

CONFIG_AT_HOST_LIBRARY=y #(note this is optional)

and using the celluar monitor but all values are just unknown

RTT now spits out:

+CEREG: 4
[00:01:29.086,212] <dbg> lte_lc: at_handler_cereg: +CEREG notification: +CEREG: 4

[00:01:29.086,334] <dbg> lte_lc_helpers: parse_cereg: Network registration status: 4
[00:01:29.086,334] <dbg> lte_lc_helpers: parse_cereg: LTE mode not found, error code: -22
[00:01:29.086,395] <dbg> lte_lc_helpers: event_handler_list_dispatch: Dispatching event: type=0
[00:01:29.086,395] <dbg> lte_lc_helpers: event_handler_list_dispatch:  - handler=0x00019D9D
[00:01:29.086,425] <dbg> lte_lc_helpers: event_handler_list_dispatch: Done
[00:01:29.086,456] <dbg> lte_lc_helpers: event_handler_list_dispatch: Dispatching event: type=4
[00:01:29.086,456] <dbg> lte_lc_helpers: event_handler_list_dispatch:  - handler=0x00019D9D
[00:01:29.086,486] <inf> internet: LTE event: cell update
[00:01:29.086,517] <inf> internet:      TAC -1 ID -1
[00:01:29.086,517] <dbg> lte_lc_helpers: event_handler_list_dispatch: Done

[JackFitton]

Managed to get the AT client running with UART

> AT
OK
> AT%SYSTEMMODE
ERROR
> AT%XSYSTEMMODE=1,1,0,0
OK
> AT+CFUN=1
OK
OPS: 0
OK
> AT+COPS?
LR
> AT+COPS
ERROR
> AT+COPS
> AT+COPS=?
*** Booting nRF Connect SDK v2.5.0 ***
The AT host sample started
Ready
> AT%XSYSTEMMODE=1,1,0,0
OK
> AT+COPS=?
ERROR
> AT+CFUN=1
OK
> AT+COPS=?
> AT+COPS
*** Booting nRF Connect SDK v2.5.0 ***
The AT host sample started
Ready

when i run `AT+COPS` the device crashes / reboots

[Charlie]

Hi Jack,

Thanks for the inquiry. There are two problems according to your description. The first one is not able to find a network which may be related to the matching network. The second reset issue may be related to the power supply. Both of them are hardware related, I hope you have referred nRF9160 Hardware Design Guidelines when you do your hardware development. My colleague is working on your hardware review now. Let's see how your HW can be improved.

For the question to test this besides using a VNA, I think this is a necessary step to tune your matching network for your hardware. If you did not do it, it is high chance your antenna performance will be bad. This is properly the reason you see the issue. For the reset issue, please check with a power to make sure it can serve enough current for the device, especial for the network searching period. nRF9160 specification has one section introduce about peak current consumption under different conditions.

We can also help customer to do antenna tuning in addition to HW design review.

Best regards,

Charlie

[Achim Kraus]

> I am getting CEREG 4. it is difficult to tell from the documentation if this is:

You need to distinguish between a response to the read command and a "notification/unsolicited result codes".

With the set and read command you configure and check, which data is contained in an "notification/unsolicited result codes". Such a notification is reported by the modem on it's own without using a read command.

The documentation itself mentions then "For the notification syntax parameters, see Read command."

AFAIK, that is only half true. That documentation for the read contains a  <n>, which is only contained in the response to the read command. It indicates the subscribed information level there. The "notification/unsolicited result codes" itself then doesn't contain the <n> and starts with <stat>. That patter is used quite often, I guess therefore the author didn't pay too much attention to it.

Maybe a candidate for a small improvement ;-).

[Charlie]

Hi Achim and Jack,

Thanks for your report. I agree with the improvement proposal and will share with our modem team.

Best regards,
Charlie