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.
If its only a display option then its easy. Compute in Celsius and display in Fahrenheit. Of course, setup either is convert back or always program in Celsius.

But priority first - get it stable...

I think programming in C and displaying in F would be a bad solution, and very confusing. Converting back does not seem feasible to me, the calculation will not be simple, and even if something clever could be done, it would probably be approximative, and not much better than just setting the value in C and displaying in F (like I said before, it will be weird).
I'm not saying no, I'm just not sure that the solution in the end would be good enough to warrant the effort. If it is not simple, and not perfect, then I actually think the current solution is better. If there is a way to implement it that is perfect (or at least near perfect) and don't add to much complexity, then I'm open to this.
 
Oh yeah. I forgot.
I've been working on the "power off" function and I think I might have something soon that is good enough. Also, I'm adding functionality to show setpoint when pressing 'up' button when temperature is showing.
These are pretty much the last features I wanted to add. I also know that changing step manually during a profile, does not really function as one might expect. It won't change until the profile calculation is run (which might be an hour away). I've been thinking about this and fixing that issue will not be easy and the fix might be worse than the problem.
So, I'll try to run some more tests myself, but if no major issues are found, I'm thinking v1.0 might not be far away.
 
Oh yeah. I forgot.
I've been working on the "power off" function and I think I might have something soon that is good enough. Also, I'm adding functionality to show setpoint when pressing 'up' button when temperature is showing.
These are pretty much the last features I wanted to add. I also know that changing step manually during a profile, does not really function as one might expect. It won't change until the profile calculation is run (which might be an hour away). I've been thinking about this and fixing that issue will not be easy and the fix might be worse than the problem.
So, I'll try to run some more tests myself, but if no major issues are found, I'm thinking v1.0 might not be far away.

Great news! Thanks for the update and the hard work. I'll of course be flashing and testing once it comes out.

Also, what about, for pressing 'down' button, to show duration elapsed, or remaining duration? It would complement the setpoint feature well.

I also think a thorough testing by a few of us would be a good idea before declaring a 1.0 version, just in case. Mainly just want to ensure that all the substeps of a profile work properly, and that all other features (swing, delay, etc) work properly. Shouldn't take more than 2-3 days max.

I'm more than happy to document those results in a QA-style format, since I work around those folks every day (Proj Mgr here).
 
Just curious, how many people are there out there actively flashing the latest version of Alpha's code onto an STC?

1. Alpha (I assume :) )
2. Myself (disney7)
 
Great news! Thanks for the update and the hard work. I'll of course be flashing and testing once it comes out.

Also, what about, for pressing 'down' button, to show duration elapsed, or remaining duration? It would complement the setpoint feature well.

I also think a thorough testing by a few of us would be a good idea before declaring a 1.0 version, just in case. Mainly just want to ensure that all the substeps of a profile work properly, and that all other features (swing, delay, etc) work properly. Shouldn't take more than 2-3 days max.

I'm more than happy to document those results in a QA-style format, since I work around those folks every day (Proj Mgr here).

Thanks! I'll try to test a bit more when I get home, and hopefully push the changes. If you are eager, I push to my 'work' branch before I push to master.

Yes I thought about that as well. I might need to think about that for a bit, because you'd really need to show both step and duration, ideally even which profile is running. It might not be impossible, but again, it might not fit either. I could give it a try though.

Setting up a few test cases would not be a bad idea. I'm even thinking about if I could set up a test rig, for running a profile and logging temperature, time and maybe even relay output, it would be nice to be able to run some kind of long term test. I do have a couple of TEC's that would be cool (pun intended) to use for that.
 
I'm still waiting on my spare STC to arrive before flashing - it shipped via Amazon yesterday.
 
It seems like it would be easy enough to have both a F and C version. There's absolutely no reason to be switching between the two. Just a thought.
 
There is some new code in the work branch on GitHub if anyone like to test. I added button down shortcut to show profile, current step and current step duration.
I haven't had enough time to test the changes myself, so I'll hold off a bit more before merging to master.
 
Word, I'll check it out in a bit. Got some klipsch surround speakers I'm installing first.

Sent from my Nexus 5 using Home Brew mobile app
 
I remember those back in the days of flashing the ECU on my car! Can you use that by just connecting it to the pins on the STC-1000 board, or do you need to remove the chip and place it in the ZIF socket?

It has an ICSP header on it also - that is what you would connect to the board.
 
Alright, alphaomega, I'm having some serious problems getting the controller to turn on the cooling relay. It appears to have some software issue where it's stuck in cooling delay mode, or worse -- hardware fault and is now hosed.

Here's what I've done:

1. Config'd Pr0 to have a series of steps downwards. Current ambient beer temp is at 66. Sp0 is at 62 with hY of 0.5 degrees.
2. The steps eventually, over a series of 18 hrs, run it down to 48F.
3. Set cooling delay to 0, or 1. Just to get it to come on quickly.
4. Select rn and the Pr0 profile.

And that's it. It sits there flashing the cooling light, and never solidifies and turns the relay on. I'm stumped. At first I realized I had the delay set to 15, so i set it down to 1 min. Then that didn't do crap, so I set it to zero. With a delay of 0, it should be cutting on immediately. I've been sitting here for 30 mins fiddling with it, and CANNOT get it to come on. I've unplugged it and plugged back in, I've verified that St is on 0 (step zero) and that the current SP is indeed 62F. It will just not come on.

I'm wondering if I've discovered a serious bug. This is really frustrating, and I'm afraid I've possibly fried the cooling relay on my controller somehow, despite not messing with it in some unreasonable manner.

Edit: further testing reveals that the heating relay works just fine. I ran another profile, and the heat relay cut on just fine. The instant I switched back to my cooling profile, it went straight back into the flashing cooling light (keep in mind, cd is set to 0 so it should never do that).

I'm starting to wonder if cd's value is not getting updated properly or something. I know that cooling has worked before, as I accidentally activated it the other day while fiddling with settings.

2nd Edit: Flashed your latest from working branch, and its non-functional. Buttons dont do anything at all, can't access menus, etc. Pressing S does nothing, except on every 2nd press of S, the screen flashes. Going back to latest official release. After further testing, I have concluded that sometimes it's a result of flashing too fast, I think. However, your latest firmware will not work, period. I tried reflashing several times, to no avail. I had the same problem when reverting to an earlier official version (no buttons and screen blink), but a reflash did it, leading me to believe that it's the speed of the flash, on occasion. Still not sure why the latest doesn't work at all though.

3rd edit:Flashed back to latest official release and still no luck with the cooling relay. I'm going to now flash 1 version before that. After flashing back 2 versions, still no luck with the cooling relay. I'm convinced that it's either fried somehow (I hate to say it, but possibly due to flashing the controller a bunch somehow), or there's a software bug. It makes me think software since it sits here and flashes, and I never hear it attempt to click on. However, I'm leaning towards hardware now, as I just unplugged it, an when plugging back in, it made some really loud clicks over and over again, then I unplugged and back in again, to find it back to where it was -- blinking and doing nothing. Def starting to think the relay is hosed.

Overall, this has been a very frustrating night. I'm afraid my cooling relay is done for somehow. I know I got the cooling to work at some point with this software (cant recall which version), but I'm just not getting anywhere with attempts to get the relay to turn on at this point. Nothing but flashing (ie cooling delay). I've tried different delays and timed them, and have never heard a single sound to indicate any sort of switching. I actually had to send my 1st STC-1000 back due to issues with the cooling relay not working, so I'm wondering if I've got yet another one that's hosed (this time not immediately, but after modding). It worries me, in terms of the longevity of these controllers.

Alpha, assuming my relay is indeed hosed, is it possible that something in your software is contributing in some way to a short life span of the relay? Like, some sort of improper way to safely switch it, etc? Especially when switching the relay OFF, or handling the relay when the device is unplugged and then plugged in again? I'm just puzzled as to what could've caused this, especially given the fact that it ran for only ONE time since I got the thing flashed, and I had no issues then. Now all of a sudden it's broken, and I'd been using it fine for months now with stock software.
 
OK, I feel the need to post this in a separate post.

I'm going to bed now, but I just spent a bunch of time configuring up my replacement controller, and have the SAME EXACT results. Cooling relay does not fire up, but heat has no issue at all!?!?

This has gotta be software, right? I find it extremely unlikely that I keep getting the same controller with a bad cooling relay. And of course I have no way to test it out in stock firmware because it's gone!
 
Hi!

Ok, first of all. Your cooling relay is fine (well, I can't really make that statement with 100% certainty, but I'd say it is very it is unlikely damaged).
It is not exactly true that with 'cd' set to zero, it will never have any cooling delay. The cooling is set initially, and the way it works, the cooling delay counter will not be updated with a new value until the counter has counted down to zero.
Worst case is the counter is initialized improperly, then it could be flashing for up to 18 hours at most, but I do think that eventually it will turn the relay.

I have not had the chance to test the code in work so much, but I did not have those problems.

Disney7 has also had these these problems for a long time now. I have also had very weird things happen during development. When I make a small change and reflash, suddenly nothing works. I revert, and it still doesn't work. I make some other change, and suddenly it works again.

I do think something is not quite right. I don't know right now what is wrong. I don't think there is a problem with flashing. But of course, I can't be sure.

My prime suspect right now is SDCC, I quote from the SDCC manual under the PIC14 port (a bit confusingly, PIC16F has 14 bit instructions, so it uses PIC14 port)
"This port is not yet mature and still lacks many features. However, it can work for simple code."
I'm starting to think my code is not so 'simple' anymore.

I'm not saying this IS the problem, but it definitely is a candidate. It could also be some hardware stuff in the MCU is not initialized properly and is causing this to happen. I have not developed for PIC before, so it could be possible I have missed something. I would say this is not a very likely scenario, as the MCU should reset into a well known state.

I hate to do it, but I might have to have a look at a proprietary compiler (XC8).
 
I'm completely pissed off right now.

That may well be, but that just isn't helpful.
I've been working very hard at squeezing the last drop out of this controller. I don't want to leave any of you with non functional controllers, but I have clearly stated that it is not done yet and I've made no promises.
 
Well, this is still in development. No one should be relying on this to control beer temps while it's so new and untested. So why so angry?
 
OK, I feel the need to post this in a separate post.

I'm going to bed now, but I just spent a bunch of time configuring up my replacement controller, and have the SAME EXACT results. Cooling relay does not fire up, but heat has no issue at all!?!?

This has gotta be software, right? I find it extremely unlikely that I keep getting the same controller with a bad cooling relay. And of course I have no way to test it out in stock firmware because it's gone!

I'm completely pissed off right now.

Seriously?

We've got a guy (AlphaOmega) who has spent a ton of personal time to frickin' reverse engineer a PIC controller for us and you are going to start ranting over the first setback? Not cool.

He warned everyone at the beginning that this is experimental. We will probably have a pretty sweet $17 fermentation controller at some point. At worst it will have been a very interesting attempt and well worth the cost in my opinion.
 
NickMV, just curious if this works on yours. If it is still doing the thing where the set button doesn't work, if you power cycle it, then hit the set button once, then hit the up button, does it put you in the menu?

Also, if you are flashed to the latest work commit, can you power cycle it and then hit the up and down buttons (don't hit set first) to see the set temperature and the run mode?
 
OK, so first off, I think most of you are taking this way too personally, and shouldn't. I understand if alpha is, but the others?

I have every right to be stressed out, frustrated, and pissed off at my controller for not working? Is the code the cause? It appears likely considering I woke up this morning and found my controller at 58F and running according to program. Am I pointing fingers, calling someone names, or saying someone ruined something of mine? Nope. Am I fermenting a batch? Nope....just trying to do some simple cold crashing, and by no means something critical.

Does that mean I'm butthurt about alpha omega and his program? ABSOLUTELY NOT, UNDER ANY CIRCUMSTANCES! I'm plenty appreciative of his work, and have worked hard myself to try to help him improve the software, whether it be bug fixes, program improvements, etc. I've got plenty of vested interest in seeing this project succeed.


You guys are taking this completely the wrong way. What, am I supposed to smile and say "good news! my controller doesn't work and I LOVE IT!" Heck no. So cut me some slack when I get frustrated after putting many hours into trying to get it working for the first time that I've truly gotten around to testing it for its main features.


Anyways, alpha -- like I said, I woke up a sec ago to find it at 58F, which means it cut on and ran for a bit. Back to your comments -- you say the cooling delay won't be updated until the counter has counted down to zero. What counter? Clearly it does work now, so i'm curious as to what counter you're referring to. The delay counter? Ie. so if it's set to 15mins, it won't actually update to zero until 15 mins have passed? If this is true, would you consider this to be a bug? It would seem like it would be, since the idea of adjusting from 15 to zero is to get the controller to cut on immediately. If I have to wait 15 mins, it defeats the point of the adjustment, at least for the first time.

Anyways, alpha, if I offended you I'm sorry. I in no way said you did something wrong, or ruined my beer or anything like that. I was simply frustrated with not having any success after many tries (esp after I knew that the cooling had worked before).
 
I think he's only performing actions on the hour counter? That's why changing a SP won't take effect until next hour mark?
 
Cool then, it just sounded kinda harsh against someone who is a volunteer. Written words on message boards are sometimes hard to interpret the tone behind them anyway.

Nickmv, did you see my last post? Does your current flash exhibit that behavior? Just curious.

The current code has a fixed 300 second cooling start delay on power up (I think the factory delay is 10 minutes fixed). This is to keep the fridge compressor from short cycling if the power flickers. No matter what the cooling delay is set to, you are going to have at least 300 seconds to wait for the cooling relay to close. On my STC that Alpha and I have deemed "haunted", it will go way beyond that 300 seconds, even if the CD is set to zero, so something funky is going on with the timer there. I thought it was maybe adding the start delay to the cooling delay, but that isn't the case. I've seen it activate the cooling relay in anywhere from 24 minutes to overnight, even when the CD was set to zero or one minute. I have the button weirdness on top of that.

Now, my second flashed STC (with the current work commit), is behaving normally.

I don't know enough about PIC programming to say this is anything more than a gut feeling, but I think something is either not being erased fully before applying new firmware or some error is adding up with each firmware re-write. I can still go back and re-write the firmware version that I initially put on my haunted STC and it works fine, which makes me think there is a piece of code still in there that doesn't match up when newer or older firmware is written. I could be completely wrong.
 
OK, so first off, I think most of you are taking this way too personally, and shouldn't. I understand if alpha is, but the others?

I have every right to be stressed out, frustrated, and pissed off at my controller for not working? Is the code the cause? It appears likely considering I woke up this morning and found my controller at 58F and running according to program. Am I pointing fingers, calling someone names, or saying someone ruined something of mine? Nope. Am I fermenting a batch? Nope....just trying to do some simple cold crashing, and by no means something critical.

Does that mean I'm butthurt about alpha omega and his program? ABSOLUTELY UNDER NO, UNDER ANY CIRCUMSTANCES! I'm plenty appreciative of his work, and have worked hard myself to try to help him improve the device, whether it be bug fixes, program improvements, etc. I've got plenty of vested interest in seeing this project succeed.


You guys are taking this completely the wrong way. What, am I supposed to smile and say "good news! my controller doesn't work and I LOVE IT!" Heck no. So cut me some slack when I get frustrated after putting many hours into trying to get it working for the first time that I've truly gotten around to testing it for its main features.


Anyways, alpha -- like I said, I woke up a sec ago to find it at 58F, which means it cut on and ran for a bit. Back to your comments -- you say the cooling delay won't be updated until the counter has counted down to zero. What counter? Clearly it does work now, so i'm curious as to what counter you're referring to. The delay counter? Ie. so if it's set to 15mins, it won't actually update to zero until 15 mins have passed?

I'm not offended, I just don't think lashing out is very constructive.
Development has been plenty frustrating at times as well, certainly when chasing heisenbugs such as this. You have to understand, I have no way to run a debugger, or in any way know what is going on in the controller. If something doesn't work, the only thing to do is trying to figure out the problem, make changes based on assumptions, recompile, reflash and see if it helps.

Yes, that the only way to implement the delays. Set a variable (the delay counter) to a value, then decrement the variable once every time in the loop. When the counter is zero, the delay is up and cooling is allowed to switch on. When cooling is switched off, the counter is again loaded with a new value.
Say that 'cd' is set to 60 (minutes). Once cooling turns off, the delay counter is loaded and will wait for this period to end. Changing 'cd', will not affect this cycle, so it will be close to 1h until cooling will be allowed again and the counter can be reloaded.
So, if by error or bad EEPROM data, the counter is set to maximum, the longest period achievable by the counter is 17.5 hours. But eventually it will run out.
 
Cool then, it just sounded kinda harsh against someone who is a volunteer. Written words on message boards are sometimes hard to interpret the tone behind them anyway.

Nickmv, did you see my last post? Does your current flash exhibit that behavior? Just curious.

The current code has a fixed 300 second cooling start delay on power up (I think the factory delay is 10 minutes fixed). This is to keep the fridge compressor from short cycling if the power flickers. No matter what the cooling delay is set to, you are going to have at least 300 seconds to wait for the cooling relay to close. On my STC that Alpha and I have deemed "haunted", it will go way beyond that 300 seconds, even if the CD is set to zero, so something funky is going on with the timer there. I thought it was maybe adding the start delay to the cooling delay, but that isn't the case. I've seen it activate the cooling relay in anywhere from 24 minutes to overnight, even when the CD was set to zero or one minute. I have the button weirdness on top of that.

Now, my second flashed STC (with the current work commit), is behaving normally.

I don't know enough about PIC programming to say this is anything more than a gut feeling, but I think something is either not being erased fully before applying new firmware or some error is adding up with each firmware re-write. I can still go back and re-write the firmware version that I initially put on my haunted STC and it works fine, which makes me think there is a piece of code still in there that doesn't match up when newer or older firmware is written. I could be completely wrong.

Yeah, that is true also, the initial delay is fixed to 300 secs.

It might be a problem with programming, I'm not excluding that possibility but my gut feeling says it's not. My observation during development, is that making a small change and uploading, can make menu not work, then reflashing old HEX file that I know worked before, still wont fix it. Sometimes pressing buttons suddenly brings menu back.
It is very possible there is a bug, it could be code, it could be compiler, it could be hardware that is in wrong state, it could be a lot of things.

I have a few ideas to try. And I really hope to get to the bottom of this.
 
NickMV, just curious if this works on yours. If it is still doing the thing where the set button doesn't work, if you power cycle it, then hit the set button once, then hit the up button, does it put you in the menu?

Also, if you are flashed to the latest work commit, can you power cycle it and then hit the up and down buttons (don't hit set first) to see the set temperature and the run mode?

I'm honestly not sure. When I encountered non-functional buttons, I didn't play with it very much. I just noticed that the buttons wouldn't do anything, but that every 2nd press of the "S" button, the screen would flash/flicker once. Nothing would actually change.

As far as doing the combination you're talking about -- I didn't try that, so I'm not sure.

Regardless, I'm happy to at least have the controller functioning right now.
 
I actually think think I have found the problem.
I seems to have been a perfect storm between a compiler issue that static variables are not initialized properly AND my code relying on them being initialized.

The funny thing is that that is why me fiddling with the buttons actually could bring menu back. If you press 's' for menu and then down until variable was in range, it would work.

This could also explain why cooling delay is initialized to WAY longer than 300 secs.

I will move all static variables to be global instead + make less assumptions on their value where possible and hope the issue is gone for good. I have uploaded new code to work branch, that hopefully will work. I even hope your 'haunted' STC will work Disney7.
 
Good News Everyone!

The buttons on the haunted STC work perfectly now.

I'm not sure about the cooling delay though. Did you make any changes to it or were you going for the buttons first?

I configured all the settings and power cycled the STC. I am about 8 degrees above my set point (with a 0.5*F hysteresis), it has been 10 minutes, and the cool led is still blinking.

Also, I assume that only the fixed startup delay should pass (300 seconds) before it allows the relay to close... the cool delay shouldn't come into effect until after that first closing of the cool relay, correct?

The fix for the buttons is great.
 
Awesome alpha. I look forward to trying tonight. Everything is working right now and my beer is crashing down according to schedule. So far.

Sent from my Nexus 5 using Home Brew mobile app
 
Back
Top