Stc-1000+

[wilconrad]

Is there any possibility to add a feature to disable the alarm? I'm wiring up a control box and getting it all set up. Right now I don't have phone jacks wired to all of my temp sensors yet and they are a bit loud! Or is there a way to soft power them off while the alarm is running? I've tried plugging a sensor into the jack, soft powering one off, then pulling it out to plug into another to do the same, but the first one powers back on when I remove the sensor. I should have wired in a manual power switch to each one, but alas I did not think of that until they all started screaming at me!

If you're comfortable with a soldering iron, you could remove the speaker/buzzer from the board on each STC. Or you could just finish wiring up the sensors...

 

[mattd2]

If you're comfortable with a soldering iron, you could remove the speaker/buzzer from the board on each STC. Or you could just finish wiring up the sensors...

Or just jump the sensor pins with a 10k resistor in the meantime

 

[alphaomega]

Is there any possibility to add a feature to disable the alarm? I'm wiring up a control box and getting it all set up. Right now I don't have phone jacks wired to all of my temp sensors yet and they are a bit loud! Or is there a way to soft power them off while the alarm is running? I've tried plugging a sensor into the jack, soft powering one off, then pulling it out to plug into another to do the same, but the first one powers back on when I remove the sensor. I should have wired in a manual power switch to each one, but alas I did not think of that until they all started screaming at me!

That is a bug. It makes no sense for alarm to sound when unit is soft off. I'll try to fix that as soon as I can.

 

[Spellman]

If you're comfortable with a soldering iron, you could remove the speaker/buzzer from the board on each STC. Or you could just finish wiring up the sensors...

The thought definitely crossed my mind!

 

[Will_D]

Have run a few tests and I am delighted with the performance.

My one question (prompted by a few posts back re. settings for hy, dh and ch):

I notice that my fridge undershoots a bit so much that the heater then comes on.

One fix maybe would be to allow a much longer 'hd' say from 4 mins to 60

Would this be possible in next version?

We could then tweak the delays to run both the heater/cooler a bit less!

Maybe also a bit more time delay in the debounce logic as sometimes it skips from say pr0 to pr2

But all inj all everyone in Ireland thinks its great. We have a maker fair comming up in July so I will be showing them YOUR brilliant work!

Chhers for now Will

 

[alphaomega]

Have run a few tests and I am delighted with the performance.

My one question (prompted by a few posts back re. settings for hy, dh and ch):

I notice that my fridge undershoots a bit so much that the heater then comes on.

One fix maybe would be to allow a much longer 'hd' say from 4 mins to 60

Would this be possible in next version?

We could then tweak the delays to run both the heater/cooler a bit less!

Maybe also a bit more time delay in the debounce logic as sometimes it skips from say pr0 to pr2

But all inj all everyone in Ireland thinks its great. We have a maker fair comming up in July so I will be showing them YOUR brilliant work!

Chhers for now Will

Hi Will!

Thank you so much for the positive feedback and excellent suggestions for improvement!
First off, hy, cd, and hd settings. I wish I could help you more, but I have not had a chance to actually use STC-1000+ myself. I'm just finishing my fermentation fridge as you might have seen previously in this thread. Intuitively, I would say choose cd to be the minimum 'rest' time you think is acceptable, then choose hy to be the tradeoff of how much swing you can tolerate vs how short cycles you can tolerate. This depends on your setup, so I think you need to get a 'feel' for this setting.

Honestly, I hadn't really though about the hd setting as a means to prevent heater coming on when temperature undershoots (frankly I thought it would be kind of unimportant). If it is to be used like this, then it would need last longer that the entire cooling cycle as well (so yes, probably a lot more that 4 minutes needed). Looking at the code, I can see that it probably would be a pretty easy and cheap fix, so I will definitely add this to the TODO list (I'll create an issue for it).
Related to this, I wonder if BOTH delays maybe should be reset when either relay is turned off. This might be a bit confusing, but kind of makes sense when you think about it. The same situation could occur if your fridge is in a place colder than desired ferm temp, then you might not want to turn on fridge directly on an overshoot.
What do you guys think?

Since keypress/menu logic is moved to its own timer, increasing debounce time a bit should be a relatively easy fix. I'll look into that as well.

Again thanks for excellent feedback/suggestions! This was very helpful info!
And I can't thank you enough for bringing STC-1000+ to the maker fair!!! That is excellent marketing! Thanks so much for spreading the word! If at all possible, I would absolutely love to see a few pics.

Cheers!
//mats

 

[balrog]

Or just jump the sensor pins with a 10k resistor in the meantime

I like this idea. But does anyone need/see need for/use the buzzer on these?

I would say choose cd to be the minimum 'rest' time you think is acceptable, then choose hy to be the tradeoff of how much swing you can tolerate vs how short cycles you can tolerate. This depends on your setup, so I think you need to get a 'feel' for this setting.

Hm. I'm not sure I know this "feel" thing of which you speak. I mean, how much cycling is "too much" for a little cube dorm fridge? I hate to find out by destroying it through over-cycling, but will have to data log it to even know cycle rate and duration.

As it stands now, with my simple setup, I'm in the fairly stable cellar, room temp is just above my setpoint, and my little cube fridge is small enough that it doesn't overshoot by more than 0.1°F to 0.2°F so my SP=63, hy=1 looks like it's swinging between 62.9 and 64, about 1 hr regular cycle.

Related to this, I wonder if BOTH delays maybe should be reset when either relay is turned off. What do you guys think?

Yes definitely on this--I hadn't thought about it but it makes sense to me that any delay is reset when any relay has turned off. Machine state finishes a cycle (heat/cold), dealys are reset to 0, nothing happens for hd/cd.

 

[helibrewer]

In my system, I put the probe in about 1 cup of water, that amount seems to be good to act as a buffer and help prevent the overshoot problems. Cycling is just a factor of how well your fridge is insulated...if it loses heat rapidly, it will cycle a lot. You can try a longer delay setting.


Sent from my iPad using Home Brew

 

[alphaomega]

I like this idea. But does anyone need/see need for/use the buzzer on these?

Hm. I'm not sure I know this "feel" thing of which you speak. I mean, how much cycling is "too much" for a little cube dorm fridge? I hate to find out by destroying it through over-cycling, but will have to data log it to even know cycle rate and duration.

As it stands now, with my simple setup, I'm in the fairly stable cellar, room temp is just above my setpoint, and my little cube fridge is small enough that it doesn't overshoot by more than 0.1°F to 0.2°F so my SP=63, hy=1 looks like it's swinging between 62.9 and 64, about 1 hr regular cycle.

Yes definitely on this--I hadn't thought about it but it makes sense to me that any delay is reset when any relay has turned off. Machine state finishes a cycle (heat/cold), dealys are reset to 0, nothing happens for hd/cd.

Personally, I'm no fan of the buzzer. I don't really see the point of it, but hey, it's there.

The 'feel' thing I'm referring to, is that the amount of cycling will be dependent on what fridge you have and your batch size etc. I would say keeping an eye on it during active fermentation and just make a guesstimate if the cycling is too frequent could be good enough.

I'm not sure what you mean by 'nothing happens for hd/cd'. But I guess you agree on that the proposed change would be a good idea?

In my system, I put the probe in about 1 cup of water, that amount seems to be good to act as a buffer and help prevent the overshoot problems. Cycling is just a factor of how well your fridge is insulated...if it loses heat rapidly, it will cycle a lot. You can try a longer delay setting.

Sent from my iPad using Home Brew

The consensus is that attaching the probe to the side of the FV and covering with insulation is best practice (short of using a thermowell). You want to measure beer temperature, not fridge temperature. Also, submersing the probe directly is probably not a good idea.

 

[helibrewer]

For fermentation I use a thermowell, for my serving fridge I use the small water sample, I have found too much of a difference using the insulation method.


Sent from my iPad using Home Brew

 

[uatuba]

Keep in mind that these were originally intended to be sold as aquarium temperature controllers. As such, there are two things we should realize: the alarm makes sense and the probe is submersible.


Sent from my iPad using Home Brew

 

[alphaomega]

For fermentation I use a thermowell, for my serving fridge I use the small water sample, I have found too much of a difference using the insulation method.

Sent from my iPad using Home Brew

That makes a lot of sense.

Keep in mind that these were originally intended to be sold as aquarium temperature controllers. As such, there are two things we should realize: the alarm makes sense and the probe is submersible.

Sent from my iPad using Home Brew

That also makes a whole lotta sense. However, I still wouldn't trust submersing the probe for extended periods. I've had water creep into probes before and it can be a sneaky error. Even if they're supposed to handle it, I'd avoid it just to be on the safe side.

 

[alphaomega]

Ok, I have been working a bit on the stuff mentioned earlier and have pushed a new version to the work branch.

There are some changes (that also concern thermostat function) that I want to 'mature' before make an official release.

So, what's new?

• The 'power off' function is reworked. Alarm should not be a problem any more when in power off mode. This is a bigger change than it might seem, so I'd be glad to have some help testing. When powering on again, a reset is forced.
• Allow longer heating delays.
• Reset both cooling delay and heating delay counters when either heating or cooling cycle ends. Hopefully this could help avoid unnecessary cycling on over/undershoots by setting appropriate cd/hd values.
• Increased button debounce time. Took it as far as I felt comfortable (i.e. without buttons feeling 'sluggish'), unfortunately button acceleration is not quite as smooth anymore, but selecting profile to run should be a bit easier.
• Added a check when writing EEPROM to avoid unnecessary writes.

Please help out testing if you can.

Cheers!
//mats

 

[balrog]

Ok, I have been working a bit on the stuff mentioned earlier and have pushed a new version to the work branch.

There are some changes (that also concern thermostat function) that I want to 'mature' before make an official release.

So, what's new?

• The 'power off' function is reworked. Alarm should not be a problem any more when in power off mode. This is a bigger change than it might seem, so I'd be glad to have some help testing. When powering on again, a reset is forced.
• Allow longer heating delays.
• Reset both cooling delay and heating delay counters when either heating or cooling cycle ends. Hopefully this could help avoid unnecessary cycling on over/undershoots by setting appropriate cd/hd values.
• Increased button debounce time. Took it as far as I felt comfortable (i.e. without buttons feeling 'sluggish'), unfortunately button acceleration is not quite as smooth anymore, but selecting profile to run should be a bit easier.
• Added a check when writing EEPROM to avoid unnecessary writes.

Please help out testing if you can.

Cheers!
//mats

Will grab tomorrow and take a look. What I meant in prior post about HD/CD reset is exactly what you implemented I believe. Either delay does not start counting until any relay turns off. I had thought the factory default STC method was to start the delay counter when cycle was requested--if cooling was called for, start cooling delay, but maybe the delay really started at the end of cooling cycle.

 

[rjmaster19]

Extremely cool project. And thanks a bunch for sharing.

 

[Spellman]

I'll see if I can look these changes over tomorrow as well. I got all of my sensors wired up today and noticed one is about 5-6 degrees lower than the others. I haven't calibrated them yet and I suspect they may be a reading a degree or two higher than they should, but I noticed that the compensation limit is 5*, is it possible to change that to a higher value? I know most people won't need that much, and after proper calibration I might not either, but it could be useful to some people. Thanks again for all of your hard work!

 

[Spellman]

One minor typo in the manual on page 13:
SP Set setpoint 40 to 140°C or 40 to 25°0F

 

[wilconrad]

Ok, I have been working a bit on the stuff mentioned earlier and have pushed a new version to the work branch.

There are some changes (that also concern thermostat function) that I want to 'mature' before make an official release.

So, what's new?

• The 'power off' function is reworked. Alarm should not be a problem any more when in power off mode. This is a bigger change than it might seem, so I'd be glad to have some help testing. When powering on again, a reset is forced.
• Allow longer heating delays.
• Reset both cooling delay and heating delay counters when either heating or cooling cycle ends. Hopefully this could help avoid unnecessary cycling on over/undershoots by setting appropriate cd/hd values.
• Increased button debounce time. Took it as far as I felt comfortable (i.e. without buttons feeling 'sluggish'), unfortunately button acceleration is not quite as smooth anymore, but selecting profile to run should be a bit easier.
• Added a check when writing EEPROM to avoid unnecessary writes.

Please help out testing if you can.

Cheers!
//mats

I flashed with 1.05 this morning and like the new debounce time, nice improvement! Button acceleration still works well enough, so the tradeoff you made here was a good one, in my opinion. Will let it run for a while and see if any issues pop up, but so far, so good. Thanks Mats!

 

[Spellman]

I flashed mine as well and love the ability to turn off without having to have a sensor plugged in, another great feature! I haven't had much time to test much else yet. Been hard at work making a fridge to house my coolant reservoir.

 

[disney7]

Alpha, I'm still on version 1.04, so I don't know if the following behavior has been changed in 1.05.

I finished a fermentation a few weeks ago and turned the STC+ off using its power button. I then unplugged it and set it aside.

When I went to use it again, I plugged it in and the display flashed, "-8", and went back off. I unplugged and plugged it back up a few times and got the same result. At that point I thought the STC had gotten fried by a power surge, cosmic rays, etc.

Then I remember that I had turned it off earlier. Plugging it back up and holding down the power button to turn it back on took care of things.

Is there any way to indicate that it is in the off state when it is plugged up? Maybe flash "OFF" for a couple of seconds?

 

[alphaomega]

Alpha, I'm still on version 1.04, so I don't know if the following behavior has been changed in 1.05.

I finished a fermentation a few weeks ago and turned the STC+ off using its power button. I then unplugged it and set it aside.

When I went to use it again, I plugged it in and the display flashed, "-8", and went back off. I unplugged and plugged it back up a few times and got the same result. At that point I thought the STC had gotten fried by a power surge, cosmic rays, etc.

Then I remember that I had turned it off earlier. Plugging it back up and holding down the power button to turn it back on took care of things.

Is there any way to indicate that it is in the off state when it is plugged up? Maybe flash "OFF" for a couple of seconds?

Hi Disney!
That the display flashes is a glitch and hopefully this will not occur in v1.05 as I have implemented a cleaner handling of the off state.
I'm not a fan of the off functionality as I think it is misleading, but I can understand why some would find it handy. I'd really like to keep this kind of excess functionality as basic as possible, and adding the 'OFF' display when applying power would IMHO use code space that could be better utilised.
I hear what you are saying though, I'll create an issue for it and promise to look into it. If I can find a way that doesn't 'cost' much, I'll absolutely consider it.

Cheers!

 

[disney7]

Thanks, it really isn't a big deal and I should have realized what I had done.

If nothing else, you might just mention the behavior in the manual. I can see other people plugging one in that they hadn't used for a while and thinking it was dead before realizing it was just turned off.

I frankly don't know what the OEM firmware does if you turn it off and then unplug/replug it. Probably the same thing as you wouldn't want it to start running the fridge/heater just because the power went out.

 

[alphaomega]

Yes, I'm pretty sure stock firmware does the same. Mentioning it in the manual is a good idea. In fact, I'm thinking that a FAQ section or something of the sorts could be useful.
Thinking about it, it could actually be more difficult than I thought first, as in the reimplementation of the power off functionality, I turn of the timer for handling the thermostat and all, so what probably happens is that the watchdog timer keeps resetting the unit until it is turned on.
Maybe I should investigate the possibility of having interrupts for the buttons and if they could be active during proper MCU sleep. I wish I had more time for this...

 

[priest77]

My arduino finally arrived and I used one connector from an old car stereo so I don't have to open and solder for every update (I am waiting for PID firmware ).

 

[Spellman]

Well, I got my sensors calibrated, most were pretty close as they were, except one was 8* off. I tried tinkering with changing the temp_corr_max and temp_corr_min to 100 and -100, but I don't think I'm saving something right as I can't get it to go past 5. Not that experienced with the arduino.

 

[vzom]

Just tried flashing mine today but looks like I bricked it. I have the A400_P version and quintuple checked my wiring. When I connected it, the alarm made a noise but I didn't know if this was normal or not at the time (I should've watched a video on the flashing first).

It did detect the controller and started to flash it but it seems to have errored out partway through:

Incrementing address to 0x7FE
Incrementing address to 0x7FF
Incrementing address to 0x800
Validation failed for address 0x805 wrote 0xDB but read back 0x0
Programming hex data...
Programming program memory
Programming config memory
Programming 8 bytes at EEPROM address 0x0
Resetting address for EEPROM
Validation failed for EEPROM address 0x0 wrote 0xA0 but read back 0x0
Writing magic.
Writing version.
Leaving programming mode

I then saw a ton of Java I/O errors in the main Arduino window.

When I tried again, it is no longer being detected. Guess I'll have to buy another controller (or two) and try again.

Anyone else run into this, or have the alarm go off as soon as the connection between the boards was made yet flash successfully?

 

[gueykewl]

Just tried flashing mine today but looks like I bricked it. I have the A400_P version and quintuple checked my wiring. When I connected it, the alarm made a noise but I didn't know if this was normal or not at the time (I should've watched a video on the flashing first).

It did detect the controller and started to flash it but it seems to have errored out partway through:

Incrementing address to 0x7FE
Incrementing address to 0x7FF
Incrementing address to 0x800
Validation failed for address 0x805 wrote 0xDB but read back 0x0
Programming hex data...
Programming program memory
Programming config memory
Programming 8 bytes at EEPROM address 0x0
Resetting address for EEPROM
Validation failed for EEPROM address 0x0 wrote 0xA0 but read back 0x0
Writing magic.
Writing version.
Leaving programming mode

I then saw a ton of Java I/O errors in the main Arduino window.

When I tried again, it is no longer being detected. Guess I'll have to buy another controller (or two) and try again.

Anyone else run into this, or have the alarm go off as soon as the connection between the boards was made yet flash successfully?

I don't think you bricked it. It is pretty tough to brick this thing.

When you said 'alarm' made a noise what type of noise was it?

- An alarm, loud high pitch sound, means the temp probe is not connected or, as in the case of my last controller, board terminals were bad so STC did not recognize that there was a probe connected. Sent it back to Amazon for a prompt refund.

- If a clicking noise then the Arduino was in the process of uploading the program to the STC. Those java errors were probably a result of losing communication between the Arduino and STC. Depending how you are connecting the two devices this can be very easy to do.

Try closing the Arduino program and starting over again see if that helps. I was able to recover from similar problem.

 

[wilconrad]

Yeah, agree with Gueykewl, highly doubt you bricked it. Like he said, close Arduino and start over; sometimes you need to upload the firmware to the Arduino again as well. Basically start from the beginning and follow the full process and I'll bet it comes back to life. I've flashed 100 of these now and haven't bricked one yet, would be impressed if you pulled it off!


Sent from my iPhone using Home Brew

 

[gueykewl]

First, allow me to thank Alpha and others who have commented on this thread for your hard work and testing on the project. You have literally taken a raw diamond and crafted it into a true gem. Simply brilliant.

Purchased a female/mail 5-pin DIN connector from Fry’s, both for a total of around $ 3.33. Soldered some dupont wires into the STC-1000 and will eventually solder those wires to the 5-pin female DIN connected. This along with the STC-1000 will be installed into the lid of my fermentor, a 14.8 cu ft Kenmore chest freezer. Going to do the same for an upright as well.

The ability to enter a few basic fermentation profiles is awesome. As we know even the same beer does not always ferment out the same. I see that there is the ability to ‘jump’ in the profile, which I am having a hard time wrapping my brain around. If I understand this correctly current duration ‘dh’ is incremented every hour until ‘dh’ has reached the current step duration, after which ‘dh’ will be set to zero and current step ‘St’ will be incremented by 1. Question is, in order to jump to the next step would we would change the current step duration to the current duration ‘dh’? This way on the next query the current ‘dh’ = the current step duration and thus zeroes out the ‘dh’ and increments by 1 the current step? Is there any way we can display the current ‘dh’ so we know what to set the current step duration to in order to ‘jump’ the profile?

Is there a button combination that we press to automatically set the ‘dh’ to the current step duration, thus forcing a jump?

Am I totally confused as to how this works? I feel like I am.

 

[alphaomega]

Hi and thanks!
That sound sweet! Please feel free to post a few pics when you're done.
It sounds to me like you pretty much got it. 'St' is the current step and 'dh' the current step duration. 'dh' is incremented hourly. If 'dh' is equal (or greater) to the duration of the step as programmed, then it is zeroed and 'St' is incremented. 'Jumping' in the profile, is simply manually setting new values for 'St' and/or 'dh'. Note that this will not change setpoint 'SP', only once the hour is up, new values for 'dh', 'St' and 'SP' will be calculated.
So, if you want it to skip ahead to the next step, setting 'dh' to value greater than or equal to 'dhX' - 1 (where X is the current step) will cause it to start the next step once the hour is up.If you don't want to mess about with figuring out how long this step is and just force next step, simplest would be to just just set 'dh' to a large value (like 999). Then next step should be started within the hour.
That is how it should work at least, I'm not sure how much this has been tested, but I think it should be ok.
Changing a running profile or the profile runtime data ('St' and 'dh') is a bit 'crazy side of the street', you could get unlucky and manage to change the value in the exactly wrong microsecond when it is being recalculated and something unexpected could happen (not dangerous or anything, but you could end up in the wrong step for example) this would be extremely unlikely though.
Also, when running a profile you can press and hold button 'down' (I think) to see current step and step duration. It might also help to note the profile data on a piece of paper or so for quick reference.
Please, try it out and if you have any more questions, ask. Don't feel bad if it isn't obvious at first glance. Jumping in the profile really is 'power user' stuff

 

[vzom]

I don't think you bricked it. It is pretty tough to brick this thing.

When you said 'alarm' made a noise what type of noise was it?

- An alarm, loud high pitch sound, means the temp probe is not connected or, as in the case of my last controller, board terminals were bad so STC did not recognize that there was a probe connected. Sent it back to Amazon for a prompt refund.

- If a clicking noise then the Arduino was in the process of uploading the program to the STC. Those java errors were probably a result of losing communication between the Arduino and STC. Depending how you are connecting the two devices this can be very easy to do.

Try closing the Arduino program and starting over again see if that helps. I was able to recover from similar problem.

It was a loud, high-pitched sound, but I didn't have the temp probe connected. I'll make sure to connect it when I try again to avoid waking my family up.

It did make the clicking noise as soon as it was in the process of writing to the STC-1000. The alarm sound turned off at this point as well.

I did close and restart the Arduino program, as well as disconnect/reconnect the board from the PC and uploaded the sketch to the Arduino again.

Now when I make contact with the STC-1000, I hear the Windows USB disconnect sound and I get an error that the COM port is not responding. I got around it by connecting the STC-1000 to the Arduino before plugging in the Adruino's USB cable into the PC. However, this is where I run into the STC-1000 not detected error.

I'm glad to hear that these are not easy to brick. I will try again after work today, and hopefully end up with better results.

 

[wilconrad]

Yeah, hook the probe up. Maybe also watch the video on flashing on my website (click the "black box" link in my signature, go to "DIY" tab).

 

[balrog]

Alpha, just wanted to say thanks again, and report that last night I got to do a simple test, thanks to Mother Nature and a slew of bad weather. Power was out a little while, but STC+ picked right back up when the power returned. Now if you could figure out how to incorporate the STC+ setting to magically make the wife understand the joy of having not ruined an ongoing fermentation, well that would be sweet.

 

[alphaomega]

It was a loud, high-pitched sound, but I didn't have the temp probe connected. I'll make sure to connect it when I try again to avoid waking my family up.

It did make the clicking noise as soon as it was in the process of writing to the STC-1000. The alarm sound turned off at this point as well.

I did close and restart the Arduino program, as well as disconnect/reconnect the board from the PC and uploaded the sketch to the Arduino again.

Now when I make contact with the STC-1000, I hear the Windows USB disconnect sound and I get an error that the COM port is not responding. I got around it by connecting the STC-1000 to the Arduino before plugging in the Adruino's USB cable into the PC. However, this is where I run into the STC-1000 not detected error.

I'm glad to hear that these are not easy to brick. I will try again after work today, and hopefully end up with better results.

It seems others as well have had problems with USB disconnecting when attaching the STC. Making the Arduino-STC connection before connecting the USB might be a good idea, but make sure that the Arduino has been flashed with the picprog.ino sketch BEFORE doing this.
It sounds weird that the STC is not detected when doing it this way. Only thing I can think of is making sure all connections are good. I don't just mean correct pins, but that there are no shorts or bad connections.

Short of physical damage (ESD, shorts, etc), the STC really should not be 'brickable' as there is no bootloader or anything that could render it unprogrammable.

Alpha, just wanted to say thanks again, and report that last night I got to do a simple test, thanks to Mother Nature and a slew of bad weather. Power was out a little while, but STC+ picked right back up when the power returned. Now if you could figure out how to incorporate the STC+ setting to magically make the wife understand the joy of having not ruined an ongoing fermentation, well that would be sweet.

Cool
I consider myself to have a pretty decent understanding of the inner workings of micro controllers, the inner workings of women I don't think I'll ever understand. Even remotely.

 

[vzom]

Yeah, hook the probe up. Maybe also watch the video on flashing on my website (click the "black box" link in my signature, go to "DIY" tab).

I watched the actual flashing part of the video last night after my failure, to see how far the output should've gotten, but I'm going to watch the full video tonight before another attempt.

 

[vzom]

Only thing I can think of is making sure all connections are good. I don't just mean correct pins, but that there are no shorts or bad connections.

Short of physical damage (ESD, shorts, etc), the STC really should not be 'brickable' as there is no bootloader or anything that could render it unprogrammable.

I tried again - with the probe in and still get the alarm. I read in the instructions that came with the controller that if there is a short the alarm will go off too, with an EE on the screen. Apparently you should be able to silence the alarm by pressing any button but that doesn't work, nor does anything show up on the screen, but I am now certain that the probe is connected.

I notice when I try to detect the controller, I get the following:

Device ID is: 0x3FFF
STC-1000 NOT detected. Check wiring.

As opposed to this when the controller is not actually connected to the Uno:

Device ID is: 0x0
STC-1000 NOT detected. Check wiring.

I will be bringing it in to work tomorrow to get my boss to take a look as he wants to set one up as well. He's a lot better with this sort of stuff than I am, so I have my fingers crossed.

 

[gueykewl]

If you have a meter check to see if the terminal blocks (green) are good. I returned because of a faulty terminal block where the temp probe connects.


Sent from my iPad using Home Brew

 

[alphaomega]

I tried again - with the probe in and still get the alarm. I read in the instructions that came with the controller that if there is a short the alarm will go off too, with an EE on the screen. Apparently you should be able to silence the alarm by pressing any button but that doesn't work, nor does anything show up on the screen, but I am now certain that the probe is connected.

I notice when I try to detect the controller, I get the following:

Device ID is: 0x3FFF
STC-1000 NOT detected. Check wiring.

As opposed to this when the controller is not actually connected to the Uno:

Device ID is: 0x0
STC-1000 NOT detected. Check wiring.

I will be bringing it in to work tomorrow to get my boss to take a look as he wants to set one up as well. He's a lot better with this sort of stuff than I am, so I have my fingers crossed.

If the alarm goes off, then then something is wrong with sensor connection. It won't affect programming, but is very annoying. Besides, at some point you will need to have the sensor working anyway. Same thing there, make sure it is the correct terminal block you are connecting the sensor to and that the connection is good. If it still won't work, check with multimeter that you have 10-15 kohm (ish) over the sensor leads. And inspect board for any issues.

Device ID 0x00 and 0x3FF indicates the same problem, that communication between arduino an stc is not working. It has read all zeros or all ones.
It is difficult to say exactly what the problem is, best advice I can give is the same as before. Make sure all connections are good.
I hope you (and your boss) can get your STC-1000+ on

 

[balrog]

Simple thought from simple mind here, but before I flashed any of the STC's I got, first I plugged in temp probe, power, and a couple of indicator items (fans, lights) all hooked up to the STC straight from the box and power it up. If it did not work stock method I returned it. I always wanted to know things were as correct as I could tell before trying to flash it.

 

[vzom]

If you have a meter check to see if the terminal blocks (green) are good. I returned because of a faulty terminal block where the temp probe connects.

Same thing there, make sure it is the correct terminal block you are connecting the sensor to and that the connection is good. If it still won't work, check with multimeter that you have 10-15 kohm (ish) over the sensor leads.

Simple thought from simple mind here, but before I flashed any of the STC's I got, first I plugged in temp probe, power, and a couple of indicator items (fans, lights) all hooked up to the STC straight from the box and power it up. If it did not work stock method I returned it. I always wanted to know things were as correct as I could tell before trying to flash it.

I'll be checking things over with a multimeter today and report back on how things go. My boss will also help me with soldering the pins in (I was just holding the header to the back of the STC-1000).

I should have mentioned that before attempting to flashing the STC-1000, I previously used it in my fermentation chamber and it worked ok. So if it is broken now, I only have myself to blame

Thanks to everyone thus far on all of your help!