@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:
https://www.youtube.com/watch?v=80j7L1H61Hw

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:
https://www.youtube.com/watch?v=S3vY2LyQn1A

TL;DR: It turns out that masking had essentially no efficacy. :face_palm: 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:
https://www.youtube.com/watch?v=fJSNAyMmNGk

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:
https://www.youtube.com/watch?v=KD-av4cTL-Q

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!