Posts made by NeverDie

Fun to see what hobbyists can achieve when they stick to it long enough:
I Landed A Rocket Like SpaceX – 07:05
— BPS.space

OK, PCBway finished its fabrication. I've got this figured out now. PCBway, and probably the others as well, don't start the clock ticking when you submit your files and make payment. Instead, they start the clock ticking whenever the job gets to the MI stage of production. So, in that technical sense, PCBway made good on its 24 hour production advertisement. There's no apparent limit though on how long the job spends in either engineering pre-production, nor in how long it takes to ship the PCB's after the build is complete. The fab's don't seem to make any promises with regards to either of those, but either/both can stretch out the turnaround time. That said, it appears PCBway may be generally faster than JLCPCB, and definitely faster in tackling new orders submitted over the weekend. For those reasons, I think I'll be using PCBway going forward.

Meh, 24 hours later after submitting the files, PCBway is still only 56% complete on its production, but that still places them ahead of the 0% complete that JLCPCB would be if I had ordered by JLCPCB instead over the weekend.

It's really quite amazing. I used Pcbway back in 2017 to build 10 pieces of my coincell sensor PCB:
https://www.openhardware.io/view/510/Multi-Sensor-TempHumidityPIR-LeakMagnetLightAccel

At the time, it cost me $38 at PCBway, plus shipping, to have them fabbed. Now I could probably get 30 of the same PCB from PCBway for $5. Plus, pcbway has kept the zip file, so if I had misplaced it, I could either download it or just hit the re-order button. Nice! Shipping costs are a little more now than then, but you get the picture. Prices have gotten so low that the PCB fab price is almost trivial, and I fab all kinds of breakout boards and add them to the orders because it's just so cheap to do so now, and they can piggyback on the shipping cost, which often doesn't go up for the incremental baggage.

In a previous house I had a wireless sensor that was cylindrical. I drilled a roughly 3/4" - 7/8" diameter hole in the doorframe and slide it in, so it wasn't at all visible when the door was closed. Because of the packaging and form factor, some exotic things, like that, are far easier to buy than build, though I suppose it would be within the grasp of someone with skills who was determined to make their own.

Less exotic: if you made your sensor flat enough, you could hollow out the door molding and hide it inside of that. A properly designed door sensor could run off of a CR2032 coincell battery for 10+ years, so it's not such a wild idea.

@Larson It turned out that in the end it didn't matter. Despite their estimates, it still took them 2 days to build. With JLCPCB, the patterns has been 2 days of build time and then ship on day 3 or 4, but usually day 3. There seems to be considerable lag between them finishing production and them shipping it out. Fortunately, once DHL gets it, delivery is very fast, usually in 2 days, including weekend days. I've had no complaints about quality, so that's why here I'm mainly focused on speed, because it's important for keeping momentum going vs. a project stalling out for want of a nail, as it were.

@nagelc With JLCPCB, if I place an order on Monday morning (china time), I can receive it by Friday afternoon (US time) if I select DHL, which costs around $21 for the shipping. Shipping cost is a little higher with Pcbway, but build cost for multiple copies of the same board is lower at the margin with Pcbway, which I hope may be a day or two faster on turnaround. We'll see. According to their tracking, they're now 18% of the way done with their 24 hour processing claim, so they'll have to hustle if they're going to get it to 100% done in about another 12 hours. So far, the main difference is that it's the weekend, and Pcbway is at least doing something to progress a new order, whereas JLCPCB would be waiting until Monday to even start.

Well, maybe PCBway really is better. I was about to place an order with JLCPCB, but they said production wouldn't start until Monday, whereas PCBWAY said they would be finished in 24 hours. Then again, even though they say the "processing time" is 24 hours, now that I've placed the order, they're saying that the estimate finish time is on Monday, August 8. Huh? That's more like 48 hours. Hopefully by "finish" they mean shipping on Monday.

I ran into a "gotcha" with the larger piezo buzzer. It turns out that they have high enough inherent capacitance that you need either a resistor or something else to "drain" them during the off-phase of a square wave. Otherwise, the sound is minuscule. According to my Fluke multimeter, the large piezo's have only about 24nF of capacitance. I haven't yet checked with an LCR meter to confirm.

It turns out you can use an inductor instead of a resistor and setup a resonant circuit, which is more energy efficient than just using a resistor. So, I may try that, even though it's a more complex circuit to construct, because this way it will also increase the voltage (and hence volume) of the buzzer:

https://www.digikey.com/en/articles/design-techniques-to-increase-a-piezo-transducer-buzzer-audio-output

What's also interesting is that for buzzer's with a feedback terminal, you can use a simple circuit to automagically drive them at their resonate frequency:

https://www.hackster.io/taunoerik/self-drive-piezo-buzzer-e9786f
Evidently this also serves the purpose of "draining" the buzzer without using a resistor directly across Main and Ground.

Well, by trial and error, I've determined that it takes about a 100 ohm resistor to adequately "drain" the buzzer during the low phase of a square wave. Assuming 3V, that means 300ma wasted current during the high phase. On it's face, that seems excessive.

The small buzzers seem to neither need nor benefit from these drain resistors. I guess their inherent capacitance is simply too low to matter.

[Reporting back: I tried out the self driving buzzer circuit, and 1. it works at higher voltages of around 9-10v, and 2. even then it isn't as loud as a proper square wave at 3v. So... I'm nixing that idea. Besides, it's rather fiddly as to getting the component values just right in order to work, and who knows how much variation there might be in the manufactured piezo buzzers.]

Another thing I've noticed about JLCPCB is that if each item in my order is just the minimum quantity 5, the whole order seems to get fabricated in about a day. If any item is higher than quantity 5, then it seems to get kicked into a slower queue. I don't have extensive datapoints to say definitively, but so far that seem to be the pattern.

@Mishka Very nice work indeed. One question though: I don't see an antenna of any kind built into the PCB. Maybe I'm just not seeing it, or is there none? I do see a connection for an off-board near field antenna, but off-hand I don't see where the antenna is for 2.4Ghz RF.

Oh, I see it now. You're using a chip antenna. Got it.

Well, now that you've been using it for a while, how is the Raybeacon working out for you?

If/When I advance to the point of designing the RF chips directly onto a PCB instead of relying on RF modules, the assembly feature would probably pay for itself. I'm not quite there yet, but maybe later this year. LCSC has nRFx chips, whereas a lot of the desirable nRF52x modules just aren't available anywhere. So, if I can't buy, maybe the answer is build from scratch!

Fortunately, there is one advanced project that could maybe serve as a pathfinder:
https://www.openhardware.io/view/742/rayBeacon-nRF52-on-the-go-Development-Kit
but I don't see where he has an antenna built into the PCB. I'll have to inquire with the author about that.

Sounds interesting. Please post the schematic as well.

@Larson said in Which PCB fab do you currently like the best?:

@NeverDie Just for clarification, you are not asking about assembly, right?

Right.

@Larson

@lood29 said in Which PCB fab do you currently like the best?:

Pcbway do produce better finished pcb

How is it better? Aside from the quality of silkscreen, which I have noticed varies from one vendor to another, what should I be looking for?

@Larson said in Most reliable "best" radio:

But I remember that there is a sweet spot (resonant frequency, perhaps) where the sound would just pop.

Yup, I've noticed the same, if by "pop" you mean becomes noticeably louder. It's not free though, as the current consumption also hits a peak at that frequency, which is yet another way to identify where the "pop" happens. But, anyway, yes, I agree, that is the magic sweet spot, and it's absolutely worth the extra current.

Here's a similar project:
https://www.openhardware.io/view/268/Arduino-Pro-Mini-Shield-for-RFM69HW

@Larson Thanks for your post. With parts getting ever more tiny, I think that would be a nice resource to leverage.

I'm presently learning more about buzzers than I ever wanted to know, but I'm having to discover the critical knowledge by experiment because the datasheets don't really adequately characterize them. In the end I think it's going to be a tradeoff between form factor, sound level, battery life, and the number of components needed to assemble the objective, as well as ease of assembly. My first design was this:

and I have a lot of alternate designs in the pipeline that I'll want to compare against it before picking a winner. Because of the buzzer dynamics, I have to actually build them in order to do a proper job of comparing them. For instance, the buzzer on this prototype is rated at 100dB at 10cm, but, as I've learned, that really only means 80dB at 1 meter if powered at 5v. But what is the SPL if powered at 3v or even 2v? Those are in the acceptable voltage range, but the datasheet doesn't say, so I have to buy buzzers and try them out in order to find out that kind of info. And it's not as straightforward as you might think, because the resonate frequency seems to change depending on the voltage. So, I have to discover that as well in order to do a proper apples-to-apples comparison.

Further complicating matters is: how much current can a coincell really be counted on to deliver, especially as it ages and as its voltage drops. It turns out that answer isn't straightforward either, because it depends on how long you draw it for, and then there's a recovery period after which you can draw more current than if you don't wait for a recovery period. And how long do you need to wait, and so forth. Try figuring that out from a datasheet. That type of essential info just isn't there, and yet I need to know it if I'm going to compare the design in the photo against another design which might use, say, a CR2477 or a CR2450 or a CR123A, etc. Probably somewhere someone has built a coincell simulator to answer these types of questions. I presume that Durael or Energizer have the info but decided not to include it in their datasheets, maybe for marketing reasons.

So, to cut through all that, I'm taking the empirical route of build-and-test for a number of different design concepts, and I'll use the results to zero-in more quickly on the winner.

The strange thing about buzzers is that most of the datasheets express their SPL measured at a distance of 10cm, whereas, in contrast, most other sound sources are measured at 1 meter. Fortunately, from plugging the numbers into this conversion calculator: https://www.omnicalculator.com/physics/distance-attenuation
it turns out you can take the oddball buzzer datasheet measurements and convert them into conventional one meter SPL measurements by simply subtracting 20dB from the 10cm datasheet value. So, in reality, what the datasheet calls a "100 dB" buzzer is actually an 80db buzzer for purposes of standard comparison to most sound sources.

I've been using JLCPCB for the last several PCB fabrications. I've pretty much convinced myself that on Sundays they may continue progressing work that's already in progress, but nothing new seems to start until sometime later on Monday. i.e. there's no apparent advantage to submitting new work on Sunday (China time). Also, it seems to inevitably take 2 days to fabricate, but even if finished early on the second day, nothing gets truly shipped until late on day 3 at the earliest.

Since the quality seems about the same with all of the fabs, the main differentiators these days boils down to price and speed. Are there any fabs with faster turnarounds than this that anyone here likes to use?

I discovered by accident that if I place an order with JLCPCB and then place a parts order with LCSC before the JLCPCB order ships, then LCSC will discount the shipping cost for the LCSC parts order, even though they can't actually combine shipping. Huh? This was actually my first time ordering parts from LCSC, so I'm just passing along the finding in case it might benefit anyone who might be reading this.

BTW, Intel recently predicted the chip shortage will last into 2024.

@Larson said in Bootloading a barebones arduino:

How tight are the radios to baud support they get from the 328P? I would imagine the internal crystal baud rate is dependent on voltage. Maybe some formula exists in the 328P datasheet that allows for adapting this on the fly.

The radios are connected over SPI, with the radio as slave and the atmega328p as master. The master sends out the clock signal, and the slave is literally "slave" to that clock signal, even if it isn't steady. Therefore, within normal parameters, it's not something you need to worry about, because the shared clock signal synchronizes their communication. Naturally there's some limit on how fast you could theoretically run a master's clock before it becomes too fast for the slave to follow, but AFAIK there is no limit on how slow you can run the clock. You could probably even toggle the clock pulses manually by hand if you wanted to. The slave isn't allowed to get bored and time out no matter how long it takes. The protocol simply says that whenever there is a clock transition, the next bit of data has to be ready for reading on the datalines (both MOSI and MISO). i.e. the protocol is agnostic as to the clock speed and even its consistency. You and a group of friends could sit around a table and pass bits and bytes to each other using an SPI communication protocol. Better than telephone!

@Larson Thinking about it now, I suspect maybe what you're describing is why I previously couldn't get lesser UART chips "to work" and instead took refuge in, generally, a CP2102, which could maybe handle such inconsistency better at nominal baud rates. So, if that's the case, good on ya for sticking with it and figuring out how to make cheaper UART chips work. Evidently they do work after all if you dial-in the actual rather than the nominal baud rate.

As a side note, I just now looked at the CP2102 datasheet, and it finally explains why I seemingly couldn't get the nominal 1mbps baudrate out of the nRF52805, even though the nRF52805 datasheet offers that as a possible setting. It's because the CP2102 is maxed out supporting a nominal 921600.

With that mystery now solved, the remaining mystery is why I can't seem to get a USB virtual com port on a PC to do hardware flow control. Do I literally need a physical serial port rather than a USB to get hardware flow control working? It's breaking somewhere in the chain; I'm just not sure where. For now I've worked around the lack of proper hardware flow control at high speeds by just padding in some extra time between transmissions, which does allow communication to happen, but obviously slower than what it could be with proper RTS/CTS protocol working. Who knows? Maybe it's a factor in your situation as well, depending on what assumptions you're making or how you're configuring things. As it turns out, without HWFC, at higher baud rates you actually need less of a catch-up delay between transmissions than at lower baud rates, so running at max baudrate is a double win of sorts.

I think I know what you mean. On the nRF52805, one of the nominal UART Tx baud rates is 921,600, but the datasheet states that the "actual" baudrate at that setting is 941,176, so I set my terminal emulator to that, the actual baud, rather than the nominal rate. I don't ever remember encountering that kind of distinction on the atmega328p, but maybe there are some that I've just never run across. At slower speeds it's probably more forgiving. There's also the issue of hardware flow control, but it often isn't used by some link in the chain, which ruins it.

@Larson said in Bootloading a barebones arduino:

The barebones Atmega 328P running without an external clock can’t exactly keep up with the IDE’s baud rate of 9600. Clock accuracy, I’m told, is the cost of using the low-power internal clock setting. So after some iterative looping, I’ve discovered that coding Serial.begin (8800) works on one board, and Serial.begin(9000) works on the other. Your chip will probably be different.

Something is amiss then. Maybe you're running with very long wires? I can't remember having problems running UART at 115200 baud without a crystal, and that's true across many atmega328p's and across many different boards. For sure I've never had a problem at 9600 baud.

Are you using either an official FTDI or a CP2102? Either of those works great. The cheap UART alternative chips which aren't those might be a problem problem though. I avoid those.

@Larson
I suppose the design could be changed to include an optional diode on pin 13 for those who want to stay strictly orthodox Arduino.

One could also allow a crystal oscillator to be installed, for those who want that as well, but I happen to think running from a crystal oscillator is generally a bad idea for a battery powered application, especially when the 8Mhz resonator seems to work so well.

I made this CR2032 coincell powered locator beacon using an nRF52805:

It was my first experience using a TAG-CONNECT to make the programming connections. It's for that reason that I haven't yet attached the battery holder. The TAG-CONNEC provides power during programming (and debugging as well if so desired).

I have the antenna hanging out over the edge, as per Nordic Semiconductor recommendations, so that it doesn't hover over the ground plane. However, that makes the overall footprint a bit larger, somewhat defeating the point of powering it with a CR2032. I may try making a smaller version where the antenna doesn't overhang just to see how much difference it does or doesn't make. For a device like this, I mostly care about reception rather than transmitting, so maybe for receiving such a change won't make much of a difference.

Who makes the world's smallest nRF5x module?

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

https://mcudude.github.io/MiniCore/package_MCUdude_MiniCore_index.json
It's very easy to use. You can install it into the regular Arduino IDE, pick from among the MiniCore "boards" in the board manager, select the 8Mhz option and a few other obvious options, and then you're done with instalation. From that point on your code will automagically compile using MiniCore. Just to be sure, I gave it a try myself, and I'm now blinking a blue LED off of Ardino Pin 20. It works!

I leave this post as a reminder to anyone else reading this thread. The MCUDude link and installation step is VERY important. To install in the Arduino IDE add the link in File/Preferences/Additional Board Manager URLs; go to Board Manager and filter on minicore, click on Install when MiniCore comes up. Next when selecting the MiniCore board, make sure to select Clock as Internal (8 MHz), or avrdude won't be able to find your board. I went with the other board manager defaults and ... WaLa... my new barebones board is blinking on both pins 20 and 21. Overlooking, or not remembering, this May 14 post has cost me several weeks. So if you build yourself a barebones, heed this post.

Thanks for your post. I just now pasted it into the project's main description page on openhardware.io: https://www.openhardware.io/view/22651/Version-30-atmega328p-test-platform

Reporting back: I tried it out, and that thing really is ear splitting when powered by 9 volts. It's so loud that even if I completely cover the opening, it's still loud. That's great. That means that even in a worst-case scenario where it's buried inside some sealed container, it's extremely likely I'd still be able to hear it. After all, a locator that can't be found is no good. Although it's probably overkill, when it doubt build it stout.

Also, I ordered some PCB slices to try making an enclosure that way (as illustrated in the sliced enclosure photos above), so we'll see how that goes.

OK, I think I may have found a solution that I could mount external to the enclosure:

It promises to deliver an ear-splitting minimum of 110dB of sound pressure while drawing no more than 5ma. So, the benefits are:

1. Plenty loud. Even if buried in some box, I bet this could be heard.
2. A voltage range of 1 to 40v, with 9v being nominal.
3. Externally mounted, so not muffled by the PCB casing
4. Only requires just a couple of solder pads on the PCB, which won't consume much PCB real estate.

Downside: runs at 9v for maximum effect. Datasheet doesn't indicate the sound pressure level at a lower voltage, so I'll have to buy one to test it out. Maybe this changes the form factor to more of a 9v battery size if that's what it takes. Though not ideal, that wouldn't be so bad.

Re-thinking it all now, maybe heatshrink alone would be a "good enough" enclosure that I needn't bother with a rigid enclosure? Or, better yet, since PCB's are so cheap, maybe I build an enclosure out of a stack of custom routed FR4? That would give me a lot of flexibility without having to manually fabricate something. The FR4 could give rigid protection against dings and dents. Then bolt it together through 4 corners and, presto!, a sliced stack enclosure, similar to how some raspberry pi enclosures are fabricated:

or

where FR4 could be used instead of plastic, simply because that's something a PCB house is already good at routing and shipping. Rock bottom PCB's tend to be thin, though, so this might only be economically viable for a small device, such as what I'm attempting to make. Obviously, custom 3D printing something will probably be more economical, but that comes with its own set of hassles and costs, whereas a sliced enclosure might be easy to throw together.

[Edit: I just now priced it out at JLPCB, and, for instance, a 50mmx50mmx1.6mm slice with a 30mm diameter hole in the middle would cost about $0.20/slice at quantity 100. i.e. low enough to be interesting. ]

I sent a couple boards off to the fab, but it's now more obvious than ever before why the pro's prefer to mount a ceramic disk piezo in the case, and that's because it simply takes up too much space on the PCB. With a loud enough buzzer surface mounted on the PCB, I had to do tons of routing origami to make the parts fit. I could take another stab at it using 0402 instead of 0805 parts, but then soldering will be harder in the trade-off. For that reason, I think the short-term solution may be gluing a large surface mount buzzer to the inside top of an enclosure and then running wires from that to the PCB....except then when I screw on the top, I'd be twisting the wires. Ugh. Maybe I could pre-twist them in the wrong direction so that twisting them during the screw-on makes them untwisted when it's all finished. I'm starting to feel more like a system architect than a hobbyist. On the other hand, if I could glue the PCB to the buzzer, then it would all rotate together and life would be good. Hmmm.... Yeah, maybe that's the best option.

Another thing: it's not easy finding coincell holders that will stack two CR2032's to yield a 6v voltage. I've been down this path before on a prior occasion, and, IIRC, the solution is to stack the two coincells inside a kind of "drawer", which then slides into a clip cavity on the PCB. That does tend to add some amount of height, but it also avoids the two coincells from slipping apart and/or shorting-out against the metal of the holder. The downside is that it has a slightly bigger footprint than the non-drawer types.

On the other hand, with a flat two-cell design, there would be plenty of room for even a large SMD buzzer. Hmm.... Maybe not a bad idea.

@Larson said in Bootloading a barebones arduino:

I assume the skill that is required to remove the bootloaded 328P's from the Nano is a higher challenge. Soldering a new chip, as I did, has to be easy-peasy compared to removing and resoldering an existing chip.

Honestly, you'll be surprised how easy it is to desolder a 328P if you use enough Chipquik. You basically lower the melting point to where all 32 pins are in liquid metal all at the same time, and then you just push it aside. I'm sure there are other techniques as well that don't rely on Chipquik, but this method is very easy. If it's still sticking, melt more Chipquik onto the pads and keep everything heated until the whole thing is swimming in liquid chipquik. If you follow that heuristic, you can't fail.

Well, having now test driven some of the 70db and 80db buzzers, I just don't think they're loud enough to guarantee being heard under worst case scenarios. So, I found a buzzer that promises a minimum of 100dB...if powered by 150ma at 5v. Argh. So, I guess I'll be using two coincells now, plus some other support chips, in order to guarantee I can find the beacon under even adverse conditions. Maybe it's not so bad after all though, as I perhaps won't have to be concerned as much with the voltage droop that's common in CR2032's. Also, 100dB is darn loud, so that should make finding the thing by ear a lot easier.

I wonder just how long a burst of sound needs to be in order to be heard clearly? At that level of consumption, I only wanting it buzzing for the absolute minimum.

So, I think I'll opt for taking a slight bite out of the GND pad in exchange for having a sturdy connection:

It looks as though that by rotating the TAG-CONNECT footprint a few degrees, I can fit the landing pads onto a coincell size platform without having its holes penetrate into the CR2032 connection pad.

The diameter of the PCB is 24mm. However, one of the three alignment pins might not be well supported, so maybe pushing the footprint up would be the better way to go with this. I don't see that having a hole in the GND pad of the CR2032 will make any meaningful difference. I do think that having it close to the edge, though, is probably a good idea, so that the TAG-CONNECT can hook up without hitting the metal of the coincell holder.

@vomaxa A lot of people seem to like the Voron. Its base doesn't move, so it prints the same regardless of whether it's a small model or a large model. Also, it does hardware autoleveling instead of software autoleveling. In addition, it has very active development, and it prints fast.

On the other hand, Ender 3 and its variants is probably the most popular because of its low price and relatively fast setup.

I have a Prusa i3 MK3, and quite honestly, the design is getting a bit long in the tooth. That said, a lot of prominent youtubers who are focused on 3D printers still describe it as their "go to" 3D printer, because, perhaps more than some other printers, "It just works."

@Larson said in Most reliable "best" radio:

You are welcome to 'my' KiCad file based on your design. Is there somewhere that I can drop it. I can't do it here.

Thanks! No need to share the file as I'm not presently using RFM69 in a manner where I would need it, but your answers told me all I need to know for when any kind of similar need arises in the future.

Clever! Thanks for your post. Exactly which type of guitar strings do you buy that work the best? i.e. do you try to match the castellation diameter with the diameter of the string? Also, regarding your layout for them on the PCB, how do you decide where to position them? i.e. do you use a formula or something, or do you eyeball it and take a WAG? And how do you keep them perpendicular to your PCB while you solder them? Or do you just fit a bunch in, force in the part, and then use the tension to hold them in place while you solder?

@ejlane said in Most reliable "best" radio:

They don't automatically come with the cables, which could be a pain if you didn't know to add them to the order. Though this way I guess if they wear out it's easy to just buy the one without the other...

I ordered this one: https://www.tag-connect.com/product/tc2030-idc-nl-10-6-pin-plug-of-nails-spring-pin-cable-with-0-1-ribbon-connector-10-version
and it looks to me as though the cable will be baked right into it. I ordered the 2.54mm pitch cable connector because it should be relatively easy to create an adapter board for it using 2x3 male pin header that I already have.

I also ordered the little holder pieces that you mentioned: https://www.tag-connect.com/product/tc2050-clip-3pack-retaining-clip though I didn't buy their $1 paper clip for holding it. Sheesh! The audacity.

I had to open one up to get this photo, but this is what the inside of a Fanstel beacon looks like:

Obviously it's meant to be programmed with pogo pins. Interestingly, although the case is black, it has some translucency to it, so maybe the LED can shine through it enough to be visible.

It has one intriguing feature though that none of the aliexpress beacons have, which is that they also expose 4 other pins along the JS5 connector outline. This opens the possibility that with the right ultra-thin buzzer, the right resistor, some UV glue, and some solder, it just might be possible to kludge a buzzer onto this board and still fit it back in its case, which looks like this:

which has dimensions: 30x31x10mm (9300 mm^3) , which is just a tad narrower than the Apple AirTag but 2mm thicker. Assuming that the apple airtag is fully optimized for size, I'd say that's pretty good. As a further datapoint, my el cheapo keyfinder tag that I took apart earlier in this thread is 47x31x6mm (8,742 mm^3), so thinner than either than either the AirTag or the Fanstel, but obviously 50% longer. Being circular, the airtag has the least volume, at just 6,430 mm^3, whereas the sample case I linked above has a radius of 31mm but a thickness of 15mm, giving it a volume of 11,114 mm^3, so hopefully I can find a thinner sample jar with less volume to repurpose for my DIY enclosure, although given the cheap price for sample jars I could certainly live with 15mm if I can't find better. I do like that the sample jars appear to be very clear, and since they're acrylic, I assume (?) they won't yellow if kept away from UV light sources like the sun.

Anyhow, I estimate that a 2mm thick buzzer might not exceed the height limitation imposed by the casing, so today I ordered a few different 2mm thick buzzers from mouser to try and see if I get lucky. If that fails, then there does exist at least one buzzer that's 1.9mm thick that might be able to squeeze in, but that appears to be the minimum possible buzzer thickness, at least for what's available on Mouser. In general thinner means both less loud and more expensive, so there's that as a trade-offs.

Apple's AirTag measures in at 1.26 inches in diameter, and it has a height of 0.31 inches, or 32mm and 8mm respectively.

Part of that is going to be due to the inevitable bulk of the surrounding enclosure, yet I think I might be able to get in the ballplark to the same dimensions with a DIY solution that leverages inexpensive sample containers as the enclosure:
https://www.amazon.com/gp/product/B00YOS7N4A/ref=ox_sc_saved_image_4?smid=AS7VB9OCJNT4I&psc=1
I say that because a surface mount CR2032 holder needs a footprint of around 25mm in diameter. That allows for a little extra space for the module antenna to overhang without hovering over the GND plane. That means I can craft a solution that's close to the one I had already done 5 years ago:
https://www.openhardware.io/view/510/Multi-Sensor-TempHumidityPIR-LeakMagnetLightAccel
but this time it can be just an MCU (nF52805 this time around) with a buzzer and LED, without the need for all the other bells and whistles. I'll try to see whether I can fit a Tag-Connect footprint onto it. I'm fairly sure it can be done. By the way, I've looked at a lot of nRF52 "beacons", and none of them come with a buzzer, nor would it be easy to add one, so that's what necessitates this as a DIY project. The only reason the earlier project had the big 10pin box connector was that it was very easy to plug it into an nRF52-DK for J-TAG using just an IDE ribbon cable with that particular connector. With time comes better options, and so this time it'll be ixnay to the box connector.

@ejlane said in Most reliable "best" radio:

They don't automatically come with the cables, which could be a pain if you didn't know to add them to the order.

Uh, which cables do I need to add? I thought the Tag-Connect came with a cable already built into it. Unfortunately, none of them seem to come with Dupont wires on the other end of them, so it looks as though I may need to build some kind of adapter board to make use of the cable-connectors it does come with.

@ejlane said in Most reliable "best" radio:

I prefer the type without the locking pins, and then there's a little board that you slide on the alignment pins from the back to hold everything together.

Aha! Thank you. So that's how it's done with the so called "legg-less" connector. I had worried that without the legs it would be flapping in the breeze whenever I wasn't applying hand pressure to guarantee the connections.

Another thing I like about the tag-connect is that there's no soldering involved. With the JST_SH, it's one more thing to solder, not to mention the cost of the JST connectors themselves. So, I agree with you: the amortized cost of the Tag-Connect seems reasonable to me.

@alphaHotel Thanks for your post. It reminded me that for one-time programming, all one really needs is just the through-holes on the board. You can then bend the pins on a male header to create a kind of "weave" pattern, and that alone is enough to hold it into place during the programming, after which you can simply remove it. I've confirmed this works at 2.54mm pitch, and so I'll try it at 1.27mm pitch. I expect it should work well with that too.

I did find this video, which makes it seem fairly straightforward to set up a custom bed of nails:
Building a low-cost test fixture – 22:36
— FOSDEM

but he did say during the Q&A that it took him 4 days to design it. However, with the benefit of knowing his solution, I don't think it should take anywhere near that long to design just the PCB part of it. Maybe an hour, give or take? Someday I'm going to try it. His approach to the push-pin alignment seems quite simple and, I would think, should be easy to adapt to a whole range of different targets.

@alphaHotel

Unfortunately, it also looks like it's the most work. I tried the picoblade on Version 1.0 of the Barebones, but I found that although picoblade makes the connection easily, the disconnection process is hard because it locks into place when you plug into it. So, for small projects, I'm looking into JST-SH connections, which have 1.0mm pitch and maybe (?) don't lock as well, which in this instance would be a good thing. I found some on amazon:
https://www.amazon.com/dp/B01DUC1M2O?psc=1&ref=ppx_yo2ov_dt_b_product_details
but the sockets are vertical. For right-angle sockets, I may may have to order from Aliexpress, because even Mouser just doesn't seem to stock them.

I was faced with this same problem previously when I did this project: https://www.openhardware.io/view/510/Multi-Sensor-TempHumidityPIR-LeakMagnetLightAccel

My "solution" at the time was, in future versions, to use a micro-usb connector, which indeed was much smaller, but there was nearly universal pushback on that from people saying that anything which looks like a micro-usb connector would be mistaken for an actual USB connector, and at some point end-users would hook it up wrongly on that assumption and basically destroy the system with 5 volts. Thinking about it now, that grim outcome could be avoided by the addition of just a single diode, but then again that's yet another extra part and more board real estate.

Reporting back: I finally found a name for some "press-fit" board-to-board connects: Molex slimstack.

For instance, it could maybe be used for connecting a "compute module" to a backplane. Pitch is just 0.35mm, and they come in all sizes from 6 pins up to 60 pins:

On the other hand, for a temporary programming connection, the 6 pin tag-connect might be a good idea:

Or you could possibly use a pogo-pin clip:

or possibly DIY your own using an inexpensive pogo pin header:

For that matter, with a few registration holes and a toggle clamp, it looks to me like you could have a darn good connection for either one-off programming or for more extended debugging:

I think I may move in that direction, because then you can spread out your pogo pin pads and fit them wherever there's extra a little extra space on your PCB rather than having to bunch them all together, as in the case of the other solutions. In that sense, I suppose it's more or less a conventional custom-built bed-of-nails.

@Larson said in Bootloading a barebones arduino:

Looking at the schematic you attached, I see that direct access to reset exists on JP7, pin 10. That would do it, wouldn't it?

You're right! I forgot about that pin. So on a pro-mini you would have easy-peasy access to the reset pin from the get-go. For that matter same thing on the Arduino Uno R3. You wouldn't need to pop out the DIP chip. You could practice programming it in-situ if you wanted to.

@Larson I just had an idea that might help you. If you have the Version 1.0 board, then before installing the capacitor on DTR, do a solder bridge across it instead. By doing that the DTR in will be directly connected to the reset pin on your chip, and you can use the DTR pin to gain access to the reset pin on the atmega328p. When you're all done with programming the chip and then later want to switch to using an FTDI to upload your scripts, then at that point you melt the solder bridge and install the capacitor.

Actually, the same would hold true on an Arduino Pro Mini, so if you wanted yet another possible way to practice on a "known good" platform, you could desolder the DTR capacitor, do a solder bridge, and you'd be all set to practice programming the atmega328p chip on it by using the DTR pin on the Arduino Pro Mini as the reset pin during your programming exercise. i.e. you'd solder bridge across capacitor C2 in this Arduino Pro Mini schematic:

https://cdn.sparkfun.com/datasheets/Dev/Arduino/Boards/Arduino-Pro-Mini-v14.pdf

Confirmed. Looking at the schematic of an Arduino Uno R3 and its ICSP:

you need a direct connection to the reset pin on the chip. For that reason, you can't use the DTR pin to program it, because there's a capacitor in the way. So, that also confirms that Version 3.0 may be a worthwhile upgrade for people like you, thanks to @alphaHotel 's suggestion.

For a "known good" starting point, you could pop the DIP atmega328p out of an arduino uno and practice burning your bootloader into that on a breadboard. If it gives you the same guff, then you know it's your procedure and not the chip that's at fault. Anyhow, as there's not really much that can go wrong, my WAG is that, based on @alphaHotel 's earlier comments requesting a reset-pin breakout (now baked into Version 3.0), it might have something to do with either the means or the assumptions under which your burner is accessing the reset pin.

Myself, I burn the bootloader and fuses in one of those spring-steel clamshell chip holders:

before soldering it onto the board, so I can't say that I've already done what you are attempting to do. IIRC, they cost only something like $10, but I do understand that simply knowing that doesn't really help you in the moment if you don't have one on hand already and you simply want to push forward with what you've got.

Reporting back on Piezo buzzers discussed earlier in this thread: I just now tested out a ceramic disk piezo, and, indeed, it appears they more or less require a resonate cavity of some kind to get loud enough. Putting a 3.8KHz square wave into one that already has a resonate cavity to go with it, it appears to consume about 400ua at 3v and around 260ua at 1.8v. Interestingly, it appears you can identify the frequency of maximum loudness by selecting a frequency that gives rise to the maximum current draw. A steady tone sounds like a hearing test though, so for a more pleasant effect, I guess you have to dial-in some creative frequencies.

Anyhow, despite the cheap price for ceramic disks, I don't feel like designing a suitable resonate cavity for one, so I guess I'll look more into the premade surface mount buzzers that have resonate cavities already built into their modules.

I had thought that I wouldn't need a particularly loud buzzer, and maybe that's still the case, but since I will be putting these into sealed plastic boxes as a locator beacon, I guess maybe the louder the better in terms of finding it by ear. The trade-off is that louder mostly seems to also mean bigger.

The premade buzzers fall into two camps: actively driven by some kind of built-in circuit vs. externally driven. Since the above initial test appears to indicate that current drain won't be much, I'm leaning toward driving it "externally" with an MCU pin so that I can make R2D2 sounds if I want to. Well, I'm joking about R2D2, but I would much prefer something that doesn't sound like a hearing test.

BTW, I had thought that changing the duty cycle on the square wave used to drive the piezo would change the volume, but in the tests I performed so far, the duty cycle length actually seems to have almost no effect.

Reporting back: Yeah, I just now contacted them. The price they're quoting now is $3.89 per module and they want $35 shipping. They said "Mass production is about 2.5-2.2 USD", which is higher than what their Alibaba listing says for quantity 3 sample pricing, which they now say is 2 years out date and should be ignored. Checking, I see that the quoted pricing is actually slightly worse than the $3.82/unit in their Aliexpress store. What a joke. I mean, given that this is allegedly the manufacturer talking, who can't be bothered to keep their own Alibaba listing updated even though it's allegedly two years out of date.... I guess the pricing indicated on Alibaba means nothing, which certainly explains a lot.

Maybe they reflowed the chip on backwards (rotated 180 degrees)? You could compare the chips orientation to photos of known good breakout boards, or to the datasheet. If so, you'd definitely have a solid case for a refund if it's worth your time to pursue it with the seller.

@monte There are $1.59-$2.39 nRF52805 Minew modules on Alibaba: https://minewtech.en.alibaba.com/search/product?SearchText=nrf52805
The size is just a couple mm larger than the the dime sized BC805M (above photos). I've never ordered from Alibaba so I can't really say how well that may or may not go. i.e. maybe it's a good deal, or maybe it's clickbait pricing and they hammer you on shipping. For instance, unlike Aliexpress, I don't see a rapid way to place an order, which is kinda weird given that the minimum order is just quantity 3. I assume one has to send the seller an RFQ indicating the quantity desired, and then the seller responds with a price that includes shipping? Anyone know if that's how it works? Obviously I have no idea where the breakpoint is, but maybe if you were to order 20 or 30 you'd come out ahead vs ordering from Aliexpress.

@alphaHotel said in Version 3.0 atmega328p test platform:

@NeverDie Awesome. thanks.

I uploaded the files for version 3.0, including the KiCad 6.0 project archive as a .zip file contained within the .rar file. As it has already served its purpose for me, I didn't meddle with the spacing on the batteries, but I did go out of my way to avoid possible short-circuits between the battery holder and traces on the PCB.

Enjoy!

@alphaHotel OK, I squeezed one in for you, near the corner, where it will be easy to attach your hook/grabber:

Technically speaking the courtyards overlap, but I'm going to ignore that technical error, as there just isn't much wiggle room.

@Larson No worries. I'm glad you're finding the help you need.

@alphaHotel You mean a single through-hole for the reset that you could latch onto with maybe a test probe hook/grabber? Yes, that seems like a good idea.

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.

I suppose an alternative would be to omit them entirely, and then if you didn't want to use the header pins, you could just short across the header pads instead. That would be more minimalist, and so more simple and so better. So, I think I'll omit them on version 3.

@alphaHotel said in Version 2.0 atmega328p test platform:

Could you use a solder jumper/bridge there instead for the same purpose?

Yes. Solder bridge would serve the same purpose. They're onlly there in case you don't have any interest in measuring current and, thus, don't care to install the 4 header pins or the header pin jumpers.

@alphaHotel said in Version 2.0 atmega328p test platform:

@NeverDie I hit up Keystone Electronics for a 3D model of the battery clip (p/n 92) and then did a little work on setting up 3D models of 2 and 4 of them together - though the 4-piece model is based on the spacing of 16.8mm between centres. If you're interested, I'll share them in a Github repository, since I can't upload them here.

Yes, please! Sounds like it may be very useful!

@monte said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:

@NeverDie sorry, where did you buy them? I don't see them anywhere

https://www.fanstel.com/buy/bt832f-low-cost-longer-range-bluetooth-50-module-cjtrx-8shlz-r7a7z

Presently sold-out of this particular model, but if you watch for it, it seems to come back into stock fairly often. When I was buying they had only 10 in stock, so I bought all ten. Then the next day they had another 15 in stocki, so I bought all 15. Then they were out of stock for a while, but then recently they re-stocked. Apparently that didn't last, because now they are already out of stock again.

@monte said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:

@NeverDie are you saying it is only programmable with j-link? Won't stlink/blackmagic work?

Yes, you're right. Either of those should work. I happen to be using j-link, so that gave me tunnel vision, but if either or those were the basis, then problem solved!

BTW, I just now checked, and the module I'm using literally does fit on a dime:

$2.50 each.

@monte said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:

@NeverDie have you checked the radio already? How much work is needed to make it work with mysensors?

Answering your question: Presently taking baby steps. Using pseudo bare metal programming I have it sending and receiving very simple packets using the proprietary mode radio at 2mbps. Nothing fancy. Just the bare minimum. But it works, and the code is portable with no meaningful library dependencies other than just regular C-language libraries like string.h. After I clean up the code I'll post it to github. I had already posted it on github in micropython and forth, and I just recently translated it back into C (which is what I had started with originally but didn't save the code ). Anyhow, the benefit of writing it in pseudo bare metal is that it should pretty much compile without changes and run no matter which tool chain you're using (Sandeep, SES, or whatever).

You know, it occurs to me that we should upload not just the source code, but a full VM of the development environment used to compile, link, and upload it. That would be smart. After all, all projects become time capsules, and who knows what toolchain or library will be in vogue years down the line when you want to make some change in the code you've written. If it's all in a VM, then you can step back right where you were without missing a beat. Hmmm.... I like this idea. So obvious, yet so powerful. The only problem I foresee is that J-link license is bound to the particular nRF52-DK that you own, so at least that part might make sharing a common VM a bit awkward. Everything would need to be either open source or free to use for a shared VM to work without incurring problems of its own.

But, anyway, details aside, a shared VM development platform would create a stable starting place for any newcomer who comes along. Even if the setup instructions are current at the moment they are written, over time entropy kicks in and eventually....you all know how that goes.....

And not just SW development. HW development too. For instance, rather than share just a kicad archive, if you could share a VM of the entire kiCad that you used to create a PCB.... that would be the ultimate. Then, if KiCad 7 comes along and isn't fully backward compatible with KiCad 6, everything still works just as well as it always did the moment you finished with it.

For anyone who may be interested, this is what the current draw on an nRF52805 looks like when it's sleeping:

It's about the same whether it's using DCDC mode or LDO mode when the system is sleeping in ON mode. When I first saw this plot I thought the MCU was waking up, doing something, and then falling back to sleep on what seemed like a very repeatable periodicity. I even went hunting for some part of the system that I had forgotten to turn-off that might be causing this behavior. However, when that hunt didn't turn up anything, my present theory is that this is just how the low power mode works when the system is ON but in sleep mode: it maybe is more efficient to sip current at periodic intervals than it is to run the LDO/DCDC continuously.

Now that you've seen the above picture of the spikey nature in which a nRF52 module draws its sleep current, you can appreciate that using a uCurrent Gold or a Current Ranger (let alone a multimeter) to measure sleep current is likely to give an erroneously low measurement: these pulses pass by too quickly for such a meter to properly register. That's why, for instance, I began to suspect that this guy's measurements were possibly too low:
Pro Mini nRF52: Less than 2µA System ON Sleep from 3v – 01:08
— Pro Mini Micros

Indeed, when I hook my same sleeping module up to a current ranger, the current ranger shows 0.0ua when set in ua mode. In na mode, though, the measurements are jumping around all over the place. The point being: if that was all I had to go on, I'd probably erroneously conclude that the sleep current was something less than 1ua, whereas the PPK2 here is reporting an average 5.3ua within its measurement window.

What remains unexplained is why the average current draw I measured with PPK2 while sleeping like this is so high. According to the nRF52805 datasheet, the current drawn while sleeping in system ON mode with full memory retention should be just 0.8ua.

and so I'm not sure why I'm experiencing so much more than that (5.3ua in this PPK2 example), unless maybe it's something about the Fanstel BC805M module that it's a part of which is raising the sleep current. If so, that would certainly be disappointing: I bought it precisely because the nRF52805 is supposed to have such a low sleep current compared to the other Nordic nRF52 chips that are out there.

As a matter of fact, the spikey nature of the current draws led me to wonder whether maybe the PPK2 itself was perhaps not measuring the current correctly. So, to answer that, I added a 220uF bypass ceramic capacitor (i.e. between VCC and GND) near the nRF52805 module to better average out the current draw seen by the PPK2, and then I measured using the PPK2 again. Guess what? Now the PPK2 measures an average of 0.81ua, which is spot-on with what the datasheet predicted. Whew! What a relief. I find this new measurement trustworthy not only because (a) it agrees with the value predicted by the datasheet, but now also (b) both a PPK2 and a Current Ranger produce current measurements that agree with one another, and (c) by averaging out the current draw, the potential problems stemming from a highly spikey measurement are cast aside.

@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

Well, I was able to artificially raise the CTS line, which is active low, and halt the transmissions, so I don't think the problem is with the UARTE on the nRF52x. Rather, I think the problem may be with how virtual com ports are handled on PC's, and maybe they aren't configured to properly use RTS and CTS for flow control. At any rate, I was able to crank the UARTE transmission speed all the way up to 941176 baud, and at that speed it takes only a very small artificial delay (around 300usec) after each transmitted string to avoid problems, so I'm just going to do that and move on rather than chase down how to get perfect RTS/CTS working on a PC's virtual com port. So, for that reason, this PCB project will still have value when its finished by keeping the "wiring" all within a single PCB rather than strewn about externally with a rat's nest of actual wires.

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.

Well, I take it back. Although the above method worked for doing an "erase-all" and unlock the nRF52832 that's built into the nRF52-DK, it isn't doing anything to unlock a nRF52805 that's externally connected to an nRF52-DK. "Erase all" does seem to erase the program that on the nRF52805, but it nonetheless doesn't allow access to the reset registers NRF_UICR-> PSELRESET[0] and NRF_UICR-> PSELRESET[1]. I say that because, for instance, NRF_UICR-> PSELRESET[0] and NRF_UICR-> PSELRESET[1] are still zero after the "erase all" instead of 0xFFFFFFFF, and attempting to write them both to 21 fails.

I also tried nrfjprog:
nrfjprog --erase all
nrfjprog --recover
nrfjprog --resetpinenable
nrfjprog --family NRF52 --recover
nrfjprog --family UNKNOWN --recover
nrfjprog --eraseuicr

and after each try the nRF52805 still has the reset registers impervious to writing.

Well, I see that the nRF52805 has been blessed with some kind of fancy new access port protection (APPROTECT), but reading the value of NRF_UICR->APPROTECT, it is currently at 0xFFFFFFFF, which means that APPROTECT is disabled.

So, not sure what to do about this one.

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

After looking at it again with fresh eyes, I've decided to do a version 3. It will drop two of the 10K resistors because they are probably overkill. Also, I'll add to the silkscreen so that it will be more self-documenting than the present version as to which pins are what. I may or may not fiddle just a tad with the spacing on the two AA batteries to make it a bit more symmetric, but it's going to be tight no matter what I do in order to avoid changing the spacing on the radio shields. However, with the switch now gone, it will be easier to add in a separator between the two batteries if needed.

If I had never posted the files I probably wouldn't be doing any of this, but now that it's posted, Ill do a give-back to the community by putting it into a more polished state rather than just leave it as is.

After making some attempts to connect to the nRF52-DK over its "virtual" port using a number of different terminal emulators, I'm beginning to doubt whether the nRF52-DK actually does support UART hardware flow control with even the nRF52832 that's built into it. I'm having no success with getting hardware flow control to work, but I don't know whether it's user error or just reality for the nRF52-DK. There is this: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrf52832_dk%2FUG%2Fnrf52_DK%2Fvir_com_port.html which on the one hand gives all the pinouts for TXO RXI CTS and RTS, and seems to imply that there's hardware flow control. But then it seems to contradict that by saying "Note: The mbed OB interface does not support HWFC through the virtual com port." It contradicts because, as far as I can tell, the firmware interface on the nRF52-DK is based on mbed. Maybe it wasn't always so? When I look for firmware to download from Nordic, I only see mbed firmware for the nRF52-DK.

Anyone happen to know?

I have a ticket into Nordic to inquire, but who knows how long it will take to get a satisfactory answer, if ever. Meanwhile, I may have to redesign this PCB to account for either possibility. Hence, the project is on-hold until I get answers.

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:

#1 Say NO to ARDUINO! New ARM Microcontroller Programming and Circuit Building Series – 12:02
— BuildYourCNC

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.

@nagelc said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:

After correcting a wiring error (duh!) I was able to erase using my J-Link Mini EDU.
I used Nordic's nrfjprog:
nrfjprog --family NRF52 --recover
nrfjprog --family NRF52 --recover

I had to run it twice to get the unlock. I think this makes sense after reading the devzone article.
Once unlocked, I could use my black magic probe for programming. I expect the blackmagic folks haven't had time to adapt to the new lock scheme yet.

For future reference, yet another way you can also erase your chip is using the "Programmer" app that you can install into "nRF Connect for Desktop" program. Just connect and press the "Erase All" button:

I find that I have to do this in order to unlock the chip for the first time prior to enabling the reset pin with the code:

  // Note: if chip has never been mass erased, then most likely PSELRESET[0] and PSELRESET[1] are both zero.
  // When that is the case, the chip is locked and neither can be set to 21.
  if (((NRF_UICR-> PSELRESET[0])==0xFFFFFFFF) && ((NRF_UICR-> PSELRESET[1])==0xFFFFFFFF)) { //if the two RESET registers were erased by a mass erase
    NRF_NVMC->CONFIG=1;  // Write enable the UICR
    //Note:  BOTH registers must be set to 21, or else PIN00.21 will not function as a RESET pin.
    NRF_UICR-> PSELRESET[0]= 21;  //designate pin P0.21 as the RESET pin
    NRF_UICR-> PSELRESET[1]= 21;  //designate pin P0.21 as the RESET pin
    NRF_NVMC->CONFIG=0;  // Put the UICR back into read-only mode.
  }

Meh, why wait? I just now uploaded the version 2 schematic and gerbers. I'll post the KiCad project files soon....

Maybe https://www.openhardware.io/view/630/BEEP-base-v2#tabs-instructions ?

I've cleaned up some loose ends in the design, and I just now submitted version 2 to the fab. In the end I decided not to change the spacing, because I want to continue using the various radio shields I already made for it. It may not be perfect, but it served well enough the purpose I meant for it, which was having a common platform for comparing different radios. Aside from the hardware design being a bit more polished, from a programming perspective I expect version 2 will work the same as version 1.

After I validate the version 2 boards from the fab, which should arrive in about a week, I'll replace the version 1 files with the version 2 files, at which point I will remove the "work in progress" tag.

The good news is that if you liked version 1, you'll probably like version 2 even better.

In order to properly test it, I should probably start with all new batteries. I did capacity testing on some of the older batteries and then retested their capacity again to see if the numbers matched. They didn't. So, given the small sample size, I'd be weary that there might be too much noise in the sample to draw conclusions if I start with batteries that are already impaired.

What became clear though is that batteries which just sit in a drawer can degrade quite a lot, and that it's not from overuse or re-charging. That's just what happens to NiMH batteries as they age. I guess it shouldn't be surprising, because that's what we expect from alkaline batteries also. But maybe some of the impairment was due to allowing their charge to fall while being stored? That seems to hold true for SLA batteries. Not sure about NiMH batteries.

So, unfortunately, I just don't have the data to say what the effects of trickle charging might be. If it turned out to actually extend the useful life of rechargeable batteries, then that would be an interesting outcome. Maybe someone reading this will feel inspired to conduct such a test and post the results.

Thanks for posting! Sounds at least a little similar to the system recently described by Andreas Spiess, which also uses espnow as well as repeaters to backhaul packets to a central processing station:
No Infrastructure Network with ESPnow and LoRa (incl. Repeaters and Gateways). A TTN replacement? – 11:02
— Andreas Spiess

@nagelc Sorry I don't have an informed answer, but thanks for posting and making us aware of your experience with the minew's! Haven't heard from you in a while. Have you tried upgrading the firmware on the J-link that's part of a DK? I can't say that I have, but the firmware upgradeability was one of the alleged selling features of a DK's J-Link. That potential upgradeability didn't ever seem to matter, but maybe now it does.

As for me, after a long break I'm back to have a run at getting the nRF52805 to work. So far I've got bare metal blinking and bare metal UART working. I'm opting for bare metal code because it's unclear how well anything else will work with the nRF52805, which doesn't seem all that well supported. Soon to get some basic bare metal proprietary radio working, I hope.... If successful, I'll post it to github to memorialize it. There are surprisingly few examples of bare metal code out there, even though that's all the datasheet itself talks about. I guess I can understand why, because I've found some surprising ambiguities in the datasheet. For instance, who would have thought that PSELTXD would refer to an actual pin number and not to a bitmask? From the datasheet I thought for sure it would be a bitmask (like nearly everything else in the datasheet), but no, it's the actual pin number. I mean, why does the datasheet show literally every bit of a 32 bit word is relevant for specifying the pin number? On a different issue, bare metal UART doesn't work quite right without some artificial delays, even if driven by interrupt events, apparently because the actual generated baudrates aren't exactly right (something the datasheet admits). So, there's some finessing involved that you don't see when you're only working from abstracted libraries.

Regardless, the architecture itself remains pretty cool, and I enjoy it a lot!

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 an assortment (pictured) of older AA NiMH batteries. Rather than trusting BigClive's trickle charging idea to fate, 1. I think I'll capacity test each of them plus a few others as controls, 2. record the measured capacity on each of the cells, 3. let the charger trickle charge the treatment group of batteries (i.e. those which are not serving as experimental controls) to maintain their charge, and 4. re-test the capacity of all the batteries from time-to-time to see if the capacity of the trickle charged batteries is degrading any faster than the control group batteries.

It's easy to imagine ways in which adding an MCU to the equation might improve the charging/maintaining of the batteries, but if it turns out that BigClive's approach works just fine without any negative consequences, then keeping the design simple, such as it already is, may be the greater virtue. On the other hand, if big improvements are possible, then that would be good to know as well.

Success! Treating the nRF52805 like an nRF52810 and uploading to it from Segger Embedded Studio's IDE using Nordic's nRF52 SDK's PCA10040e board definition, then pin P.18 blinks using the same sketch that blinked P.18 on the nRF52832. I'm reporting back with this good news, because I haven't seen it tried or documented anywhere before. At least for this modest first attempt, this simple spoof works! At $2.50 each, these tiny nRF52805 modules with their trace antennas are a good value.

By the way, the compiler that's built into Segger Embedded Systems is super fast compared to gcc.

Reporting back: As a first step I programmed an external nRF52832 by blinking P.18 using this method for wiring it up: https://devzone.nordicsemi.com/f/nordic-q-a/14058/external-programming-using-nrf52-dk This method of wiring is worthy of note all by itself, because prior to now the conventional wisdom was that the target mcu had to be separately, externally powered for the J-link on the DK to recognize it properly. With the illustrated approach to wiring it up, though, you can power it from the DK itself.

Nice.

That worked just fine. Then I tried uploading exactly the same code, using the same wiring scheme, to the nRF52805. I even erased it beforehand just to be sure.
According to J-Link, both the erasure and the subsequent upload were successful. However, P.18 does not blink. So, it would appear that a straightforward upload by treating it like an nRF52832 just isn't going to work, even just for blinking a particular pin. Argh! I feared as much. Disappointing!

Anyone here programmed an nRF52805? I made a breakout board for one and was planning to program it using the J-LINK on an nRF52-DK:

but because there is no official DK for the nRF52805, there is no "board" for it, and so I'm unclear as to how exactly it is supposed to be programmed. Segger Embedded Studio makes no mention of the nRF52805 at all, as near as I can tell. Fortunately, our old friend Sandeep Mistry does appear to have a core for it: https://github.com/sandeepmistry/arduino-nRF5/tree/master/cores/nRF5/SDK/components/device
so that may help save the day. Unfortunately, the nRF52805 upload instructions from Nordic are a hassle: https://devzone.nordicsemi.com/guides/short-range-guides/b/getting-started/posts/developing-for-the-nrf52805-with-nrf5-sdk Is there no easier way?

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

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!

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

@ben999 said in nrf24+ module with stick antenna:

Please note that i do not need any additional range.

Please don't take this the wrong way, but have you ever heard the phrase "If it's not broken.... "?

That being said, if you want to do it anyway... you'll want to consider impedance matching and probably want a VNA to check your work. i.e. it immediately gets very complicated. If none of that matters, then I guess how you execute it doesn't really matter either: there's just GND and ANTENNA to wire up. GND goes to the outside, and ANT goes in the center. If it's not a dipole antenna, then maybe only just the ANT connection will matter. Just be aware that you might be worse off than before you began.

If, on the other hand, you wanted to add a wire-whip antenna instead, then you could theoretically start-off long and then trim the length down to tune it better.

I wish there were an easier way, but, AFAIK, almost nothing about antennas is straightforward if you want to do it better than what you already have.

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 GURU

Unrelated to that,I found a nice introductory tutorial series on then nRF52:
https://www.youtube.com/c/SumairsEmbeddedEngineering/videos

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

I've had success getting the nRF24L01 to listen once per second for packets at an average current drain for just the nRF24L01 of 5.35ua. Not bad! The snag I'm running into though is that the listen window, encompassing power-up of the nRF24L01 through Rx mode is 1.6ms. However, if I use the atmega328p to time that 1.6ms, it raises the average current drain to 45ua, which is worse than my keyfinder keyfob's current drain (about 30ua on average). So....I need to find some way to sleep the atmega328p for 1.6ms in order to keep the total current drain low. However, how to do that? The TPL5111 has a minimum period of 100ms, so that's out. The atmega328p's WDT has a minimum period of 16ms, so that's out too. Unfortunately, the atmega328p has no built-in RTC. Even if I were to add an external RTC, I don't know of any that would let me dial-in 1.6ms.

Presently I can think of only two solutions:

1. Add some kind of external oscillator and feed it to Timer2 in asymchronous timer mode while sleeping the atmega328p. However, I can't seem to find from the datasheet what the current drain of that configuration would be, so it seems like a shot in the dark.

2. or, possibly use a GPIO pin to charge up an external capacitor and somehow calibrate the charging time so that when the capacitor discharges via some RC time constant it triggers a falling edge interrupt on the atmega328p to wake it up from sleeping after 1.6ms (the sleep time begins after it charges the capacitor). I haven't tried this, but it might actually work. It would notionally be kinda/sorta similar to how one can use an atmega328p to charge up a capacitor in order to determine the capacitor's capacitance value: https://www.norwegiancreations.com/2019/08/using-a-simple-arduino-to-measure-capacitor-value/.

If anyone has any other ideas on how to sleep an atmega328p for 1.6ms, please do post.

[Edit: Regarding #1, I suppose I could try measuring the sleep current with external asynchronous mode engaged but nothing connected to it. If it's acceptably low, I could then hook up an ultra low current 32.768K external crystal at an additional 500na or so. Hopefully there's some way tot turn everything off on the atmega328p except for the asynchronous counter. I'm doubtful as to whether I can apply such fine grained control like that to one of the sleep states (POWER_SAVE MODE), but maybe....? Here's some reason to be hopeful:

Power-save: is similar to the power-down mode, but the Timer2 is still awake and could be operated via an external clock.
https://wolles-elektronikkiste.de/en/sleep-modes-and-power-management

Ugh. Except Timer2 is an 8 bit counter...., but that's OK: 1.6ms would be 53 ticks on a 32.768k oscillator, so at least that part should work if the mcu sets timer2 to overflow in 53 ticks and then go to sleep and if that overflow will trigger an interrupt to subsequently wake the mcu back up after 1.6ms.

Well, it's a plausible theory. Just need to test it!

Is it worth the effort though? Even if it worked, an nRF52 module would outperform this type of setup, would be more compact, would be easier/faster to assemble, and would (probably) be lower cost as well. Hmmmmm..... And the nRF53 will be even better hardware still, though the nRF53 does come with the extra overhead of an RTOS....]

@NeverDie said in Most reliable "best" radio:

@alphaHotel said in Most reliable "best" radio:

E01-2G4M27D

I'm fairly certain the ones I ordered won't be arriving with antennas (as none were pictured in the aliexpress posting), but, no problem, I'll let you know for sure after they arrive. Most likely if you have an old wi-fi router that you no longer use, you could probably unscrew those antennas and use them, since they'd also be 2.4Ghz.

@alphaHotel Reporting back: I received them, and mine did not come with any antennas.

@Larson I haven't studied Kevin's solution, so maybe I'm missing the point of it, but the adafruit TPL5110 BoB is so much less expensive and draws so little current that it seems like no contest to me.

@Larson said in Most reliable "best" radio:

@NeverDie said in Most reliable "best" radio:

CORRECTION: Earlier I said that Adafruit's TPL5110 breakout board appeared to use a 1M pulldown resistor on DONE. I remeasured today and that's wrong. It's actually a 10K resistor.

Thanks for redirecting me to this thread. I think you were right on your original 1M Ohm assertion. Since I'm playing with my new TPL5110,s I took it on to make my own MM measurements. While my Harbor Freight MM might not be the most accurate instrument, I did show the resistance between DONE and GND to be 900 K'ish. Next, I got out the magnifying glass to spy the resistor in-line with said pins to have a marking of 1004. Google affirmed that that means 1 M ohm. So, your 5K, or 10K would be a big change – and if it comes at no cost for the quiescent current AND enables ESP action, then perfect!

I just now checked the adafruit schematic for the TPL5110, and you're right: it does show a 1 megaohm resistor. I guess I must have measured it wrong. https://github.com/adafruit/Adafruit-TPL5110-Power-Timer-Breakout-PCB

@Larson Thanks for posting your measurements. Mine match up with yours: https://forum.mysensors.org/topic/11954/most-reliable-best-radio/20?_=1656174349755

I just yesterday put together a TPL5111 to serve as purely a wake-up timer for a sleeping MCU, and it's working well also in that capacity.