Most reliable "best" radio
-
I never realized you can send/receive BLE data using an nRF24L01:
use NRF as a BLE Module | Arduino NRF24L01 Bluetooth Low Energy Tutorial – 12:17
— electronic GURUUnrelated to that,I found a nice introductory tutorial series on then nRF52:
https://www.youtube.com/c/SumairsEmbeddedEngineering/videosMost of the nRF52 stuff on youtube only considers either just the hardware or just the bluetooth aspects, but this series covers much more than just that. Lately Nordic's development has embraced the Zephyr RTOS, but this youtube series does not rely on Zephyr, which may (?) be good if you want tight control over the hardware without the overhead of an RTOS.
-
@NeverDie said in Most reliable "best" radio:
@alphaHotel said in Most reliable "best" radio:
@NeverDie With the first version of the battery/MCU board, you lamented running traces directly under the batteries. You have the space now to re-route them but choose not to. Did you find a way to resolve the issue it caused?
Actually, I fixed it on the new version (pictured above). The red traces run on top, so they're adequately isolated from the battery holder metal, which is on the back side except for the through-holes where it sticks through the board. Where I ran into trouble was running traces on the back side, beneath the battery holder metal. If the battery holder metal was pressed up hard against the board, some shorts resulted on some of the boards. The workaround was to not press the battery holder metal hard up against the board, but the new version removes that concern entirely.
Okay, I see now. I misunderstood the original issue and also didn't think about the top/bottom side orientation in relation to those traces vis-a-vis the battery holders. Thanks for clarifying.
@alphaHotel said in Most reliable "best" radio:
@NeverDie said in Most reliable "best" radio:
@alphaHotel said in Most reliable "best" radio:
@NeverDie With the first version of the battery/MCU board, you lamented running traces directly under the batteries. You have the space now to re-route them but choose not to. Did you find a way to resolve the issue it caused?
Actually, I fixed it on the new version (pictured above). The red traces run on top, so they're adequately isolated from the battery holder metal, which is on the back side except for the through-holes where it sticks through the board. Where I ran into trouble was running traces on the back side, beneath the battery holder metal. If the battery holder metal was pressed up hard against the board, some shorts resulted on some of the boards. The workaround was to not press the battery holder metal hard up against the board, but the new version removes that concern entirely.
Okay, I see now. I misunderstood the original issue and also didn't think about the top/bottom side orientation in relation to those traces vis-a-vis the battery holders. Thanks for clarifying.
I received the PCB today, and I think I see now the source of your confusion: I had put the silkscreen outline for the battery and its clips on the FRONT instead of on the BACK where it belongs. I'll correct it on the next iteration. On this first iteration I'm mainly just testing for fit and to make sure the space is such that the battery clips don't short against either themselves or against the headers. I'll also be adding polarity markers as a reminder for the correct way to insert the batteries.
-
Here's the first pass on the new version:
The good news:
-
I widened the separation between the batteries, and now the clips aren't at risk of shorting against one another.
-
list itemThe machine pins now sit nice and low against the PCB. The idea is that this way a shield can arch overhead without having to add much to the overall height. That's why I have regular headers on the outside part.
Not so great: as a guard against shorting against the clips, I maybe overcompensated by overwidening the headers as well. I think I can probably narrow the overall board width by 3 to 6mm and still have adequate clearance. I'll do some more iterations until I zero in.
Also, unlike the earlier test platform, this board lacks a way to separate out current measurement to the radio vs to the mcu. Since I already have the test platform for that, I don't think I care, but maybe someone else would want that? It could be added to the backplane, or it could be added to the plug-in modules themselves.
Lastly, I'm noticing that the battery clips fit so tightly against the PCB holes that you probably don't even need to solder them! ;-)
-
-
Here's the first pass on the new version:
The good news:
-
I widened the separation between the batteries, and now the clips aren't at risk of shorting against one another.
-
list itemThe machine pins now sit nice and low against the PCB. The idea is that this way a shield can arch overhead without having to add much to the overall height. That's why I have regular headers on the outside part.
Not so great: as a guard against shorting against the clips, I maybe overcompensated by overwidening the headers as well. I think I can probably narrow the overall board width by 3 to 6mm and still have adequate clearance. I'll do some more iterations until I zero in.
Also, unlike the earlier test platform, this board lacks a way to separate out current measurement to the radio vs to the mcu. Since I already have the test platform for that, I don't think I care, but maybe someone else would want that? It could be added to the backplane, or it could be added to the plug-in modules themselves.
Lastly, I'm noticing that the battery clips fit so tightly against the PCB holes that you probably don't even need to solder them! ;-)
@NeverDie said in Most reliable "best" radio:
I widened the separation between the batteries, and now the clips aren't at risk of shorting against one another.
It's looking good! I'm curious, how far apart are the battery clips now (center-center)? I noted on the original board layout it was 15.62mm. I'm guessing it's about an extra 3mm based on the lines of the silkscreen and the size of the mounting holes you added.
Also, an off-topic question for you - I believe I read in a thread somewhere recently (not sure which one though) that when adding a USB port you prefer USB Mini. Which footprint do you like to use and where do you source them from?
-
-
@NeverDie said in Most reliable "best" radio:
I widened the separation between the batteries, and now the clips aren't at risk of shorting against one another.
It's looking good! I'm curious, how far apart are the battery clips now (center-center)? I noted on the original board layout it was 15.62mm. I'm guessing it's about an extra 3mm based on the lines of the silkscreen and the size of the mounting holes you added.
Also, an off-topic question for you - I believe I read in a thread somewhere recently (not sure which one though) that when adding a USB port you prefer USB Mini. Which footprint do you like to use and where do you source them from?
@alphaHotel said in Most reliable "best" radio:
It's looking good! I'm curious, how far apart are the battery clips now (center-center)?
Most likely it will be either 16.75mm or 17.75mm. 17.75mm is plenty wide. I have some test boards coming at 16.75mm to see if losing 1mm still guarantees adequate separation.
As for which USB connector, it depends on context. If size is not an issue, then lately I'm liking USB-B more than USB-mini. It's the same USB connector commonly found on the classic Arduino Uno. Super robust. I recently sourced 10 of them from mouser: https://www.mouser.com/ProductDetail/490-UJ2-BH-2-TH at close to 50 cents each.
-
@alphaHotel said in Most reliable "best" radio:
It's looking good! I'm curious, how far apart are the battery clips now (center-center)?
Most likely it will be either 16.75mm or 17.75mm. 17.75mm is plenty wide. I have some test boards coming at 16.75mm to see if losing 1mm still guarantees adequate separation.
As for which USB connector, it depends on context. If size is not an issue, then lately I'm liking USB-B more than USB-mini. It's the same USB connector commonly found on the classic Arduino Uno. Super robust. I recently sourced 10 of them from mouser: https://www.mouser.com/ProductDetail/490-UJ2-BH-2-TH at close to 50 cents each.
-
@NeverDie, Thank you.
@alphaHotel The 17.75mm separation is as close as they can get and still use an M3 on the mounting holes. For the 16.75mm boards I have on order, I reduced the mounting holes to M2 sizing.
The long turnaround time when ordering PCB's is a frustration. I should get my cheap CNC PCB etching machine up and working again to resolve these silly dimensioning issues without having to send off to a fab somewhere.
-
@alphaHotel The 17.75mm separation is as close as they can get and still use an M3 on the mounting holes. For the 16.75mm boards I have on order, I reduced the mounting holes to M2 sizing.
The long turnaround time when ordering PCB's is a frustration. I should get my cheap CNC PCB etching machine up and working again to resolve these silly dimensioning issues without having to send off to a fab somewhere.
@NeverDie I thought your turnaround time was decent compared to mine. It has been taking up to 3 weeks for me to get mine from OSHpark. The last fab I ordered, I priced it out at PCBway but they were $29 versus OSHpark's $16. I do find though that within days of sending it off for fabrication, I'm making improvements to the design and kicking myself for placing the order too soon.
-
@NeverDie I thought your turnaround time was decent compared to mine. It has been taking up to 3 weeks for me to get mine from OSHpark. The last fab I ordered, I priced it out at PCBway but they were $29 versus OSHpark's $16. I do find though that within days of sending it off for fabrication, I'm making improvements to the design and kicking myself for placing the order too soon.
@alphaHotel said in Most reliable "best" radio:
I thought your turnaround time was decent compared to mine.
My latest OSH Park order was 9 days inclusive (ordered 6/20/22, delivered on 6/28/22). I find that pretty remarkable. I've read, somewhere, that the timing is at risk of your position in the panel queue; if you are early on the panel, then it is slower. There is a “super swift” service from OSH for a charge. Free-shipping moves faster than I can, so I can wait. The price can't be beat and the quality is great (except for the errors that I make!!!)
@NeverDie
The silkscreen markings for the AA mount posts on your Test Platform V001 are on the right side for me. Mine arrived last week! Sure, the markings are on the reverse side, but once the batteries are installed, that side is invisible. I’m still fretting the moment when I need to solder the Atmega 328P chip.To follow-up on earlier posts: the speed of delivery from China has dramatically improved. Most of the orders I’ve place in early June have arrived. Even the hard-to-get Atmega 328P chips have arrived so I don’t have to desolder my old Nano’s or ProMini’s. And the Chinese packaging is efficient - less trash for my conscience. Digi-Key leaves me wondering how such little can arrive in a box that is so big. But... Digi-Key is so fast.
-
I'm finding that some of the basic UART example programs in Segger Embedded System's IDE no longer even compile for the nRF52-DK without encountering obscure errors that, judging from some youtube videos, didn't exist a year ago. Did Segger fail to maintain their example code during covid? I couldn't get to the bottom of it, so I'm punting on SES and will be switching to gcc, which I hope won't have the same issues. Fingers crossed.Looks as though I'll be sticking with SES a bit longer, because it does contain at least one example shell for the nRF52805, and as long as I can hollow out and fill that shell with bare metal code, then (so far) it all seems to compile and upload and the code works on the nRF52805. At the moment I've confirmed that the bare metal UART code I put together from just the datasheet alone (which has far more ambiguity in it than I remember it having) is now properly working inside the nRF52805, which was (is?) probably the hardest thing to get going, but now that it's in place (for debugging purposes) I feel more comfortable moving ahead like this. One thing I do like about SES is that compared to GCC the compile and upload cycle happens very, very quickly. That alone may not by itself be a deciding factor in what to toolchain to choose, but it is a nice luxury that I truly enjoy.
Next up: getting some bare metal proprietary radio code to work on the nRF52805. Ignoring the PCB antenna, the rest of the module looks as though it is smaller than the size of a dime! I don't yet fully grasp the details of how Nordic crippled it, so I hope I won't be tripping across any nasty gotcha's. ;-) Apparently one of the benefits of the crippling it is that it is more power efficient (as, for instance, it has less memory to retain while sleeping). Compared to its siblings, it has "only" 24KB of RAM and 192K of flash, but that is nonetheless hugely more than what the atmega328p has, so from that perspective it should have more than enough for doing most Arduino-type things. It's biggest cramping limitation seems to be its very small number of GPIO pins (technically 10 pins, but really more like 9 pins since one of the ten pins serves as a RESET pin).
-
I have nRF52805's and nRF52832's talking to one another using the proprietary radio, and I obviously have nRF2401's talking to one another, but getting the two groups to talk to each other? It's not obvious how to do that: Enhanced Shockburst of the nRF24L01 has a weird 9 bit section called PCN in the middle of it, and it's not clear how to get an nRF2 to receive that kind of oddball frame without rejecting it. That said, I think it probably can be done, but it would maybe turn into a long detour that I'd rather not take right now. It turns out there does still exist regular, non-enhanced Shockburst which the nRF24L01 can still use and which doesn't have the oddball 9-bit PCN, but then the maximum transmit speed of an nRF24L01 is limited to 1mbps. That's no good, because I want to use the faster 2mbps, which is almost the entire allure of using Nordic chips instead of something else. So, in the interest of not getting detoured, when it comes to 2.4Ghz, I guess I'll just plow ahead using just nRF52 chips and see how low I can drive the energy consumption on an nRF52805 and still be able to wake it up with a radio packet. Since a lot of the energy goes toward just waking up the radio and getting it up to speed before it can receive anything, it may yet turn out that accepting a 1mbps on-air bitrate won't be too big a compromise, but I'd rather make that decision based on actual measurements rather than guesswork alone.
Between now and then I need to confirm that the BC805M has functioning DCDC circuitry in it, and I also need to measure the sleep current on the BC805M to make sure it won't be worse than expected with the integrated RTC running, which I'd like to use instead of a TPL5111 if the current drain will allow. If I need little to no external circuitry, then, aside from batteries, this whole thing could literally fit on a dime.
By the way, and unrelated to all that I just wrote, I finally came across a nice articulate introduction to the stm32 and its toolchain:
He had already done one introductory series, but now he's re-doing it to make it current and more polished. So far I like his approach of starting with the simplest possible thing and then building up from there. STM has some pretty cool looking tools that I haven't seen before in other toolchains. For instance, one of the tools has Node Red built right into it! In addition to that, there's a debugging tool that not only allows you to inspect the value of a variable, but plot its value over time. Like I said, nifty cool stuff. That said, the whole thing looks like a surprisingly PITA to install, which is where this video series comes to the rescue by holding your hand through all that. If you ask me, STM should add this guy to their payroll, because he clearly "get's it" far more than the ST product managers do. For instance, he shows that if you follow the ST installation instructions to a T, then you run into dead links that have evidently gone stale. So, he walks you through what the instructions should have been to avoid that.
-
I have nRF52805's and nRF52832's talking to one another using the proprietary radio, and I obviously have nRF2401's talking to one another, but getting the two groups to talk to each other? It's not obvious how to do that: Enhanced Shockburst of the nRF24L01 has a weird 9 bit section called PCN in the middle of it, and it's not clear how to get an nRF2 to receive that kind of oddball frame without rejecting it. That said, I think it probably can be done, but it would maybe turn into a long detour that I'd rather not take right now. It turns out there does still exist regular, non-enhanced Shockburst which the nRF24L01 can still use and which doesn't have the oddball 9-bit PCN, but then the maximum transmit speed of an nRF24L01 is limited to 1mbps. That's no good, because I want to use the faster 2mbps, which is almost the entire allure of using Nordic chips instead of something else. So, in the interest of not getting detoured, when it comes to 2.4Ghz, I guess I'll just plow ahead using just nRF52 chips and see how low I can drive the energy consumption on an nRF52805 and still be able to wake it up with a radio packet. Since a lot of the energy goes toward just waking up the radio and getting it up to speed before it can receive anything, it may yet turn out that accepting a 1mbps on-air bitrate won't be too big a compromise, but I'd rather make that decision based on actual measurements rather than guesswork alone.
Between now and then I need to confirm that the BC805M has functioning DCDC circuitry in it, and I also need to measure the sleep current on the BC805M to make sure it won't be worse than expected with the integrated RTC running, which I'd like to use instead of a TPL5111 if the current drain will allow. If I need little to no external circuitry, then, aside from batteries, this whole thing could literally fit on a dime.
By the way, and unrelated to all that I just wrote, I finally came across a nice articulate introduction to the stm32 and its toolchain:
He had already done one introductory series, but now he's re-doing it to make it current and more polished. So far I like his approach of starting with the simplest possible thing and then building up from there. STM has some pretty cool looking tools that I haven't seen before in other toolchains. For instance, one of the tools has Node Red built right into it! In addition to that, there's a debugging tool that not only allows you to inspect the value of a variable, but plot its value over time. Like I said, nifty cool stuff. That said, the whole thing looks like a surprisingly PITA to install, which is where this video series comes to the rescue by holding your hand through all that. If you ask me, STM should add this guy to their payroll, because he clearly "get's it" far more than the ST product managers do. For instance, he shows that if you follow the ST installation instructions to a T, then you run into dead links that have evidently gone stale. So, he walks you through what the instructions should have been to avoid that.
@NeverDie Just checking in. I've received lots of different radios and built two of your bare-bones kits. Soldering the Atmega328P chips were easier than I thought – first time ever on pins that small. My MM showed many, many solder bridges existed. Solder-wick helped fix that. Hope I didn’t burn the chip.
Before I start running tests on the different radio’s as you have, I’ve been getting a GPS functioning which has been fun. After collecting data around the perimeter of our small property, I figured out how to do a XYZ 3-D plot in Excel – not easy.
In the GPS process I’ve been watching this video (https://www.youtube.com/watch?v=gtM832Z0ujE&t=219s ) and he has a conclusion that you might be interested in: locating the transmitting radio (nrf24L01) close to the MCU was limiting the packet/per/second performance, and limiting range. With this in mind, I hope to test your radio carrier boards on a Dupont wire extension raising it off the bare-bones board. Then test with and without and see how it does. Again, I’m hoping all that wire doesn’t inadvertently create unwanted antennae interference.
But, obviously, I’m on the slow road still.
-
@NeverDie Just checking in. I've received lots of different radios and built two of your bare-bones kits. Soldering the Atmega328P chips were easier than I thought – first time ever on pins that small. My MM showed many, many solder bridges existed. Solder-wick helped fix that. Hope I didn’t burn the chip.
Before I start running tests on the different radio’s as you have, I’ve been getting a GPS functioning which has been fun. After collecting data around the perimeter of our small property, I figured out how to do a XYZ 3-D plot in Excel – not easy.
In the GPS process I’ve been watching this video (https://www.youtube.com/watch?v=gtM832Z0ujE&t=219s ) and he has a conclusion that you might be interested in: locating the transmitting radio (nrf24L01) close to the MCU was limiting the packet/per/second performance, and limiting range. With this in mind, I hope to test your radio carrier boards on a Dupont wire extension raising it off the bare-bones board. Then test with and without and see how it does. Again, I’m hoping all that wire doesn’t inadvertently create unwanted antennae interference.
But, obviously, I’m on the slow road still.
@Larson said in Most reliable "best" radio:
@NeverDie Just checking in. I've received lots of different radios and built two of your bare-bones kits. Soldering the Atmega328P chips were easier than I thought – first time ever on pins that small. My MM showed many, many solder bridges existed. Solder-wick helped fix that. Hope I didn’t burn the chip.
When I encounter hard-to-rid solder bridges, I ladle on gobs of that resin that I linked for you earlier on amazon. Use tons of the stuff, such that the whole area is submerged in it. Then when you hit the area with a hot soldering iron, the solder bridges all magically separate like Moses parting the Red Sea. Not all resins are equally effective in that regard, which is why I pointed you to a resin that seems to work really well. There are also some "hoof" soldering tips that help pull off excess solder onto the tip via capillary action, which you can then wipe off onto brass wool or a sponge. Those tips are a definite nice-to-have, but not strictly necessary. With the right resin, the resin will do most of the work for you. If you're still having trouble, then you may want to raise the heat on your soldering iron. When I want to deliberately create solder bridges, I lower the temperature on my soldering iron to make it closer to the melting point.
-
I'm using my "proto-board" to prototype a basic nRF52805:
It's working fine, except for the reset pin. Apparently Nordic has introduced new "advanced protection" that's preventing me from assigning and enabling P0.21 to be the RESET without some sort of complicated obscure sequence to disable the advanced protection. -
@Larson said in Most reliable "best" radio:
@NeverDie Just checking in. I've received lots of different radios and built two of your bare-bones kits. Soldering the Atmega328P chips were easier than I thought – first time ever on pins that small. My MM showed many, many solder bridges existed. Solder-wick helped fix that. Hope I didn’t burn the chip.
When I encounter hard-to-rid solder bridges, I ladle on gobs of that resin that I linked for you earlier on amazon. Use tons of the stuff, such that the whole area is submerged in it. Then when you hit the area with a hot soldering iron, the solder bridges all magically separate like Moses parting the Red Sea. Not all resins are equally effective in that regard, which is why I pointed you to a resin that seems to work really well. There are also some "hoof" soldering tips that help pull off excess solder onto the tip via capillary action, which you can then wipe off onto brass wool or a sponge. Those tips are a definite nice-to-have, but not strictly necessary. With the right resin, the resin will do most of the work for you. If you're still having trouble, then you may want to raise the heat on your soldering iron. When I want to deliberately create solder bridges, I lower the temperature on my soldering iron to make it closer to the melting point.
@NeverDie Thanks for the tip. I went as far as dipping my solder wick in my new SRA Flus #135 (yes, your recommendation; thank you again). That may have been the trick because ... it worked! Actually, I didn’t dip it but smooged the stuff onto the wick using a toothpick as a trowel. Yea, it was a mess afterwards. I used a foil tray as an alcohol bath before cleaning with a toothbrush.
My problem today is bootloading the brand new 328's with my old USBASP. The IDE says something about “cannot set SCK period” and then “initialization failed”. I’ve been here before and it just takes time to relearn. I made ReadMe notes but I can’t find them. I’ll try again tomorrow.
-
@NeverDie Thanks for the tip. I went as far as dipping my solder wick in my new SRA Flus #135 (yes, your recommendation; thank you again). That may have been the trick because ... it worked! Actually, I didn’t dip it but smooged the stuff onto the wick using a toothpick as a trowel. Yea, it was a mess afterwards. I used a foil tray as an alcohol bath before cleaning with a toothbrush.
My problem today is bootloading the brand new 328's with my old USBASP. The IDE says something about “cannot set SCK period” and then “initialization failed”. I’ve been here before and it just takes time to relearn. I made ReadMe notes but I can’t find them. I’ll try again tomorrow.
@Larson I use an AVR Dragon. I don't think they are even manufactured anymore, but it still works and it makes burning bootloaders and setting fuses a snap from within what is now called Microchip Studio (what used to be called Atmel studio). It's also a "high voltage" programmer to resurrect chips that low voltage programmers cannot. It turns out I've never had a reason to use the high voltage feature, but it was a selling point at the time.
Anyhow, I meantion it because if you can find a programmer that does dance with Microchip Studio, it's a fairly easy interface to learn and to use. You just go to menu Tools....Device Programming... and it's all right there. Microchip Studio is free so if you want to preview what it might look like, just download it and give it a squiz. I don't actually use Microchip Studio for anything other than just this particular feature
-
@Larson I use an AVR Dragon. I don't think they are even manufactured anymore, but it still works and it makes burning bootloaders and setting fuses a snap from within what is now called Microchip Studio (what used to be called Atmel studio). It's also a "high voltage" programmer to resurrect chips that low voltage programmers cannot. It turns out I've never had a reason to use the high voltage feature, but it was a selling point at the time.
Anyhow, I meantion it because if you can find a programmer that does dance with Microchip Studio, it's a fairly easy interface to learn and to use. You just go to menu Tools....Device Programming... and it's all right there. Microchip Studio is free so if you want to preview what it might look like, just download it and give it a squiz. I don't actually use Microchip Studio for anything other than just this particular feature
@NeverDie said in Most reliable "best" radio:
Anyhow, I meantion it because if you can find a programmer that does dance with Microchip Studio, it's a fairly easy interface to learn and to use. You just go to menu Tools....Device Programming... and it's all right there. Microchip Studio is free so if you want to preview what it might look like, just download it and give it a squiz. I don't actually use Microchip Studio for anything other than just this particular feature
Thanks for another tip/reminder. I still have the Atmel Studio 7, Microchip Studio predecessor, loaded and I think that played a role for me in the past in this hurdle – you reminded me of that. I’ll give it another go. I remember the strength of AS7 was that one could debug code (see registers) a command at a time – pretty cool.
-
@NeverDie Thanks for the tip. I went as far as dipping my solder wick in my new SRA Flus #135 (yes, your recommendation; thank you again). That may have been the trick because ... it worked! Actually, I didn’t dip it but smooged the stuff onto the wick using a toothpick as a trowel. Yea, it was a mess afterwards. I used a foil tray as an alcohol bath before cleaning with a toothbrush.
My problem today is bootloading the brand new 328's with my old USBASP. The IDE says something about “cannot set SCK period” and then “initialization failed”. I’ve been here before and it just takes time to relearn. I made ReadMe notes but I can’t find them. I’ll try again tomorrow.
@Larson said in Most reliable "best" radio:
My problem today is bootloading the brand new 328's with my old USBASP. The IDE says something about “cannot set SCK period” and then “initialization failed”.
If you have a second USBASP or an Arduino of some sore lying around, you could try to update the firmware on the USBASP. I recommend this edition, latest release and a Google search for "how to update usbasp firmware". You may see that with release v1.06 of that repository, there was an improvement that "Includes automatic SCK slowing".
Of course, the problem may be more rudimentary. Can you read the fuses? Are they set to use an external oscillator that doesn't exist?
-
@Larson said in Most reliable "best" radio:
My problem today is bootloading the brand new 328's with my old USBASP. The IDE says something about “cannot set SCK period” and then “initialization failed”.
If you have a second USBASP or an Arduino of some sore lying around, you could try to update the firmware on the USBASP. I recommend this edition, latest release and a Google search for "how to update usbasp firmware". You may see that with release v1.06 of that repository, there was an improvement that "Includes automatic SCK slowing".
Of course, the problem may be more rudimentary. Can you read the fuses? Are they set to use an external oscillator that doesn't exist?
@alphaHotel I'll try the firmware update. Thanks. I suspect my problem is the SCK speed. I get immediate failure. I don't think I can reach the fuses if the 'target' chip doesn't have a bootloader. Do I have that wrong? The wierd thing is that I used my USBasp to bootload an extra Nano I have on hand. That worked fine. On the bare bones board, I've double/triple checked the connections and I've rechecked the 328 chip for solder bridges & solid connections with pins. I have downloaded your recommended link. The 2011-05-28 Thomas Fischl Readme.txt file looks complicated. I'll see if I can manage that. Thanks again.
-
BTW, I had previously failed to notice that an nRF52840 can be powered from up to 5.5v because it has a built-in buck regulator designed to manage that higher input voltage. That might make a 3 or possibly even 4 battery configuration, depending on battery chemistry, pretty compelling, because it would extend battery life so much longer.
