BoSL Board nRF9161

This is a temporary page to discuss an upgraded version of the BoSLboard where the AVR/SIM7000 stack is replaced with a nRF9161.

The nRF9161 is an evolution of the nRF9160 and its main advantage for our applications is the ability to perform PSM on roaming networks [1]

In terms of loading applications onto this new board. It seems possible to use MCUboot to upload new firmwares over UART [2][3][4]. Though the specifics, I am not yet sure of.

Flowing this guide [5] has been very useful. With it I have been able to update the firmware on the nRF9160, though the last step about confirming the image is throwing an error so I am unable to keep the updated firmware after reset. This seems like a small hurdle however and I am happy that I have been able to load a new program via UART.

2024 November 7

One problem to deal with is that the nRF9161 has only 4 unified SPI/I2C/UART ports, 3 of which are needed for the SDHC card, RTC, and external programming. This leaves one UART for talking with external sensors. To provide more we will need to lean on UART expanders which multiplex one SPI port into several UART ports. A nifty part I found for this is the SC16IS752, this breaks one SPI into two UART which can either operate in RS232 or RS485 mode! It has great low power performance too.

2024 November 29

A stretch goal for the design of the BoSLboard is to robustify the power input. Specifically, we are looking for the following capabilities:

1. Solar battery charging (via CN3083?)
2. 5V output for SDI-12
3. high voltage input support (> 12 V)
4. maintain low quiescent current ( < 100 µA req., < 10 µA ideal)

Browsing available components it seem that compatibility for both Liion inputs and higher voltage battery will involve very complicated circuitry (read expensive) and perhaps not achieve the low quiescent current target. I therefore feel that permitting a high voltage inputs via a secondary power input would be the best solution. For the high power input, we would drop the quiescent current restriction as presumably the high voltage battery will have quite a large capacity.

Looking at available power management IC, an interesting component is the nPM1300. This combines battery charging, an o-ring circuit, a battery fuel gauge, and a WDT (replacing the need for the ATtiny), into one package. The only weaknesses are that it doesn't have a 5V output (only an unregulated VSYS = max(VBUS, VBAT)) and the VBUS input cannot handle a 12 V input. These issues however can be solved with a 5V buck/boost converter on the output and a 12 V -> 5 V buck converter on the input side.

To enable solar panel charging, we can connect the solar panel directly to VSYS, if the input buck convert has reverse current protection then everything should be fine, we would just need to check that putting current backwards through a solar panel does not harm it (it shouldn't, its a diode, but always better to double check).

2025 March 14

The new BoSLboard has arrived. Its time to start testing! Herein I will document the testing regime.

power

for this first set of tests I plugged in a 3.7 V li-ion battery and measured the voltage at the various power outputs

[ ] VBAT board power on 
    [X] 3.3 V OK
    [ ] 5.0 V OK
    [X] VPP == VBAT OK
    [X] VHV == 0 V

[ ] PMC
    [ ] battery charging
    [ ] I2C configuration
    [ ] WDT OK

[ ] fuses
    [ ] work
    [ ] fuse test LEDS

[ ] battery charge (HV and LV)

[ ] I2C isolation

nRF9161

powering up with the battery input and connecting the segger debugger the nRF9161 could be connected to via SWD. This is great as it indicates that the nRF9161 is powered and working. The next I used the nRF programmer gui utility to program modem firmware v2.0.1 [6] as this was compatible [7] with the nRF-sdk version I installed (v2.5.2). I then build the `/nrf/samples/cellular/at_client/` sample using the `nrf9161dk_nrf9161_ns` board as I have not yet made a custom board for this BoSLboard hardware. Following these steps I was able to flash both the modem and application firmware. After re-configuring the project to use SEGGER RTT as the terminal output I could confirm that the application was indeed running, however I ran into difficulties attempting to send and receive AT commands - investigation ongoing. This is because the nrf9161dk board expects a uart passthrough non existant on our board. To proceed futher we will need to make a custom board which maps the default uart through the USB-TTL converter.

[X] SWD OK
[X] modem firmware flashable
[X] application firmware flashable
[X] hello world
[ ] GNSS OK
[ ] SIM  OK
[ ] cell OK
[ ] RST button OK
[ ] DFU button OK

[ ] USB-uart programming

peripherals

[ ] SHDC
[ ] RTC
   [ ] RTC battery
[ ] RS485
[ ] GPIO
[ ] GPIO extender
[ ] SDI-12
   [ ] level shifting
[ ] ADC
[ ] USB UART
[ ] status LEDs
[ ] power switches
  [ ] I2C isolation

power use

[ ] sleep current
[ ] idle current
[ ] on current
[ ] ...