Closed mrweaver closed 4 years ago
Where are the other sensors located?
Thanks for getting back to me. I have my wort in a chest freezer, one sensor is in free air in the freezer, the other is located in a stainless steel thermowell in the centre of the wort, in close proximity to the iSpindel.
Cheers, Michael
Well, a few thoughts. Bear in mind I am not a maintainer here ....
The sensors are digital. Either you get a reading or you do not. If you do not the fault condition is 85°C. I don't see that there. What it looks like is that calibration is at times not being applied. Not sure if iSpindel uses a temp calibration but if it does that's a possibility.
Also, I never see a temp sensor in a gravity device as anything other than a way to internally calculate a temp correction. It's not exactly in a thermowell because there's a large airspace and it's at the top of the wort. It's not a chamber temp either because it's in a sealed space in a sealed space. There's a large potential for the air in the fermenter to stagnate which could lead to erratic readings.
If it's not the first (which would take some corroboration and debugging) I think it would just be something you'd have to deal with (and ignore.) In BrewPi Remix I am not going to even chart that temp in future versions since it leads to more questions than it answers.
Thanks for getting back to me again.
I agree with your point, I would have considered that if the digital packet was broken it would simply return as invalid, as opposed to a partial reading. To me, the erroneous readings appear to have a 0.5°C step, which seems a little quantised, given the smaller increments it makes are 0.0625°C as expected.
That is a fair point, I wouldn't take it as a strictly true representation of the wort temperature either. Even so, it does not need to be calibrated perfectly to be useful. A temperature controller could still be set with the feedback from the iSpindel sensor, however if it is jumping between values at random intervals, it is much less useful.
I know I could filter the data as well, but it seems like this is a fixable problem. If no one else has experienced this, it must be hardware or configuration. I wonder if it is likely to get a bad batch if DS18B20 sensors.
I’ve yet to hear a good argument why someone needs to use a floating SG sensor as the source from which to control their chambers’ temps. I’ve heard arguments discounting those I have against it, but no real firm advantage to the use of that sensor.
You’re basically giving up PID in order to have one less sensor, a trade I just can’t embrace. I mean you already have the sensors with which to prove your original issue - why not just let it do what it’s supposed to do (allow temp correction) and use the others to control the chamber temp?
I’m sincerely not arguing. In my mind however this is a little like making a Tesla Pickup. One wonders what void is being filled. :)
I suppose it is a convenience argument for many, if you could have a single monitoring device that works, why not? Especially at the amateur level. In the context of temperature regulation, the insulating air chamber design of such a device does make the feedback loop of an already slow system, even slower.
Haha, we'll add some shatter-proof windows next then :) ? For me its not a big deal at all, like you say, I'm using another system for that and don't intend to change. I thought it was worth flagging at the least for others who may rely more heavily on the output from this sensor. Given that there are people floating around such forums with a lot more experience and competence than me at fixing these issues, I thought that it may turn out to be a trivial solution.
Well like I said, I’m not a maintainer here. The subject interests me because it comes up so often and so many people seem so interested in it. I just want to make sure I’m not missing something simple.
In case you have not read the other arguments, the biggest reason not to do this is the sample interval. It’s far too wide in order to keep battery life reasonable. You would be going from milliseconds to minutes. What you’d be left with is a pseudo-thermostat rather than a temp controller, with potentially wider swings because of the sample rate. It would probably keep a steady state system like a kegerator, but I’d be very concerned about a more dynamic system like a fermenting wort.
Someone did some work on this in I want to say BrewPiLess, but the temp graph showed it was nowhere near as good as a wired sensor to a controller. They did 5 minute intervals IIRC and in a non-dynamic system got it around +-.5 deg F. So that’s cutting the battery life quite a bit to get even that.
At best I think you could emulate a thermostat keeping pseudo-chamber temps. As a guy who started Home Brew Automation with temp control, it would pain me to step backwards. :)
Still, there’s something odd in your graph. Do you have temp correction?
I hadn't read the arguments, and that hadn't occurred to me - or it was since forgotten. You are totally right, of course! The polling frequency makes the device all but useless for most temperature regulation. Thanks for pointing that out!
I recall looking into it at one stage but I don't think that I'm running temp correction. From memory, it would have been a modification of the SG polynomial, with 'temp' in addition to the 'tilt' parameter. Although, I didn't post a plot of it. I'll have to wait until my current brew has finished to grab it and check.
Like I said, as a static system (the person I recall did it with water), there's little reason to worry about polling quickly. Depending on what you are fermenting it can generate quite a bit of heat. I'm on painkillers from surgery or else I would do the math. :)
If there's no discrete temp correction, then I suspect that's not it.
Does iSpindel log raw data to the serial port? If so it would be interesting to see what if anything changes at that cadence.
Never a better excuse to avoid the math! Hope you're recovering well. This is true, there would also be issues of how good your environmental insulation is, and the external fluctuations in temperature that may effect the wort. Not to mention the resolution at which your system can regulate your heating / cooling - most freezers are pretty harsh - and with slow polling one could drift off target quite easily, or at least oscillate around the set-point.
It outputs some detail through serial, but I don't think it outputs temp - although I imagine that its implementation would be trivial.
@mrweaver Be aware that an interval more often than 2min will cause a self heating and hence an unreliable measurement.
@mrweaver @lbussy There is definitely a logging of the temperature in the console!
However, from my personal experience the temperature sensor of the iSpindel is perfectly usable to control cooling/heating even more reliable than outside sensors, simple related to the fact that heating/cooling is a very slow process which makes these intervals accurate enough. I do run a heating setup fine and it is totally able to regulate within +/- 0.3C
There is definitely a logging of the temperature in the console!
Good to know. iSpindel logging is next (after Python3) in BrewPi Remix so I promise I will be dusting mine off.
I had forgotten about the heating from those chips. I have a soon to be released project that suffered from that, I was disappointed I could not use a DS18B20 directly on the PCB.
However, from my personal experience the temperature sensor of the iSpindel is perfectly usable to control cooling/heating even more reliable than outside sensors, simple related to the fact that heating/cooling is a very slow process which makes these intervals accurate enough. I do run a heating setup fine and it is totally able to regulate within +/- 0.3C
Heating possibly, since the implication there is that you are removing/losing more heat than you are adding to the system. For cooling, especially when fermenting actively or otherwise adding energy to the system, you will find it more challenging. Also, a PID loop will work best when temperature readings are able to be finely/more granularly processed. Having a granularity =>5 minutes when the system has a high entropy makes it more of a thermostat than a PID loop.
When used with "beer constant" (i.e. a sensor directly in/attached to the fermenter) I can maintain +-0.1°F (0.06°C) in my own systems. If I regularly see fluctuations +-0.2°F I begin to take notice and wonder what's going wrong. I guess it depends what the user is willing to accept.
Just to put a few things right. Whether it is a PID loop or as you define a „thermostat“ is by no means related to the interval at all! PID solely defines how to react on the error response from the measurement but not how often it has to happen! In fact there are many control systems out there with super long intervals used for instance with relays. Also it is wrong to assume that heating is different than cooling in this regard- first of all that is just an example but second it is only a matter of which input you are controlling. And of course I have a cooling influence for my fermentation, logically.
However it is a huge mistake that many brewers make to believe that super fast and fine controlling of the environment will result to a good control of the wort, actually the opposite ist? the case! 2-3C difference because of fermentation is the truth. So the only reliable measurement is in fact a floating sensor in the center of the fermentation and that is where the ISpindel is very close to.
Just to put a few things right. Whether it is a PID loop or as you define a „thermostat“ is by no means related to the interval at all! PID solely defines how to react on the error response from the measurement but not how often it has to happen! In fact there are many control systems out there with super long intervals used for instance with relays.
I suppose that depends on what you consider "right."
I do have a background which supports my statements. If I use a word or two out of a specific context, I do so not because I don't understand the difference, but because I want a human to be able to understand it/me.
When I say that loop becomes a "thermostat" I mean its derived effect, in that the temperature will begin to swing much more widely before the system will react. That is quite literally the implication of a coarse sample interval. Whether or not that has a material impact on a given application is dependent upon the entropy of the system. However, you will not gain control of that which a PID system is capable when you are sampling every 5 minutes versus several times per second.
PID is about not only sensing the offset but the time it takes to achieve that offset. Without being able to sense the system while it is changing you have no idea what energy you need to add or remove from a system to effect the change you want. Most importantly, these systems have inertia, so you need to predict when a system will peak given X energy added/removed. When you are sampling every 5 minutes you cannot do that effectively.
For those following along at home: Imagine being in your car and coming up to the top of a hill for the first time. You've never seen the hill before but as you crest and start on your way down you realize the hill is very steep and before long you are exceeding the speed limit. You have to jam on the brakes, your drink spills, and the french fries you had precariously balanced on your dash spill everywhere. What happens the second, even the third time you see that hill? You anticipate it, you begin to correct before you even reach the top and before you know it you're back to driving with a hamburger in one hand, a drink in the other, and steering with your knees.
That is what PID does. It learns the system and reacts more quickly than something which just reads the temperature and says off or on. It knows about that hill because it's been there before.
If you are "testing" using a static liquid in a well-insulated container, sure, you can keep things reasonable without a granular loop. Our users, however, are using everything from commercial walk-in freezers to taped-together foam board boxes. They are using the temperature control for fermentation control where fermentation itself injects energy into the system. Unchecked in a perfectly insulated system, the temperature of a 1.070 wort will rise almost 8°F throughout fermentation.
However it is a huge mistake that many brewers make to believe that super fast and fine controlling of the environment will result to a good control of the wort, actually the opposite ist? the case! 2-3C difference because of fermentation is the truth. So the only reliable measurement is in fact a floating sensor in the center of the fermentation and that is where the ISpindel is very close to.
It's not a huge mistake, and I'm afraid you are incorrect. Fermenting wort generates currents within the fermenter. You can see this without expensive instrumentation if you just look at your fermenter. You will see bubbles rising and the occasional piece of trub, hops or other detritus pass by. This is because the rising CO2 creates a pseudo-air lift pump. This is how chemical companies ensure solutions are being mixed continuously without the dangers of shear created by a mechanical stirrer. The wort is constantly mixing and you may safely count on the temperature outside of the wort being a reasonable reflection of the center during an active ferment. This is reflected in practice by the findings of several brewers (myself included) who have compared well-insulated external probes to the readings of thermowell probes.
However, if you want to split hairs: The iSpindel is the same as having the temperature taken from the side. It resides at a boundary of wort and air, and the air is a better insulator than glass (which is why a fluffy blanket is warmer than your window-pane.) The iSpindel no better at reporting the actual "inside" temperature than an external probe and arguably slightly slower in reacting. The place to really get the "perfect" temperature is suspended in the center of the wort (i.e. thermowell).
Let's for the sake of argument ignore any differences and just agree they are similar. It is incorrect to imply that tight temperature control is impossible or somehow not better than lose control. At best you may have yeast that is not impacted by a swing of 2-3°C over a few hours. Is that what you want or expect after going to the trouble to make a PID-driven temperature control system? Do you know what I call that? A thermostat.
Please understand that I as the maintainer do not like this projects repository to become a place to discuss opinions, whether they are right or wrong. I am sharing research that was proven in order to help, I disagree but I see this is not leading to something here.
Regarding the original question the answer is given hence I will close this issue.
@universam1 Thanks for getting back to me. My polling frequency is 5mins, so I suppose it is probably not self heating. If it is only me experiencing this issue, and assuming it is not self heating, would you assume there is some other issue with my set up rather than the firmware? If I get time later, I might write some temperature polling code to see if the issue replicates on the same hardware.
@mrweaver Sounds like a good idea. My instances do not show this fluctuation, unless they are in a heavy fermentation process. Probably you could take some measurements when the device is in a dry, stable environment. There is not much the firmware can do here since that sensor is digital and it values are either received or not, with the first being obviously fine. Let me know when you have more data
Far too long since I looked at this, but with some self-isolating... So, @universam1, this morning I ran a couple of tests, here is the data:
iSpindel and original firmware in open air (polling interval 10s)
iSpindel and self written firmware in open air (polling interval 10s).
From this it seems that it is likely to be a hardware issue of some sort. Itt could be:
a partial incompatibility of hardware variant and library (using DallasTemperature.h)
a routing quirk of the Cherry Philip 4.0 board causing signal instability (seems highly unlikely).
I suppose the next step would be to get some alternative temperature sensors, whack em in, pray to the beer gods and seen what happens.
Any other suggestions?
edit: added photo of chip
For anyone having the same issue. It seemed to be that the chips were the culprit. I grabbed one from Element14 and chucked it in the iSpindel, gave it a 5 sec update time and let it run for a bit. The results look promising, no issue of the temperature fluctuation seen in the above plots. here is a plot of the output sitting in the sun:
And for completeness, here is an image of the temperature sensor, show its inscriptions:
If anyone has a reliable seller of these chips a decent price, I'm all ears. Element14 is certainly more reputable, but at $5AUD ea + shipping, and me being a bit of a tight arse, I'll be keeping an eye out for a better solution.
Good luck, happy brewing and keep up the awesome dev efforts everyone!
Cheers, Michael.
I bought these and am very satisfied.
Great, thanks for letting me know. I've just bought 10 from the seller Wavgat on AliExpress here, so will be interesting to test: https://www.aliexpress.com/item/32523899337.html
Hi guys,
Firstly I love this project, I've made a few of these now and they are super handy. Keep it up!
I've run into an issue that I ignored at first, but have since decided I should find a solution for. The temperature sensors that I am using (DS18B20) seem to fluctuate, as if the data returned is slightly corrupt. I have seen this same effect on all three iSpindels that I have made. I have made another project for heating and cooling the wort using these same sensors and have not experienced this issue at all.
I have included a capture of the data as an example, showing the sensors I've used elsewhere (top 2 plots) and that of the iSpindel (bottom).
Has anyone else had this issue? Is it a matter of including CRC checks and a few retries in the
getTemperature()
function?I am using the Cherry Philip 4.0 board for my hardware.
Many thanks in advance for your time and help! Cheers, Michael