Also if you insert USB or send a pulse on the EN pin it will also turn on.
nRF9160 Feather - Suggestions for next version
6 days later
jaredwolff
Do you have pull-up resistors on the Qwiic I2C? If not, it would be good to have them. Thanks.
zpm1066 yup! 20k
jaredwolff Great! Thanks.
5 days later
Hey all
I’ll be assembling Proto 3 boards this week and I’d like you to give them a go. They should work nicely on the 2.7.x branch of nfed and the latest Zephyr Tools plugin. If you have time to try one in the immediate future, let me know and we can coordinate outside the thread.
- Edited
Hi Jared,
I guess, it’s easier to ship the new boards within the U.S. than to ship them to Europe ;-).
Let’s see, which feedback your call gets.
My own app is still on NCS 2.6.1 and starts supporting the nRF9161-DK. Not sure, if that would also be a setup for testing the new feather. Update my app to 2.7.0 is planed, but for now without timeline.
AchimKraus I guess, it’s easier to ship the new boards within the U.S. than to ship them to Europe ;-).
It is but not impossible. I can send it as a sample so it can result in lower/no VAT for you. 
AchimKraus My own app is still on NCS 2.6.1 and starts supporting the nRF9161-DK. Not sure, if that would also be a setup for testing the new feather. Update my app to 2.7.0 is planed, but for now without timeline.
I did build out the board definition for 2.6.1 as well. I may have to sync it with the 2.7.x branch.
OK. To make it easier:
I will order/buy 3 feathers as usual in your shop, you send me 2x feather v6 and 1x new feather nRF9161.
No need to handle it special as sample or so from my side, the costs are not that high.
Would that be OK for you?
That’s OK with me!
Use the code NRF9161 for some $ off as a thank you. Everyone else in the thread is also welcome to use the same. I’ll likely have them fully assembled and tested by tomorrow. I’ll also throw in the antenna I’ve been testing with that is specifically designed to work with GPS + LTE.
Jared
Ordered ;-).
7 days later
jaredwolff Hi Jared.
I should be able to assist in testing the new nRF9161 Feather. I did install NCS 2.7.x a few weeks ago and have moved some of my CLI projects to Zephyr 3.7, although I did have to fix a couple of SSD1306 driver bugs. Also, ended up updating ST7789 displays because of the new MIPI Display Bus Interface (DBI) support in Zephyr 3.7. Anyway, it’s worth updating projects to Zephyr 3.7.x LTS.
Btw - What debug probe firmware did you end up using on the RP2040 interface MCU?
I’ll drop you an email later today. Thanks.
zpm1066 Btw - What debug probe firmware did you end up using on the RP2040 interface MCU?
For now the standard one that the RPi foundation developed. The Probe-rs version, though excitingly developed in Rust, doesn’t have all the features yet to make it a viable option.
- Edited
Update!
So I ran into some interesting issues over the past week. I wanted to share some of them with you guys as I’m going.
Board Quiescent Current
When I first went over the quiescent current measurements, I was pleased with the results. I went to revisit on some of the newer boards I have here and something was wrong. I was getting anywhere between 10-120uA which is not great!
It’s difficult to isolate the exact cause with a fully assembled board so I built a one-side board for nPM1300 validation.
While their power supply chip does seem fairly robust, it seems there are some bugs around the usage of I2C. I was able to play with it more last night and got about 1uA which includes the Iq for the nPM1300 with one buck running along with the LIS2DH12 in deep sleep (typical 0.5uA)
I’m going to build another one today to confirm I can get the same results. Then attempt to assemble the other side. Assembling the module is tricky especially when hand applying solder paste. I threw together some jigs to make that process easier.
I do need to adjust this guy a bit to raise the PCB higher. Also will be adding some mounting holes so I can put one on the bed of the pick and place.
En pin operation
I was able to validate the EN pin which is hooked up to the SHPHLD pin on the nPM1300. This allows you to completely sleep the device and wake it up by pulling EN to ground for 96ms or plugging in USB. It was < 400nA which was great.
Other open items
- Get the board as low current as possible. More on this today.
- I have seen one issue so far when “recovering” the device when switching off buck2 for power saving purposes. This keeps the RP2040 powered off so it can be used to program the nRF9161. Usually you can hold the RST button and program (default power on is with both buck converters). This prevents the nRF9161, if programmed to do so, from turning off buck 2 which powers the RP2040.
- Confirm the new QWIIC works as expected
- Edited
jaredwolff
The solder paste application by hand is certainly tricky. You should do a short video at some stage to share the process of assembling the board.
@zpm1066 sure is. Two boards I built today program and blink. Still more to test though.
A video would be interesting. Stay tuned on that
As I alluded to earlier in the last post, a solution was needed to make sure the programmer is available even if you program something terribly bad to the board. In comes the recovery fixture:
Recovery Fixture
Currently, I was soldering wires to the SWD + GND pins on these boards to get direct programming access when the onboard programmer was inaccessible. I spent some time this morning creating a simple jig for recovering & programming any nRF916x Feather.
Here I have it powered up and running with an external PicoProbe.
Part Deux
While having a 3d printable fixture is handy, ultimately something in the firmware has to change. So, I changed the startup code that is built-in to the board definition to add a delay. This allows you to unplug, and then power on and access the onboard CMSIS DAP before the board shuts down the RP2040 circuit. I had removed this delay and that’s what got me into this whole sidequest in the first place.
Onwards
Alright. Now that’s out of the way back to validating these quiescent current issues!
Awesome updates Jared! Thank you for all the hard work!! I look forward to testing it when you feel ready! 
To be frank:
One of the most repeated critical point of the old design was the TC2030-CTX-NL instead of a 10 pin header.
Now it turns into something else, you even can’t buy, or? Let’s see, which feedback that gets in the future.
- Edited
jaredwolff Nice work!
After using the solder paste on the stencil, did you use a digital microscope and a fine hot air gun to assist with soldering the SMDs?
AchimKraus One of the most repeated critical point of the old design was the TC2030-CTX-NL instead of a 10 pin header.
Now it turns into something else, you even can’t buy, or? Let’s see, which feedback that gets in the future.
@AchimKraus what can’t you buy? I’ll likely open source and make this little jig available for customers to buy as well if there’s interest. It’s definitely handy for programming many boards but not required.
Overall, the idea is to avoid this since the onboard RP2040 does everything that you’d expect (except for RTT). Since there’s a dedicated console UART I figured that final point wasn’t a big deal.
I do appreciate your feedback about the 10 pin. It simply doesn’t fit on this design and is 4x the cost of the RP2040 circuit. As you alluded, we’ll see how it goes.
zpm1066 After using the solder paste on the stencil, did you use a digital microscope and a fine hot air gun to assist with soldering the SMDs?
I do have a microscope (analog one I bought a looooong time ago) for inspection. But I do use a small reflow oven and appropriate ventilation equipment. Previously I was using one of those plug-in skillets but that got old fast (and don’t work for both sides!)
JeppeMariagerLam Awesome updates Jared! Thank you for all the hard work!! I look forward to testing it when you feel ready!
Thanks Jeppe