Hi Jared,

Any chance you can share what new changes you have in mind for the next iteration of nRF9160 Feather?

Although I do understand that board space is at a premium, I think you may be able to squeeze in a couple of enhancements.

Here are a few suggestions for your consideration.

eSIM or SoftSIM (retain the physical SIM)

  • eSIM would be great for remote provisioning
  • Nordic Semi / Onomondo’s SoftSIM for the nRF9160 looks intriguing and certainly worth an evaluation.
  • Btw Onomondo claim approx. 40uA savings

SWD 10-pin mini version

  • I know we have the Tag Connect but the 10-pin mini SWD is so much more convenient, far less cumbersome to use and highly inexpensive.
  • Working with dev boards & Tag Connect tends to be quite a challenge, with frustration at times.

Fuel Gauge

  • For a low power battery operated use cases, fuel gauge capability is very useful.
  • MAX1704X (like in Particle Boron) are pretty compact at 2mm x 3mm and low-cost
  • LC709203F in even smaller package

    eSIM

    I also like that.

    Btw Onomondo claim approx. 40uA savings

    For eDRX, which then comes anyway with higher energy consumption, when the receiver is enabled more frequently. In my experience, a common SIM in eDRX takes about 25µA (measured at the battery), I guess the 40µA are at 1.8V. Anyway, a SoftSIM, if it gets available also for small projects, would be great and would obsolete the eSIM.

    10-pin mini SWD

    With my last experience (nRF Connect for Desktop / Programmer), the point with the Tag Connect is, that it’s usually only connected for a short time. But that programmer tool needs to connect it when starting the app. A mini SWD would make that easier.

    Fuel Gauge

    In my experience, such a fuel gauge (e.g. Thingy:91) has some advantages over the battery voltage, especially the values have less noise. BUT it is also fixes somehow the battery type. If you want to run e.g. a low-self-discarge NiMh, then it may not be possible to adapt the setting for that. So my favorite would be to connect the nRF9160 direct to the battery and use AT%XVBAT. The downside would be, that the max. battery voltage will be only 5.5V instead of the 6.5V. To build a soft gauge with that requires that you record some usage voltage charts for your setup (I’m used to do that with enable GPS and send the battery voltage to the cloud every 10 mim). That chart will then be the base for a linear approximation in segments. That’s also the idea for the current approach with the ADC for the battery.

    (By the way, the current documentation mention 3v as minimum. In my experience, the minimum for that buck is 3.3V from the battery.)

    jaredwolff
    Depending on the components availability and changes may have already mapped, Are you looking at a new iteration of the nRF9160 Feather sometime this year or 1H2024?

        The design is on v5. I’d like to stabilize it for a bit unless there’s a big reason to change (for my sanity)

        I may consider an eSIM version but there are so many different eSIM variants it’s tough so have just one model.

          I considered just some pads to mount my own eSIM.

            a month later

            jaredwolff
            Hi Jared,
            I’m sure you’ve read the news on the new nRF9161 and the smaller nRF9131 package. These new additions to the nRF91xx line open some new intriguing opportunities for board designers.

            I hope you’re considering both and possibly adding a new nRF931 board. The latter would give a fair additional amount of board real estate to add new components to your future nRF91xx board(s), like a mini 10 pin SWD, eSIM, etc.

            Certainly great times ahead for designers and customers using Nordic Semi SoCs. I’m certainly looking forward to see what you and some of the other nRF91xx Feather board designers come up with in the coming year.

              9 months later

              Hi Jared,
              Any plans to upgrade the nRF9160 Feather to a nRF9161 with a few additions like a nPM1300, soft SIM, and a mini SWD connector?

              Anyway, looking forward to see how you’ll leverage the new Nordic SoCs for your next gen Feather board. Perhaps similar to nRF9131 EK but Feather format.

              21 days later

              Here’s a little preview @zpm1066 @AchimKraus

              Improvements

              • Built-in programmer/debugger/console access
              • Smart power management and battery charging with nPM1300
              • Control of RP2040 power for advanced users
              • All GPIOs are dedicated now (no sharing with other features)
              • Footprint for eSIM
              • SIM connector relocated for easier use
              • Programming connection for RP2040
              • Single antenna operation
              • RGB led

                jaredwolff
                Hi Jared, Thank you for sharing a preview. Looks very impressive! Fantastic enhancements. I’m pleasantly surprised to see RP2040 being incorporated.

                It’s going to be an awesome update. Looking forward to seeing more!

                  Will it be equipped with the new nRF9161 variant?

                  Built-in programmer/debugger/console access

                  Does this refer to the USB serial?

                  Control of RP2040 power for advanced users

                  I’m not common to the RP2040 and a short look at the spec didn’t help me too much. For me, the nRF9160/61/zephyr is a platform, which is robust and OK to develop software for. The quiescent power consumption of the feather v5 is simply the “best in class” and I’m not sure, what the consequences of a RP2040 will be on that aspect. And building systems on two MCU isn’t too easy. I don’t know, if there is so many software for the RP2040 that’s worth to consider that.
                  And if I would consider to use a RP2040, I guess it will be a SparkFun RP2040 mikroBUS Development Board with an LTE IoT 4 Click / nRF9160 and cut of the LED on the Mikro-Click.

                  All GPIOs are dedicated now (no sharing with other features)

                  I guess this is related to the feather’s GPIO, not the SOC, right?

                  Single antenna operation

                  OK. (I mainly do not use GPS, so it’s no difference for me).

                  RGB led

                  That’s something, I will enjoy.

                  Maybe, you consider also to connect some GPIO to the COEX interface? Some internal GPIO not used by the feather. the idea is to detect “radio activity” even when the app is not aware of that (HPPLMN search e.g.).

                    AchimKraus
                    Re RP2040 - If I’m not mistaken, the RP2040 is intended to be used as a debug probe running standard CMSIS-DAP debug and UART interfaces over USB. Probably a modified version of the open-source Raspberry Pi DebugProbe firmware. Currently lacks RTT support but debug probe works well on the Picos.

                    The RP2040 is a pretty inexpensive and a powerful SoC with programmable I/O (PIO) that can execute code independently of the Cortex-MO+. The PIO opens the door to a whole host of applications that manipulate IO and transfer data, essentially it can be used to emulate different peripherals and communication protocols (e.g. CAN) independent of the RP2040’s ARM core. The RP2040 is pretty well supported by Zephyr RTOS.

                    Re RGB led - A pretty useful addition. I hope the RGB led is individually GPIO addressable and isn’t a WS2812 led.

                        To be frank: I also don’t want to “waste my time” with replacing the segger jlink ;-).

                          AchimKraus
                          I can understand where you’re coming from. I use the Segger J-link & RTT all the time with nRF/Pico/STM32 devices with the SWD 10 pin connectors. If there’s no space for a Min SWD connector, an onboard RP2040 hardware debug probe is preferable to a Tag Connect.

                              zpm1066 Re RP2040 - If I’m not mistaken, the RP2040 is intended to be used as a debug probe running standard CMSIS-DAP debug and UART interfaces over USB. Probably a modified version of the open-source Raspberry Pi DebugProbe firmware. Currently lacks RTT support but debug probe works well on the Picos.

                              Correct! It will either use the pico probe firmware or probe-rs. More testing required though.

                              zpm1066 Re RGB led - A pretty useful addition. I hope the RGB led is individually GPIO addressable and isn’t a WS2812 led.

                              It’s controlled by the LED drivers on the nPM1300. Each one is individually controlled via I2C

                                    zpm1066 If there’s no space for a Min SWD connector, an onboard RP2040 hardware debug probe is preferable to a Tag Connect.

                                    If the RP2040 is removed, there will be space ;-).

                                    I guess the question is more, will the new feather be a “complete DK with debugger”. I’m not sure, if that will be the right way. The new nRF9161-DK comes at an even lower price than the nRF9160-DK. Both comes with a well working software stack.

                                    My interest in the feather is to have a device close to a “productive device” (at least a good prototype), not a “development kit”. I’m only one user, if more feel well with a DK, then I guess it will go that way. If others are also don’t consider a DK as too useful, then I would recommend not to go that way.

                                    What’s about the other additional functions? Extra flash? Accelerometer?

                                        @AchimKraus you’re more of a power user. Many of my customers have complained about the fact that they have to buy a proprietary cable and programmer. You can still program via the SWD pins on the bottom of the board but that would require a programming fixture.

                                        AchimKraus What’s about the other additional functions? Extra flash? Accelerometer?

                                        Same flash as before (32Mbit) and same accelerometer. Trying to keep feature parity with the nRF9160. I did remove the RTC though since the nRF916x can maintain the time (as long as it’s not rebooted of course!)

                                            Alternatively, I can change the 3pin SWD connector to connect to the nRF9161 instead making the RP2040 only updatable over USB bootloader.

                                              jaredwolff Yes, adding a SWD connection to the nRF9161 sounds good.

                                              I know it’ll increase the cost but how about adding a BME680? It opens the door to a quite a few other use cases for customers, including embedded machine learning.

                                              I guess, one of the reason for the RP2040 selection was the availability of an open-source DebugProbe firmware vs. licensing Segger J-Link OB firmware running on nRF52840 or nRF5340. Plus the open-source option allows future enhancements.

                                                  Terms and Conditions | Privacy Policy