Stc-1000+

[ldzielak]

@ldzielak: Hopefully I have fixed the com.ino sketch now. At one point I refactored the menu system in the STC-1000+ code and forgot to change com.ino. Unfortunately, with my current setup, I cannot test com stuff, so I couldn't verify that the change I made is correct, but it'll hardly make it worse at least

Cheers!

Sounds good, I will test it out tonight. I'm away for work till the 2nd but I have one unit with to do some testing.

So do you think it will be possible for me to modify your com.ino to print a simple CSV formatted string with Temp, SP, Cooling and heating status, while retaining all the existing features? I really want to log the data, but don't want to loose any of the great features you have created.

I don't have much for pictures on me with my setup, I was sent the wrong thermowells for the mini buckets so I didn't drill the holes in the lids yet. Here are some in progress pictures.

Cheers Lee

 

[alphaomega]

So do you think it will be possible for me to modify your com.ino to print a simple CSV formatted string with Temp, SP, Cooling and heating status, while retaining all the existing features? I really want to log the data, but don't want to loose any of the great features you have created.

Sure, it is kind of the point with the com firmware. Just a tip though, don't send commands too quickly (that is, use a delay beween each command sent of at least 10ms). Due to limitations with the protocol, communication state resets after 10ms, so if there is a cimmunication error, it allows next command to have a chance to start 'clean'. Otherwise the error may propagate.

Thanks for the pics! Let me know if the fix I put up doesn't work out. Good luck!

Cheers!

 

[FowlBall]

Hi all...long time lurker, first time contributor here. First, I want to thank Mats for all of his hard work on this project. I appreciate it more than I can ever repay you for your contributions.

For some time I've been working on a wireless logger for the STC-1000+, based on the communications firmware Mats wrote. I've been through a number of iterations on this going back almost a year now, and have something I'd finally like to share. It's based on the Adafruit Huzzah ESP-8266 package, which I find quite stable and love the 4M flash available. It also is cheap (about $10).

I've set up a Git repository with the code (written in / for the Arduino IDE) and additional details. The project also supports an OLED display to keep track of what's happening in real time. It gathers information from the running STC (setpoint, status of heating / cooling relays, current probe temp, run-mode (profile or thermostat), step (for profile), and duration hours. This data is streamed to an on-line datastream at Sparkfun (data.sparfun.com), or you can change this to a local Phant server if you prefer.

The repository includes a (crude) Fritzing diagram to show how I connected the components. When I started this, I was a noob working with electronics, soldering, using the Arduino, Github, Fritzing, etc., so please be kind in your criticisms / feedback.

There are a number of things that need to be edited in the code before compiling it, such as specifying your SSID, password, network IP info, NTP settings, timezone offset, Sparfun datastream keys, etc. These are all flagged in the code and detailed in the README. I hope to continue to enhance this by adding a web configurator in the future to handle these settings rather than having to edit the code directly, but it is what it is for now.

Good luck and please let me know if you get a chance to try it out how it works for you.

Here's the Github link: https://github.com/fowlerk/STC1000Logger.git

 

[ldzielak]

Well here is some testing results from the new com.ino

I tested both reads and writes. Looks like the only things I can find wrong are a few of the variables need to be divided by 10, hy, tc & SA (not a very big deal at all!)

rn parameter had me confused based on the comments next to them in the code. I could not write 0-6, but I can write th or Pr0... So I guess this works as intended. All other parameters I have tried writing to work just like they should.

Reading St and dh would not work until I had used a profile for a moment, then even after being back in th mode, I could read these parameters. Make sense now.

It kinda would be nice to see more info than just Ok after a write, like echo back what the parameter and value written was, but on the other hand from a script confirmation, this is all that is needed.

Thanks for the quick fix.

Lee

 

[ldzielak]

Sure, it is kind of the point with the com firmware. Just a tip though, don't send commands too quickly (that is, use a delay beween each command sent of at least 10ms). Due to limitations with the protocol, communication state resets after 10ms, so if there is a cimmunication error, it allows next command to have a chance to start 'clean'. Otherwise the error may propagate.

Thanks for the pics! Let me know if the fix I put up doesn't work out. Good luck!

Cheers!

So my thinking was this, please correct me if I'm miss understanding your com.ino It is always waiting for a request and simply carries out orders when it gets a new command, then goes back to waiting for the next command.

My concept is after waiting for 5 seconds, Arduino would query to STC for current SP, Temp, Cooling/Heating status (Maybe checking rn and if running a profile, report back the St and dh) These questions would be asked one at a time with 10+ms between them, compact the results into a single string (coma separated) and then print to serial. Something like "80.0,79.9,off,on,PR0,1,48" this would then take say 80-100ms to collect and print. Then go back to monitoring for the next command for another 5 seconds.

Next step after getting this to work is a GUI or virtual control panel where I can see my STC1000+, being updated every 5 seconds, and maybe make the buttons function just like I was really at the STC. Depending on what you select, the equivalent command would be sent to the STC and GUI would update. I would build my 5 STCs into a single interface and I could manipulate as desired from anywhere I can VPN and VNC to my RPi 2. (Want to go real crazy, make an iPhone/andriod app and interface / trend results from anywhere)

I come from an instrumentation/ advanced controls and analyzer background, 18yrs in pulp and paper and now 3yrs in oil. I have been programming Emerson DeltaV DCS for 8 years now, Metso DNA before that. I'm used to multi million dollar control systems and multi billion dollar plants. I now do controls consulting and configuration for a big oil company. I'm dreaming of having the same control over my fermentation at home as I do every day over massive advanced processes!

Cheers

 

[alphaomega]

Hi all...long time lurker, first time contributor here. First, I want to thank Mats for all of his hard work on this project. I appreciate it more than I can ever repay you for your contributions.

For some time I've been working on a wireless logger for the STC-1000+, based on the communications firmware Mats wrote. I've been through a number of iterations on this going back almost a year now, and have something I'd finally like to share. It's based on the Adafruit Huzzah ESP-8266 package, which I find quite stable and love the 4M flash available. It also is cheap (about $10).

I've set up a Git repository with the code (written in / for the Arduino IDE) and additional details. The project also supports an OLED display to keep track of what's happening in real time. It gathers information from the running STC (setpoint, status of heating / cooling relays, current probe temp, run-mode (profile or thermostat), step (for profile), and duration hours. This data is streamed to an on-line datastream at Sparkfun (data.sparfun.com), or you can change this to a local Phant server if you prefer.

The repository includes a (crude) Fritzing diagram to show how I connected the components. When I started this, I was a noob working with electronics, soldering, using the Arduino, Github, Fritzing, etc., so please be kind in your criticisms / feedback.

There are a number of things that need to be edited in the code before compiling it, such as specifying your SSID, password, network IP info, NTP settings, timezone offset, Sparfun datastream keys, etc. These are all flagged in the code and detailed in the README. I hope to continue to enhance this by adding a web configurator in the future to handle these settings rather than having to edit the code directly, but it is what it is for now.

Good luck and please let me know if you get a chance to try it out how it works for you.

Here's the Github link: https://github.com/fowlerk/STC1000Logger.git

Very cool
I don't know if you have followed this thread, but I actually played around with the ESP myself. I used a framework called Sming, which has Arduino support + a lot of other cool things. But I never got it working reliably. So, I kind of lost faith in it for a while.

Turns out though, that there was a bug in the JSON library that Sming uses (memory leak), that recently got fixed. Tried it out a few days ago, and it seems to work a lot better now, so I'm kind of in the mood to get started with it again.

I had a PoC going that starts an AP (WiFi access point) when not configured. Connect to it and configure your network (or simply use the AP if you want to). It can do all the COM stuff via simple REST interface AND you can FTP a HEX file and update the STC-1000+ firmware.

It needs some polishing, I'd like to get a modified version of the profile editor running, so you can simply edit your profile, upload and run it directly. Some logging (either to flash or cloud) would be cool as well. Waddaya think?

I don't mean to steal you thunder, on the contrary, that is a very cool project! Kudos! (Maybe I should have lead with that...)
But I don't have a lot of spare time on my hands, and if I can get others interested in contributing, that would make it a lot more likely to happen. I can share what I got right now, but I'd probably need to clean it up a bit first. So far it is mainly based on the Sming examples + the COM and picprog sketches. It is still very crude... But it shows potential. It would be cool to combine the cheap but reliable STC, with the cheap (but somewhat less reliable) WiFi capabilities of the ESP to make something really great.

Well here is some testing results from the new com.ino

I tested both reads and writes. Looks like the only things I can find wrong are a few of the variables need to be divided by 10, hy, tc & SA (not a very big deal at all!)

rn parameter had me confused based on the comments next to them in the code. I could not write 0-6, but I can write th or Pr0... So I guess this works as intended. All other parameters I have tried writing to work just like they should.

Reading St and dh would not work until I had used a profile for a moment, then even after being back in th mode, I could read these parameters. Make sense now.

It kinda would be nice to see more info than just Ok after a write, like echo back what the parameter and value written was, but on the other hand from a script confirmation, this is all that is needed.

Thanks for the quick fix.

Lee

Ok, I buckled down and broke out an STC that I could use for COM stuff and think I've fixed the remaining issue.
Reading/writing St and dh should be doable, even without first running a profile.
Yes, rn accepts "th", "Pr0"-"Pr5" (just as it shows them that way).
It can't really do more than write "Ok" as, all it knows is that the communication worked. You really need to read the same value again, if you want to verify that it really was written correctly.

So my thinking was this, please correct me if I'm miss understanding your com.ino It is always waiting for a request and simply carries out orders when it gets a new command, then goes back to waiting for the next command.

My concept is after waiting for 5 seconds, Arduino would query to STC for current SP, Temp, Cooling/Heating status (Maybe checking rn and if running a profile, report back the St and dh) These questions would be asked one at a time with 10+ms between them, compact the results into a single string (coma separated) and then print to serial. Something like "80.0,79.9,off,on,PR0,1,48" this would then take say 80-100ms to collect and print. Then go back to monitoring for the next command for another 5 seconds.

Next step after getting this to work is a GUI or virtual control panel where I can see my STC1000+, being updated every 5 seconds, and maybe make the buttons function just like I was really at the STC. Depending on what you select, the equivalent command would be sent to the STC and GUI would update. I would build my 5 STCs into a single interface and I could manipulate as desired from anywhere I can VPN and VNC to my RPi 2. (Want to go real crazy, make an iPhone/andriod app and interface / trend results from anywhere)

I come from an instrumentation/ advanced controls and analyzer background, 18yrs in pulp and paper and now 3yrs in oil. I have been programming Emerson DeltaV DCS for 8 years now, Metso DNA before that. I'm used to multi million dollar control systems and multi billion dollar plants. I now do controls consulting and configuration for a big oil company. I'm dreaming of having the same control over my fermentation at home as I do every day over massive advanced processes!

Cheers

Ok, first off. It wouldn't be that hard to change the loop function in the com.ino sketch to every 5 seconds fart out the stuff you want over serial. That would be a very good beginning exercise.

Next, if you modify the sketch, I don't see a problem in communicating with 5 STC's with one Arduino. You really only need one data pin per STC. But you'd need to write some code to address them. You could add an arduino per STC as well. If you're gonna write a GUI, then you can't have it blurt out stuff every 5 secs, so you'd need to go back and just have the GUI poll the stuff it needs over serial. But I guess that is a given.

From experience, I know serial can be a bit tricky, so you'd need some decent error handling. And for the GUI, I'd suggest you use absolute addressing (i.e. "r 125" and "w125 0" for example) instead of the mnemonics. That is why the absolute addressing is there, to make it easier to interface with a computer. The mnemonics is easier on a human

Good luck!

 

[FowlBall]

Very cool
I don't know if you have followed this thread, but I actually played around with the ESP myself. I used a framework called Sming, which has Arduino support + a lot of other cool things. But I never got it working reliably. So, I kind of lost faith in it for a while.

Turns out though, that there was a bug in the JSON library that Sming uses (memory leak), that recently got fixed. Tried it out a few days ago, and it seems to work a lot better now, so I'm kind of in the mood to get started with it again.

I had a PoC going that starts an AP (WiFi access point) when not configured. Connect to it and configure your network (or simply use the AP if you want to). It can do all the COM stuff via simple REST interface AND you can FTP a HEX file and update the STC-1000+ firmware.

It needs some polishing, I'd like to get a modified version of the profile editor running, so you can simply edit your profile, upload and run it directly. Some logging (either to flash or cloud) would be cool as well. Waddaya think?

I don't mean to steal you thunder, on the contrary, that is a very cool project! Kudos! (Maybe I should have lead with that...)
But I don't have a lot of spare time on my hands, and if I can get others interested in contributing, that would make it a lot more likely to happen. I can share what I got right now, but I'd probably need to clean it up a bit first. So far it is mainly based on the Sming examples + the COM and picprog sketches. It is still very crude... But it shows potential. It would be cool to combine the cheap but reliable STC, with the cheap (but somewhat less reliable) WiFi capabilities of the ESP to make something really great.

Yeah, I didn't elaborate in my original post (it was long enough already!), but you were my inspiration for this! I took a quick look at Sming and played around with the ESP-01, but then ESP support was added to the IDE (with which I was already familiar), and I was having issues with the ESP hanging. So, I looked around and found the Cactus Micro (combo ESP and ATmega32U4), and got the initial version running on it. Again, had issues with it hanging after anywhere from hours to days, and I didn't have flash to add much error handling. That's when I moved on to the Huzzah. So far, it's been rock-solid. It's a little more expensive ($10 US), but I like the flash size (4M= lots of future functionality!) I'm actually working on adding the web configuration you mentioned, but I really like your ideas on the OTA updates, profile editing, and local logging options. I'm not nearly at your level of coding expertise (or electronics), but I can generally read and follow other's code. (Oh, and borrow judiciously!)

All that said, I'd be happy to contribute where I can once you can get the opportunity to put up what you've written.

 

[seaner]

hey folks.. does anyone have a part number for an appropriate 3-pin terminal block to replace the 2-pin probe one for a multiprobe setup?

Anyone happen to know the pitch of the holes? looks like 5mm?

No need to use the same 10A/300V rated ones that are on there already... maybe this one here? http://www.digikey.ca/product-detail/en/1935174/277-1578-ND/568615
(Edit: I was sorting by price, and wouldn't you know it, a HIGHER current part was cheaper Here's a similar 10A/300V one for a few cents more I guess -- http://www.digikey.ca/product-detail/en/OSTYC032150/ED2903-ND/1588995 )

Cheers,
Sean

 

[mattrox]

hey folks.. does anyone have a part number for an appropriate 3-pin terminal block to replace the 2-pin probe one for a multiprobe setup?

Anyone happen to know the pitch of the holes? looks like 5mm?

No need to use the same 10A/300V rated ones that are on there already... maybe this one here? http://www.digikey.ca/product-detail/en/1935174/277-1578-ND/568615
(Edit: I was sorting by price, and wouldn't you know it, a HIGHER current part was cheaper Here's a similar 10A/300V one for a few cents more I guess -- http://www.digikey.ca/product-detail/en/OSTYC032150/ED2903-ND/1588995 )

Cheers,
Sean

Just going from memory, I think the 2nd one looks like what I got. But I got mine off eBay from Hong Kong.

 

[p_p]

Could you please give me a hand understanding the use of programs with ramping enabled?

Lets say that I program the controller such PR0 is:

SP0 20.0
dh0 72
SP1 18.0
dh1 24
SP2 10.0
dh2 0

If I start PR0 on step 0, the controller will set SP to SP1 (20.0) and over a lapse of dh0 (72 hrs) the SP will gradually change towards SP1 (18.0) after which, SP will gradually change over a lapse of dh1 (24 hrs) towards SP2 (10.0) after which it will no longer change.

Is that right?

Thanks!

 

[jleiii]

Could you please give me a hand understanding the use of programs with ramping enabled?

Lets say that I program the controller such PR0 is:

SP0 20.0
dh0 72
SP1 18.0
dh1 24
SP2 10.0
dh2 0

If I start PR0 on step 0, the controller will set SP to SP1 (20.0) and over a lapse of dh0 (72 hrs) the SP will gradually change towards SP1 (18.0) after which, SP will gradually change over a lapse of dh1 (24 hrs) towards SP2 (10.0) after which it will no longer change.

Is that right?

Thanks!

Yes that's the ramping process. See this link for building and 'seeing' what you set using Mats profile builder.

 

[jleiii]

Mats, any chance you could hop over to the PI (mashing) thread and comment on my post from a few days ago? I'm working on testing this version with my setup, in F, and not really sure where to start with the settings.

Any chance the profile builder page will get updated to include this one?
John

 

[alphaomega]

Yeah, I didn't elaborate in my original post (it was long enough already!), but you were my inspiration for this! I took a quick look at Sming and played around with the ESP-01, but then ESP support was added to the IDE (with which I was already familiar), and I was having issues with the ESP hanging. So, I looked around and found the Cactus Micro (combo ESP and ATmega32U4), and got the initial version running on it. Again, had issues with it hanging after anywhere from hours to days, and I didn't have flash to add much error handling. That's when I moved on to the Huzzah. So far, it's been rock-solid. It's a little more expensive ($10 US), but I like the flash size (4M= lots of future functionality!) I'm actually working on adding the web configuration you mentioned, but I really like your ideas on the OTA updates, profile editing, and local logging options. I'm not nearly at your level of coding expertise (or electronics), but I can generally read and follow other's code. (Oh, and borrow judiciously!)

All that said, I'd be happy to contribute where I can once you can get the opportunity to put up what you've written.

Ok, so I've got a repository up on github. I've still not cleaned up the code and it lacks documentation, but at least the code is there. It is just proof of concept stuff, but still pretty cool that it works. Now, the real work begins... *sigh*

 

[FowlBall]

Ok, so I've got a repository up on github. I've still not cleaned up the code and it lacks documentation, but at least the code is there. It is just proof of concept stuff, but still pretty cool that it works.

Okay Mats, I'll head over and take a look. No worries on cleaning up the code / documentation at this point. Give me a few days to wrap my head around Sming and what you've posted and I'll see if I can contribute.

Now, the real work begins... *sigh*

...And that's the "fun part", right?

 

[seaner]

Well, optimization has been going well.. I think we've shaved down around 15% of the code so far, and probably room for another 5% or so. Should be lots of space for new dual-probe algorithms.
I'm going to rig a unit up with dual probe and 1-wire comms on the heating relay pin and do some real-world data logging soon in order to build some nice models for simulation. Then should be able to settle on an effective algorithm

 

[alphaomega]

I've been making pretty good progress with the ESP stuff. Greatly improved on the HEX flashing. Now you can load a page (hosted on the ESP) and stream the HEX file over a websocket to the ESP, that flashes the STC on the fly. The profiles should be editable (using a modified version of the profile editor). There is a page for the set menu.
The major parts left are:
* Logging
* Documentation
* And oh my <insert deity of choice>, does the code need to be cleaned up. The web pages needs polishing and a consistent interface (which I suck at), and there are a lot of minor improvements to be done.

But over all, now it works pretty smooth! I think this could be good given time and some TLC

 

[mattrox]

I've been making pretty good progress with the ESP stuff. Greatly improved on the HEX flashing. Now you can load a page (hosted on the ESP) and stream the HEX file over a websocket to the ESP, that flashes the STC on the fly. The profiles should be editable (using a modified version of the profile editor). There is a page for the set menu.
The major parts left are:
* Logging
* Documentation
* And oh my <insert deity of choice>, does the code need to be cleaned up. The web pages needs polishing and a consistent interface (which I suck at), and there are a lot of minor improvements to be done.

But over all, now it works pretty smooth! I think this could be good given time and some TLC

This is awesome.

 

[ldzielak]

So I think I figured out how to get my 1 wire log working, this is an older screen shot and I'm not sure why there are some errors, but this was the worst case I have seen. It's been running steady for days to the Arduino IDE serial monitor on my RPi 2.

Every 5 seconds it outputs a comma separated line that will get appended to an .csv file, I will push that file to my dropbox maybe once an hour, to keep the network traffic down. In between normal commands can be used to read or write settings just like the regular com.

I have 5 SCTs with 5 Arduinos ready to plug to my RPi to do all the handling. I'm still working on the Python script. Work got a little crazy past few days so I haven't finished what I wan't. Still trying to think what the best way for error checking will be.

Guess I should explain, First number is Current Temperature, Temperature SP, Heating Status, Cooling Status
I will be adding profile, current step and current delay next. If running th mode the string will end there.

 

[ldzielak]

The following replaced void setup() and void loop()
I was going to skip fixing the temperature decimal place and just deal with it on the other end in Python, but then I figured it still had to look nice. Debating about padding the front few characters with an identifier of some kind, since I will have 5 identical units, would be nice to know what each one is in the event the USB ports get re-arranged.

See next post for update.

 

[ldzielak]

Finished adding the extra parameters to the Log string. Can't seem to create a pull request from Git. Maybe I need to get authorized or something?

unsigned long startTime = 0;

void setup() {
	Serial.begin(115200);

	delay(2);

	Serial.println("STC-1000+ communication sketch.");
	Serial.println("Copyright 2015 Mats Staffansson");
	Serial.println("");
	Serial.println("Commands: 't' to read temperature");
	Serial.println("          'c' to read state of cooling relay");
	Serial.println("          'h' to read state of heating relay");
	Serial.println("          'r [addr]' to read EEPROM address");
	Serial.println("          'w [addr] [data]' to write EEPROM address");
	Serial.println("");
	Serial.println("[addr] can be literal (0-127) or mnemonic SPxy/dhxy, hy, tc and so on");
	Serial.println("[data] will also be literal (as stored in EEPROM) or human friendly");
	Serial.println("depending on addressing mode");

}

void loop() {
	static char cmd[32], rxchar=' ';
	static unsigned char index=0;
	unsigned long loopTime = abs(millis() - startTime);
	int interval = 5000; 	//Set log ouput interval

		if (loopTime <= interval) {
			if(Serial.available() > 0){
				char c = Serial.read();
				if(!(isBlank(rxchar) && isBlank(c))){
					cmd[index] = c;
					rxchar = c;
					index++;
				}

				if(index>=31 || isEOL(rxchar)){
					cmd[index] = '\0';
					parse_command(cmd);
					index = 0;
					rxchar = ' ';
				}
			}
		}
		else
		{
			int temp;
			int SetPoint;
			int heating;
			int cooling;
			int Hysteresis;
			int Mode;
			int Step;
			int Duration;
			int Ramping;

			read_temp(&temp);
			if(temp < 0){
				temp = -temp;
				Serial.print('-');
			}
			if(temp >= 1000){
				temp /= 10;
				Serial.print(temp);
				Serial.print(",");
			}
			else
			{
			Serial.print(temp/10);
			Serial.print('.');
			Serial.print(temp%10);
			Serial.print(",");
			}
			delay(12);

			read_eeprom(114, &SetPoint);
			if(SetPoint < 0){
				SetPoint = -SetPoint;
				Serial.print('-');
			}
			if(SetPoint >= 1000){
				SetPoint /= 10;
				Serial.print(SetPoint);
				Serial.print(",");
			}
			else
			{
				Serial.print(SetPoint/10);
				Serial.print('.');
				Serial.print(SetPoint%10);
				Serial.print(",");
			}
			delay(12);

			read_heating(&heating);
			Serial.print(heating);
			Serial.print(",");
			delay(12);

			read_cooling(&cooling);
			Serial.print(cooling);
			Serial.print(",");
			delay(12);

			read_eeprom(115, &Hysteresis);
			Serial.print(Hysteresis/10);
			Serial.print('.');
			Serial.print(Hysteresis%10);
			Serial.print(",");
			delay(12);

			read_eeprom(123, &Mode);
			Serial.print(Mode);
			Serial.print(",");
			delay(12);

			read_eeprom(118, &Step);
			Serial.print(Step);
			Serial.print(",");
			delay(12);

			read_eeprom(119, &Duration);
			Serial.print(Duration);
			Serial.print(",");
			delay(12);

			read_eeprom(122, &Ramping);
			Serial.print(Ramping);
			Serial.println(",");
			delay(12);

			startTime = millis();
			delay(12);

		}
	}

 

[ldzielak]

My code is no where near a final product, this is still proof of concept stage, but will get me by for a little while.

Eventually I would like to see:

Moving the code from the void loop() and calling it as a sub routine like it should be.

L option added to the list of commands, this would toggle on/off the Log Output subroutine.

A config sub menu (something simple like when you SSH into a router) where it would automatically turn of Log output and have a simple menu like this:

1 [5] Log Interval Time in Seconds
2 [**Fementer#1**,] Header to be display at left of each string (blank is ok)
3 [x] Current Temperature
4 [, SP=] Delimiter
5 [x] Current Setpoint
6 [ ] Delimiter
...

Resulting string would be:

**Fermenter#1**,75.0, SP=74.5

If you type the number on each row, you get a simple prompt to change the contents of each row. When you make a change the entire list repopulates with an example output at the bottom, so you build as you go. So we can have a static list of log parameters, with configurable delimiters between each. When you type exit, you get back to the normal level and can toggle L back on for log output.

I would like to move away from single word based communication and read the entire variable table regardless of what is selected in the menu above, that only controls the print to log output. It could be stored as a table and output each part as required. A simple error checking scheme could be to compare to the last communication table (So store 2 tables), using While loop, to check if there is a difference, ask again for confirmation. Could repeat 2-5 times else fail. The data should not be changing that much between communication intervals. Based on what I looked at this would solve most of my current problems.

I think we really need a CRC check on both read and write communications, but this would require changes on the both Arduino and STC ends.

I need to build a layer on the write functions, I want the write function to read back what it just wrote, to confirm nothing was lost in communications. Should not be to hard to store the Address and Data, perform a read post successful write and compare the Data. Finally we can echo the OK and add a true confirmation of data written. Last thing I want when sending a SP of 73 and get 173 or something stupid because of noise or what ever communication fault.

My coding on Arduino is pretty basic right now, but this C stuff will comeback to me I hope. Maybe after 20 years, it's going to be like learning it all over again...

Lee

 

[alphaomega]

I think we really need a CRC check on both read and write communications, but this would require changes on the both Arduino and STC ends.

I need to build a layer on the write functions, I want the write function to read back what it just wrote, to confirm nothing was lost in communications. Should not be to hard to store the Address and Data, perform a read post successful write and compare the Data. Finally we can echo the OK and add a true confirmation of data written. Last thing I want when sending a SP of 73 and get 173 or something stupid because of noise or what ever communication fault.
Lee

'Real' CRC is too costly for the STC, but there already is a checksum implemented in the protocol. That is why you even get communication errors, otherwise you wouldn't even know something went wrong.
The 'right' thing to do, is what you were already hinting at. Wrap the read in a loop (i.e try to read x times before giving up and fail) do the same for a write, and then read back to verify.
You really shouldn't need to worry about a faulty value being written. It either succeeds and write or it don't. But validating that the expected value is read back is still a good idea.

 

[FowlBall]

I've been making pretty good progress with the ESP stuff. Greatly improved on the HEX flashing. Now you can load a page (hosted on the ESP) and stream the HEX file over a websocket to the ESP, that flashes the STC on the fly. The profiles should be editable (using a modified version of the profile editor). There is a page for the set menu.
The major parts left are:
* Logging
* Documentation
* And oh my <insert deity of choice>, does the code need to be cleaned up. The web pages needs polishing and a consistent interface (which I suck at), and there are a lot of minor improvements to be done.

But over all, now it works pretty smooth! I think this could be good given time and some TLC

Sounds like a great start...I'd hoped to be in a position to contribute by now, but it's been going pretty slowly for me. I managed to get a development environment built in Linux and was feeling pretty good about where I was at, flashed my ESP with some sample code and bricked it. I was able to eventually recover it, but still haven't been able to flash it successfully without bricking it again. Still trying to figure out where I'm going wrong. I haven't given up on it, but the learning curve has been pretty steep for me.

 

[seaner]

'Real' CRC is too costly for the STC

hehe.. only 28 more instructions to implement CRC-8-CCITT
(or 83 more for CRC-16-CCITT)

 

[p_p]

@alphaomega

Hi Mats,
I see you guys have been working on making some optimizations to the code base.
Do you plan on making a new release? --- So those who have deviated from the main stream (ie, me) can benefit from it?

btw, I have not forgotten about the comments you made in relation to the "menu lock" feature.
It turned out that my son has no interest or whatsoever in playing with the STC, so I have kind of postponed working on it (plus I only have one unit and will be tied for a few more weeks).

cheers

 

[alphaomega]

hehe.. only 28 more instructions to implement CRC-8-CCITT
(or 83 more for CRC-16-CCITT)

OK, I stand corrected
Anyway, I don't think there is a real problem using checksum instead of CRC. But, on the other hand, I'm not against making improvements.

@alphaomega

Hi Mats,
I see you guys have been working on making some optimizations to the code base.
Do you plan on making a new release? --- So those who have deviated from the main stream (ie, me) can benefit from it?

btw, I have not forgotten about the comments you made in relation to the "menu lock" feature.
It turned out that my son has no interest or whatsoever in playing with the STC, so I have kind of postponed working on it (plus I only have one unit and will be tied for a few more weeks).

cheers

A release is probably some time away. Once the optimization stuff and a new dual probe implementation is 'semi stable', I will push it to master and then I'll probably give some time for potential bugs to surface, before making a release.

 

[adam01]

Quick usage question.

If I want to advance the profile to the next step; I have do to :
A. set ST to the next number
B. set DH to 0

I'm trying to end my fermentation phase and move to the diacetyl rest. The lager yeast
is working very quick these days.

 

[mattrox]

Quick usage question.

If I want to advance the profile to the next step; I have do to :
A. set ST to the next number
B. set DH to 0

I'm trying to end my fermentation phase and move to the diacetyl rest. The lager yeast
is working very quick these days.

I go to the current SP which had the low ferm temp then check the next temp to make sure it is the D- rest temp. Once I find that I go back to the DH for the ferm temp and usually set it to 1. Just because I don't like 0 hrs as a duration. Does that makes sense?

 

[barreled]

First off, thanks for all the great work, and I really like being able to set my fermentation profile and forget about it. I was actually about to buy another STC-1000 and modify it, but the Aliexpress store that the readme links to says "Sorry, this item is no longer available!" Does anybody know if that's a permanent thing? And if it is, where can I buy a good one?

 

[ldzielak]

I got 6 from here and will be ordering a few more. http://www.boostbysmith.com/stc1000.html