Progress Update 2-07-24
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.
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:
- 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.
- 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 GitHub - golioth/golioth-firmware-sdk: Firmware SDK enabling any IoT device to connect to Golioth - the Universal Connector for IoT --mf west-ncs.yml
- Update west workspace.
- Update all submodules.
cd modules/lib/golioth-firmware-sdk && git submodule update --init --recursive
- Bring the hello sample into this directory.
- 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:
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).
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
- 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.
- 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.
- Sometimes a pristine build helps. At a few points, our errors were remedied by just running a pristine build.
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 workpaces 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!