Posts made by NeverDie

@eiten I haven't yet made any progress on finding a good VOC sensor, but along the way I did find out something interesting regarding CO2: namely, if you sleep with your bedroom door closed at night, then the odds are good that the CO2 levels rise to surprisingly high and unhealthy levels.

The better CO2 sensors are factory calibrated and never again need recalibration for the life of the sensor (usually around 10 years or so), because they are used in HVAC systems to control fresh air intake to guarantee indoor air quality. As a for instance, here is one such CO2 sensor: https://www.digikey.com/en/products/detail/senseair/006-0-0008/15790694 At around $50 for just the sensor element itself, it's not exactly cheap, but then again, I'd say it's worth it, because who wants to be burdened by remembering to calibrate their CO2 sensors?

Ideally, I'd like to find a sensitive VOC sensor that also will never require calibration.

Nearly all, and maybe all, of the off-the-shelf IAQ montoring stuff that you might buy for, say, $300 or less seems to require periodic calibration. For that reason, this might be one of those occasions where build is rather than buy.

I purchased a number of different consumer-ready off-the-shelf VOC monitors (priced in the range of $100-$300) from amazon for detecting the presence of VOCs (volatile organic compounds) in the air, and I'm finding that most of them detect very little of what's in the air, even if it's something I can plainly smell. What I want is a sensor (a canary in the coal mine) that will alert me as to whether there might be something in the air that I should be concerned about. From that point I would then have the somewhat arduous job of figuring out what it is. However, if I don't know it's there in the first place, then I'll never know to look further. So, I guess what I'm looking for is a sensor that's sensitive to a wide assortment of VOCs. Any recommendations?

Of possible interest: Here's a guy who is building an inexpensive open source ethernet controller for stepper motors:
What happend to Ethersweep? Project Update! – 12:36
— Neumi

If you listen to the end, it's revealed that there is now generous funding available which allows people to do this kind of open-source development as a full time job, which is what he is now doing. For that reason, I think there's a good chance he will complete his project within the allowed 6 months., and so by the deadline it will likely be nicely polished.

@skywatch said in Awesome tip: run LinuxFX instead of Windows!:

@NeverDie Thanks - Interestingly they show a free version on their site still. Did they revert due to bad publicity?

https://www.linuxfx.org/

I stopped following it, but I seem to recollect that the free version was noticeably missing things--otherwise, who'd buy the paid-for version? Anyway, its standing on Distro-watch has fallen considerably. It may seem unfair to niche distros, but I think it's generally better to stick with the more popular distros, unless you have good reason to choose otherwise.

Some humidity sensors are known to lose accuracy with age. For instance, the Si7021 is known to have this problem. If that matters to you, then the best choice is to pick sensors that have datasheets and which have specs as to their expected longevity or accuracy over time. Then buy from mouser/digikey to be certain you're getting the real thing rather than factory rejects or counterfeits.

For extra insurance, I avoid electrolytic capacitors entirely whenever possible. I buy only 7XR rated ceramic capacitors that are overspec'd. The difference in price is small compared to a failure down the road.

@skywatch said in Awesome tip: run LinuxFX instead of Windows!:

@NeverDie So how is it going for you? Have you tried USB devices with it? Did they work well? I am thinking of being able to run Win x64 SDR software on this but still wonder if it will work - Will try it out as soon as I can and report back. Meantime any hints or opinions you have would be good if you can share.

Sometime after I made the original post the LinuxFX people decided they wanted to charge people money for their flavor of the OS. As near as I can tell, it kinda imploded after that. So, I settled on Linux Mint (Cinnamon version), and I'm happy with it. I still use Windows for programs that are only supported to run under windows, like Fusion360, rather than try to use wine to get it to run under Linux, but for everything else Linux Mint works great. Fast, stable, and without all the sluggishness you typically get (sooner or later) with Windows.

I haven't confirmed whether the offered solution will work or not, but it took only one second to generate, so on that basis alone I'm impressed.

Anyone here using chatgpt for actual coding of any kind?

By way of example, I gave this prompt:

Without using zephyr, write a program for the nrf52840 to send a "Happy Birthday!" text message using the proprietary radio mode.

and chatgpt's response was:

To send a "Happy Birthday!" text message using the nRF52840 in proprietary radio mode without using the Zephyr RTOS, you can use Nordic Semiconductor's nRF5 SDK. Here's a basic example of how to create a custom radio communication program for the nRF52840. Please note that this code is a simplified example, and in a real-world scenario, you would implement error handling and more robust communication protocols.

Transmitter (TX) Code:

#include <stdint.h>
#include <stdbool.h>
#include "nrf.h"
#include "nrf_gpio.h"

#define RADIO_CHANNEL 76  // Choose a custom channel

void radio_init(void) {
    NRF_RADIO->TXPOWER = RADIO_TXPOWER_TXPOWER_0dBm;
    NRF_RADIO->FREQUENCY = RADIO_CHANNEL;
    NRF_RADIO->MODE = RADIO_MODE_MODE_Nrf_2Mbit;
    NRF_RADIO->SHORTS = 0;
    NRF_RADIO->PCNF0 = (1 << RADIO_PCNF0_LFLEN_Pos);
    NRF_RADIO->PCNF1 = (1 << RADIO_PCNF1_WHITEEN_Pos) | (3 << RADIO_PCNF1_BALEN_Pos);
    NRF_RADIO->BASE0 = 0xE7E7E7E7;
    NRF_RADIO->BASE1 = 0x43434343;
    NRF_RADIO->PREFIX0 = 0x55443322;
    NRF_RADIO->TXADDRESS = 0x00;
    NRF_RADIO->RXADDRESSES = 0x01;
}

void radio_send(const uint8_t *data, uint8_t length) {
    NRF_RADIO->PACKETPTR = (uint32_t)data;
    NRF_RADIO->EVENTS_READY = 0;
    NRF_RADIO->EVENTS_END = 0;

    NRF_RADIO->TASKS_TXEN = 1;
    while (NRF_RADIO->EVENTS_READY == 0);

    NRF_RADIO->TASKS_START = 1;

    while (NRF_RADIO->EVENTS_END == 0);
    NRF_RADIO->EVENTS_END = 0;

    NRF_RADIO->TASKS_DISABLE = 1;
    while (NRF_RADIO->EVENTS_DISABLED == 0);
}

int main(void) {
    nrf_gpio_cfg_output(20); // LED on pin 20

    radio_init();

    while (1) {
        // Message to send
        uint8_t message[] = "Happy Birthday!";
        uint8_t message_len = sizeof(message) - 1; // Exclude null-terminator

        // Send the message
        radio_send(message, message_len);

        // Toggle an LED to indicate a transmission
        nrf_gpio_pin_toggle(20);

        // Delay between transmissions
        for (int i = 0; i < 1000000; i++) {
            __NOP();
        }
    }
}

Receiver (RX) Code:

#include <stdint.h>
#include <stdbool.h>
#include "nrf.h"
#include "nrf_gpio.h"

#define RADIO_CHANNEL 76  // Should match the transmitter's channel

void radio_init(void) {
    NRF_RADIO->TXPOWER = RADIO_TXPOWER_TXPOWER_0dBm;
    NRF_RADIO->FREQUENCY = RADIO_CHANNEL;
    NRF_RADIO->MODE = RADIO_MODE_MODE_Nrf_2Mbit;
    NRF_RADIO->SHORTS = 0;
    NRF_RADIO->PCNF0 = (1 << RADIO_PCNF0_LFLEN_Pos);
    NRF_RADIO->PCNF1 = (1 << RADIO_PCNF1_WHITEEN_Pos) | (3 << RADIO_PCNF1_BALEN_Pos);
    NRF_RADIO->BASE0 = 0xE7E7E7E7;
    NRF_RADIO->BASE1 = 0x43434343;
    NRF_RADIO->PREFIX0 = 0x55443322;
    NRF_RADIO->TXADDRESS = 0x00;
    NRF_RADIO->RXADDRESSES = 0x01;
}

void radio_receive(uint8_t *data, uint8_t *length) {
    NRF_RADIO->PACKETPTR = (uint32_t)data;
    NRF_RADIO->EVENTS_READY = 0;
    NRF_RADIO->EVENTS_END = 0;

    NRF_RADIO->TASKS_RXEN = 1;
    while (NRF_RADIO->EVENTS_READY == 0);

    NRF_RADIO->TASKS_START = 1;

    while (NRF_RADIO->EVENTS_END == 0);
    NRF_RADIO->EVENTS_END = 0;

    NRF_RADIO->TASKS_DISABLE = 1;
    while (NRF_RADIO->EVENTS_DISABLED == 0);

    *length = NRF_RADIO->RXMATCH;
}

int main(void) {
    nrf_gpio_cfg_output(20); // LED on pin 20

    radio_init();

    while (1) {
        uint8_t message[16]; // Adjust the buffer size as needed
        uint8_t message_len = 0;

        // Receive a message
        radio_receive(message, &message_len);

        // Toggle an LED to indicate a reception
        nrf_gpio_pin_toggle(20);

        // Process the received message (e.g., print it)
        if (message_len > 0) {
            message[message_len] = '\0'; // Null-terminate the received data
            printf("Received: %s\n", message);
        }
    }
}

This code sets up a transmitter (TX) and receiver (RX) using the nRF52840's radio peripheral. The TX repeatedly sends the "Happy Birthday!" message, and the RX receives and prints any incoming messages. Make sure both devices are configured to use the same radio channel and have matching radio settings.

Remember to adapt this code to your specific hardware setup and application requirements, and consider adding more robust error handling for a production-quality solution.

Supposedly PIR doesn't work through glass (e.g. if looking for motion through a window), whereas I presume a microwave sensor might still work.

^^^This. Good point. Maybe do some testing with RadioLib to see whether or not you experience the same problem.

Contrast that 65535 step resolution to the 255 step duty-cycle resolution on Arduino's, and that is a big improvement for control of, say, a DIY DC-DC converter. For instance, if you want to build your own DIY solar MPPT boost converter (good luck finding one to buy in the commercial market. Probably 99%+ of those are step-down MPPT controllers, with only a rare bird being a step-up MPPT controller). The pi pico's are just $4 each at mouser and Adaruit ( https://www.adafruit.com/product/4864 ) for the genuine article, not some sketchy knock-off. Just thought I'd mention it, as I think most people aren't aware of it. I'm not sure whether or not a more stripped down version of the pi pico would consume significantly less current. If so, then it might be quite compelling: a fully formed pi pico board for $4 vs. an atmega328p chip alone for $3 (note: as a reference, these are present market prices on mouser).

@haxn2 I don't recall there being any problems of the type you describe. You didn't say what kind of "trouble" you were having, but, if anything, the high coding factor and narrow bandwidth should improve range, unless there is interference in the narrower band. Have you tried changing the frequency? Are you sure you're using a suitable antenna? Exactly what kind of range are you trying to achieve?

I don't know what guidance is being given in other countries, but here in the US the CDC is still endorsing the use of cloth masks, even now 3 years into this debacle:
https://www.cdc.gov/coronavirus/2019-ncov/prevent-getting-sick/types-of-masks.html

At the grocery store and other retail, I still see some people wearing cloth masks....

Worthy of note:
Masks, no evidence they work – 14:59
— Dr. John Campbell

TL;DR: It turns out that masking had essentially no efficacy. It blows my mind. How can it be that the mainstream got so much so wrong for so long about covid? And, more importantly, what should we have done instead?

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

@NeverDie I have noticed that in the latest version of your adapter you have lowered the capacitor value used for the first stage filtering from 100uF to 10uF, leaving the second stage one to 0.1uF. Did you have empirical benefit in tests with this configuration? 0.1uF it seems to me at first glance too small to accommodate current draw fluctuation of this module. Would be appreciated if you explain your design choice. Thank you.

The 10uF isn't for filtering. It's just to prevent voltage droop at the radio when the radio starts to pull current. So, yes, testing reveals that it seems adequate for that purpose. I originally slotted in 100uF because I wasn't sure, and overkill is better than underkill. It's possible that 10uF may also be overkill....

Reporting back: I have my BambuLab X1C printer setup and have printed with it for about a week. It's fantastic: it's fast, and the prints come out perfectly every time. Truly an appliance: it works with only minor setup straight out of the box. I'd say it's a quantum leap better than my Prusa MK3S, which I guess I should try to sell while it still has value.

I would think that it's the ambient air temperature that affects how much condensate you collect, together with how much fuel was burned. After the initial warm-up that gets you to steady state, wouldn't the efficiency be constant?

If the acidity is a problem, you can run the condensate over a bed of acid neutralizing rocks before it goes down your main drain. It's a thing.

Some kind of through-beam sensor might work: https://www.amazon.com/Optical-Endstop-Photoelectric-Control-Printer/dp/B07MFT8NWJ/ref=asc_df_B07MFT8NWJ/?tag=hyprod-20&linkCode=df0&hvadid=241938907421&hvpos=&hvnetw=g&hvrand=9189408107204898573&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9028292&hvtargid=pla-664653941028&th=1

I once was interested in the same sort of thing for monitoring the effluent from a reverse osmosis filter at the air-gap to confirm that it wasn't wasting a lot of water. In my case there turned out to be an easier way.

If it drips slow enough, maybe a simple photocell and led could be used to count each drip as it drops in-between. Use arduino analog input to look for a drop in the light intensity. i.e. a simple electric eye.

@gregvp said in Fork of BigClive AA Battery Trickle Charger:

I have a project on my list to make a NiMH capacity tester using as the load a boost regulator loaded with a range of resistors. But at my current rate of progress through the list, I'll be dead first.

Luckily, if you want to do some testing before you die, you can get pretty decent load testers for cheap these days. Not sure how accurate they are in an absolute sense, or how accurate you would need them to be for your particular purposes, but for anything I do they seem "good enough" and provide repeatable capacity numbers.

https://www.aliexpress.us/item/2255800047204598.html?spm=a2g0o.productlist.0.0.1e963f191wOpcX&algo_pvid=8930e84c-2b17-4afd-9458-68d1aabbc9bc&algo_exp_id=8930e84c-2b17-4afd-9458-68d1aabbc9bc-20&pdp_ext_f={"sku_id"%3A"10000000947167753"}&pdp_npi=2%40dis!USD!13.43!9.67!!!!!%402101d8b516678388477845208e191c!10000000947167753!sea&curPageLogUid=kEzSSWx2qqOU

I agree with your comments regarding the likely use of niMH batteries. Not sure what load to pick, but I do need to pick some kind of reference load--maybe 1C?--so that I have some way of gauging whether or not the cells kept 24/7 in the forked BigClive trickle charger degrade noticeably more than cells which aren't. In the end I suspect Calendar aging will be the biggest effect, but I won't know for sure unless I run the experiment.

@mfalkvidd As near as I can tell, there's is commonly a conflation of ideas that really should be separated. According to Dave Jones here:
EEVblog #515 - Battery Ionic Resistance Investigation – 27:52
— EEVblog

internal resistance (at least in the case of a 9v battery) 1. is quite small, and 2. doesn't vary much if at all over the life of the battery. Apparently it is what's measured with the 1kHz signal. However, what is much larger than that is what he calls "ionic resistance", which has to be measured under load. So..... I'm not sure which of those two, or what mix of those two, the battery charger is measuring. I've tried two alternate battery chargers for measuring "IR", but they each appears to measure different numbers.

The number I rely on the most is usuable mah in a battery that's arrived at by a constant current discharge, and I use an OPUS BT-C3400 to measure that. Its a repeatable number, and it's definitely a useful number. However, I'm unsure as to what value the "IR" number has, but I'm collecting it anyway in case I/we eventually figure it out, or else figure out how to measure it in a way where it has actual usefulness. So far it seems like "ionic resistance" is the more useful concept, because it indicates how much the voltage drops under a particular current load, and, anecdotally, that voltage drop does seem to be less when a battery is new or almost new as compared to when it is older and closer to failing.

Plainly, the voltage drop is greater the greater the current draw, so I'm developing skepticism that there really is a single number that represents battery health in that regard. Perhaps the only number that matters is the voltage drop that a particular application experiences from the current that it happens to draw? At the moment, I'm leaning toward that hypothesis. i.e. there is no single context free number that has meaning. Instead, maybe pick your own test conditions that have meaning for your particular application, and measure that instead. Not entirely sure though. Everybody knows that you should measure battery voltage under load, but exactly what load and for how long it should be applied before taking the voltage measurement..... I'm not aware of any standards in that regard.

Actually, the closest thing I've found to answering this question comes from putting LiFePO4 batteries under high load and seeing how they respond:
The Final Word On Grade B - Lifepo4 cells Grade A vs Grade B - SFK – 33:33
— Sun Fun Kits LLC

In that video a guy who claims to have tested thousands of LiFePO4 batteries claims it to be the method he uses to separate "Grade A" cells from "Grade B" and below cells. First he fully charges the battery, then he hits it with a 100a to 200+a load to see how it reacts. If the voltage in a cell then sags below 3.2v during that load test, then according to him it's not a "Grade A" cell. He also looks at how quickly a cell "snaps back" to inits initial voltage after the loading stops. My point is: he's looking at battery dynamics; he's not measuring a single number to determine how "good" a cell is. On the other hand, I would imagine that any sort of dynamic could be reduced to a number using mathematics....

So.... that's how a pro does it. Unfortunately, his method is more like a comparison of battery dynamics, centered around what is EVE certified as "Grade A" rather than arriving at a single hard number, but even so it's an enlightening youtube video--better than the meandering eevblog youtube video IMHO.

I suppose I could come up with a similar test for NiMH batteries, but it would be derived from a similar method of making dynamic comparisons against "known good" high quality Eneloop cells rather than referencing a single IR hard number spit out by a battery charger. That is.... unless someone here has a better way. If so, please post!

@mfalkvidd Presently, I'm just reading the IR value off the charger (see photo above), on the assumption that whoever designed it knew what they were doing (not always a good assumption). For instance, in the above photo you can see that it is reporting 72millohm on the cell in position #8 (the rightmost cell). By changing the slot selection, I'm able to read the millohm measurements off of each of the other cells in slots 1 to 7 as well.

Reporting back:

I purchased brand new Amazon Basics that I'll use to trial this charger:

I'll be recording both their internal resistance and capacity prior to the start of the test, and then measure them again somewhere down the road to see how they do or don't degrade relative to a control group of cells from the very same batch of brand new Amazon Basics NiMH rechargeable batteries. Not sure how long will be long enough to trial this method of charging. Any suggestions? Otherwise, I'll just re-test them whenever the spirit moves me to do so and report back at that time.

I understand that BigClive meant for this to be a simple design and a simple project, but depending on how the trial goes a a refinement might simply be to insert a circuit which charges them for, say, an hour or two each day rather than charge them continuously. Of course, you can easily buy off-the-shelf timers to accomplish that already, so that might be another way to arrive at an equivalent solution without needing to make any changes to the circuit board.

Anyhow, I rather do like the idea of having fully charged AA batteries always available.

Is battery internal resistance a meaningful measurement? I ask because I have yet to find a battery charger that measures internal resistance in a repeatable way. Is there a better, more repeatable wayt to measure it? As you can see from my markings in the photo above, the reporting internal resistance on each of gthe batteries is already all over the map, with a low of 52milliohm and a high of 90milliohm.

@mfalkvidd If things go sideways in the "you know where" region of eastern Europe, such that they affect Sweden, feel free to open a thread and ask for help. I'm sure everyone on this forum will do their best to get you any information or other resources you might need to adapt to events as they develop.

This youtube is perhaps a little tangential, but I found it both informative and entertaining to watch. It makes an argument for why you'd want to have a stand-alone GPS (no, not the usual "connected" one in your phone) for use in emergency scenarios:
Why Everyone Needs a GPS – 27:34
— T.REX ARMS

This youtuber also has a great sense of humor and demos some interesting products.

FWIW, the Red Cross recommends everyone should have paper maps as a backup, but these days who keeps up-to-date paper maps anymore? What this youtuber describes might make more sense as an alternative to paper maps, and he gives a compare/contrast as to why.

Although he didn't cover it, I'm fairly sure there's a way to download google maps to your phone so that you can be stand-alone that way, and this method wouldn't require any added expense (provided you have enough spare storage in your phone).

The same guy also did an interesting overview of emergency radio communications, which is very much on-topic for this thread:
An Introduction to Radios and Emergency Communication – 21:25
— T.REX ARMS

@JeeLet The Things Network claims 89,623 gateways connected via LoRaWAN: https://www.thethingsnetwork.org/map

Although it may sound wild to those not closely following current events, here's the Reuter's headline: "Russia strikes Ukrainian infrastructure, says it may destroy Western satellites"
https://www.reuters.com/world/europe/russia-hits-ukraine-homes-evacuates-kherson-warns-escalation-2022-10-24/

Considering Starlink's current use and with the sabotage of Nordstream 2 as context.... It would certainly be provocative, but civilian infrastructure apparently isn't deemed escalatory, so for that reason it's maybe not far-fetched. i.e. AFAIK, there is no "Article 5" equivalent in NATO that would be triggered, so Starlink is a sitting duck if it continues with its status-quo. It would probably take only one satellite getting fried for Starlink to shift its policy, and so I'm guessing that would happen first as a demonstration of resolve, with the threat of taking down the entire thing, or maybe one at a time, as leverage. Elon Musk can save face, because it will be his board of directors that overrule him. Ironically, giving it away for free makes it a no-brainer decision for any board of directors in a for-profit company to simply end it entirely.

Anyway, here's the TLDR: if satellite internet is anybody's "Plan B", then FWIW you may need a "Plan C"--such as discussed above in earlier posts--as a fallback. Even more so if you happen to live in Ukraine.

How many of each PCB did you order? I've found that factors into the build time. On JLCPCB, if you order just 5 of each board, thebuild time is usually 24 hours or less. If the build number per board is >5, then I've found the build time is kicked up to 48 hours (sometimes longer).

I haven't encountered any errors in the PCB's that JLCPCB fabbed, whereas one set of boards fabbed by PCBWAY was drilled incorrectly, so for that reason I've gone back to JLCPCB. Even if it sometimes takes longer, it's better to have it done right.

Reporting back: for an emergency receiver, the radio I settled on was the Crane Skywave SSB Shortwave:
https://www.amazon.com/gp/product/B07HXKR479/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

because the youtube reviews were extremely positive, because it runs for 30 hours on a pair of AA batteries, because of its compact size and light weight (good for travel), and because it comes with a 20 foot long external antenna on a compact spool for pulling in long-distance HF and Shortwave. As it would be most beneficial in a mega-disaster, I'll be glad if I never have a reason to actually use it.

For those in US, an additional radio worth getting is the Reecom R-1630C emergency alert radio.
http://www.reecominc.com/r1630.htm
It has S.A.M.E. and will listen for a broad range of emergency alerts specific to the counties you program it for. It can run for 200 hours on one set of AA batteries, and, crucially, unlike the Midland radio I already have, it cuts off the announcement automatically when it reaches the End of Message (EOM). In contrast, my Midland continues playing the NOAA weather broadcast for 5 minutes before it times out, which is irritating whenever it sounds off due to a thunderstorm warning, flash flood warning, tornado watch, etc. There are enough of them for sale on ebay that you can get one for cheap there. I just today picked one up there for $20. Curiously enough, I've lately noticed that my Alexa now warns me about severe weather even before my NOAA radio does. Incredible! I had thought that by design NOAA was supposed to be fastest of all, but these days the evidence proves otherwise. In addition to weather, it covers the gamut of other warnings as well--everything from earthquakes to civil emergency to radiological threats to fire warnings to evacuation alerts: https://www.weather.gov/nwr/eventcodes Depending on where you live, some of those might be more relevant than others. For instance, I don't live anywhere near a nuclear power plant, but there are some in my state, and I suppose if the wind blew in the wrong direction after a meltdown, I'd probably get an alert--hopefully long before the fallout lands in my backyard!

In terms of low cost gear, the Tecsun PL330 would seem to cover most of the bases: https://www.amazon.com/gp/product/B0921HN6QM/ref=ox_sc_saved_image_4?smid=AMH4W1K8OCGMX&psc=1
or possibly: https://www.amazon.com/Skywave-Shortwave-Weather-Airband-Portable/dp/B00QMTI6YK/ref=sr_1_15?crid=MU1ILCRMY0F3&keywords=aa+shortwave+radio&qid=1666551448&qu=eyJxc2MiOiIwLjAwIiwicXNhIjoiMC4wMCIsInFzcCI6IjAuMDAifQ%3D%3D&sprefix=aa+shortwave+radio%2Caps%2C131&sr=8-15&ufe=app_do%3Aamzn1.fos.006c50ae-5d4c-4777-9bc0-4513d670b6bc

What it's lacking is a PC input for decoding CW (morse code) and other digital communications. I'm quite surprised that doesn't come built in, but I don't see any low-end devices which offer that. So, for that one could use a cheap SDR receiver (like RTL-SDR v3), but then you've got the energy drain of a PC or laptop for that to function, so I'm not sure. It would be almost half the cost though, and with the right software I suppose it could receive most things, including digital communications: https://www.amazon.com/RTL-SDR-Blog-RTL2832U-Software-Defined/dp/B011HVUEME/ref=sr_1_3?crid=1MSELINZYV738&keywords=RTl-SDR+V3&qid=1666549671&qu=eyJxc2MiOiI0LjA3IiwicXNhIjoiMi43MCIsInFzcCI6IjIuMjcifQ%3D%3D&s=electronics&sprefix=rtl-sdr+v3%2Celectronics%2C119&sr=1-3
I have the original RTL-SDR from way-back-when, but this would be an upgrade to that. Maybe with an old raspberry pi attached, the total energy drain would be acceptable if you have some minimal amount of solar power to draw upon. Not sure. Some people seem to prefer a cheap laptop for this purpose: https://www.amazon.com/Evolve-III-Maestro-Book-Celeron/dp/B0B3GHTDN2/ref=sr_1_1?crid=2LSW1S3O23SCP&keywords=maestro+iii+evolve&qid=1666550241&qu=eyJxc2MiOiIwLjYwIiwicXNhIjoiMC4wMCIsInFzcCI6IjAuMDAifQ%3D%3D&s=electronics&sprefix=maestro+iii+evolve%2Celectronics%2C124&sr=1-1&ufe=app_do%3Aamzn1.fos.006c50ae-5d4c-4777-9bc0-4513d670b6bc

A more traditional emergency radio would be: https://www.amazon.com/5000mAh-Digital-Emergency-Shortwave-Flashlight/dp/B08SWF34ZF/ref=sr_1_10?crid=3RK52R7MKFG6Y&keywords=voyager+digital+emergency+radio&qid=1666550690&qu=eyJxc2MiOiIxLjgxIiwicXNhIjoiMC4wMCIsInFzcCI6IjAuMDAifQ%3D%3D&s=electronics&sprefix=voyager+digital+emergency+radio%2Celectronics%2C138&sr=1-10 No access to HF or HAM, but if what I wrote in the post above is true, then that's junk anyway. However, you probably want something that can run from AA batteries rather than some kind of proprietary battery that might be dead when you need it. The midland comes with a LiPo battery, but also allows the use of 6 AA batteries as an alternative: https://www.amazon.com/Midland-Emergency-Multiple-Flashlight-Ultrasonic/dp/B015QIC1PW/ref=sr_1_1_sspa?crid=3TZ6I1JCU1YHM&keywords=midland+emergency+radio&qid=1666551871&qu=eyJxc2MiOiIzLjYyIiwicXNhIjoiMy4xMSIsInFzcCI6IjIuNTMifQ%3D%3D&sprefix=midland+emergency+radio%2Caps%2C120&sr=8-1-spons&ufe=app_do%3Aamzn1.fos.006c50ae-5d4c-4777-9bc0-4513d670b6bc&psc=1 It has no shortwave though. I haven't yet found a good emergency radio that does it all.

Any other concrete suggestions would be welcome.

After looking into it, I'm coming to the conclusion that advanced emergency radio comms are hard to cost justify. For instance, if I were to buy a starlink for purely emergency purposes and put it on a shelf indefinitely for years, who knows whether it would even work during an emergency, as the firmware may(?) be too far out of date to function when the chips are down. Sure, it would be a nice to have, but better to get a simple emergency radio receiver that both FEMA and the Red Cross recommend everyone have. i.e. diminishing returns seem to kick in rather quickly after that. If it's a localized emergency, then help will be on the way, and if it isn't, I figure I can count on internet for a day or two from the cell phone carriers until they run out of power to send/receive emails with distant family. Maybe I'm missing the point (?), but in looking at what can be listened to over HF radio, it seems like it's almost purely junk. I can't understand why HAMs waste so much time listening to it.

Comments, anyone?

@mfalkvidd said in Anyone here tried either LoRa Meshtastic or LoRaWan for grid-down emergency communications?:

@NeverDie yes, starlink is the obvious, reliable, high capacity (and due to it bein available off the shelf, slightly boring) solution. Their RV plan can be paused and you don't pay any fees when it is paused.

That sounds like a winner. I get the impression that high quality ham hardware (the kind that gives long range) probably runs around $500 or more, so the hardware cost is actually comparable, but at least with Starlink you'd be getting the entire internet and not just simple email or just simple messaging.

Are there any other satellite internet services worth considering?

A starlink (or other satellite internet) would be expensive to keep active purely as a hot backup, but what might be ideal is if one could just buy the hardware and not activate it unless/until an emergency were to arrive, I wonder if that approach is even possible? It would be one way to keep costs low. Better yet would maybe be some kind of pay-per-use plan, like with cell phones, where you pay per gigabyte used, but pay nothing if not using it.

Short of that, Winlink email would at least get you basic functional email using just the ham infrastructure, but connecting with internet email over ham radio when possible:
Winlink Email to Gmail | Ham Radio for Preparedness – 12:38
— Off-Grid Ham Radio OH8STN

So, I'm starting to think ham is the way to go, at least for now, since it has a large user base to communicate with (or through) in an emergency.

For so called "grid down" emergency communications, some people are positing that LoRa meshtastic might fill the need, especially since it doesn't require a license to use. It even comes pre-installed on T-Beams, such as those sold on Aliexpress.

Others point to JS8Call, but AFAIK JS8Call requires a ham license to legally use, so the barrier to use is higher with it. Then again, maybe the typical range would be better?

I'm not a Ham, but I could see myself spending $30 on a T-Beam if I could be confident it would actually reach other meshtastic users in a a grid-down emergency. It's a bit of chicken-and-egg though, because I might have to build/buy one just to find out if there is anyone else it might reach. On the other hand, true high-end Ham equipment is likely able to reach other Ham's, so that would be the justification for going that route instead, even though at greater expense because of the licensing and greater equipment cost.

@qqlapraline said in Find Parent (yeah, I know):

@mfalkvidd guess what…the capacity strikes again. I’ve soldered a 47uF right on the nrf24l01+ pins and…it works.
Would someone explain me the logic there ? The traces between the pins and the capacity were like 10mm long max.
Oh well.

Qq.

It could be any number of causes. Just a WAG, but maybe high ESR on your tantalum capacitor together with what looks like crusty solder joints?

Consider using X7R low-ESR ceramic caps instead, plus putting the bypass caps as close as possible to VCC and GND on the radio. Your serial power supply might be throwing off a lot of noise as well. Check it on an o-scope.

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

@ncollins Impressive! Looks as though you even modeled the exact shape of the coincell holder. And you apparently designed the 3D printer snap enclosures as well. Even just the 3D printed enclosure modelling is quite a task all by itself. I hope to one day evolve into doing that too, but for now the Hammond enclosures are going to be my short-term solution. The smallest Hammond is still not as small as what you've managed to produce, but at 36mm wide for an off-the-shelf ABS enclosure, it's too wide by only about 10mm. Still.... one day I want to 3D print an enclosure to be as small as possible.

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

Reporting back: I did the measurements, and it takes an nRF52805 about 750uSec to go from cold-start to turning on an LED, at an average current drain of about 330ua just prior to the LED turning on. Of course, the 805 may have to spend additional time and current to re-establish a particular context, but ignoring that, the measurements suggest a breakeven point between cold-start vs sleeping with the RTC turned-on and full memory retained (roughly 1.5ua current draw) is approximately 200ms. The downside is that it would require additional hardware to benefit from the arbitrage, but if so desired it could be done. In fact, just knowing that's it's possible makes me want to try it!

On the other hand, the nRF52805 does have PORT DETECT, which appears can provide the basic wake-up functionality at no penalty to current consumption. i.e. total sleep current remains at 0.8ua with full memory retention. AFAIK, that's still better than any of the other nRF52xxx chips Nordic has so far made, and in that one respect also better than what the nRF5340 can achieve. That compares to 0.5ua current draw when the nRF52805 is in OFF mode, with no memory retention, but where PORT DETECT could still be used to wake-up the nRF52805. So, the interesting question remains: how many mah are consumed by going from stone-cold 0ua OFF to full-on? Knowing that, one could compute the tradeoff of going that route vs sleeping at 0.8ua or 0.5ua. If the stone-cold OFF interval is long enough, it will win, and so the only unknown (currently) is how long that interval needs to be to reach a break-even point, and beyond that the energy savings pile up.

One shortcoming of the nRF52805 that I just ran across: it has no LPCOMP. I'm surprised, as it's rather basic functionality.

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

Bambu Labs has gotten a lot of buzz recently for being super fast and generally awesome.

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.

Trying to enlarge some holes on an incorrectly fab'd PCB. I have a 1mm diameter drlll bit, but it turns out none of my drills will hold it--their chucks have a more than 1mm diameter void when closed. I never knew until now, when the chips are down. So, for the future, what drills will hold small bits like this?

As a one-off, I held the bit with a pair of pliers and crudely rotated the PCB around it to drill the 3 holes, but it was awkward and I never want to have to do that again. As a one-off, it did work though.

I finally did receive the boards (4 different designs in all), but on one of the designs PCBway incorrectly drilled 3 of the holes with the wrong diameter, rendering the board useless. I've never had a FAB make a mistake like that before. Because of this, I probably won't be using PCBway again. What a bummer.

I'm trying to remedy the situation by drilling a 1mm hole where they should be, but I'm finding that none of my drills will even hold a 1mm drill bit. Anyone know of a way to drill 1mm holes?

Oh great, the new China lockdown has halted shipments, so my boards are in limbo until China unlocks its lockdown.

I've hit my hassle threshold. I need to find a domestic fab....

I may try this: use an IVR, but the prompt will be "Please spell the first name of the person you are trying to reach." The corresponding number then connects the call. Anyone who really needs to reach me can figure out the prompt, but it should defeat all robocalls and, I'm guessing, most if not all of the human originated spammer/scammer calls. Worth a try, and then judge by the results. If need be, I could add further filtering with a prompt of "Please enter your callback number" And if that still isn't enough, I could add a message of "Please wait for 30 seconds while your call connects" and then add a 45 second delay before ringing for further frustration. Surely that would eliminate the scam callers who have no time for delays, yet still allow through anyone with a legitimate agenda. Meanwhile, family members would be given a secret code that would pass them through immediately and without delay. There are a number of open source IVR software packages, so I'm guessing regular VoIP hardware should interface with it over ethernet. Not sure, but IIRC, with some VoiP there may be a way to reveal the true originating phone number and see if it is a match for the Caller-ID, which nearly all the time is spoofed and therefore a glaring tell. It would make sense that such a way would exist, because a VoiP carrier would need to have a way to charge to the originator the cost of completing the call and plainly would not agree to rely on ordinary caller-id for that purpose as it does not provide a verifiable audit trail. Therefore, the carriers must have this info, and the only question is whether there's an API where that information could be retrieved in real time. I can think of no reason why it would be privileged information that would be withheld if specifically requested. Indeed, if it isn't free for the asking, there's probably a model where the carrier would gladly provide it by charging extra for such information.

If this works, then I may get an additional VoiP number and only give that out instead of my actual cell phone number. Then, if possible, I'd program my cell phone to only accept filtered calls forwarded to me from that VoiP number. This way my cell phone would be also filtered.

Well, maybe they're all about the same. I placed an order with PCBWay entirely because of their promised 24 hour build time. Four different PCBs in the order. One completed within 24 hours, but 3 did not:

Being late by a few hours can be the difference between shipping today versus shipping tomorrow.

@nagelc Yeah, that was me. I found it makes a difference.

Eneregizer promotes their Lithium AAA and AA primary batteries as having a 20 year shelf life. So, depending on the use-case, you could get 20+ years out of them. The nominal math is simple: divide the average current draw into the rated amp-hour capacity of the batteries. That will give you the nominal number of hours they should last, and from there you can easily convert into days, months, years, decades, etc. With some batteries you may have to account for the rate of self discharge, as that may be higher than the current draw of your device.

Also, it's hard to find coincells that are rated for a shelf-life that's longer than 10 years. Duracell has some that they claim are rated for 10 years shelf life. A lot of others are rated for 5 years or less, and the cheap counterfeit ones from China last a lot less than that--maybe only a year. Unfortunately, a lot of what's sold on amazon seems to be counterfeit. It looks real, and the packaging looks real, but, at least in my experience, they're often counterfeit.

@skywatch said in Help! Is there *any* way to squelch either robocalls or India call center telephone attacks to my phone?:

asking people who do accidently get through if they can't get a proper job or if their grandparents know how they make a living.

They're immune to that. I've even tried using all kinds of harsh language, and the very same person would call me back the next day--for the next five days--as though nothing had happened. They're relentless. Hanging up doesn't work. Harsh language doesn't work. Asking politely to never call again doesn't work. Trying to waste their time doesn't work. Not answering doesn't work. Nothing works. There is no way to turn them off.

I do have spam call detection on my phones, and sometimes it works and sometimes not. Unfortunately, it rings the phone even if it thinks it may be spam. I'd prefer that it not ring at all if there's more than a 1% chance that it's spam.

So, what to do? As a first step, I'm prepared to route all inbound calls directly into voicemail, without ringing the phone, and then I'll separate the wheat from the chaff after the fact. It's radical, but unless someone knows of a better way, I'm going to give it a try. It's main virtue is that it's simple, and it blocks 100%.

@OldSurferDude My wife has also tried blacklisting the moles, but in our experience, the moles get new phone numbers at least as fast as we can whack them. These SOBs don't care that you don't want to talk to them. Their strategy is to get their foot in the door by whatever means possible. They'll use all manner of fake caller-ID just to get you to pick up the phone.

I think step#1 would be to have a robo answering machine which answers all calls and asks questions and which uses AI to evaluate the answers. I estimate that would defeat at least 95% of them while still letting through legitimate calls. A prompt question could be as simple as "Who are you trying to reach?", which, if answered correctly, could be followed up by "What telephone number are you calling from?", which could be used to further validate the call. It's either that, or else I will need to hire a human answering service to screen my calls. Maybe there's a cheap call center in India that can screen my calls? There's gotta be some way to level the playing field by fighting fire with fire.

Meanwhile, I'm assuming there's some way to use home automation to solve this problem. Just not sure what it would be. Asterisk (*) and variants thereof are free, for instance, and so IVR could be a starting point.

@OldSurferDude said in Some"ting" interesting...:

@NeverDie Non-internet connected networks still need NTP. I built an NTP server from a $5 gps module, a $3 Arduino nano, a $6 ethernet shield, network cable and a USB cable. A neighbor 3D printed an enclosure for me in exchange for 4 home baked cookies (they're awesome). Just for fun, I put in software for an under $2 display to make a clock.

Should we re-title this thread, "Be Afraid, and here's how to ameliorate your fear. "

In the scenario I was referring to, the IOT devices are still internet connected. They're just on their own dedicated local LAN (which could be a virtual LAN), that's all. Now, shutting them off from the internet entirely.... maybe that's another step one could take, depending on what it is. I have some lights/switches that were cheap but which have to run through the cloud in order to connect with Alexa. They wouldn't work properly if they were cut off from the internet.

I get a daily barrage of both robocalls and B.S. India call center attacks trying to get me to give up information. It doesn't matter how many times I hang-up or ask them not to call back, they keep calling me, over and over and over and over. I get so many of these calls that my phone is practically unusable for inbound calls anymore, and there's seemingly no way to shut them off, other than turning my phone off. Therefore, I'm on the verge of looking into building something electronic whereby a caller will either need to be on my white list or else will need to enter a secret code in order to make my phone ring; otherwise, the caller will be sent to voicemail. Is there a better way? I'm totally exasperated. I'm already on the national "Do Not Call" registry in the US, and, not surprisingly, it is basically useless because 1. these people are obviously criminals in the first place, and so they don't give a damn about who is or isn't in a registry; and 2. they're calling from out-of-country locations where they can't be prosecuted.

@OldSurferDude The Snowden leaks proved it isn't paranoia, and his leaks have become the playbook for lots of countries, including China, on the grounds that the US is doing it. Somewhere on a different mysensors thread a few of us were discussing the spyware threat from purchased IoT devices, and the collective opinion at that time was to keep such devices on their own LAN (probably a firewalled virtual LAN) to hold them at bay, since you can't easily know which ones are bad actors and which ones aren't. Even if they're benign, the company behind them could be acquired by a malevolent actor, or the devices themselves could be co-opted by a black hat during a phone home firmware update. The worry is that from there they could infect your computers if they were on the same network, and if that happens they could, in theory, cause you all kinds of grief.

That said, one of the parents in my neighborhood is a penetration tester, and when I asked him about this kind of thing, his opinion was that literally anything can be breached if enough effort is put into doing so. So, his advice was to not keep anything valuable on your computers.

@OldSurferDude said in What did you build today (Pictures) ?:

@NeverDie It is my understanding, though I can't wrap my head around it, that it is the length of the conductor that makes the antenna tuned to a certain frequency. If this is the case, you could run your antenna around the edge of your circular pcb which would make the effective radius only slightly bigger.

You mean like this?

I get the impression that somehow the antenna positioning relative to the ground plane might figure into it as well:

Perhaps that stands in the way of wrapping the antenna completely around the circumference? I can't claim to have any deep understanding of how antennas are supposed to be designed. In the past I noticed that TI sold a sample set of canonical antenna designs, so then you could try them all out and see what suits you: https://www.ti.com/lit/an/swra161b/swra161b.pdf?ts=1661617962454&ref_url=https%3A%2F%2Fwww.google.com%2F

Reporting back: The Ting seems to be working reliably. It tells me: 1. if there has been a power failure, and for how long it lasted, and whether it was a community wide power failure (it reports how many other Tings in the neighborhood where I live reported a power failure at the same time. On the most recent power failure, it reported that 11 other Tings in my neighborhood were also affected), and 2. it noticed if the internet connection has failed, and when, and for how long. All in all, mildly useful information that could be gathered in other ways, but this was free and easy.

It's main function is to detect and alert to dangerous electrical arcing. In my case, it hasn't detected any, which is a good thing. It also continuously monitors the mains voltage levels, so it's capable of reporting on a brownout, should one occur.

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.

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

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.

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

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

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.

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.

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.

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.

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

Thanks for posting the schematic. Just an observation, not a criticism: it looks as though the output voltage will sag down to the level of the logic-LOW threshold of your NOR gate before the battery voltage takes over. Depending on what the load is, maybe that's a non-issue. If, on the other hand, it turns out to be an issue, you could perhaps use a voltage divider to trigger the switch-over with less of a voltage drop seen at the load. In either case, I like the simplicity of the circuit.

@Abd-AlHaleem You have three options:

1. Print it as a .pdf file. You can upload those; or,
2. Compress the kicad file as a .rar file, but not a .zip file. That will also upload.
3. Best option: Archive the kicad project (as a .zip file by default), and then compress that as a .rar file. That way you can upload the entire kicad project without it being rejected.

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

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.

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

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.

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

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!