More logging… and floating math.

Two nights ago I managed to finally get the screen that shows graphs to draw the current temperature up in the corner on top of the graph.  Most of the problem was figuring out how to convert the “float” numbers to characters.

I needed to feed this into Microchip’s Graphics Library and accommodate “unicode” characters to get the “degree” symbol on the screen eventually.  Instead of typing a string as string=”Hello There”; it ends up being string={‘H’, ‘e’, ‘l’, ‘l’, ‘l’, ‘o’, ‘ ‘, ‘T’, ‘h’, ‘e’, ‘r’, ‘e’}; which ends up being an array of character values.

A float is a decimal number.  In this case 3 digits for hundreds, a decimal position, and 3 more digits for numbers.  The sensor is kicking out two digits and I’m adding readings together, averaging them, and then rounding up or down with the extra positions in some places.  The PIC32 unfortunately does not have a floating point calculation area in its brain resulting in it “compensating” for it by automatically sliding all the other numbers around using complicated things called mantissa and a few other things I really don’t want to deal with.

The reason I don’t want to deal with them is actually NOT because it is complicated (which it is) but because since it is compensating when you divide a float it has to do MANY cpu cycles for it to compensate and come up with the answer.  It is ACTUALLY easier to multiply the float by 100, 1000, 10,000 etc and insert that number into an integer data type.  Integers can be divided, multiplied, subtracted, etc without worrying about how the numbers line up and doing crazy compensating.  They just don’t end up with a decimal.

If you have a temperature of 175.25 degrees fahrenheit you multiply it by 1000 which equals 175250.  This maintains all of  required digits as a whole number and gives extra space for “rounding” down below.

The issue with the graphics library you need to use a font for every character and take into consideration symbols like degrees etc.  This means it is not simply just a “character” but you need to allocate for all the extra stuff.  This results in a larger space for each character.  To me it looks like a single character in XChar is actually two positions instead of one to leave extra room for the fancy characters to be allowed for.  To convert text strings or float numbers into characters that can be handled by the library you have to load them into an array.  This array to convert the above number (float averaged=175.25)  looks something like this:

int showtemp[8];
showtemp[0]=averaged*1000; //175250

showtemp[1]=showtemp[0]/100000; //175250/100000 = 1 in integer
showtemp[2]=showtemp[0]/10000-(showtemp[1]*10); //175250/10000 = 17.  and then 17- 1*10 = 7 in integer
showtemp[3]=showtemp[0]/1000-(showtemp[1]*100)-(showtemp[2]*10); 175250/1000 = 175 and then 175 – 1*100 – 7*10 = 5
showtemp[4]=showtemp[0]/100-(showtemp[1]*1000)-(showtemp[2]*100)-(showtemp[3]*10); // etc
showtemp[5]=showtemp[0]/10-(showtemp[1]*10000)-(showtemp[2]*1000)-(showtemp[3]*100)-(showtemp[4]*10);

temperaturetext[0]=showtemp[1]+48; // 1 + 48 = 49 = proper number for 1 in character
temperaturetext[1]=showtemp[2]+48;  // 7+ 48 = 55 or proper number for 7 in character
temperaturetext[2]=showtemp[3]+48; // etc
temperaturetext[3]=46; // 46 = proper number for a decimal.
temperaturetext[4]=showtemp[4]+48;  //etc
temperaturetext[5]=showtemp[5]+48;  //etc

 

the results in temperaturetext looks like {‘1′,’7′,’5′,’.’,’2′,’5′}

I roasted twice now using the new graph with actual temperatures listed up top and was planning on comparing the results but I accidentally corrupted the first file.  I’ve got one more batch of some coffee from Rwanda that I was testing with.  I’m getting pretty close to running out of coffee again so it’s time to order some more soon.  I was hoping to have something good from Ethiopia come up for sale but it’s still a little early for that.

Still working on… recognizing temperatures for various(rough) stages the roast is at vs some sort of mechanism to confirm a stage marking things like first / second etc.  Also need to get ambient weather information recorded and get other sensors going on it…. and make it pretier…. and of course get it hooked to higher voltage turning on and off the heat.

Modified Thermometer Test w/ Rwanda Gkongoro Nyarusiza

So as mentioned previously I took the thermometer probe and used one of those pipe cutters with the “wheel” for cutting things like copper pipe and sliced off part of the probe.  Due to the fact that this sort of cutter “crushes” slightly while it cuts this ended up making it so I could not slide the inner electronics out without fear of not getting it back in or damaging it (without having a soldering iron currently).  I instead slid all of the formerly connected probe upwards and taped it to the probe’s plug using electrical tape.  I then crimped the remaining probe in place at the top against the braided cover.

My initial test seems to have yielded a technically proper heat ramp based on what was happening.  Additionally the cooling cycle appears to have been pretty normal too.  It appears that when the cool cycle halts the beans are approximately 158 degrees and linger there while in the roasting chamber even when removed from the roaster.  They drop to around 130 degrees after being dumped out into another container within about 20 seconds and then they hang around 130-120 degrees for several minutes if undisturbed.

Here is my heat readings for a standard roast.  In this case I was roasting the Rwanda Gkongoro Nyarusiza.

Markers are A= Rolling First Crack, B= Second Crack.  Fan speed is shown as 100% for the knob being set all the way to the right.  50% is fan knob set in the middle position (straight up).

I was not able to keep track of any additional details due to manually tracking the roast on paper.  Cooling with fan speed increased to 100% starting at 6.1 was as follows:

Bean mass started at 120g and reduced to 102g for a loss of 18g or 15%