That’s about all the advantage I see. On the other hand, desiccants can really lower humidity when fresh. Restricting air flow would limit that in cases where you don’t want the humidity to plunge or for the containers to use up desiccant fast like your example.
Thing is, as the desiccant absorbs water its effective humidity will rise and it won’t grab additional water as hard or fast. As it gets used up, you’d want less and less of that air flow restriction or else the rate it soaks up water will go down and it will get less effective.
It’s like you’d need a series of lids with small holes to big ones and swap them out with bigger and bigger holes as the desiccant gets more and more used up to have the same performance over the life of the desiccant if that makes sense.
To my thinking I’d like for humidity spikes to get taken up by desiccant instead of by filament though. In a filament container, it seems to me you’d want the desiccant to soak it up fast along the lines of the other discussions on that regeneration peak and however important high humidity short-duration spikes may or may not be.
I don’t have a good answer. I was going to try to simulate a spike and weigh before and after to see but haven’t yet.
Those containers are like having a desiccant container that’s small but has the water holding capacity of something much bigger. I see the utility for more gentle water scavenging/drying but not sure how it applies to filaments. I tend to want low humidity and fast getting I think.
I really don’t see a point in that at all. This concept does not only limit moisture spikes but also reduces effectiveness against slow constant sources. Think of a spool that hasn’t been perfectly dried and continuously emits some moisture. I want the desiccant to pick that up as fast as possible to keep humidity low instead of the other dry filaments soaking it up. with a restricted desiccant, the equilibrium level will be just higher.
And I think regarding lifetime until regeneration, this has zero benefit. When the moisture is inside the container, the desiccant will have to soak it up anyway. It doesn’t get any less saturated when it takes a week instead of a day to do so.
The really only use case would be if somebody leaves a door or lid open for hours. I can think of better measures against that situation.
I hadn’t thought that far ahead, but that’s a very generous offer. I’ll get back to you on that. Chips and PCB haven’t yet arrived. I was planning to do initial testing to confirm whether the sensors worked at all after soldering with just a regular ATmega328P, since demo code is almost always oriented around that and I can sleep the MCU at just 100na to get extreme battery life, but as to a more permanent home I hadn’t yet given it any thought.
Some of the scales on amazon have 0.1mg resolution. I don’t own one, but if I did, it would be a fun experiment to see if I could watch desiccant weight increase in real time after the tare just from the ambient humidity.
Anyway, with that kind of measurement and a stopwatch you could better judge just how much capacity you’re giving up by opening the lid. Without a compelling story based on that kind of measurement, I’d rather have more desiccant exposure, not less, and do what I already do, which is not dilly daly while the AMS lid is wide open: do the necessary and just close the lid again as fast as you can. I’d wager it’s the slow bleed from the ambient air leaking into the ams that’s more signficant overall than the episodic opening and closing, aad if that’s so, it just isn’t going to make any positive material difference no matter what, at the likely expense of your filament acting as the desiccant while it remains choked off because of its limited openings in the advertised desiccant lid.
Correction: chips arrived late today, delivered by GOFU, the same carrier Temu uses. I only mention it to report back that there were no Tariff problems, in case anyone had lingering doubts.
Got it. I went the other way with always-on LEDs for the humidity bargraph and the microcontroller staying busy. Not even any provisions for a battery except as a backup when USB power is out. Not a single sleep command in the code anywhere.
If anyone wants one of the loggers, it’s not that restrictive to only support the SHT4x line.
Even though it very much serves the purpose of validating the i10, I just now created a separate fork for the sensor development aspect, so as not to dilute the main topic, as there are a lot of details, and we can better discuss them if concentrated in their own thread. Everyone is welcome to join in or follow along.
