Stc-1000+

[schmartz]

I'm guessing you want to use a strain guage instead.
Still, this has several problems. Finding/building a suitable weight, keeping said weight +string sanitized, attaching to the strain guage and somehow pass through the lid of the fermenter in a sanitary way.
After that you just need to worry about CO2, krausen and drift of the strain guage to mess with the measurements, before you're done.
That's why you don't just do that.
Not saying it can't be done (it even has been done with the beer bug I think), I'm saying it is not all that easy and probably more trouble than the reward.

Strain gauge is what I meant - long day. I'd think using something like ptfe for the weight and suspension might work. You may need something less dense though. I've never worked with strain gauges. Just throwing out an idea that I'd think may be able to be more accurate for those so inclined.

I tend to not really want to worry that much and make fermentation temperature changes based on visual observation or set times which tends to work just fine.

 

[Jakor]

Strain gauges (and instrumentation amplifiers) can be bought pretty cheaply on eBay. But still, I think over time drift may be a problem.
I guess there are people who take their beer making a lot more serious than me, considering the efforts that go into continuous SG readings. I just don't care that much. Pitching an active culture at an appropriate temperature, I just trust my 'yeastie boys' to do their thing and so far it's been working out quite nicely
Now, if someone comes up with a simple-ish, cheap-ish, none invasive method of measuring SG continuously that works reliably, then that would be really cool and I'd definately look into it, but until then, I'm not losing any sleep over it

Yeah your method of a time based fermentation profile is surely the best way to automate this, I've just been looking for a cheap DIY project to do that hasn't been done already. I don't think putting something in the carboy will turn out a net beneficial result. Meh, I'll post if I do anything that proves promising, otherwise consider these ideas impractical.

 

[stpug]

I have a question on manual adjustment of my current profile using St and dh:

I'm into Pr0, SP0, and dh0 is at 46 of 48 hours. I'd like to go back 10 hours so I'm at 36 hours of 48. I'm thinking that I would set:
St = 0
dh = 36

Would that be correct?

 

[alphaomega]

@stpug: That is correct. Just note that SP (the current setpoint) will not be updated until the next one hour mark

 

[Jakor]

Okay so sorry for so many questions in the last couple days, but I just found out that the CP2102 module I ordered has the pin layout that doesn't exactly match the arduino. I can solder them together without much issue, but it looks like both my CP2102 and my aduino clone have RST connections instead of DTR. Based on some research, there is some backwards compatibility, but does anyone know if RST will work with flashing the STC?

 

[stpug]

@stpug: That is correct. Just note that SP (the current setpoint) will not be updated until the next one hour mark

Excellent! I felt like I was thinking about it correctly, but then I doubted myself, and with the update not taking place within a few minutes made me doubt myself even more. Thanks for the confirmation, and the unit has now updated (I just checked!).

Cheers!

 

[alphaomega]

Okay so sorry for so many questions in the last couple days, but I just found out that the CP2102 module I ordered has the pin layout that doesn't exactly match the arduino. I can solder them together without much issue, but it looks like both my CP2102 and my aduino clone have RST connections instead of DTR. Based on some research, there is some backwards compatibility, but does anyone know if RST will work with flashing the STC?

The DTR line of the serial port is used to reset the arduino to get into the bootloader. So I think it is safe to assume that RST is DTR, just labeled diffrently.

Excellent! I felt like I was thinking about it correctly, but then I doubted myself, and with the update not taking place within a few minutes made me doubt myself even more. Thanks for the confirmation, and the unit has now updated (I just checked!).

Cheers!

Cool! Yes, ideally the change would be instant, but then that would make a special case that would need to be handled (adding code and complexity).
Glad you got it sorted!

Cheers!

 

[wbarber69]

Yeah I like the idea of a strain gauge, but it looks like a more expensive route. Working with a voltage divider would make it really easy, assuming the stc can handle it. Alpha, do you know what voltage is applied across the probe terminals? I looked into possibly a weight that was just buoyant at an SG of 1.030. That way, when it sinks, it pulls down on a sensor or gauge. In the end it's probably just more reliable to put a scale at the bottom of the charger, and not mess with putting anything else in your carboy...

Why not get a decent scale. Measure your equipment in full without any wort. Then fill noting the sg then take reading over the course of the ferment. Specific gravity is measured by the weight of the liquid based in the absolute weight of pure water. The difference is the sg. I've been learning how to arduino so I could build something out of a wiifit board that could do scheduled measurements but I'm a long way off. Only reason I want the wiifit board is because it's wireless but any decent digital scale that could measure down to .001g could do the trick. It needs to be metric since that's what specific gravity is measured with.

 

[alphaomega]

@wbarber69: Same thing. A scale is just a pre built unit based on strain guages.
It might be doable, but like I said, i think drift could be an issue. Unless you plan on lifting on and off the scale for measurements.

 

[pietro811]

Hi , sorry if I make a silly question . I would use this stc1000 to make homebrew , all grain method , I would like to figure out how to set the minutes in the different steps of temperature , unfortunately I find just hours . Thank you

 

[alphaomega]

Hi , sorry if I make a silly question . I would use this stc1000 to make homebrew , all grain method , I would like to figure out how to set the minutes in the different steps of temperature , unfortunately I find just hours . Thank you

'Standard' stc-1000+ only allow hours. There is a minute time base version here or a version built to completely control a brewing session of a single vessle brew system here.

 

[adam01]

http://www.thebeerbug.com/
Digital hydrometer...

Now if they have an output port to work with the STC...

 

[wbarber69]

@wbarber69: Same thing. A scale is just a pre built unit based on strain guages.
It might be doable, but like I said, i think drift could be an issue. Unless you plan on lifting on and off the scale for measurements.

That's why I said it needs to be a decent scale. Something that would probably have to be able to read continuously during the brew. It's just a little idea I was working on. Never said i had it all figured out. You're probably looking at a good $1000+ scale too. The wiifit on the other hand has multiple weight sensors. There are old projects using them online but I haven't had any luck getting a current run of Linux to work the way I need it to, something about some updated drivers that don't quite work the way they used to. I have even found one project where a guy was using it to measure the total weight of his beer fridge to make sure his kids didn't sneak a bottle here and there, but it's like anyone who ever had any interest in messing with them just moved on years ago.

 

[FuzzeWuzze]

Strain gauge is what I meant - long day. I'd think using something like ptfe for the weight and suspension might work. You may need something less dense though. I've never worked with strain gauges. Just throwing out an idea that I'd think may be able to be more accurate for those so inclined.

I tend to not really want to worry that much and make fermentation temperature changes based on visual observation or set times which tends to work just fine.

Not to jump in late but....
I would think something like a hall effect sensor would probably be the more reproducible over time when it comes to this if you could make something that was reliably neutrally buoyant at a set gravity. At that point your basically just making a level sensor like many cars use in their gas tanks. Hall sensor on top of fermenter, float with magnet on top, float moves up and down, giving the hall sensor varying current you base your gravity readings on. Alternatively you could put a strip of hall sensors down the side of your fermenter and use the values of each to determine where exactly the float is and correlate that to a gravity reading.

You can read more about it on the Wiki
https://en.wikipedia.org/wiki/Hall_effect_sensor

Either way, its a very difficult problem to solve, even the commercial products that do it are rather iffy from what i have read.

The issue with all of these though is using any type of float is going to have its measurements skewed by krausen and Co2 bubbles that form and stick to your float, screwing its 'expected" buoyancy up.

 

[alphaomega]

@FuzzeWuzze: I think you are right that a hall sensor would probably be better. And that even without drift issues, the issues with CO2 and krausen still would be a problem. Floats does noot seem like a goos option to me.
With all the 'problems' that is why I think a simple bubble counter would be a good start. I will at least provide some info on the rate of fermentation and is really simple to implement.
I'd like to see something simple and non-invasive to 'beat' that, something like measuring resonance frequency of the wort or possibly capacitance, but I don't know if either of those will provide any data that correlate to state of fermentation. Like I said before, personally, I don't really care that much, so I'll leave the breakthrough to someone else

 

[doug293cz]

@FuzzeWuzze: I think you are right that a hall sensor would probably be better. And that even without drift issues, the issues with CO2 and krausen still would be a problem. Floats does noot seem like a goos option to me.
With all the 'problems' that is why I think a simple bubble counter would be a good start. I will at least provide some info on the rate of fermentation and is really simple to implement.
I'd like to see something simple and non-invasive to 'beat' that, something like measuring resonance frequency of the wort or possibly capacitance, but I don't know if either of those will provide any data that correlate to state of fermentation. Like I said before, personally, I don't really care that much, so I'll leave the breakthrough to someone else

Alpha, you might be on the right track with the resonant frequency thing. I bought a piece of gear many years ago for real time monitoring of an etch solution specific gravity. It was basically a tuning fork made from a hollow tube thru which the solution flowed. Tube was shaped like a water heater element (the non-wavy kind.) There was a transducer on the free end of the tubing loop that could magnetically excite vibrations along the tube. The resonant frequency was a function of the density of the liquid in the tube. I don't remember, but it may have been possible to measure viscosity based on the "Q" of the resonance peak. Implementation issue for fermentation monitoring is that you have to pump wort/beer thru the loop. The other issue is size. That thing was 2.5 - 3 feet long, and the protective cover was about 5" in diameter. I'm sure it could be made smaller, but the smaller it is, the higher the resonant frequency, and probably the lower the sig/noise ratio.

Edit: found some interesting information here

Brew on

 

[jaw94087]

I’ve been lurking in the shadows on this thread for some time and thought I’d post my observations regarding automation and monitoring. I took the chicken’s way out and purchased a completed unit from Will Conrad, which I’ve been very happy. I use his 2 sensor model to help with overshooting on the cooling cycle. I also have a Beerbug with both ambient and fermentation temperature monitoring. The Beerbug uses a stress gauge as discussed, but gravity readings are very inaccurate and variable, which I suspect is the nature of the beast relating to stress monitoring the weight of the plastic probe during fermentation.

I have found that monitoring of ambient and fermentation temperatures are just as useful from the standpoint of determining the progress of fermentation as the Beerbug stress gauge gravity readings. During active fermentation, as the yeast produces heat, there is an easily detectable delta, and that seems to directly correlate to fermentation progress. I’m not a biologist, but the delta correlates well to the drop in gravity. This led me to take a spare Raspberry Pi and implement something like this here What I do is capture the ambient and fermentation temperatures and save these temperatures every 5 minutes in a file stored in the cloud at box.com. It is trivial to take that data and graph with excel. This is really a lot simpler than messing around with the Beerbug and dealing with a probe sitting in fermenting beer. What is shown in the attachment are two graphs of ambient and fermentation temperatures for a wine and beer fermentation. The wine has been fermenting at a constant 70 degrees for the past week. The beer graph is a completed fermentation where the STC-1000+ setpoint was ramped up when the fermentation slowed. Shown in each graph (attached), are two polynomial trend lines for the temperatures that smooth the data and make it easier to interpret. As you can see in the wine plot, the delta is large at first because the difference between the starting wine must temperature and the setpoint on the STC1000+, but a few days later after the fermentation has stablished, the fermentation begins to drive a larger delta, but then the delta declines as the yeast is starting to slow. When brewing beer, I use the point of decreasing delta as a trigger to ramp up the fermentation temperature a few degrees.

I can’t imagine how such data would make it possible to automate the STC-1000+, but I have found temperature monitoring interesting and helpful…

View attachment Graphs.pdf

 

[alphaomega]

@jaw94087: That is a really good idea! Thanks a lot for sharing! As you probably know, STC-1000+ is pretty constrained by the MCU, and implementing this on the STC might not be feasible. Another big issue would be that the STC does not know what each step does, so even if it could tell the differential is closing in, what should it do?
It could be done by using the communication sketch and an extra tempprobe on the arduino for ambient. Then the arduino could update either the profile or the setpoint to ramp up.
Anyway, thanks again for sharing! This is definately interesting, this I feel is something I need to investigate a bit

 

[Jakor]

Finally got my arduino, and I have been having nothing but problems. I suspect that my pro mini came without a bootloader (http://www.amazon.com/gp/product/B00GLES8BW/?tag=skimlinks_replacement-20)

Looking around, it looks like if this is the case, I can't install a bootloader without a dedicated programmer. If this is the case, it might not be worth spending additional money to get my STC flashed. Does anyone know how to check if a bootloader is installed? And if I don't have one, is there a way to install it with my UBS to TTL CP2102 module? When I attempt to upload the sketch, the progress bar reaches about 90% before hanging for about a minute, then spits out the following error:

"avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xce"

Thank you for any guidance anyone can provide!

 

[Jakor]

Okay so first off, sorry for the double post. It seems like my posts must get approved before they appear in this thread, but I need to call it quits for tonight and wanted to give an update.

I somehow successfully uploaded the sketch once to the arduino by holding the connections together extra tight. I suspect that my jumper wires are flaky. Next, I soldered wires to connect the arduino to the CP2102 module, and the device would not successfully upload anymore... I believe I had to switch the connections to TX-TX and RX-RX to get it to work. I tried both with my new soldered connection. Regardless, it looks like the arduino saves the sketch even when it's been powered off, so I can go into the serial monitor, and the intro text pops up. I send 'd', and I get the error that the STC is NOT found. I have double and triple checked my wiring that the arduino is connected correctly to the programming headers of the STC. no luck. I tried to blow the solder out of the holes, but I am pretty sure I will lift the pads before I ever have success with that. Even if my connections between the arduino and CP2102 are messed up now, shouldn't the firmware flasgin be successful, since the arduino is only sending text to the pc (Successfully), and being supplied power? Right now my main suspicion is that the jumper wires aren't all making a solid connections while I hold them against the pins. I tried melting the solder to level off the surface, and I can get the LCD screen to turn on when powered by the arduino, but I still get this error.

EDIT: Weird, my other post never went through... Well it is irrelevant at this point anyways!

 

[alphaomega]

@Jakor: You only need to upload the sketch once, so that should be good. You get the initial message in the serial monitor, that is good.
With 99% certainty, your problem is the connection between the arduino and STC. It can be a bit tricky to get a reliable connection. Try and try again. Check again that all the wires go to the correct pin.
Usually it shouldn't be that hard, but I've had units that have been finicky and even one unit that really wasn't flashable. I guess one of the pins (probably ICSPCLK) didn't have connection to the MCU.
I wouldn't give up just yet. Really make sure all the wires are correct and have good connection.
Best of luck!

 

[Jakor]

SUCCESS!!!.... sort of. I wound up soldering the wires directly to the STC, and it recognizes it. However, when I try to flash the Fahrenheit version of the software, the following appears:

"Bulk erasing device
Bulk erasing program memory
Bulk erasing data memory
Programming¨Â "

And it hangs there. Celsius works fine though. Could it be that the sketch I uploaded to my Arduino was corrupted? I definitely don't feel like getting the sketch to upload again, so Celsius will work fine, but I found that inconsistency peculiar. I even tried flashing the program memory only to the STC in Fahrenheit, and same thing. Both options for Celsius work though.

Anyways, thank you so much for all of your hard work @alphaomega!! I wish I could gift you some homebrew to thank you, but I'm pretty sure it wouldn't survive the trip to Sweden...

Cheers!

 

[adam01]

Hi Alpha;

STC is doing great. Lager profile is running. I have been adjusting the thermostat mode temp a bit these past few months.

Is is possible to have the SP parameter be the first on the list. Right now it comes up with hysterisis. I have changed that maybe once.

Great job...

 

[alphaomega]

@Jakor: Nice. Sure, try to upload the sketch again. Couldn't hurt trying.

@adam01: I hear ya. At the moment things need to be in order of the type of setting. I might be able to change that, but I can't make any promises. I haven't had much time to put into this lately. But I made and issue for it, so I won't forget.

 

[anil]

Having purchased two stc1000 from ebay and found them to be the version that uses the N96A8211 chip, I decided to do the conversion to PIC 16F1828. I wanted to see if it was possible. It was successful, below is the info you will need if you want to have a go.

The pinouts are as follows

16F1828 - N96A8211
1----------- 15 (VDD +5V)
2----------- 1
3----------- 2
4----------- MCLRn/VPP/RA3 (Programming Header)
5----------- 10
6----------- 13
7----------- 14
8----------- 19
9----------- 18
10---------- 11
11---------- 12
12---------- 6
13---------- 3
14---------- 9
15---------- 8
16---------- 7
17---------- - Temp Probe 2 Input
18---------- 20 Temp Probe 1 Input (ICSPDAT Programming Header)
19---------- 17 (ICSPCLK Programming Header)
20---------- 5 (GND)


The button BTN_PWR and BTN_S and BTN_UP and BTN_DOWN Addresses need to be swapped respectively in the software.
The temperature probe on the N96A8211 operates in the opposite way to the PIC version.

So that has to be changed. It requires a 10K ohm resistor pull down resistor on the input of the pic, with the temp probe connected between the pic (pin 18) input and vcc. (+5)
The conversion can be done on a bit of prototyping board, there is enough space in the case for it,

Hope you find this useful.

 

[smithabusa]

If you decide to change your mind I have lots of the flashable versions if you need one/some

 

[alphaomega]

Having purchased two stc1000 from ebay and found them to be the version that uses the N96A8211 chip, I decided to do the conversion to PIC 16F1828.

The pin outs are completely different.
The button BTN_PWR and BTN_S and BTN_UP and BTN_DOWN Addresses need to be swapped respectively in the software.
The temperature probe on the N96A8211 operates in the opposite way to the PIC version.

So that has to be changed. It requires a 10K ohm resistor pull down resistor on the input of the pic, with the temp probe connected between the pic (pin 18) input and vcc. (+5)
The conversion can be done on a bit of prototyping board, there is enough space in the case for it.

I’m toying with the idea of getting a small PCBs made that will hold the PIC chip and that can be soldered in place of the N96A8211… I’ll publish the pcb layout and or make the adaptor available if there is any interest.

That is cool
But there is no need to gamble anymore. The correct manufacturer is known now and has a store on aliexpress.
So, you know. Go for it if you want, do tell your experiences if so. Or just get another unit
The stock ones are still good, and you can always make some use of them.

 

[alphaomega]

Hi!

After not having done very much coding for the STC-1000+ project during the summer, I have made a pretty hefty push now.
I decided that the 'minute' base version of the firmware stays, and that the differences between the OVBSC fork and the main project are smaller than the similarities. So, to make maintenance easier, I have merged the branches/forks into master and completely reworked the build scripts.
I have also in the process fixed a few issues and reworked some of the differences.

From a user perspective not really big news, if anything I might have added bugs, but long term, this will definitely make for a more stable code base and issues does not need to be fixed in more than one place. The OVBSC project on github is now deprecated, I'll leave it for a while just as a fail safe, but eventually I will drop it.

I have also reworked the profile editor / sketch generator web page. I think it is a bit cleaner now, and supports all the firmware versions that is built.
Please check it out. And as always, please report bugs!!! If you don't report, it will (likely) not improve.

Check it out here:
https://goo.gl/z1KEoi

I still have to clean up / rearrange / edit some documentation, but once that is done and no major (found) bugs are left, v1.09 is next

Cheers!

 

[HansEinar]

Great!
Just to clarify. Latest release in Github is 1.07, but download Vanilla version from sketch generator is 1.09. What are the differences between those two?

 

[alphaomega]

Great!
Just to clarify. Latest release in Github is 1.07, but download Vanilla version from sketch generator is 1.09. What are the differences between those two?

Ah... Yes... Alright... I must have already bumped the version before... Dang it.
Well, no backsies.... I'll just leave the 1.08 to be lost. Like leasure suit larry 4

I'm working on the revising the documentation, that will make it clearer I think. But the vanilla version has probe 2 stuff removed (hy2, tc2, Pb2). Which makes it less confusing if you never intend on adding a second probe.

Otherwise, the only change should be that SP has moved to the front of the Set menu (that + different layouts of eeprom for the different versions, makes for the need to update eeprom data as well).

Edit: Turns out you could tag a previous commit and create a release from it, so I created the release for v1.08 (which added the communication and 433MHz radio firmwares).