• Please visit and share your knowledge at our sister communities:
  • If you have not, please join our official Homebrewing Facebook Group!

    Homebrewing Facebook Group

Stc-1000+

Homebrew Talk

Help Support Homebrew Talk:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Alpha, we should be able to flash without overwriting the config as long as you haven't introduced a new setting (such as Ramp 0/1) since the last flash, right?
 
I succumbed to the panic buying mentality and ordered two more AGPTeck units from Amazon. The one I got from them a few weeks ago was 1.0. They should be delivered tomorrow, so I'll let everyone know what I get.

Recall that I had previously ordered two EliTechs from Amazon and one was 1.0 while the other was 1.1.

I wonder if there is any realistic chance of getting in touch with someone at the factory in China to find out what the story is.

I also ordered two more...
 
Regarding version number, I think that is a pretty good idea. I might not want to add it to the 'Set' menu as I don't think it would be a good idea for the user to be able to actually set it, so I'm thinking along the lines of adding it after 'sp' is displayed when pressing up or even like a combo, so it is displayed when pressing both up and and down.
Sorry - I was not clear. If it was on the menu, it would be a read only item - the up/down would not have any effect - only exit up a level.
Personally I don't like the multi-key sequence things - I always found it tricky on the original unit.
The version would need to be stored in programme space. If you also had a version in the settings eeprom, you could then "check for compatibility" of the settings if there was a new feature added that invalidated the eeprom settings. however this does make things more complicated!
 
Alpha, we should be able to flash without overwriting the config as long as you haven't introduced a new setting (such as Ramp 0/1) since the last flash, right?

Yes, but even if a new config value is just added, you could opt not to overwrite data and just set that value manually. Really, only if flashing a brand new device or if there needs to be bigger changes (like how the data is laid out, or if we need to remove one profile to allow other data to be stored), then it could be convenient to know values are initialized to sane values.

Sorry - I was not clear. If it was on the menu, it would be a read only item - the up/down would not have any effect - only exit up a level.
Personally I don't like the multi-key sequence things - I always found it tricky on the original unit.
The version would need to be stored in programme space. If you also had a version in the settings eeprom, you could then "check for compatibility" of the settings if there was a new feature added that invalidated the eeprom settings. however this does make things more complicated!

No, you were perfectly clear. Let me explain my point of view. First, I think it would be strange to have a setting that is not a setting. Second, the state machine to set config values need to make assumptions to keep it simple, having a read only setting would add a special case and increase complexity and there are too many special cases already. Third, I can't imagine checking version is something normal user would be doing on a daily basis, so I think it is acceptable that it is slightly 'tricky'.
Program version really is not related to EEPROM data, so it is still very much possible to add an EEPROM version that is just not shown in menu, to keep track of if EEPROM data neess to be updated. However, if that functionality should be implemented, I need to do some thinking first. I'm not sold on the idea of uploading and not knowing if EEPROM data is retained or not. So, I actually don't think it is too bad to leave it up to the user to decide.
 
No, you were perfectly clear. Let me explain my point of view. First, I think it would be strange to have a setting that is not a setting. Second, the state machine to set config values need to make assumptions to keep it simple, having a read only setting would add a special case and increase complexity and there are too many special cases already. Third, I can't imagine checking version is something normal user would be doing on a daily basis, so I think it is acceptable that it is slightly 'tricky'.
.
One option is to add to the arduino serial commands, 'v'. It could show the code version, and possibly EEPROM content version if you go that way.
Another would be a power on version number, however this would require a start up timer of sorts... So may not simple!
 
Eh, the way it works now is fine, especially if it is the most efficient way to implement it.

I'm not going to be checking the version number frequently, so the dual button press thing isn't a big deal for me and I'd rather not have another config option to have to cycle past.
 
One option is to add to the arduino serial commands, 'v'. It could show the code version, and possibly EEPROM content version if you go that way.
Another would be a power on version number, however this would require a start up timer of sorts... So may not simple!

Thinking about this, there are actually a few 'User ID' bytes near the config words, they could probably be used to store version and EEPROM version. It would be pretty easy to include that in the HEX... Hmm... Not a bad idea... It wont use up any EEPROM and can easy be checked at programming time.
I'll look in to that.
Still I think the decision to initialize EEPROM data should be left to the user, but with this it should be easy to determine if it is 'needed' or not.
I'll probably add it to the 'd' command though.
 
Just received my two STC-1000s and both are v1.1 Interesting that the date on both my boards is 2009.6.20 and I noticed that disney7's in post #344 shows 2013.11.18 (assume that means Nov 18th, 2013 versus my June 20, 2009).

I'm going to spend a little time tracing the schematic and see if I can figure something out.

-gary

edited to add picture:

version and date.jpg
 
My two AGPTek's from BrainyDeals on Amazon were just delivered and they are both 1.0s. Though one is missing one of the orange mounting clips (think I'll keep it though).
 
Alpha, I'm scouring the thread to pull together the bits of new commands and functionality that differ from the published GitHub instructional readme; The "rp", "b", "g", up/down/both display, etc. What I don't see is a cancel--would you simply go into SET menu and choose 'rn' and then 'th' to cancel a Pr# currently underway?

By the way, the latest flash is fabulous and goes without a hitch; I still want to test flashing program with/without data to preserve profiles. Plus my temp datalogger is giving me fits right now so profile testing for me is at a standstill.

But this is truly something you should be uber-proud of, it's an amazing hack!
 
Hi!
Yeah I think you are right, that are probably the main differences. And yes, that will effectively stop/cancel the running profile.
I am currently working on a better user manual (PDF) that I hope will be complete enough. I am working on storing version in User ID location at the same time, and making the sketch a little user friendlier.

And thanks for the kind words! It is really nice to have some positive feedback as well (not that I don't appreciate bug reports and opinions and such also)!
I do think it is coming along nicely :)
 
I think the sketch is about as user-friendly as it gets--
-open in IDE (if IDE complains about wanting to make a folder, let it)
-check compile
-upload
-hook up STC
-open monitor Ctrl-Shift-M
-change baud
-send 'd' to verify
-send 'f' or 'g' to flash all or program only
-listen to the STC make noise for 20s
 
I think the sketch is about as user-friendly as it gets--
-open in IDE (if IDE complains about wanting to make a folder, let it)
-check compile
-upload
-hook up STC
-open monitor Ctrl-Shift-M
-change baud
-send 'd' to verify
-send 'f' or 'g' to flash all or program only
-listen to the STC make noise for 20s

Yeah, and I won't change that I'll just add some helpful output, like a greeting when you connect (and urge you to connect wires and send 'd') + some more info on d command if a previous stc-1000+ firmware is found and what version it is and what version sketch holds and the options for flashing. Maybe I can even come up with something to indicate if EEPROM format has changed.
So, just some assistance basically.
 
Are you letting all of the ladies know that you've reflashed your temp controller and want to put it in their fermentation chamber? If that doesn't do it, nothing will.
 
Are you letting all of the ladies know that you've reflashed your temp controller and want to put it in their fermentation chamber? If that doesn't do it, nothing will.

Hope he's not using yeast to ferment that.


Oh god, I just went too far. My sincere apologies.
 
My two new STC-1000's came in today - I only opened one of them up - but it was a flashable unit! :rockin: I think I'll try and flash it without soldering the pin header on - just to see if its possible...

EDIT - It wasnt possible after a couple of beers...
 
I'm really curious to see if the header-pin-holding-after-3-homebrews method really works.

Because I know from experience that soldering to the reasonably large pads was not terribly easy after 3 homebrews!
 
I just ordered a couple STC's from AGPtek since everyone seems to be getting the programmable ones from there. I already have two running separate chest freezers but they're installed rather well at this point, so I'd rather play with something new before I tear those apart.

I also have an Uno on the way, all of which is expected tomorrow.

Been watching this thread from the beginning and have been rather impressed with what I'm seeing!

Alpha, when do you expect to have an updated install guide up? As soon as you do, I'll gladly follow it and let you know the results.
I'm completely new to anything Arduino, but have been in IT for almost ten years now, so I don't expect it to be too hard for me.

I saw way back in the thread a post about soldering a 5 pin header on the stc. Does anyone have a source for the parts to do this?
 
Has anyone attempted to install a 5-pin USB jack into their project, for easy flashing? Or some other solution involving a standardized plug?

I see that microUSB supports 5-wire connections, so this could be ideal to make things quick, versus constantly hooking up individual wires.
 
Has anyone attempted to install a 5-pin USB jack into their project, for easy flashing? Or some other solution involving a standardized plug?

I see that microUSB supports 5-wire connections, so this could be ideal to make things quick, versus constantly hooking up individual wires.

It's not the same format, although there are adapter chips that would work.

I believe something like this might work in taking the place of the Arduino (Although I havent had any luck flashing with anything other than the Arduino)

http://www.oddwires.com/usb-isp-3-3v-5v-avr-programmer/?gclid=CMrC_8O5w70CFcqUfgodjLYAjg

BUT - Why bother? The firmware will become stable and the adapter will become useless. You wont have to re-flash it again. The last time I flashed mine, I didn't remove a wire - I pulled it out, popped the case open enough to get the ribbon cable in, flashed it, and had it back together in less than ten minutes.
 
Thanks, I've seen those on amazon, also. What about the ribbon cable and female connector that will mate to those pin headers?

Thats a bit tougher.... Mine came with an ISCP PIC programmer (PIC is the processor in a 1.0 STC)

http://www.ebay.com/itm/USB-PIC-Aut...706?pt=LH_DefaultDomain_0&hash=item48545cf5da

But if you dont want to buy the programmer, you could buy this cable and use either the front six pins or the back six pins, I believe it would still work.

http://www.ebay.com/itm/2-Pcs-2-54m...C-Flat-Ribbon-Cable-Length-15cm-/170941249939
 
It's not the same format, although there are adapter chips that would work.

I believe something like this might work in taking the place of the Arduino (Although I havent had any luck flashing with anything other than the Arduino)

http://www.oddwires.com/usb-isp-3-3v-5v-avr-programmer/?gclid=CMrC_8O5w70CFcqUfgodjLYAjg

BUT - Why bother? The firmware will become stable and the adapter will become useless. You wont have to re-flash it again. The last time I flashed mine, I didn't remove a wire - I pulled it out, popped the case open enough to get the ribbon cable in, flashed it, and had it back together in less than ten minutes.


I think you and I are on different pages here. I'm not talking about something to replace the Arduino. I'm talking about making it easier to flash WITH the Arduino. Currently I have wires (with tips that easily connect into the Arduino's pin slots) that are taped over individually. Each time I want to connect, I have to remove the tape from each wire, then connect them all, then hook it all up to the computer, etc.

Itd be nice if I could take a microUSB cable (5-wire) and cut off one end and have that rigged to plug into the Arduino (I only use that thing for flashing this controller --- nothing else). Then I could wire up a female end to the controller, and have it easy to hook things up to flash.


However, you make a very fair point -- at some point soon, we're gonna be 100% stable and unable to add more features. At that point, maybe more flavors will come out for different purposes. I for one wouldn't mind seeing the stock firmware basically being remade in order to flash the controller back to a simpler set of logic.
 
I just ordered a couple STC's from AGPtek since everyone seems to be getting the programmable ones from there. I already have two running separate chest freezers but they're installed rather well at this point, so I'd rather play with something new before I tear those apart.

I also have an Uno on the way, all of which is expected tomorrow.

Been watching this thread from the beginning and have been rather impressed with what I'm seeing!

Alpha, when do you expect to have an updated install guide up? As soon as you do, I'll gladly follow it and let you know the results.
I'm completely new to anything Arduino, but have been in IT for almost ten years now, so I don't expect it to be too hard for me.

I saw way back in the thread a post about soldering a 5 pin header on the stc. Does anyone have a source for the parts to do this?

Thanks!
It'll probably be a few more days before I have something that I can present and even then will probably have to update the manual somewhat if you guys are nice enough to give me some feedback (which I hope and believe you will).

Has anyone attempted to install a 5-pin USB jack into their project, for easy flashing? Or some other solution involving a standardized plug?

I see that microUSB supports 5-wire connections, so this could be ideal to make things quick, versus constantly hooking up individual wires.

I like the mini XLR connectors (just search ebay for 'mini XLR 5 pin'), they are great for tempsensors as well., but micro USB might work.

Sure, I feel also that the firmware is approaching stability and that there probably will be less and less updates. But, you never know if/when some bug is discovered, or someone comes up with some nifty feature. So I don't see anything wrong with having an at least somewhat accessible programming header.
 
I have pushed the new sketch to work branch.
It adds version number to user ID location when programming the STC and some help for the user (like if EEPROM data has changes since the version that is currently flashed).
There is nothing new in the actual firmware.
But if someone wants to try out the new sketch, please do.
Just one note, as this is the first time User ID locations are written, it will claim to no previous STC.-1000+ firmware is detected, even if there is. Disregard that, you can check with 'd' command after flashing and it should detect the version.
 
Regarding soldering, krazydave, I got these and soldered the ribbon ends to the easily reachable back of the STC -- note that case may or may not close on this but once I have stable firmware flashed I'm closing it up. Then I got these to use as pins from the Arduino to the connector on the ribbon cable mentioned above.

Alpha, flashing "help" is VERY NICE!
BEFORE:
STC-1000+ firmware sketch.
Copyright 2014 Mats Staffansson

Send 'd' to check for STC-1000
Enter low voltage programming mode
Leaving programming mode
Device ID is: 0x27C5
STC-1000 detected.
No previous STC-1000+ firmware detected.
Consider initializing EEPROM when flashing.
Sketch has version 0.11

Send 'a' to upload Celsius version and initialize EEPROM data.
Send 'b' to upload Celsius version (program memory only).
Send 'f' to upload Fahrenheit version and initialize EEPROM data.
Send 'g' to upload Fahrenheit version (program memory only).


AFTER:
Device ID is: 0x27C5
STC-1000 detected.
STC-1000+ Fahrenheit firmware with version 0.11 detected.
Sketch has version 0.11

Send 'a' to upload Celsius version and initialize EEPROM data.
Send 'b' to upload Celsius version (program memory only).
Send 'f' to upload Fahrenheit version and initialize EEPROM data.
Send 'g' to upload Fahrenheit version (program memory only).
 
I have a couple old PC wiring harnesses laying around. Is there any reason I couldn't use one of the four wire connectors to solder in a permanent header to both the STC and the Arduino? That way you just clip it in if you need to flash. And, no cost.


Sent from my iPhone using Home Brew
 

Latest posts

Back
Top