nRF9160: LTE Sensor Gateway on Thingy:91

[Mattchew]

I am trying to fun the LTE Sensor Gateway on the Thingy:91.

The boards are missing from zephyr so I copied nrf52840_pca20035 and nrf9160_pca20035 from ncs\nrf\boards\arm.

When running samples/bluetooth/hci_uart.

The BLE and UART don't seem to be configured correctly. I get "warning: BT_CTLR_DTM_HCI" and "warning: BT_CTLR_ASSERT_HANDLER".

I created ncs\zephyr\samples\bluetooth\hci_uart\nrf52840_pca20035.overlay based on https://devzone.nordicsemi.com/f/nordic-q-a/51693/hci_uart-on-thingy-91

This still doesn't work.

Adding the lines below to nfr52840_pca20035\Kconfig.defconfig seem to fix the BLE issues? UART is not working so, I don't know if it is working.

config BT_CTLR
default BT

When running samples/nrf9160/lte_ble_gateway I get errors "warning: UART_2_NRF_UARTE" and "warning: UART_2_NRF_FLOW_CONTROL"

I see that nrf9160_pca20035ns.overlay is missing from the folder but I am not sure how to modify it. There is no status light configured. 

Help?

[Sigurd]

Hi,

I got the automatic reset-line to work. I got the Thingy:91 to connect to a Thingy:52 over BLE, and when I flipped the Thingy:52, the orientation got posted to nRFCloud. Might be better ways to do it, but at least it works. Note that I have not tested it very thoroughly, so might potentially be some minor bugs present.

I tested this on nrf(fw-nrfconnect-zephyr) master, hash d4a23f96221fce9bff846a2979d304c0130d6b74

Here are git diffs, and pre-compiled hex:

lte_ble_gateway_thingy91.zip

EDIT: 

Minor bug-fix: for samples/nrf9160/spm/nrf9160_pca20035.overlay, and  samples/nrf9160/lte_ble_gateway/nrf9160_pca20035ns.overlay , the rts-pin should be set to 0xFFFFFFFF , not 0xFF

[Mattchew]

Thank you! This is working a lot better!

Should the rts-pin take place of the TP8 short? It doesn't seem to..

There is a warning on the compile. I think it is causing an issue. The Thingy:91 seems to randomly crash. 

nrf52840_reset.c

while (uart_fifo_read(h4, &c, 1)) {
		continue;
	}

implicit declaration of function 'uart_fifo_read'; did you mean 'uart_drv_cmd'? [-Wimplicit-function-declaration]

[Sigurd]

Mattchew said:

Should the rts-pin take place of the TP8 short? It doesn't seem to..

No. RTS is disconnected. You don't need to do anything with TP8 with the new changes.

As mentioned, the code was not thoroughly tested. I just saw that it was able to get data over BLE from Thingy52 to Thingy91, and then the Thingy91 sent it to the cloud.

Mattchew said:

The Thingy:91 seems to randomly crash

When this happens, did you see any error-logs being printed over RTT from the nRF9160? If not already done, you might also want to enable RTT on the nRF52840(hci-uart), and see if any errors are being printed there also. 

[ArchDevel]

Hello Sigurd,

I was directed to this thread by Håkon as I am currently attempting to do the same thing; use the Thingy:91 with the lte_ble_gateway and a Thingy:52, for a proof of concept in the smart energy sector.

I have downloaded your .diff files and tried to utilize the:

git apply nrf_patch.diff

 

and 

git apply zephyr_patch.diff

commands in the respective root directories and was greeted with error codes that echo "already exist in working directory" and "patch does not apply." Is it safe to assume that these changes to support the Thingy:91 made it into the v1.1-branch nrf tree?

I proceeded forthwith writing the precompiled hex files to the respective controllers on the Thingy:91, I was able to successfully connect to the cloud after the firmware update. However, I am confused as to how to get the Thingy:52 to connect as the readme is written for the nrf9160dk and talks about a pattern that must be entered. 

---

1. The first time you start the sample, pair the device to your account:

   1. Observe that both LED 3 and 4 start blinking, indicating that the pairing procedure has been initiated.
   2. Follow the instructions on `nRF Cloud`_ and enter the displayed pattern. In the terminal window, you can see the pattern that you have entered.
   3. If the pattern is entered correctly, the board and your nRF Cloud account are paired and the device reboots. If the LEDs start blinking in pairs, check in the terminal window which error occurred. The device must be power-cycled to restart the pairing procedure.
   4. After reboot, the board connects to the nRF Cloud, and the pattern disappears from the web page.

---

I have been successful at getting J-Link RTT Server to identify both the nrf9160 chipset as well as the nrf52 chipset and got RTT Client to "Connect" but am not receiving any output from either chipset. I am certain that I have missed a step. May you shed some light for me and help me work toward a solution?

[Sigurd]

Hi,

ArchDevel said:

Is it safe to assume that these changes to support the Thingy:91 made it into the v1.1-branch nrf tree?

No, they are not in the v1.1-branch. I was on master commit d4a23f96221fce9bff846a2979d304c0130d6b74 when the patch was made, you likely need to be on the same commit to use the patch directly. If not, you need to manaully add the changes.

Once v.1.1 is tagged, I will create a new patch and do some refactoring of the code in the patch.

ArchDevel said:

I am confused as to how to get the Thingy:52

The Thingy:52 advertises with a specific UUID in the advertising packet. The Thingy:91 is scanning for BLE advertising packets, and will auto-connect if this UUID is found when scanning.

ArchDevel said:

and talks about a pattern that must be entered. 

This does not apply here. This pattern is for adding non-JITP nRF91-DKs to the nRF Cloud. (DKs without pin-code)