Develop with Me - Bluetooth/LTE Tracking Device

[joeyquatela]

Hi everyone! My name is Joey, I’m a senior computer engineering student at Vanderbilt University, and for the past few months my partner, Grey Aycock, and I have been working with Chris Gammell at Golioth to develop a BLE/LTE tracking system. In short, the idea is that there will be many BLE enabled peripheral tracking devices communicating with a central hub, which will be sending data to the Cloud (which is where Golioth comes in), such as an alert if one of the peripherals leaves the immediate area.

This project is being built on Zephyr and prototyped on Nordic-Semi Devboards. We, as college students, have absolutely no idea how to use either of these technologies, so we will be having fun figuring it out as we go.

On the forum, we will be keeping this thread up to date with our progress, what we have discovered, and things we have learned. Feel free to provide feedback, suggestions, or just follow along with what we’re doing; we’d love for this to get incorporated further into the Golioth community!

[joeyquatela]

Progress Update 1-26-24

Apologies in advance for the length of this first update… Subsequent entries will be much shorter.

Context and Technology

When Grey and I started this project, we had essentially no experience with BLE, IoT, Zephyr, Nordic Devices, embedded Linux, or the Golioth platform, so to say this has been and continues to be a learning journey is an understatement. On the bright side, everything we document here is from the perspective of fresh eyes on the industry. To get started, we got a couple nRF 9160DKs and nRF 5240DKs and attended one of the Golioth Zephyr training session with Chris to get our feet wet, the content of which you can find here.

Zephyr

I don’t know if you have tried to read some of the peripheral or central BLE samples that come with the new nRF Connect SDK, but for someone that is new to the industry, it is terrifying. That being said, sometimes the best way to learn is by doing. Chris encouraged us to just get familiar with the development environment and with using the tools. As we did so, we became comfortable using the devices we had and had a more steady platform to stand on while trying to understand the Zephyr code. In contrast, it makes it even harder to understand BLE code in Zephyr when you’re unfamiliar with the language of BLE so we decided to take a step back and learn some fundamentals there.

BLE

Bluetooth low energy, like many standardized protocols, has a lot of jargon surrounding it that makes it difficult to understand without having studied the basics. Thankfully, Nordic Semi offers a super awesome learning platform for BLE and LTE basics (separately, but both are free) on their website. Completing that training was a fundamental turning point for this project, as we could actually understand what the samples were doing and even started writing our own Zephyr code.

Finding Pre-Existing Solutions

After scouring around the SDK samples for some time, we were convinced that in this stage of our learning process, developing this application from scratch was not feasible. Instead, we looked for a jumping off point. Chris initially sent us a link to a Nordic repo that did exactly what we were trying to do, but we couldn’t get it to work and it turned out that it was severely outdated. A Nordic Dev then pointed us to a more updated version, that was slightly different than what we were looking for, but was a perfect starting point.

Most Recent Progress

In the future, this section on will be the typical length of an update
From our jumping off point, we were able to get an nRF52840 to communicate via BLE to the nRF52840 on the 9160DK, which then transferred data serially to the nRF9160 chip on the same DK, which finally could be sent to the cloud (see image for clarification). This is more or less the architecture we are aiming for, so this was super exciting.

Next Steps

Currently, the 9160 is sending data to nRF Cloud, but we soon want to switch that over to the Golioth platform. First, though, the application can only communicate with 1 BLE peripheral, and we need at least 10 (for now). Finally, the code is still a pretty big black box to us, so we will continue delving into how it works.

Follow for future updates!

[greyaycock]

Progress Update 2-07-24

Summary

Some great progress has been made since our last update! Recently, we were focused on connecting our dev board to the Golioth cloud so we could see our logs on the Golioth Dashboard. We also set up the bluetooth side of the system to scan for all nearby BLE devices, and then filtered for only the ones we were interested in. Combining these together, we were able to see the presence (or lack thereof) of one of our other BLE boards on the Golioth dashboard.

LTE Communication

It turns out that connecting to the internet is really easy using the Golioth SDK. In fact, it’s mostly all abstracted away and you don’t even have to manually do any work with the LTE modules on the hardware we are using (as far as we can tell). Because of this, we scrapped our last repo, which was built on an nRF Cloud sample, and just went ahead and built the base ‘hello’ sample from Golioth. To do this while still using Nordic Tools in the nRF for VSCode workspace, we followed these steps:

1. Create a new directory close to C drive. We did it within Desktop/Projects/Golioth, but even that is pretty risky as some of the build folders approach the 250 character file path limit.
2. Create a west workspace, using the Golioth repo as the west manifest repo. Open a terminal and navigate to the folder you just created. Call the command:

west init -m https://github.com/golioth/golioth-firmware-sdk.git --mf west-ncs.yml

3. Update west workspace.

west update

4. Update all submodules.

cd modules/lib/golioth-firmware-sdk && git submodule update --init --recursive

5. Bring the hello sample into this directory.
6. One final step before testing that our workspace can link all of the SDKs properly is to add our Golioth credentials to the prj.cfg (project config) file. At the end, append the lines:

CONFIG_GOLIOTH_SAMPLE_PSK_ID=“your_psk_id”

CONFIG_GOLIOTH_SAMPLE_PSK=“your_psk”

These steps were found in the newest Golioth SDK repo, in the examples/zephyr README.

To build, the nRF Connect interface for building and creating build configurations was a little iffy at times. More experimentation is needed here. In the meantime, we instead used

west build -p always -b nrf9160dk_nrf9160_ns

With that setup done, we could successfully see the “hello” message being logged on the Golioth Dashboard (which has its own, well documented setup).

BLE Communication

With the LTE side of the board taken care of, we now had to add in the bluetooth capability. This was done by adding 2 files to this application, a ble.c file and its header. In this file, the bluetooth modules were initialized and a callback function was set to log the address of any discovered device while scanning. Of course, we didn’t want to log every device in the room, just the “peripheral” device that we wanted to track, which in this case was another nRF DK. To accomplish this filtering, we obtained the BLE address of the peripheral and added it to the peripheral accept list on the central, which is essentially a filter for BLE addresses. We also needed to update the board and project config files to use BLE, and inform CMake of our new target source, ble.c. Finally, the 9160 needed a ble host controller to operate in the way we are using it, so the 52840 on the 9160DK was programmed with the hci_lpuart sample from Nordic, which communicates with the 9160 via a UART interface.

In short, this code built on 4 samples from Nordic’s SDK: hci_lpuart for the 52840, a combination of ble_lte_bridge and ble_observer for the bluetooth part of the 9160 code, and the ble_beacon sample for testing with a known beacon device.

Issues / Learning Points

There were many roadblocks while trying to get this to work, but they all more or less revolved around a few common issues. We acknowledge that most of this is just inexperience, but maybe in the future this will be useful to others

1. Use west, not Git. Getting all of the SDKs to work together (Nordic, Zephyr, Golioth) is best done by using the proper west manifest file, within a west workspace. Do that early to avoid headaches.
2. Work on everything as close to the root directory as possible. It wasn’t obvious that this was the cause of build failures, but at one point none of the applications were building because the file path was too long.
3. Sometimes a pristine build helps. At a few points, our errors were remedied by just running a pristine build.

Next Steps

We would like to review this plan with Chris before moving on, but we intend to organize this code and make it more portable. There are two of us, and cloning the code within different west workspaces requires some magic that we don’t really understand yet. Then we would like to test with multiple peripheral devices. We expect this to work well, but it still needs to be tested. Finally, we should start thinking about moving this application onto custom hardware, which is a beast we have yet to tackle in understanding. Any tips, resources, or advice is always welcome on any part of the project!