Stc-1000+

Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum

Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Awesome work AlphaOmega!

I just reprogrammed mine and it worked perfectly the first time. Is that the relays chattering when the programming is being done? (weird)

I had to adjust the STC-1000 down by 2.6*F to match my Thermapen at 56*F. Then I tested it in some water that the Thermapen said was 76.4*F and the STC was reading 0.2* lower. So, it's pretty close.

I'll do some more testing this weekend.
 
What do you think about interfacing the R Pi to the STC-1000 to create a controller to make the step/profile changes dynamically, controlled from a web page? This might solve the limited memory issues you're facing trying to cram all that code and variables into a couple of bytes of RAM.

-gary


I'd love to see a project like this!
 
I was slacking while my code was compiling, came to HBT and...ended up reading more firmware.

Seriously, though, I am impressed. Great job on the reverse engineering, and the comments in the code make it easy to follow what's going on. The only part that confused me on a cursory look through the code were the magic numbers in the button_menu_fsm function. One could figure it out with the info at the top of page0.c, if necessary, though.

Nicely done! I'm sure the simplicity of the code belies the amount of reverse engineering involved.
 
I'd love to see a project like this!

Check out http://www.brewpi.com/. If you already have a Raspberry Pi, I don't see much sense in trying to interface it with a limited capability controller like the STC-1000. Just hook up an SSR and control it directly. Adding extra features in a fully-supported OS is probably going to be a lot easier than cramming them into the limited firmware of the STC-1000 or reconfiguring the STC-1000 to be interrupted and controlled by an external device. That said, it would be fun to do this, just not very practical.
 
Adding extra features in a fully-supported OS is probably going to be a lot easier than cramming them into the limited firmware of the STC-1000 or reconfiguring the STC-1000 to be interrupted and controlled by an external device. That said, it would be fun to do this, just not very practical.


Couldn't agree more. These are great ideas, but some of them are totally impractical and just not worth attempting, given the reward or lack thereof.
 
Awesome work AlphaOmega!

I just reprogrammed mine and it worked perfectly the first time. Is that the relays chattering when the programming is being done? (weird)

I had to adjust the STC-1000 down by 2.6*F to match my Thermapen at 56*F. Then I tested it in some water that the Thermapen said was 76.4*F and the STC was reading 0.2* lower. So, it's pretty close.

I'll do some more testing this weekend.

Most calibration techniques would suggest preparing a crushed ice/water bath to test and/or boiling water.
 
If you can, it is best to calibrate in the temperature range that you will be using the device.

I don't plan to freeze or boil my beer, so I think somewhere in the 60*F range is good.

The crushed ice mixture and boiling is good if you don't have a thermometer with a known good calibration to use as a comparison. The Thermopens are certified.

I will check it at both extremes though. It'll be interesting to see if it is very far off at those ends of the range.
 
If you can, it is best to calibrate in the temperature range that you will be using the device.

I don't plan to freeze or boil my beer, so I think somewhere in the 60*F range is good.

The crushed ice mixture and boiling is good if you don't have a thermometer with a known good calibration to use as a comparison. The Thermopens are certified.

I will check it at both extremes though. It'll be interesting to see if it is very far off at those ends of the range.

That seems like pretty sound logic there. Let me know if you find there to be a big difference, so I can recalibrate mine if needed before my first brew with it. I've got a Thermapen along with an RT-600C that's identical in accuracy and calibration. That's what I used to calibrate mine the other day.
 
So I just want to update on what's going on. I have just updated github with latest changes.
I have refactored and cleaned up the code. This might induce bugs, but I think in the long run, it is better to refactor early. I feel pretty good about the changes made, so hopefully there won't be need for many larger changes down the road.

I have updated the lookup table with new data that I found for NTC thermistor (10k 3435). The old data is very similar to the new data for temperatures above room temperature, but start to deviate some below. This would account for nickmv's observations. Still, looking at the specs for the sensor, there is a fairly large tolerance, so calibrating the sensor around your working point would still be a very good idea.

I have managed to cram in oversampling and averaging of the AD, which is also a really good thing.
I have had problems with sensor alarm, somehow it interferes with the cooling relay, (this is driving me nuts... I had a helluva time locate what was causing the problem, and now that I found it, I cant for the life of me understand why it could be an issue). So, until I can figure out what the issue is, I have disabled the alarm for now.
 
The new code isn't working for me. It will display a temperature, but none of the buttons work, so I can't get into set mode. The best I can get is an occasional blink in the display that seems associated (delayed) with a set button press.
 
AlphaOmega, question about the following:

The way that STC-1000+ is implemented, the profile will automatically set 'SP' when a new step is reached in the profile. That means when running a profile, 'SP' is NOT preserved. Every hour, 'dh' (and if next step is reached, also 'St') is updated with new value(s). That means in case of a power outage, STC-1000+ will pick up (to within the hour) from where it left off.

So are you saying that the duration value should decrement over time? For example, if I set SP0 at say, 65F, and dh0 to 4, will dh be 1 after 3 hours of running that profile under that step?
 
The new code isn't working for me. It will display a temperature, but none of the buttons work, so I can't get into set mode. The best I can get is an occasional blink in the display that seems associated (delayed) with a set button press.

I've had that issue as well, but thought I had it fixed now. When did you download?
Just to verify, I downloaded the actual sketch from github and tried it myself, I it seems to work for me (both C and F). If you're interested, the technical issue was that I was trying to use the display state (from Page1) to determine if display should show temperature (in Page0). That seems to work very sporadically. It could be because of a compiler bug. I have since changed that and it has worked a lot better.
Check that you really are running latest code, and if you still have the issue, please report it again, so I can go kill myself (nahh... I shouldn't joke about that stuff... I've been listening to the BN too much lately...). Seriously though, if latest code still have this issue, I may have a real problem.

AlphaOmega, question about the following:



So are you saying that the duration value should decrement over time? For example, if I set SP0 at say, 65F, and dh0 to 4, will dh be 1 after 3 hours of running that profile under that step?

No, dh and St counts up (so dh will, hopefully at least, be 3 after 3 hours, provided the step is longer than 3 hours of course), but otherwise correct. They track progress in current running profile.
 
I downloaded it this morning, just a few minutes before I made the post.

What is the best way to tell what version I have? I didn't see a version number in the code.

Thanks
 
No, dh and St counts up (so dh will, hopefully at least, be 3 after 3 hours, provided the step is longer than 3 hours of course), but otherwise correct. They track progress in current running profile.

Ahhhh, ok that makes sense. I learn something new about this every day. I thought it was telling you progress remaining, but that makes sense.
 
I just ran a diff on the code I downloaded this morning and what is currently available, and they match exactly.

I reverted to the previous version I had and it works as before, so that rules out a hardware failure.
 
I just ran a diff on the code I downloaded this morning and what is currently available, and they match exactly.

I reverted to the previous version I had and it works as before, so that rules out a hardware failure.

That is bad news. I've been assuming that the global state thingy didn't work because the variable was used from different banks, if that is not the case then I think the cause is we're running out of either stack or program memory for page 0. So, I will probably need to slim the RAM and/or program mem usage even more and might have to drop some functionality.
Has anyone else confirmed this? Currently, my setup works OK, but I have seen the same problem previously.
 
Great work -I'll flash it and give you feedback as soon as my STC-100 turns up.

How tricky would it be to alter the code to allow for times between setpoints of less than 1 hour? (fraction of hour or in minutes)

Not useful for brewing but would open this project to pretty much any other temperature control applications that could use a cheap non PID controller.
 
Congrats on Hackaday!

The older code worked pretty well, though I would like to see it with the specific temp sensor specs that you found.

On the recoded version, could you drop a profile and free up enough memory or are we talking about needing a lot more?
 
OK, so either I've found a bug, or I don't fully understand how to use the software.

I have Profile 1 set to sP0 of 72F, with dH0 of 150 hrs, and a hysteresis (under "set") of 4.0 degrees). I then select "rn" under the set menu, and select Pr0 to run the configured profile.
Now, based off the settings, the controller should not run, as the beer's temp is currently at 68.5F.

However, the Heat relay is engaged. Luckily I don't have a heating device hooked up so nothing happens, but the fact remains that it's trying to heat, despite being within the allowable swing range.

Am I just using this thing wrong?

EDIT: After unplugging the whole contraption and plugging back in, the Heat light goes off. I think there's some bug that's keeping it on. Perhaps, once it cuts on, it won't turn off until it hits setpoint, regardless of the hysteresis setting? This would explain why, if so.
 
Congrats on Hackaday!

The older code worked pretty well, though I would like to see it with the specific temp sensor specs that you found.

On the recoded version, could you drop a profile and free up enough memory or are we talking about needing a lot more?

I'll look into it.
OK, so either I've found a bug, or I don't fully understand how to use the software.

I have Profile 1 set to sP0 of 72F, with dH0 of 150 hrs, and a hysteresis (under "set") of 4.0 degrees). I then select "rn" under the set menu, and select Pr0 to run the configured profile.
Now, based off the settings, the controller should not run, as the beer's temp is currently at 68.5F.

However, the Heat relay is engaged. Luckily I don't have a heating device hooked up so nothing happens, but the fact remains that it's trying to heat, despite being within the allowable swing range.

Am I just using this thing wrong?

EDIT: After unplugging the whole contraption and plugging back in, the Heat light goes off. I think there's some bug that's keeping it on. Perhaps, once it cuts on, it won't turn off until it hits setpoint, regardless of the hysteresis setting? This would explain why, if so.

First, if Pr0 is run, data in Pr1 won't matter. I'll assume typo.
Even so, if it already is heating, then it will continue until it hits setpoint. That is how it works, when within the allowed range it shouldn't change state.
 
I'll look into it.


First, if Pr0 is run, data in Pr1 won't matter. I'll assume typo.
Even so, if it already is heating, then it will continue until it hits setpoint. That is how it works, when within the allowed range it shouldn't change state.

Yeah it was a typo, and yeah, I think you're right. For some reason I was just getting confused about the logic. It makes sense that it would keep running. Otherwise, if you had an SP of 70 w/hysteresis of 2F, and got to 72.1, it'd cut on and only run down to 72.0 and stop.....which of course wouldn't make sense.

Ignore me...carry on, lol
 
Yeah it was a typo, and yeah, I think you're right. For some reason I was just getting confused about the logic. It makes sense that it would keep running. Otherwise, if you had an SP of 70 w/hysteresis of 2F, and got to 72.1, it'd cut on and only run down to 72.0 and stop.....which of course wouldn't make sense.

Ignore me...carry on, lol

No worries :) It's better to ask if not sure, than missing a bug. So please, you carry on :)
You haven't had any issue with the buttons nickmv? Are you using the latest code?
Have you seen any improvement with the temperature since I updated the lookup table?
 
I'm using the latest code and absolutely no issues whatsoever, at least that I can tell. Certainly no button issues. I of course have just flashed 1 version over the other (I don't believe there's any other way to do it, is there?).

I've started labeling the versions I've downloaded so I can revert to older ones. So far I've got the past 3 versions.

I'm also trying to see what I can do regarding making it easier to flash. It appears that Mini and Micro USB are both 5 port designs, so I think I could, using the solder gun, get the wires rigged up into a female port that I could mount into the side of my controller project box.

This is probably a bit far off time-wise, but sure would make flashing a lot easier. For now, I gotta unscrew the box, take the cover plate off, then take tape off the wire ends (on there so the wires dont cross while NOT being used), then hook it all up, then of course repeat in reverse.
 
I'm using the latest code and absolutely no issues whatsoever. I of course have just flashed 1 version over the other.

I've started labeling the versions I've downloaded so I can revert to older ones. So far I've got the past 3 versions.

I'm glad to hear! Maybe 1.0 is not so far away :)
 
Haha, yeah I've marked them as 1.0 and up, but should probably have that as 0.1 and up.

Anyways, check this out. You, as well as a couple of my pictures, are getting recognition. I saw it linked on reddit. Was like "Oh cool another article on it....WAIT, thats my pictures!"



Also, after flashing your latest firmware, I noticed that the calibration was much tighter. That new thermistor data appears to be working out. I only had to adjust the probe down 0.4 degrees F, which is very nice. I need to do some more testing near the actual fermentation temps, to make sure it's close at that range, which is the one that counts (unless you can reverse engineer yeast to ferment at 32F LOL).
 
NICKMV, a question: you mention disassembling to flash--does the STC not work without cover? Or are you just be careful? Pardon my ignorance if this is a silly question, mine has yet to arrive & it's killing me.
 
Hello. New guy here, not into brewing myself, but I on occasion assist another member on here with projects to help his brewing.

We just flashed his controller to the latest code as of this morning. Being the practical sort, I thought that it would be a good idea to have a good solid method of reprogramming the controller without taking the entire unit apart each time.

This is what I came up with. The 5-pin header is an Extension cable for a balance plug for 4s LiPo battery packs. It has both a male and a female on one cable, which I just cut in half.

Male side on the controller, sticking out of the back.

dDDDtgV.jpg


Female side on a protosheild with jumperwires to pins.

kw4nAcT.jpg


Thank you for all your hard work! I predict this controller becoming MUCH harder to find in the very near future!
 
NICKMV, a question: you mention disassembling to flash--does the STC not work without cover? Or are you just be careful? Pardon my ignorance if this is a silly question, mine has yet to arrive & it's killing me.

It works fine without the cover on it, which is just made of plastic. But you can't flash it unless you take that cover off. Otherwise, you have no way to get to the points to which you need to solder either wires, or a pin header. You can put the cover back on afterwards, but you're going to need to do some work on the case in order to fit the wires through.

I of course wanted to leave my wires on after flashing, so I could flash easier in the future. So, before reassembling mine, I modded the back of the casing so that the wires CAN fit. I basically just took a Dremel grinding bit and ground down part of the case, which let the wires fit through easily. Hard to describe without pics, but I don't feel like taking it apart to get a pic right now. You'll see when you get to that point.

Next time alphaomega gets a new software release, I'll take a pic. But you may have your controller and other equipment by that point.

Side note for AlphaOmega -- damn, I'm behind on the weekend. Just saw you had already posted about hackaday. Whoops...
 
Thank you for all your hard work! I predict this controller becoming MUCH harder to find in the very near future!
First off, excellent work on rigging it up for easy flashing! I might have to find something similar.

Secondly, to your quote -- Why's that? It's been in production for a while now, with plenty of supply. If you're suggesting that the homebrew community is going to snatch it up in droves, it ain't gonna happen.

This is a great project, but it's for the tinkering homebrewer who's willing to risk destroying equipment in order to mod something. I think you'd be surprised to find that the amount of increased demand that this project generates is likely immeasurable when compared to the current demand the controller has in general. And when you mention the word SOLDER, you usually drive away over half of folks.

Regardless, I hope it starts getting more recognition. I ordered a 2nd one last week, so I now have an extra on hand just in case (possibly replacing my Johnson A419 in my keezer soon). I'm also debating ordering 1-2 more just to have PERIOD, in case they're ever discontinued.
 
I have to agree with nickmv on supply--this controller has been mentioned in these forums for YEARS--and there are scads on eBay, on Amazon, at NewEgg, just about everywhere. I've been lurking for months making notes to use one for a fermentation chamber but the sad fact is that until I can steal my kid's college dorm fridge away (May!) from them, I don't have anything to control but basement hatchway space for cooling and small heater.
 
This is probably too many posts in a row now, at 3, but whatever.

AlphaOmega, a quick temp calibration observation, and some suggestions about the software.

First off, after calibrating to 32.0F ice water, I decided to do some with a cup of 65.1F water. The probe read 65.4F, which is of course 0.3F high. So there's definitely some tweaking still necessary, most likely. However, this brings up a valid question --- how much tweaking is possible/necessary to attempt before you can never truly get an accurate look-up table. And furthermore, how much of it is likely due to manufacturing variances from probe to probe. This isn't an industrial/commercial-grade probe after all, and costs pennies to make.

For all of you other guys who've flashed, please calibrate to 32.0F water, then do a test in the 60-70F range and see what kind of differences you get! This data is very useful. I may go back and do some more thorough testing in the 60-75F range, attempting to test every 2 degrees and comparing (ie. 60, 62, 64, 66, 68, etc).

Now, onto the menu suggestions:

1. Why is the Profile accessible through both the main menu, as well as the Set menu? This seems repetitive, and possibly confusing.

2. Based on #1, why not have the "Run" function located on the main menu instead of having it inside the "Set" menu?

So basically, the main menu would contain:
1. Run -- choose to then find a profile to execute. However, don't have settings on the Profiles when you choose. So basically, I'd press S to bring up the main menu, then choose "rn", then choose Pr0, for example, and it's done. No settings to bring up, etc. Just a very quick and to-the-point execution of a profile.

2. Set -- show all settings, but also show profiles. Or perhaps, somehow have the profiles as a submenu inside the Set menu. But bottomline, keep the settings of setpoints and durations for profiles somewhere inside the "set" menu, and nowhere else.


Thoughts?
 
Regardless, I hope it starts getting more recognition. I ordered a 2nd one last week, so I now have an extra on hand just in case (possibly replacing my Johnson A419 in my keezer soon). I'm also debating ordering 1-2 more just to have PERIOD, in case they're ever discontinued.

This is what I was talking about. :)

Just because of a new firmware (and potential shenanigans with it) you pulled the trigger on a new one. And you are now thinking about two more.

Multiply that by, how many people do we have browsing this thread? And all the reblogs and shares on all the various social media sites? And the talk about it at hackerspaces across the world?

That was what I was thinking about. The fact that most of the hard work has been done already (making a functional open source firmware) means that tons and tons of people are going to pick it up and start modding it for their own use. And combine with how cheap it is already...

I was right there in the beginning when the WRT54G was cracked wide open, and I saw that router go through supply and demand price fluctuations that would make a gas station owner do a double take.

At any rate, that is my thoughts on the matter.
 
I'm using the latest code and absolutely no issues whatsoever, at least that I can tell. Certainly no button issues. I of course have just flashed 1 version over the other (I don't believe there's any other way to do it, is there?).

Hmm, I tried the current version twice and got the same results (buttons don't work) before I reverted back to the previous version (which still worked fine).

Alpha or Nick, any ideas why it might be doing this on mine? Anything different I can try?

BTW, I'm not supplying AC power to it when flashing. Doesn't seem to need it unless you think it might be causing my problem.

Thanks
 
Hmm, I tried the current version twice and got the same results (buttons don't work) before I reverted back to the previous version (which still worked fine).

Alpha or Nick, any ideas why it might be doing this on mine? Anything different I can try?

BTW, I'm not supplying AC power to it when flashing. Doesn't seem to need it unless you think it might be causing my problem.

Thanks

So you've never had any issues with the previous version(s) working?

Reason I ask if because I might suggest checking your soldering to make sure no wires are crossed or another contact was crossed, but it sounds like that's not likely.

I'm not sure I have any ideas. That sounds VERY strange. Where did you get your controller from? I assume it DID say it was from Elitech and had the standard orange box with a white manual inside? Just curious.
 
Check out http://www.brewpi.com/. If you already have a Raspberry Pi, I don't see much sense in trying to interface it with a limited capability controller like the STC-1000. Just hook up an SSR and control it directly. Adding extra features in a fully-supported OS is probably going to be a lot easier than cramming them into the limited firmware of the STC-1000 or reconfiguring the STC-1000 to be interrupted and controlled by an external device. That said, it would be fun to do this, just not very practical.

Brewpi is interesting. I've been following it since Uberfridge days. However, there are still several issues with Elco's chosen method of control---and the basic implementation. Really the nicest thing about brewpi is the UI and its Rpi based features.

Specifically, it doesn't support direct heating of a fermentation vessel---ie, a heater attached to the side of the fermenter. Second, it requires a separate Arduino uno/leonardo, and associated hardware for every control point (fermenter, etc). The arduino alone costs more than an STC-1000, and I still need an SSR, and a temperature probe. With case an all, each Brewpi control point will cost around $40. Besides, I've already got the STC-1000's. I have a total of 6 managing my fermentation chamber and 4 separate fermenters. So...free or spend another $240+ for a BrewPi setup?

So, if a primitive protocol could be implemented using the EUSART to allow I2C type of access to several STC-1000's that are then managed by an Rpi (or a Teensy 3.1) that would have a lot of value.
 
OK, so I went back and took some readings in the fermentation zone, and was impressed by the results.

AlphaOmega, please note that for my report earlier today about the 65.1F water, I FAILED to remember my temperature correction was being used (set to -0.4).

Ge6bjaL.png
 
Back
Top