Most reliable "best" radio

[NeverDie]

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.

[NeverDie]

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

[NeverDie]

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.

[NeverDie]

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.

[NeverDie]

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.

[Larson]

@NeverDie Soldier on, my friend. I love reading, but I've got nothing to add other than to report that I'm moving on to the radio portion of the barebones design. Maybe I do have something to add: I found that having JLCPCB/LCSC fabricate parts was really easy and not very expensive. The required EasyEDA design environment, I recall, linked LCSC inventory with JLCPCB quite seemlessly. As usual, for me, the learning curve took a long time. I think there were limits that wouldn't allow for exotic parts. That is not a problem for me and my simple ways. But shipping confusion did not exist as it was a combo thing. The minimum order of 5 and the single-sided fabrication were limitations that I could work with. Manually soldering SMD's is really hard and JLCPCB makes it so easy.

[NeverDie]

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

[Larson]

@NeverDie said in Most reliable "best" radio:

because the resonate frequency seems to change

Ahhh, I have something to offer. I remember way back when playing with piezo buzzers (something that is part of my mole project and in use today unfortunately) I remember incrementally changing the PWM frequency and duty cycle in the loop. I may be off base because I really don't understand what you are doing. But I remember that there is a sweet spot (resonant frequency, perhaps) where the sound would just pop. I've seen this in vocal quartets too (we are talking humans) when they hit some vibe some kind of God's amplifier gets invoked. It is really cool unless one has hyperaccousis, as I do. So I run an hide, but marvel at the science.

@NeverDie said in Most reliable "best" radio:

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.

During dev, I try to overpower with big batteries, or lines to sort it all out before playing with the smaller cells. Understand the demands first, then find the cell that can deliver. The LIR2450 seemed to deliver a good punch of curent that can carry radio transmission peaks of a ESP8266, 400uF caps helped. Nice thing is that you can control the timing of the peak audio with any other peak load... like a radio or something and prevent an overload.

[NeverDie]

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

[NeverDie]

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

[NeverDie]

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

[Larson]

@NeverDie Yep, that rocket stuff, and that dedication-to-task stuff, is pretty cool. Thanks for sharing - very inspirational.

At a more modest level ... I received the Atmega 328P programming harness/clamp you recommended long ago. Nice. And your barebones board loaded with my RFM69HCW jig are working nicely. Also received: a bunch of your suggested radios and the carrying boards. Time, I need time. Can't thank you and @alphaHotel enough for the encouragement. I look forward to reporting if only to chronical for my own record and possible use for others.

I hope it doesn't take me 7 years, but it may. Now all I need is a bunch of 48 hour days.

[NeverDie]

What I've learned lately about buzzers, through experimentation, is that to get maximum loudness I need to drive a buzzer within about plus-or-minus 5Hz of its optimum resonance frequency. More than that and the loudness drops off precipitously. Unfortunately, manufacturing variance is probably more than plus-or-minus 5Hz, so that's a potential problem. The voltage supplied on the feedback pin of a piezo is only around 50mv, which is too low for an for an MCU to measure accurately without some kind of extra circuitry to help. It would be nice if the system could self-calibrate the driving frequency to match the inherent resonance frequency of the buzzer.

Meanwhile, I'm switching over to an H-bridge for driving buzzers, because an H-bridge not only efficiently drains the charge that builds up on the piezo buzzer but it also effectively doubles the peak-to-peak voltage seen by the buzzer. At these low voltages, more apparent voltage means more loudness.

When I started this project, I really didn't expect that the buzzer part of it would turn-out to require as much attention as it has! Sure, getting some amount of loudness is not a problem, but really maximizing loudness at these low voltages, while maintaining a tiny footprint and ease-of-assembly, isn't as easy as you'd think a priori.

[Larson]

@NeverDie said in Most reliable "best" radio:

It would be nice if the system could self-calibrate the driving frequency to match the inherent resonance frequency of the buzzer.

Perhaps an initialization User Interface selection? If the big picture is arranged and the region is only 5 Hz, then maybe a centeral default with an user option would be acceptable. Start slow, then rise in 0.25 Hz increments? If the user doesn't repond, then the default is mid-range. As in life, you can only help people so far. I think my mother tried to tell me that once.

Caveat User (Emptor).

[NeverDie]

@Larson said in Most reliable "best" radio:

@NeverDie said in Most reliable "best" radio:

It would be nice if the system could self-calibrate the driving frequency to match the inherent resonance frequency of the buzzer.

Perhaps an initialization User Interface selection? If the big picture is arranged and the region is only 5 Hz, then maybe a centeral default with an user option would be acceptable. Start slow, then rise in 0.25 Hz increments? If the user doesn't repond, then the default is mid-range. As in life, you can only help people so far. I think my mother tried to tell me that once.

Caveat User (Emptor).

You mean make it user selectable?

I'm toying with the idea of an initial calibration using equipment not on the PCB. That's how I arrived at the optimal frequency on my prototype. However, it's unpleasant listening to the frequency sweeps. Even my wife complained about it, and she was in a different room entirely. The only upside is that it's sure to work.

I found a good size for a shell, using a Govee temperature-humidity sensor:

It runs on a CR2477, so it has plenty of depth to it. Nobody seems to shell the shells though, and it would be a shame to canibalize their sensor just for the shell alone. I guess I'll have to 3D print something....

[nagelc]

Check out the Hammond 1551V1gY (vented) or 1151SNAP1GY (unvented).
They look like they are about the same size. I've been using the vented ones for temp/humidity sensors. Not as ugly as most project boxes.

[Larson]

@NeverDie said in Most reliable "best" radio:

The only upside is that it's sure to work.

Very, very funny. Fell off my chair, funny. I had a similar experience with testing buzzers only I failed to recognize the upside/benefit. I ended up putting a switch on the speaker effect to maintain domestic tranquility.

Yes, frequency user selection was my thought. It sounded like the mV range detection/optimization was too complicated. If the design gets close enough to the expected range, then punt to the user for fine tuning.

Shells: Unless a resonant cavity is important, how about a simple tic-tac container with a pre-drilled speaker hole and some hot glue? Maybe a pezz container, if they make those any more? Even a Gatorade bottle cap filled with epoxy might work (use cellophane to cover/embed the mechanical parts of the speaker.) Failure has taught me many things, and this is one of them.

[NeverDie]

Good suggestion on using a tic-tac container. It never would have dawned on me. Too bad I'm on a Keto diet, but I guess I could give the tic-tacs to my son, who doesn't need to diet.

I may have spoke too soon that the nRF52 isn't sensitive enough to read the feedback voltage precisely enough. It turns out to have a 0.6v internal voltage reference, and it has a 12-bit ADC, so in theory it could measure in increments of as little as 0.6v/4096=0.146millivolts. Is that good enough? I really don't know, but I'm going to give it a try. The closer the piezo gets to resonance, the more the feedback voltage should shoot up. I'd be counting on it shooting up by a lot when it hits resonance. So, I just now uploaded the files to a fab for a PCB which can do those measurements, and hopefully I'll receive it in about a week.

[NeverDie]

@nagelc said in Most reliable "best" radio:

Check out the Hammond 1551V1gY (vented) or 1151SNAP1GY (unvented).
They look like they are about the same size. I've been using the vented ones for temp/humidity sensors. Not as ugly as most project boxes.

Good find! I like the vented ones, as it look like they would let out a lot of sound.

[NeverDie]

@nagelc said in Most reliable "best" radio:

Check out the Hammond 1551V1gY (vented) or 1151SNAP1GY (unvented).
They look like they are about the same size. I've been using the vented ones for temp/humidity sensors. Not as ugly as most project boxes.

@nagelc I ordered the white version of the vented model you referred to so that I can give it an up-close looky-loo. I also found an interesting "similar but different" vented enclosure from New Age Enclosures, though at twice the price, which I also ordered for comparison:

https://www.mouser.com/ProductDetail/789-P1A-151510
With benefit of hindsight, maybe I should have started to look at possible enclosures from the get-go, because, depending on what's available, that may very well determine what form factors are even worth considering. i.e. the project will end-up needing to fit the enclosure, probably not the other way around.

[NeverDie]

I think I may now finally understand the purpose of the optional S0, LENGTH, and S1 fields in the nRF52 packet frame. The datasheet gives very little insight into them, so I had previously disabled those fields just to avoid the topic altogether because it seemed so obscure. However, in trying to figure out how to send/receive packets between an nRF52 and an old-style nRF24L01+, the puzzle finally makes sense: they are there to either 1. provide a means of compatability with the nRF24L01's Enhanced Shockburst, which puts a 9-bit field in the middle of the frame:

or 2. allows you to roll-your-own super Enhanced Shockburst with extra bits (in which case standard nRF24L01P ESB compatibility goes out the window). Well, for a host of reasons, I think nRF24L01p compatability is worth enduring an extra 9 bits of airtime, so I'll go that route and configure the nRF52 accordingly now that I've inferred what those fields are meant for.

[kirianjahiem]

I like your ideas. Is there a circuit for common mode rejection? It would be worth exploring. And using a test port for different pull-up resistors, better yet a variable resistor, would allow for testing.

[NeverDie]

Reporting back on the E01-2G4M27D radio's that I had referenced earlier. For those who don't remember, these are nRF24L01P radios that have been upgraded to use a 27dBa PA and, allegedly, other higher quality components (https://www.ebyte.com/en/product-view-news.aspx?id=450). 27dBa = 0.5 watt. For comparison, the maximum Tx power of a plain nRF24L01 is just 0dB. I had occasion to try them out today, and they appear to perform extremely well, even at 2mbps while transmitting over the worst-case transmission path in my house that I've been using to test all the radios on.

I'd venture to say that in terms of reliably getting a packet through to its destination, they outperform all other enhanced nRF24L01P's that I've ever tried previously. If you opt to try them on the test platform, as I have done, I recommend you upgrade your BoB capacitor to 100uF or 200uF, because 10uF doesn't seem to be enough when transmitting from somewhat weak batteries. Nonetheless , 10uF is sufficient if powering it from a really stiff power source. Ironically, they vastly outperform the 2.4Ghz LoRa radios that got me started on this whole mini-blog in the first place.

Looks as though you can buy them on sale at $4.59 each: https://www.aliexpress.com/item/2255800350626109.html?gatewayAdapt=4itemAdapt
No, they don't come with the antennas. You'll have to source those separately.

I'd say the main downside to these modules is that there does not appear to be any way to dial-down the transmission power, so that you only use as much power as you really need to fit your circumstances. There's no reason that such a module couldn't be designed and built (just as the RFM69HW allows), but, AFAIK, there aren't any on the market like that for the nRF24L01P. It's such an obvious enhancement that I'm surprised none of the vendors have offered it, even if it requires extra pins. Maybe someone reading this knows of one? If so, please post.

[NeverDie]

Doh! It just occured to me that rather than being a fixed output power, maybe these modules actually do have adjustable gain via adjusting the power output of the nRF24L01P:

That would perhaps mean that you could adjust the power output to be 27dB minus 18dB = 9dB? i.e. they effectively offer a gain of 27dB to whatever output power your radio chip already has? Is that how PA's work? Or, instead, would it just be blasting out mostly noise at 27dB if I were to set the nRF24L01P's output power to -18dBm? I'm guessing the former and not the latter, but unfortunately I don't have any radiated RF power measuring equipment that might tell me the answer. Anyone know? Perhaps measuring the current consumed during transmission would tell the tale, as one could infer the output power from that. Hmmmm...... Worth a try. Might be able to approximate the answer from that. If it turns out that they are adjustable in this manner, then I would think they are pretty awesome as a default "go to" module for just about anything. i.e. you'd have good communication even on the low-end of 9dB, but you would also have plenty of headroom to notch it up to a higher output power if it were truly necessary to cover whatever contingency you might run into, provided it remains within the legal limits of whatever your jurisdiction is.

I once tried (and reported on) a 4watt 2.4Ghz amplifier that you can buy on amazon, and it had a "sweet spot" for input power that it could amplify from, but below that sweet spot it didn't do much good at all. Perhaps that's a more accurate model of how this works in real life?

Looking at the manual, it does say the output power is multi-level software adjustable, so there's hope. https://www.ebyte.com/en/downpdf.aspx?id=450 I don't see that it offers any hints beyond that though.

[NeverDie]

Well, attempting to answer my own question above, here is the power profile of the E01-SG4M27D when the nRF24L01P is set to 0db (plus whatever power the PA on module boosts that to):

Here it is when the nRF24L01P is set to -18dBm ( (plus whatever power the PA on module boosts that to):

So, it looks as though the latter is the current is roughly 1/3 of the former, and since the voltage is the same, that would imply that the power is about 1/3 also. However, if my earlier theory was right, then the second chart should be showing a maximum of about 7.4mw, as compared to the theoretical 500mw of the first chart.

So, really, neither chart makes much sense. 3.3v x 580ma = 1.9 watts and 3.3v x 180ma = 0.594 watts. Well, I guess that's wrong if the radio module converts the 3.3v to a lower voltage for running the radio at via an LDO, which means it disappates the difference as heat. Still, the ratio between high and low Tx power is something like 3 to 1, whereas in theory it should be more like 67 to 1. So, I really don't know what to make of all that, other than the PA doesn't have much dynamic range to it. Does that extra power at the low end translate into proportioinately more radiated RF? I have no way of knowing, as this is the limit of what I can test with the equipmet that I have. I'd need something which can measure actual radiated RF.

This guy demonstrates how that might be done:
RF Power Watt Meter – 06:43
— 0033mer

In a nutshell, it would require both the power meter and, in this intance, an attenuator to go along with it.

I suppose an alternate, non-elegant way to solve the problem would be to have an array of different nRF24L01 modules, each optimized for a different power level. Then, by selecting the right CE pin, you could switch among them for the desired power level for a transmission. Not completely outlandish if size doesn't matter so much, because nRF24L01P modules, in whatever flavor, are generally fairly cheap--perhaps cheaper than buying the $80+ worth equipment needed to measure RF power that would probably be only one-time use. So, for a gateway, that might be a possibility. For a sensor node, probably not.

[NeverDie]

@NeverDie said in Most reliable "best" radio:

I think I may now finally understand the purpose of the optional S0, LENGTH, and S1 fields in the nRF52 packet frame. The datasheet gives very little insight into them, so I had previously disabled those fields just to avoid the topic altogether because it seemed so obscure. However, in trying to figure out how to send/receive packets between an nRF52 and an old-style nRF24L01+, the puzzle finally makes sense: they are there to either 1. provide a means of compatability with the nRF24L01's Enhanced Shockburst, which puts a 9-bit field in the middle of the frame:

or 2. allows you to roll-your-own super Enhanced Shockburst with extra bits (in which case standard nRF24L01P ESB compatibility goes out the window). Well, for a host of reasons, I think nRF24L01p compatability is worth enduring an extra 9 bits of airtime, so I'll go that route and configure the nRF52 accordingly now that I've inferred what those fields are meant for.

It worked! Well, sort-of. I have it working using the five byte address 0xE7E7E7E7E7, which dodges the question of how the address bytes are ordered over the air in one scheme versus the other. That's the next puzzle to solve. You might think this would be easy to solve, as I did, but so far not.

Here's part of what's weird (this is taken from the nRF52 datasheet):

Can you see the disconnect? On the nRF52 the LENGTH field comes in the middle of the 9 bits, whereas on the nRF24L01 ESB it comes at the front of the 9 bits.

Also, I haven't been able to get any non-repeating address to work yet. e.g. x0101010101 works, and so does 0xE7E7E7E7E7, but that's a rather limiting type of address to rely upon, though I suppose I could live with it if I had to. Go figure.

[Larson]

@NeverDie You are building a library. I don’t have the time to consume/enjoy it now as I’m deep in eldercare. But for sure, I’m coming back to your wonderful library to learn more – just later. Don’t interpret my silence as… indifference.

[NeverDie]

@Larson No worries. It works better with feedback from a knowledgeable audience, but... that entire audience has seemingly evaporated. Nonetheless, this rubber ducking may still have some value even under the current "everyone long gone" circumstances.

[NeverDie]

Aha! Apparently there is some kind of undocumented difference in the way addresses are represented in an nRF24L01P vs. an nRF5x. I found this address conversion function in Nordic's "micro-esb" library (https://github.com/NordicPlayground/nrf51-micro-esb/blob/master/common/micro_esb.c ) which holds promise for illuminating what that difference is:

and

Just from eyeballing it, nRF24L01P apparently transmits in the order of most significant bits first (which is undocumeneted), as compared to nRF5x, which transmits in order of least significant bits first (which is documented). Well, that would explain why xE7 (=B11100111), worked in my earlier addressing attempt, since it is the same either way.

Well, yes, though the algorithm is a two-step process. The bytewise_bit_swap function apparently reverses the ordering of bits in each byte, but leaves the bytes in the same order:

1111111111111111111111110100 -> 11110000111111111111111100101111
1111111111111111111111110011 -> 11110000111111111111111111001111
1111111111111111111111110010 -> 11110000111111111111111101001111
1111111111111111111111110001 -> 11110000111111111111111110001111
1111111111111111111111110000 -> 11110000111111111111111100001111

The radio address config section then reorders the sequence of the bytes. The net effect is the same as what I had guessed.
Well, this does explain why on the nRF5x, the "prefix" comes after the address section in the above diagram. My original impression had been that it was a poor choice of nomenclature.

Next I need to test this new theory on the hardware and see if it works.

[Larson]

@NeverDie said in Most reliable "best" radio:

I suppose an alternate, non-elegant way to solve the problem would be to have an array of different nRF24L01 modules, each optimized for a different power level.

Does the optimization mean different HW components with different RF_PWR settings? If the HW remains the same then one could incrementally change the RF_PWR level in the loop, right? Perhaps even by using two input pins one could control the RF_PWR level settings manually. The pins determine 00, 01, 10, or 11 and that gets fed to RF_PWR. That might be easier.

[NeverDie]

@Larson said in Most reliable "best" radio:

@NeverDie said in Most reliable "best" radio:

I suppose an alternate, non-elegant way to solve the problem would be to have an array of different nRF24L01 modules, each optimized for a different power level.

Does the optimization mean different HW components with different RF_PWR settings? If the HW remains the same then one could incrementally change the RF_PWR level in the loop, right? Perhaps even by using two input pins one could control the RF_PWR level settings manually. The pins determine 00, 01, 10, or 11 and that gets fed to RF_PWR. That might be easier.

Is your two pin solution referring to picking different modules, or to somehow adjusting the Tx power on one module? Not really following what you mean there. Since all the nRF24L01 modules use SPI, what I imagined was a separate chip enable line for each one, which would make it very easy to select among them. Indeed, that's the very definition of how SPI works. Straightforward.

[Larson]

@NeverDie said in Most reliable "best" radio:

two pin solution

Sorry, sometimes when I reread what I wrote, I don't understand it either.

My suggestion was to use only one radio and rotate different RF_PWR settings into the radio from the Atmega328p chip. That could be done by different means: 1. in the loop every 10 seconds or so for testing, or 2. by using GPIO pins defined as inputs, or 3. since we are talking radios, the power level could be transmitted to subject radio, read in code, and changed on the fly, or 4. any variety of other means (sensed light, temperature, vibration...)

For example, I'm looking at your barebones board right now. The radio module I'm using (RFM69HCW) is mounted on the first 8 pins of the headers that include SPI connections. Neighboring pins A0 and A1 on the barebones header are open and could be jumpered to GND (logic 0) or VCC (logic 1). The program on the 328 could sense those pins and select one of 4 power levels in the RF_PWR setting per the table you show above.

Hope that helps!

[NeverDie]

Reporting back regarding how to successfully transmit a packet from an nRF24L01P to an nRF5x, here's what I've confirmed (using the actual hardware) regarding the differences in how addressing is handled between the two different platforms:

Suppose the receiver address on a particular nRF52 (let us call it nRF52#1) is this:
prefix: 0x01
base-address: 0xACC01ADE
However, despite the name "prefix", we know from the datasheet that, from a temporal standpoint, when the over-the-air bits get sent, the prefix actually gets sent after the base-address. That means that if another nRF52 (let us call it nRF52#2) were transmitting an address meant to match nRF52#1, then the over-the-air bits, which are sent least-significant bit first on an nRF5x, would be sent as follows if you were writing them down left to right in temporal transmission order:
(reverse 0xACC01ADE) followed by (reverse 0x01)
Hence, from a certain twisted perspective it does make sense to call 0x01 a "prefix", because this is the same as:
(reverse 0x01ACC01ADE)

So, given that, the target Tx address, from the standpoint of an nRF24L01P, concatenated together, is the very same:
(reverse 0x01ACC01ADE)
because an nRF24L01P transmits in the order of most-significant-bit first.
As it turns out, this is equivalent to:
(reverse 0xDE) (reverse 0x1A) (reverse 0xC0) (reverse 0xAC) (reverse 0x01)
concatenated together.

That number turns out to be:
0x7B 58 03 35 80

QED.

HOWEVER, worthy of note: when you send that address over SPI from an atmega328P to an nRF24L01, the order of the bytes (but not the bits in the bytes) is again reversed. Confused yet? That means the temporal order of the bytes sent over SPI to the nRF24L01P is actually:
0x 80 35 03 58 7B
from left to right. i.e. 0x80 gets sent over SPI first, then 0x35, and so on. "Why is that?" you may ask. It's because, as per the nRF24L01 datasheet, the target address is sent LSByte first over SPI:

Regarding how to configure the S0, LENGTH, and S1 fields on the nRF52, it makes sense to do the following:
S0 = 0
LENGTH = 6
S1=3

because then the LENGTH field is properly alligned with the LENGTH bits transmitted by the nRF24L01.

[NeverDie]

To memorialize all that detail in easy to understand c-language code, here is a simple program which converts an nRF52 address into an equivalent nRF24L01P address that you can compile and run on any linux machine using gcc:

#include <stdint.h>
#include <stdio.h>

// This program defines a nRF5x address and converts it into an equivalent nRF24L01P address 
// so that a nRF24L01P radio can send packets to the nRF5x device.

// Define prefix and base-address for an nRF5x:
uint8_t this_Node_Nrf5x_Address[] = {0x01, 0xAC, 0xC0, 0x1A, 0xDE};

//Note: Node_Nrf5x_Address[0] is the prefix address, and the remaining bytes are the base-address.

// Define an equivalent address used by an nRF24L01 which, when transmitted, will correspond to the this_Node_Nrf5x_Address
uint8_t nRF24L01P_Tx_Address[5];


// Function that, given a byte, returns a byte with the bits reversed. 
// This function is derived from the function originally provided by Nordic Semiconductor (https://github.com/NordicPlayground/nrf51-micro-esb/blob/master/common/micro_esb.c)
uint8_t bytewise_bit_swap(uint32_t inp)
{
    inp = (inp & 0xF0) >> 4 | (inp & 0x0F) << 4;
    inp = (inp & 0xCC) >> 2 | (inp & 0x33) << 2;
    return (inp & 0xAA) >> 1 | (inp & 0x55) << 1;
}


//Convert from the given_Nrf5x_Address to the equivalent nRF24L01P_Tx_Address
void convertAddress() {
  nRF24L01P_Tx_Address[0] = bytewise_bit_swap(this_Node_Nrf5x_Address[4]);
  nRF24L01P_Tx_Address[1] = bytewise_bit_swap(this_Node_Nrf5x_Address[3]);
  nRF24L01P_Tx_Address[2] = bytewise_bit_swap(this_Node_Nrf5x_Address[2]);
  nRF24L01P_Tx_Address[3] = bytewise_bit_swap(this_Node_Nrf5x_Address[1]);
  nRF24L01P_Tx_Address[4] = bytewise_bit_swap(this_Node_Nrf5x_Address[0]);
}

//Given a pointer to an address array of 5 elements, print the address in hexadecimal
void printAddress(uint8_t *theAddress) {
  for (int i=0;i<5;i++) {
    printf("%02X",theAddress[i]);
  }
  printf("\r\n");
}

void main() {
	printf("nRF5x address:  0x");
	printAddress(this_Node_Nrf5x_Address);
	convertAddress();
	printf("equivalent nRF24L01 address:  0x");
        printAddress(nRF24L01P_Tx_Address);	
}

In this example, the output is:

nRF5x address:  0x01ACC01ADE
equivalent nRF24L01 address:  0x7B58033580

[NeverDie]

That's probably it for this thread. Proof of concept is working, and time to move on. Thank you to the few who had anything to say. Hopefully there will be more of a community again after the chip shortage is over. If not, I hope what has already been posted is at least preserved in some retrievable way so as not to be completely lost in the sands of time.

[Larson]

@NeverDie said in Most reliable "best" radio:

not to be completely lost in the sands of time.

Wish I could do more from my end. As long as this forum and the web exists... your library of knowledge will be of great value to me, and I presume, to others. I thank you!

[NeverDie]

Epilogue: It turns out that although I'm now able to receive packets on an nRF52 that are sent by an nRF24L01, the payload appears to be gibberish. Argh! So close, and yet no cigar. I thought it worth mentioning for anyone who happens to be following along. I'm fairly sure it must involve those mysterious S0, S1, and LENGTH bit blocks, but as there's virtually no documentation on this aspect of things, a solution will either involve extensive troubleshooting or else locating some relevant code and figuring it out from that. In the end, I'm not sure it's worth the effort. I may just stick with plain vanilla nRF52-to-nRF52 communication, as that much is working fine and without further hassles.

[Larson]

@NeverDie A young Scott Harden taught me, via Youtube how to use a soundcard and Audacity recording SW as an o'scope. He would transmit a known preamble followed by a known pattern. I think this can be done in OSK, FSK, OOK. When the data is in Audacity, or an o'scope, then you can take your time to learn the timing of the transmitted and received signal. Seeing is believing, for me.

[NeverDie]

@Larson Although I haven't tried it myself, I have my doubts that a soundcard would work for recording signals sent at 2mbps, if only because that is way outside the spec for normal sound recordings. However, for slow signals, yes, I can believe it would work.

There are also software defined radio receivers that would probably do a good job of receiving and, with the right software, displaying signals. Certainly HackRF One would be one such device that could do it. I haven't tried that either, but it was designed for the purpose. IIRC, Andreis Speiss did a video on using a cheap ($10-$20) SDR to receive and decode some fairly basic radio packets. Maybe it would display them as well.

[Larson]

@NeverDie If I remember correctly, I was working on 433 MHz radios at the time - so a little slower rate. The sampling rate available though Audacity was way more than I needed to see the digital signal. At the time it was my first introduction to digital radio. And, in life so often, the first experience is the best. And it helped me realize that more advanced SW/HW like the PPKII depend on the same sampling of a signal. Pretty danged cool.

[NeverDie]

@Larson About 10 years ago I did it using the A2D on an Arduino Due once for a simple 433Mhz OOK receiver. It worked well enough. Like you, it was my first experience doing such things. The hardware was so basic that it was a software-only radio from the mac layer up. The Due was fast enough that I could detect both the original signal (shortest path) and subsequent bounced signals (multipath) as separate entities. I still think it's pretty cool.

[Larson]

@NeverDie Sorry for the slow response/question. Elder care still demands the day(s).

Is the bounced signal physical? Or is it electronic reflection? I suppose it would be difficult to decipher.

[Larson]

@NeverDie Here is a view of what the Power Profiler Kit II sampler (100,000 samples/second) could see. This is my 433 MHz radio/motion-detector rig picking up motion and sending a HT12E 12-bit address/data byte. Really fun to see that the ones and the zeros can be clearly seen in the FSK profile of the measured current of the device.

[NeverDie]

@Larson That's pretty cool. I suppose if it were OOK, you wouldn't even need a receiver to see the contents of a transmitted packet. You could maybe check your garage door opener or one of the cheaper TH sensors. Or check an IR transmitter to see what pattern it's sending.

[Larson]

@NeverDie Excellent thinking on the signal detection. I think I'm going to build a garage door repeater. While the signal probably has some kind of encryption, maybe all I need to do is to repeat the same signal. But before I do that, I’ve got to return to the radio project you inspired. Elder-care has all of my time for now.
My description above was a bit cryptic. What I marvel at is that I was only measuring the device power and didn’t know the transmitted code would be revealed in the power profile. But that makes sense now for most any battery powered transmitter including OOK, ASK protocols. As such your thought about detecting codes from TV remotes to garage doors would apply just by measuring the power battery power to the device. Effectively the PPKII becomes an O’scope.

[NeverDie]

@Larson Unless you have a really ancient garage door remote, your garage remote most likely uses some kind of rolling code that's intended to prevent a simple playback attack. Unless you happen to know the packet/frame layout, and probably the algorithm as well, then reverse engineering it can be quite time consuming. I once did it for a consumer soil moisture sensor, and it was damn hard. Reading the bits wasn't hard, but figuring out the semantics represented by those bits took quite a bit of effort--way more than it was worth, as I subsequently discovered the sensor didn't have good accuracy in the first place. A bit ironic, as there was no way to discover that until after I had the detailed data that had previously been inaccessible.

[Larson]

@NeverDie said in Most reliable "best" radio:

your garage remote most likely uses some kind of rolling code

Yep, that's me. I figured the relay/repeater would echo the same rolling code in-and-out without having to figure it out. I've got enough earthly bound problems that are hard enough, so I'll take your advice and spend my festering curiosity on something more productive. But still ths PPKII is pretty danged cool.

[NeverDie]

@Larson What all does the elder care entail? If it's just supervision, maybe you can provide it using your automation skills. Obviously, something better than merely, "I've fallen down and can't get up!"

[Larson]

@NeverDie said in Most reliable "best" radio:

What all does the elder care entail? If it's just supervision, maybe you can provide it using your automation skills.

Thanks for asking. Yea, I thought of assigning a robot to the task of caring for my mother, but then I would be cast to the dungeon of my own making. Broken-hip, surgery, Rehab, Discharge - it is complicated and demanding. Fortunately we have skilled nursing and CNA's to do the bulk of the hard work. But getting mom's 'extended' taxes done, pain management intervention, arranging for PT, OT, Surgeon follow-up, rehab facility discharge, hemotologists, PCP's and where to land... it is a full time job. And then there is emotional support visits for the patient, my mom, while stress among sibilings and spouses becomes damaging. We all live too long.

Yea, programming radios is my relief: develop, test, then correct. Far less human, and far more certain and way more fun. And when you are done for the day... you simply go to sleep. Sweet!

I've been rereading this thread this evening. I'm glad for the record as I can relearn - even from myslef. So many great ideas that need further work by me. My 433 ASK transmitters are now controlled by 328P chips because the transmit times can be limited to 200 mS at about 6mA. I know, some of your radios can transmit faster but I'm just now divorcing my HT12E and HT12D chips and that is going to take time. Baby steps.

On my new config (Barebones/SR501 motion detector/433 transmitor, the sleep current seems to be about 62 uA and that supports the SR501 motion detectors. That power dominates the energy profile of the device and is near the shelf-discharge of the battery - so it doesn't deserve much study. But the speed of the radio transmission does warrent further study since that is the high current period.

[Larson]

It has been a long time but I’ve learned a few things that I wanted to share.

1. This library of information (Thank you NeverDie and others) has been so helpful in my hobby developments.
2. Software Defined Radios for signal analysis. With the help of Andreas Spiess explanation of IQ transformations, I learned about Software Defined Radios and I bought one (RTL-SDR). Using this I can clearly discriminate between effective 433 MHz transmitters and bad ones. Not only is the signal density displayed on the software (SDR#) but so is the frequency.
3. Power Profiler Kit II has been indispensable in watching power usage and seeing into the details of the radio transmission. In effect this thing has saved me from buying an oscilloscope for my simple little bench.
4. Tonight, I saw this video: https://www.youtube.com/watch?v=Z9nycymUd-I It describes common PCB errors. It is too advanced for me, but I did pick-up a few ideas about ground planes (tip #6 from the video).

I hope this is of some value for folks.