Search the Community
Showing results for tags 'data logging'.
Found 1 result
There is a lot in the analysis of humidor performance based on how you look at data. Take this case in point. I often look at raw data from my data loggers in a highly compressed, macro perspective. While this view can leave you, will leave you, without much in the way of detail, it will help you espy trends and shifts, and even corrections needed to your system. Here is the first data log. Now I data log this test box everyday, unless I forget to download the logger and reset it. I test a lot of stuff in this box. I house a few boxes of cigars in here plus my frauds collection. The cigars just take up space as I use the humidor for some overflow and to park cigars while I move them around, or have no other place to put them. This is a 'working' humidor, tuned to work in the real world and not tuned to find utopian results. This humidor works in my shop, not in my home and I keep cigars in it even when the temps in the shop exceed 90˚F. If you look at the data streams, the data is so compressed that it gives you an overwhelming sense of the highs and lows, the extremes, while obscuring the data in between the highs and lows. One of my clients needed a low profile humidifier and I chose this box to test it. What I have not liked about how this humidifier works in this cooler, is the deep low-end extreme values that the humidifier produced in this cooler. It is important to note, that at my level, sometimes the slightest change in your humidor design will produce profound effects. This is one such case. So what I did here is to replace my standard 26CFM fan with a 36CFM fan. I wanted to match the rate at which the cooling would strip water from the humidor with a humidifier that would meet or match that rate when the humidifier was operating. Now, this philosophy is not without risk. You can overshoot your system parameter when you use the approach, and empirical testing is the only means to determine if you have succeeded! Here is the micro look at what these cooling cycles look like. You can clearly see the system cool and the humidifier compensating for the loss of humidor water as the system cools. This is one logger, logged through my controller sensor so it is time aligned. The deep rH cycles are of course the result of cooling cycles, some of which can be cured by tuning the activation logic. Since this logic approach will ultimately affect the way the humidor as a hole runs, and I could 'tune it' for a specific result, I deliberately chose not to do so here. Like I said, I generally 'tune' humidors to run in the real world, not to provide limited 'perfection' to post about. I could tweak this thing to look damn good on the logger but that is not my point nor my goal. A robust working humidor is my ultimate goal. There are a lot of factors that go into making decisions about this "robust working humidor" philosophy. None of which I am going to cover here. I just wanted to say, if I was hell bent on tweaking this for a 'better log,' I could do it, but would consider it cheating! Here is what happened when I changed the fan... Wow! What you can see here is the rapid rate of hydration that the new fan provides. For now, I will call this one a success. Of course there may be lurking a specter of overshoot if the right conditions are met. Now I have studied the cooler function now for several days and I don't think it is going to happen, but it still could under the right circumstances. Lets look finally at the micro view. It too is very telling. One of the keys to knowing that I have succeeded here is in seeing that the initial running of the humidifier during cooling actually is halted by programming, it is overpowering at this stage, as it overproduces water initially, requiring a shutdown and restart. Look at the chart and you will see it all. ... now a little activation logic tweak... maybe. -LOL It never ends...! That another day! Thanks for reading! Prof. Piggy