nRF9160 Feather - Suggestions for next version

zpm1066 · 2023-05-17T02:51:26+00:00

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 i...

jaredwolff

zpm1066 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.

This has something other customers have asked for in the past. I’d consider it but it may push the cost way to far to make the project sustainable.

zpm1066

jaredwolff Thanks. A BME280 at half the cost of a BME680 may be worth a consideration.

I use the BME688 in Thingy:53 and Adafruit BME688 breakout for prototyping; and BME688/nRF52840Dongles in a Thread network. In addition to BME680 features, the BME688 has a gas scanner function for ML. BME688 costs ~$7 per 100, about the same price as a BME680; and BME280 is ~$4 per 100. Personally, I’d pay the extra and go for the BME688.

AchimKraus 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.

I didn’t realize that nRF9161-DK is considerably lower in price than a nRF9160-DK. A quick check on mouser.com shows nRF9161-DK ~$99 vs. nRF9160-DK $155.

It’ll be interesting how Nordic will price the upcoming Thingy 91:X (nRF9151, nPM1300, nRF5340, nRF7002, nPM6001, and same sensors as Thingy:53) and nRF9131-EK (nRF9131, nPM1300, Segger J-Link OB Programmer/debugger). Both of these offerings will be excellent for prototyping.

I would use the nRF9161 Feather boards as deployment devices with easier development accessibility, either a Mini SWD 10-pin connector or the proposed design.

AchimKraus

In my experience of the past years:

you will get troubles developing a cellular application, if you not only run demos.
in trouble you need the Nordic Forum and the first question back is, “Please provide a modem trace”
it’s also easier to solve trouble, if that could be reproduced with Nordic equipment

All that, and the new price of the nRF9161-DK, ends up in my conclusion, that a developer will have such a nRF9161-DK. Those who only use demos and slightly modify them will be happy with the USB bootloader.

The Thingy is nice, I also use a couple of them. But once you need your own sensor, or other batteries or antenna, then the nRF9160 feather is still the best in class.

zpm1066 I would use the nRF9161 Feather boards as deployment devices with easier development accessibility, either a Mini SWD 10-pin connector or the proposed design.

That is exactly also my usage. For example the Mobile BeeHive Scale is built with an nRF9160 feather, a Thingy:91 is missing expandability and a DK is just to large in size.

zpm1066

AchimKraus The Thingy is nice, I also use a couple of them. But once you need your own sensor, or other batteries or antenna, then the nRF9160 feather is still the best in class.

In the few Thingy:91X perspective photos shared from MWC Barcelona 2024 and the recent Embedded World exhibitions, it looks like Thingy:91X may be supporting an EB (Expansion Board) like Thingy:53. If so, then we may get I2C, SPI and several GPIOS for sensors and peripherals. It definitely has an I2C STEMMA connector, plus holes for ‘charge led’ & ‘led2’ above the USB-C and STEMMA connectors. As yet, I don’t see an “edge_connector” defined in the thingy91x devicetree in NCS v2.6.0/nrf/boards/arm. Thingy:91X release was suppose to be in Q1 but looks like it’ll be in Q2, so perhaps work in progress.

zpm1066

AchimKraus That is exactly also my usage. For example the Mobile BeeHive Scale is built with an nRF9160 feather, a Thingy:91 is missing expandability and a DK is just to large in size.

For LTE, I’ve been using Particle Boron Feather boards with nRF52840 / UBlox SARA modem, though these are not low power like the nRF91xx. I’ve been pretty satisfied with their Borons. BTW - Their EOL Xenons (nRF52840) make excellent Zephyr dev boards. A few online places still have old stock.

I haven’t come across any nRF9160 boards in a Feather format that satisfy my requirements in terms of a SWD 10-pin J-Link connector for ease programming/debugging. I was planning on designing my own nRF91xx Feather but thought I’ll check what Jared’s plans are going forward for the next iteration of his board. Why re-invent! Hence, the reason for starting off this topic last year.

However, Jared’s proposed design for a nRF91xx Feather checks off several asks - nPM1300, SWD Programmer/Debugger, and eSim. So, I definitely hope to use these nRF91xx Feathers for future deployments and development.

zpm1066

AchimKraus Thingy:91 is missing expandability and a DK is just to large in size.

Recently Nordic Semi has been making a few changes to the Thingy91:X devicetree files, e.g. added support for the expansion board and other misc changes. I don’t see an “edge_conenctor” defined in the "“thingy91x_nrf9151” devicetree yet like in nRF5340. Somewhat slow progress at the moment, perhaps there are delays in nRF9151 availability.

I expect the Thingy91:X Expansion Board will be the same spec as that in the Thingy:53 (nRF5340) or an enhanced version with backward compatibility. The nRF7002-EB WiFi 6 ( I use several with Thingy:53 and nRF52840 boards) should work with the Thingy:91X. With I2C (EB and I2C STEMMA), SPI and several GPIOs, the Thingy:91X should be pretty expandable for sensors and peripherals.

Originally, both the Thingy91:X and nRF9131-EK were planned for Q1 release. Hopefully we’ll see a Q3 release.

zpm1066

jaredwolff
Is there any reason why you wouldn’t want to use the nRF9151 over nRF9161 other than perhaps pin compatibility with nRF9160?

From the specs, nRF9151 looks to be identical to a nRF9161 with the addition Power Class 5 20dBm and , of course, a smaller packaging. What advantages does nRF9161 provide over nRF9151?

jaredwolff

zpm1066 Is there any reason why you wouldn’t want to use the nRF9151 over nRF9161 other than perhaps pin compatibility with nRF9160?

They are actually not exactly pin compatible and does require a footprint change.

From the specs, nRF9151 looks to be identical to a nRF9161 with the addition Power Class 5 20dBm and , of course, a smaller packaging. What advantages does nRF9161 provide over nRF9151?

It’s available now vs waiting a while for the nRF9151. I do have an idea for the nRF9151 since it allows for more room. There’s still time to switch but I’m limited by when Nordic can deliver.

AchimKraus

Thingy:91X

If it gets extendable, that will be nice. Exchanging the battery and antenna has also some benefit, so at least I will continue to use feathers for prototypes and the thingy:91 mainly as “network discover and tester”.

AchimKraus

I’m only interested in real low power devices. Leave the other stuff for the MQTT folks ;-)
I guess Jared remembers, that before I ordered the first feathers I asked him in a private e-mail, if the feather really goes down to 10µA (because the Thingy:91 before v1.6 was more about 35-40µA and only, if you disable the 3V in deep sleep).

A “low power device” (beside of a lot of marketing plurr, the nRF9160 is the only kid) accompanied by a “low power protocol” (CoAP/DTLS 1.2 CID) enables to build battery solutions and makes such devices much more independent.
E.g. the Mobile BeeHive Scale runs from 3xAA 2000mAh (LSD) more than a year in the “wild” (in theory even 2 years ;-) ).

zpm1066

jaredwolff It’s available now vs waiting a while for the nRF9151. I do have an idea for the nRF9151 since it allows for more room. There’s still time to switch but I’m limited by when Nordic can deliver.

I suspect nRF9151 availability may be closer to Q3. Probably similar for the nRF54xx as well.

Btw - Have you considered doing a Feather board with nRF7002 with either nRF54L15 or nRF54H20?

AchimKraus

In the meantime I got it, that the RP2040 will be used as USB bridge, and though on the board, maybe for swd. For the USB bridge it would be great to have two channels, that makes getting trace easier. I guess, there are then drivers for such an USB bridge, for Ubuntu and Windows? Mac?
About the swd: The thingy:91 has a switch to select the target. Maybe that’s also an idea.

jaredwolff

@AchimKraus @zpm1066

I need your input!

Your thoughts on preferred VDDIO? The options are 3.3V or 1.8V. I could go either way right now. There would be longer term savings if 1.8V is used. Depends on the application though.

zpm1066

jaredwolff
Hi Jared,
Like the majority of the “makers”, nearly all the sensors I use are 3.3V. However, for the longer term, I think it’s worth having a configurable 1.8-3.3V VDDIO if not much additional effort.

Are you planning on driving the RP2040 at 3.3V or in addition also thinking of using 1.8V, as RP2040 does support multiple power options?

Will there be an option to shutdown RP2040 if nRF9161 is in a sleep mode?
Any plans to bring out any of the GPIOs from the RP2040 to the Feather pins?

jaredwolff

And a little preview. 😉

AchimKraus

Hi Jared,

as for now, in my opinion, 3.3V helps the “makers”. Quite a lot of sensor boards are for 3.3V (or 5v). To craft the first 100 devices will benefit from 3.3V in my opinion. I consider, that in the most cases, it’s decided with that 100 to either build a product or not. So for me, 3.3V is preferred.

The other idea would be to connect the “battery” direct to the modem and make VDDIO “configurable”. That depends on the other ICs on the board, if that works. And for me, it’s not that important.

AchimKraus

nRF9160 feather v5, 400days

Just for those, who are interested; that’s a nRF9160 feather v5, running from a 2000mAh LiPo for about a year. Exchanging a message with encryption over CoAP/DTLS 1-2 CID.

jaredwolff

@AchimKraus thank you for sharing!! The chart is also fantastic.

JeppeMariagerLam

I’m still a bit of a noob compared to Achim and zpm, but my view is that you should keep it to 3.3v - Even if there would be powersavings by going to 1.8v, it it already so low that pushing it even more wont really matter, but as you also state, the hurdles to newcomers might be significant since a lot of other stuff out there needs 3.3v.

We use GPS on some of our things, but I did find it a bit odd that it was included by default rather than being an “addon” initially.

RGB LED is no doubt a great addition, and i’m looking forward to eSim!

jaredwolff

Thank you @JeppeMariagerLam for your feedback 😎

JeppeMariagerLam We use GPS on some of our things, but I did find it a bit odd that it was included by default rather than being an “addon” initially.

Can you elaborate more here? I’m not sure what you mean. The fact that you needed a separate antenna?

JeppeMariagerLam

jaredwolff yes, we have an external antenna, for example mounted on the top of a car rather than inside the steel box where the unit is connected to power.

jaredwolff

@zpm1066 thank you for the amazing feedback! 😄

zpm1066 Like the majority of the “makers”, nearly all the sensors I use are 3.3V. However, for the longer term, I think it’s worth having a configurable 1.8-3.3V VDDIO if not much additional effort.

It is possible actually with the nPM1300. The only part that wouldn’t work is the onboard NOR flash. It does not support such a wide voltage range. They have 1.8V variants and 3.3V variants. My thoughts would be to go with the 3.3V version and if any flash writes need to occur the buck needs to be placed into 3.3V mode. Testing is still necessary since I’m not sure how the flash would handle 1.8V. If it ends up leaking tons of current that would put the kibosh on it right there.

zpm1066 Are you planning on driving the RP2040 at 3.3V or in addition also thinking of using 1.8V, as RP2040 does support multiple power options?

Right now, thanks to all the feedback thus far, the plan is to run it at 3.3V. It does have a separate VDDIO pin which allows for running the IO at 1.8V. It does require 3.3V for USB (which is critical for this board!) on the other power supply pins no matter what.

zpm1066 Will there be an option to shutdown RP2040 if nRF9161 is in a sleep mode?

Good questions. It’s the reason why I’m asking you guys your preferences on IO voltages. 😇 By default it’s on on a cold boot but then is configurable in software to be shutdown when not in use. Both buck converters actually can be configured in “retention mode” which lowers the rail voltages when in a sleep mode (very neat).

zpm1066 Any plans to bring out any of the GPIOs from the RP2040 to the Feather pins?

No plans since it’s mostly meant to be a programming IC. All the GPIOs are going directly to the nRF9161.

« Previous Page Next Page »