FreshRoast SR500 Teardown – Part 1

By | | , ,
Leave a comment

This article will explain how to teardown a FreshRoast SR500 roaster and probably an SR300 as well. If you are looking to modify an SR500 the following content will be useful as well. It will include technical information about the components that make the SR500 work and suggestions of where modifications will need to take place if you wish to split fan and heater control to external dimmers, VARIAC devices, or otherwise control your SR500 with a Microchip PIC, Arduino, or other microcontroller or PID controller device.

Now that I’ve finally obtained a spare SR500 base I’m a little more comfortable with tearing down the roaster to see what is inside.  This process has confirmed my initial memory of the roaster being simple to open up.

On SweetMarias’ forum there was a question by a user that I replied to about how to open the SR500 to clean it. I made reference to the FreshRoast SR500 being pretty easy to open up to clean it out inside if you felt it had clogged in any way but did not have the ability to just pop one open nor did I have enough notes about it.  The user managed to clean his through the holes in the roaster using compressed air through the various openings due to having difficulty removing the screws and getting the bottom off.  I suspect he missed taking out the screws in the middle labeled as 7 and 8 below.

This article will be the first part explaining how to teardown a SR500 roaster and probably a SR300 as well.  If you are looking to modify an SR500 the later parts will be much more useful though everyone will need to know how to open it up to do most things.

Opening a FreshRoast SR500 Coffee Roaster

You will need:

  • A phillips screwdriver.
  • A SR500 Base (SR300 may be similar except for changes to the microcontroller board)
  • A baggie or small tray to hold screws
  • A clean area to work
  • Optional: Vacuum and/or compressed air to clean chaff from interior of the roaster base

Step 1:  Unplug your SR500 from the wall.

There is serious electrical voltage at levels that can kill you inside the SR500. DO NOT OPEN THE ROASTER BECAUSE YOU WILL VOID YOUR WARRANTY AND YOU WILL GET ELECTROCUTED AND BURN DOWN YOUR HOUSE.  (No really…)

Step 2: Place your SR500 base in a clean work area.

Remove the roast chamber, chaff collector, and lid so that all that is left is a base.

FreshRoast SR500 Base

SR500 Control Panel

Step 3: Since you apparently do not mind getting electrocuted, burning your house down, or voiding your warranty it’s not my fault if you continue further.

When you electrocute yourself and end up dead don’t come crying to me about it…. or haunting me either. I also don’t want to hear from your spouse, parents, kids, lawyer, or the fire department either.  I will smudge stick , holy water, and exorcise this house at the drop of a hat should your “ghost” come to haunt me… don’t tempt me. By continuing further you have indicated your agreement that you are willing to get electrocuted at your own risk and void your warranty and risk burning your house down. You also agree that you will not haunt me afterwards because this is what you wanted to do at your own risk. Now that we have the formalities covered you may (if desired) continue to Step 4.

Step 4: Turn the roaster over.

FreshRoast SR500 Bottom

Step 5: Remove the 8 screws from the bottom.

FreshRoast SR500 Screws (8)

Numbered Screw positions for SR500 Roaster

Step 6: Loosen and remove the bottom plate.

The bottom plate should be VERY loose at this point and could simply fall off.  In addition be aware the top ring of the roaster will be very loose now too.

FreshRoast SR500 Bottom Plate and Screws

Step 7: Bag up your loose screws so that you do not lose them.

Better to be safe than sorry.  Store the loose screws in a tray or sandwich bag.  There will be additional screws later if you remove the micro control board later.  Also be aware

Step 8: Inspect the interior.

From top to bottom in the picture below you have AC Power cord entering the roaster base, power control board, blower fan in the middle as well as the heater assembly around the fan, and the main logic micro control board at the bottom.

To the right you have the fan potentiometer wiring leading from the round potentiometer leading to the right side of the power control board.  On the left you have the main logic board wiring leading to the middle of the power control board.  In the middle the blower fan and the heater have black and white wiring that lead to the power control board.  Out of the side of the heater assembly are two small wires that are not visible in this photo.  Those are the NTC sensor wiring.

FreshRoast SR500 Interior

Step 9:  If you are interested in cleaning the roaster you certainly can do so now.

Compressed air and/or vacuuming can be done at this time.  With a narrow crevice tool you can probably get access next to the motor in the middle.  There are many small blades as part of the blower inside the black housing shown above.  If you are more adventurous you will need to disassemble further and this will get you closer to the intake around the motor assembly.

Step 10:  Further Disassembly.

If you are disassembling the roaster further you will need to remove the power board, the lower housing from the upper housing, and disconnect the “microcontroller board” from the power board.  These will be explained in Part 2.

TechToys SSD1963 eval kit on a PIC32 I/O Expansion Board

By | | , , , , ,
Leave a comment

Now that I’ve gotten all the leaks taken care of on my new aquarium I decided I should at least figure out if the new SSD1963 eval kit with 7 inch 800×480 LCD that came from TechToys. com.hk works. Officially it is listed on the site as SSD1963EVK-R3B + 7″ WVGA color TFT with Touch Panel Part #: SSD1963EVK-R3B-TY700TFT and as of July 2011 was listed as a bundle price of $119 USD plus shipping. This includes the LCD, SSD1963 board with a cable between them, and 40 jumper cables.

This kit is intended for a development board created by TechToys that fits the connector perfectly. On that board you can then place a PIC32 starter kit. For my purposes this is not usable because I do not need the devices on that board such as the MP3 player. I also need to add a variety of I2C and SPI devices for sensing environmental conditions. For my project sticking with the PIC32 I/O expansion board is the best bet.

I decided I would leave the original breakout boards attached and wire the LCD and graphics chip on. I removed the Microchip Graphic boards from the side and popped out the riser card. To properly find the wiring you need to use you need to consult both the schematic for the Multimedia Evaluation Kit for Microchip PIC32 Starter Kit and the Evaluation Kit for SSD1963QL9. You are looking at the diagrams for MCU interface and SSD1963 EVK Interface. What you will find is that not all of the pins are diagrammed through to both sides. They need wired through though and the correct connections can be determined elsewhere on the schematic. Wire everything from the SSD1963 EVK Interface diagram and then add onto it the Reset, LE and other pins. Once you do this you end up… with a mess:

Then I began the process of trying to compile the modified MultiApp Demo. I selected one of the hardware profile includes for the 7 inch LCD and SSD1963 that involved a PIC32MX795 and tried to compile it. I’ve read about people potentially having to modify when using a Graphics Library higher than 2.0. Turns out this was not the reason I had errors. Instead I needed to fix the driver file because it mentioned parts I was not using and didnt match the name of the driver. I commented out a few lines and uncommented the lines that matched the actual names from the driver. It reports not having a compatible Controller prior to that and worked fine following that. However, the tech toys modifications stopped other graphic apps from compiling so you need to do a diff comparison to figure out changes necessary to newer libraries.

Once the lines were commented out I compiled, uploaded and launched the app. Success was short. Within a few moments I realized while pressing around on the touch screen calibrating the corners and pressing to save the calibration I noticed that the program didnt continue any further. Stepping through a debug I noticed it was at a point waiting for the EEPROM to respond. That’s when it hit me. TechToys sells a development board which happens to include an Atmel SPI EEProm. On the Microchip boards this is found on the graphics board because they expect you to change graphics boards potentially with your own and they supply it on their graphics board.  For TechToys it’s on their development board and not with the graphics boards.

Upon removing the microchip boards I thus no longer have an EEPROM. Upon playing around I found that pressing in the upper right corner instead of calibrating results in the board eventually skipped the write and reload of the calibration and jumped to the home page though I had issues reproducing this reliably. Ultimately just to test it working I ended up triggering buttons about 2/3 of the way from the bottom to trigger the lower buttons and then gradually moving up until it selected another item.  The various graphical items displayed and I managed to get some of the apps to launch though not be able to control them very well.  All that mattered to me is it technically worked as wired.

From what I can see there is an acceptable write speed to the LCD for setting up a coffee roaster control screen but I will need to test further once I can store the configuration data and switch to the original roaster program on the larger screen. I’m thinking I should actually be able to store this to a file on a SD memory stick instead of an EEPRom. Both are SPI but will require a different process to read/write but there’s been others who have done so without much issue into a config.ini file.

Ordering…7 inch LCD using SSD1963 graphics board.

By | | , , ,
2 Comments

So I’ve decided that the regular Microchip development kit LCD touch screen it comes with is fine for watching results on but ultimately it stinks if I need to interact with the roaster at all.  The only way I’ll get away from this is to order a kit with a 7 inch LCD using SSD1963 graphics controllers.  Why?  One of the issues is really that I would need to interrupt the normal processing and switch control back and forth between various screens.  The PIC would then need to keep tracking the updates and logging them in the background but drawing anything I missed when I eventually go back to the other screen.  This would need to take place regardless if I did leave the screen during a roast but I’d rather keep an eye on everything while I’m changing things in a different portion of the roast control screens.

So to do this I’m attempting to use an SSD1963 graphic controller chip to squeeze a little bit more resolution out of things and going to send it to a 7″ touch screen module that I have on order.  I know there are plenty of projects out there that have demoed a 7 inch touch screen and other 640×480 and 800×480 LCD outputs driven by a PIC32.  MOST of them people keep trying to run video or turn the thing into a full resolution JPEG slideshow.

Everyone pretty much goes on and on about how a PIC32 can’t run much screen and it takes too much time to draw the screens.  Those that tend to say these things keep trying to get the PIC32 to stream video from somewhere which it is not the right kind of system to try that on.  When it involves only drawing graphs and buttons and text responses on the screen the system seems to run just fine in my opinion.  The way the graphics library seems to work these sort of updates are drawn in small sections.  It tells it to go to this position and draw text.  Go here and draw a line.  Go over there and put a dot.

My hope is that once I manage to convert a driver that works with the graphics library and get this thing up and running I can plan out which areas of the screen to update and find an acceptable balance and end up just spreading things out and enabling a few controls so that when I’m reviewing past information and configuring the upcoming roast it shows more resolution and then when it runs live it uses only what it can produce quickly on the screen.

I also think I need to start considering what sort of enclosure I need to use for mounting some prototype stuff into so I don’t have a pile of circuit boards spread out on the counter.  I’ll be needing to use some high voltage stuff soon so it’s safer to firmly mount connectors to a board and then safely mount a circuit board in a way that those ends won’t accidentally be bumped into.  I’m not sure where to begin with.  Obviously I’ll need to find something that I can purchase in single quantities.

FYI I’ve taken a tiny break…

By | | , , , , ,
Leave a comment

So as some of you may have guessed with the gaps between postings I have way too many hobbies.  One of them includes aquariums.  I only do freshwater stuff but I do more than “a goldfish in a bowl”.  Really I mainly focus on plants, shrimp, and a few not really extreme fish that are deemed compatible with the shrimp.  The plants need lots of light to make them grow which is why most people can’t keep aquarium plants alive.  The shrimp pick at the base of the plants pulling away the dead parts and look cool.

Several months ago I had some setbacks with some shrimp and some illnesses that came in with them.  I’ve decided to start over and build a setup that is designed to keep all of the conditions very solid that was hard to do in the “nano tank” that I had been using.  This resulted in ordering a new tank that came with a matching size stand that was unfinished.  I had to sand, finish, and assemble a stand and I’ve been throwing together a bunch of automated controllers that monitoring a variety of probes and adjust things…. not much different than controlling conditions in a coffee roaster.  Eventually I’ll be building my own control system for it and I’ll be selling off the existing control system that I’m installing just to get it running.

There is obviously value in “get it done now” vs building it yourself.  There is always a cost to results ratio that needs met to justify buying something or doing it yourself.  I think a lot of the coffee roasting world in the DIY arena operates in this world.  For people who cannot do it themselves and insist on programmability etc there are 800-900 dollar roaster systems.  For everyone else there is 150-500 dollar roasting setups.  Finally for those that want to make a 900 dollar roasting system on their own there’s Arduino and other micro controllers and the $9.99 Poppery roaster to the $200 random brand entry level roaster.

Anyway, I’m at a stage with the roaster that I need to hook up relays to cycle the heating systems on and off.  I’m probably going to order a second SR500 base from a site I found on the internet to take apart completely and splice these relays into it for the microcontroller to cycle.  I’m pondering the 3 stages of heat from the selector switch and actually cycling the power to the heater element.  I need to check some voltage readings from inside the roaster once I take it apart and decide if I want my controller sending signals in place of the switch to vary the desired heat status or just control the heater.  It might be easier to try controlling the fan speed first from my controller and then come back to the heater later.

For the moment I need to finish the fish tank stuff.  This weekend I’m trying to finish the under tank plumbing and then get the tank up on the stand.  The tank is an 18x18x18 25 gallon glass tank (no plastic, only a silicone seal between the glass).  I’m using a Neptune System Apex Controller underneath and am running all the sensors into the plumbing underneath.  The light on top is a 70 watt Metal Halide and the I’ve got CO2 gas bubbled into the plumbing based on the pH.  The entire thing gets logged and can be graphed onto a device web page.  I’m using an Eheim Ecco canister filter and running the output through a UV sterilizer, inline heater, and the CO2 reactor.  Later (once I get the right fittings) I’m mounting a IceProbe chiller inline through some plumbing as well.  I need to modify it with different fans to push air from inside the enclosure through the heat sink and then vent it out of the tank rather than blowing air down onto the heat sink.  The fan is pretty noisy so I’ll be replacing it with fans used to make super silent computer vent fans and running a series of small ones along the sides blowing inward and one large one up top to suck outward that will pass through the base enclosure wall.

I’m kind of discouraged in the coffee world right now.  Mainly I’ve been waiting for a good Ethiopian coffee to come in but this year has not been a good year for coffee.  I’m trying to figure out what else I want to try as my “base” coffee for the ongoing roasting experiments.  I really need to have a base to compare one roast to the next as I adjust the programming on the controller rather than having different beans roast after roast.  I just havent found anything I want to drink week after week while I work out the kinks.

More logging… and floating math.

By | | , , , , , , ,
Leave a comment

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.

FreshRoast SR500 Wattage

By | | , ,
Leave a comment

Earlier in the blog I posted photos showing the circuit boards inside the roaster that were labeled 1000W.  The roaster was reported as being 1500W and it’s a pretty major deal to be 1000W vs 1500W.  After looking back at the blog and some of the things I’ve worked with and struggled it made me wonder more about the wattages used by the SR500.  Additionally it seems there are a lot of people that come to this blog looking for information about how many watts the SR500 is.

In the interest of providing accurate information I went out and got a device for measuring wattage drawn by a device.  Upon plugging it in I discovered that the SR500 draws .8 Watts in “idle” mode.  For comparison a coffee pot I had here with only an Off/Timer/On toggle button and a button to let you change the clock and a tiny little LCD you can’t even REALLY see except when trying to look at it to program the start brew time was drawing 1.2-1.5 watts.  When I turned on  the coffee pot it went to around 1460-1470 watts.

Back to the coffee roaster the manufacturer reported it as 1500watts.  Looking at the circuit board it seemed to show 1000W on one of the labels.  Turns out it is indeed 1500 watts when running full force as described.  I have no idea why the circuit board reports 1000 watts.  I started thinking maybe there is something with the electronics and mainly the fan that would suck up a significant amount of wattage while it was turned on.  Knowing the model of processor inside the circuit and the other parts there was not a lot of electric being consumed.  This was proven when looking at the cool cycle.  First let’s start with the typical roast numbers.

Starting we have .8 Watts  in a sort of standby mode waiting for the controls to turn the roast on. [Edit 4/14/11 – The meter in a sort of standby of its own with nothing plugged into it runs about .5 watts.  This means the roaster in standby probably consumes something more like .3 watts.]  Once I turned on power it lurched upward and for many of the settings hovered +/-  one to five watts one way or the other from the following numbers:

Fan / Heat / Wattage Reported

Low / Low / 1420
Med / Low / 1475
High / Low / 1500
Low / Med / 1420
Med / Med / 1475
High / Med / 1508
Low / High / 1420
Med / High / 1475
High / High / 1505 to 1520

The wattages slowly ticked up and down without seeming to be connected too heavily to anything in particular that was going on.  This was measured WITHOUT the roasting chamber in place allowing the roaster to simply run full force.  When I have more time I’ll run a regular roast through and see if there is any significant peak points where the numbers differ much fluctuating during the roast and if there is a pattern to any of it.  This leads to cooling.

Cooling for all intents and purposes is the roaster running with all electronics EXCEPT for the heater.  This is particularly interesting because the amounts that the wattage changes is not necessarily reflected on each of the tiers for the fan/heater combo.

High Fan / Cool / 182 watts
Med Fan / Cool / 148 watts
Low Fan / Cool / 107 watts

As you can see the wattage of the roaster is pretty reasonable to be called 1500 watts.  You cannot say that the HEATER is 1500 watts….  but it IS a 1500+ watt device like most other items advertised that way.  Why the internal parts are labeled 1000w I cannot imagine.  My guess is there may have been an earlier design that reused the same circuit board to control things and it just needed a stronger heater element.

The roaster appears to not vary the heat outside of the full power to the heater element and then it turns off when the LOW/MED/HI threshold is met.  I expect to see the wattage go from 1400-1500ish down to the 140-180 range every time the heater cycles the way this looks.

For those looking for an update on SD memory I am pleased to say that I found the problems with the SD memory wiring that were actually conflicting with more pins than I knew.  I also found a couple other places that were conflicting randomly that I had odd symptoms that I had not traced yet.  How did I do this?  I blew up the datasheet pin diagram from 8.5 x 11 to 3 feet by around 2 feet something after color coding a few of the pin types and then systematically crossing out a few pins that I have no control over which ones are used because they either HAVE TO be used due to existing circuit boards on the development kit or else there are so many other pins being used in a “set” that I cannot use that function.  Examples would be if you needed to use UART1 TX/RX.  These are on pins RF2 and RF8.  ALSO living on these pins are SDI and SDO #3.  Obviously if you use UART 1 those pins are tied up and now you cannot use SPI (SDI/SDO) set number 3.

Once I cross those functions off the list it makes it soooo much easier to find all the other functions that I need to place or can place in other locations.  I’m gradually transferring these items into a schematic building power supplies and VGA interfaces etc onto them.  I’m beginning to get closer and closer to having created a full schematic for the entire project up to this point.  I can convert that schematic into a circuit board layout and after a few more rounds of tests and seeing if I can figure out a few more sensors I’ll probably be ready to test out a preliminary test board that will become a “condensed” development platform.  This will let me test 1) building circuit boards, 2) knowing that I’m close to getting a functional system, and 3) having a lot less junk on my desk.

I’ve now managed to get time and date stamp and temperature readings sending to a CSV file that loads easily into Excel that I can apply a chart to.  Next up — Roasting something to get real temperature numbers.

Writing to SD memory…

By | | , , , , , , ,
Leave a comment

Soo… the latest update… I had wired in the SD memory stick reader and had been testing it separate from the main roaster program. I’ve found having a “dedicated” programs for a particular sensor with the rest of the sensors and displays attached but not initialized has resulted in easier testing and troubleshooting.  Occasionally it works right away but other times conflicts come up.  Generally once I have manage to confirm it works without the other code running I at least have a reasonable assumption that it may actually work and is wired properly.   Since I’m pretty new to the whole wiring these things up it’s a pretty good idea to test my wiring out.  So far I’ve actually done pretty well reading enough about each sensor to figure out what I need to make it work the first time.  If I go too long not getting it to work I try to disconnect everything else and run it by itself which usually helps me identify conflicting pin usage that I didn’t see initially.

So far I tend to find issues with the LCD interface / graphic chip / memory config chip to conflict with a particular pin here and there.  If it works without the LCD boards attached it obviously has a much smaller number of pins from the new sensor to try to find a conflict with. Usually by the time I isolate the LCD away from the system I’ve managed to throw together code that works within minutes of starting things up again.
My last success with the SD memory was short lived because I discovered there were pins that I had not noticed on the SSD1926 that apparently do something even though I’m in 8 bit mode instead of 16 bit.  They seem to have ended up being connected when I was trying to check my Write Protect and Card Detect pins.   It took probably about 3 hours of looking at the schematic for the graphics board assembly to figure out which wires (15 minutes) it was and then find some (the rest of the time) that were not being used already.   Since I am using 8 bit communication instead of  the 16 bit mode I would have assumed them to be “dormant” and potentially available.   Not quite sure what is going on with that since I have not obtained the data sheet for the SSD1926 chip yet.

I had an unexpected guest show up early in the week and didnt get much time to work on this.  After making a few adjustments to the wiring I got it up and writing to the SD with the LCD attached.  This weekend I got it loaded inside the Coffee Roaster programming.  I ran into a few initialization problems that resulted in a momentary “stream of gibberish” coming out the UART port that I was using for watching status of some of the code I was troubleshooting with in a terminal window.  It seemed as if the system had a baud rate to the com port of the computer that suddenly “shifted” up and down a few times in the middle of the machine starting up and then returned to normal. After I removed some of the apparently duplicate excess code from the init area it resumed working normally.

I then had to move the “write to SD” down through the startup past the time and date retrieval area.  This results in accurate time/date stamps on the file now being written to the SD memory card.  I then began to modify the SD demo write into a command that builds the buffer data using a sprintf template inserting date and time on a line separated by commas and a few sections (with 0.00’s right now) for sensor data as well.  I’m going to bundle the write commands up into a function so that I can insert it into roaster loop as a external function.  Every time it samples the temperatures and other future sensors it will shove it into the call to the “write to SD” function where it will get formatted and append to the file it created during the initialization of a new roast loop.

As I said, I havent had much time to work on it this past week but probably tonight and tomorrow I’ll get significantly closer to figuring that part out and probably test running the roaster with nothing in it just to get some temperaturee logging as it goes up/down for a few seconds and then exit the roast to close it to check the accuracy. Then when I’m sure that’s working I’ll try to do a regular roast with it out in the kitchen and see if I can get “good numbers” that I can post.

If I can get that working then the next step will be to get a “file management” function going to come up with names of files to make them unique and maybe let me load the data into the system to preview it on a graph on the PIC32 LCD as well as delete files. THEN I get to start figuring out how to program it to control things by itself based on my normal data.  😀

Close Encounters of the SD Memory Kind…

By | | , , ,
1 Comment

Sooo generally annoyed with sensors I decide to take a different direction, SD Memory.  Fun things happen with SD Memory.  You rip one open and you’ll usually find a single little flash memory chip and some other chip in front of it.  I haven’t identified the “guts” yet but that’s not really important.  What’s important is that generally you talk to that little flash memory chip using SPI (usually unless you wanna pay for licensing fees to use the direct SDIO method it sounds like.  Crazy licensing costs = faster SD Memory.  Free method = slow access.  If you need every bit of speed you can get then you’ll likely need that expensive method.  If you can buffer up data internally and then write it out later then you’ll use the SPI method).  This is likely to be preferred to have a built in memory chip to buffer items up just like working with a document on your computer.  It then isn’t until you save the file that it then transfers it from the internal memory out to the SD memory for transportation to the PC.

There is not much to it other than that except for having some structures that issue a few reads and writes to find a spot on the chip and make a file name and fill the file full of stuff.  That portion is the “FAT” portion that makes you able to read it on a computer etc.  This slows things down considerably in an SPI Method.  Apparently people have experimented with reading/writing to the SD memory chip with no

After a few days of poking at it and moving a couple wires around I’ve now managed to get it to make a file… and I can see that file on a PC.  The problem is I can’t get it to put anything INSIDE the file.   It just keeps getting stuck on the portion where it’s expanding the size of the file…  further it’s been quite a pain that any SD memory sample code out there is written focused on the 3xx series PIC32 and from looking at the various forums my issues are pretty common.  Most people get the 3xx series working just fine.  Many people seem to get files with no contents on 6xx and 7xx series PIC32s.

The only published successful people I’ve found seem to be commercial product developers who don’t want to share any code samples clarifying how to handle the failures properly.  The only exception I’ve found was some code modified by the user bmorse on mypic32.com.    His code appears to be modified to work specifically at 60mhz and using SPI2 which worked for initial testing to ensure I had things wired properly.   I needed to put a pull up resistor on the CS and the DO of SD to SDI2 on PIC32 and everything started working properly.

I’m now trying to isolate the portion of the code that affects the timing to increase the system speed back up to 80 mhz and scale the SPI back down again.   To assist in this department I’ve procured a FT232 UART to USB Com port chip on a breakout board from SparkFun.   This board is commonly used to take the UART output of various text and data from the running PIC and interact with it in the terminal window instead of watching the raw data on the debug watch.  I’ve learned that the watch window often “messes up” a lot of SPI states by constantly inspecting the information.  The idea is that it interrupts the normal state (data waiting etc) flags due to having read it for the watch window  blocking the rest of the circuit from detecting it.

I’ve also obtained a DS3234 clock.  At time time I only have the one I2C DS1307 clock and I may wish to eliminate the I2C bus unless I come up with something else that needs it.  Even if I use I2C elsewhere it seems as if 5 volt I2C is more of a rarity meaning I can’t really use that bus for other things anyway.

User interface work.

By | | , , , , , , ,
Leave a comment

So at this point I’ve gotten annoyed with the other temperature sensor and decided I might as well move ahead with the functional part of the roaster.  This means the first thing I needed to do is draw a main menu for options.

Main Menu

As you can see this lists Manual and Auto Roast.  My plan is to make it where the first option simply gives you a few readings and then lets you “drive” by sliding the controls around.   I would make it log the information of what you set things to and what you got back from the system and perhaps let you “store” the settings to play them again as a profile.  That is where the next phase comes in, the Auto Roast.

I expect Auto Roast to be a portion of the system that would let you choose to either A) load a previous profile, or B) let the roaster pretty much run itself using a basic model of “drying” at a lower temperature for the first few minutes at a high fan speed and then begin to lower the fan speed and raise the temperature responding based on the time into the roast vs the temperature.  Expectations of driving first crack and the end of the roast based on a desired result would vary how it would work.  I’d anticipate some sort of yes/no 1/2/3/4 etc sort of question and answer series immediately before the roast activates.  While it would be mostly automatic you can step in at any time and seize control of a particular setting.

Main roasting screen

At this time the roasting system only monitors.  I have yet to work on actually connecting it directly to any of the controls on the roaster.  This will come later when there are more and better controls implemented.  Currently it simply shows bean temperature in Fahrenheit.  I will add the option to switch the temperatures on the Settings option from the main menu.  It also has a slighly inaccurate timer.  It seems to gain a second or two over the system clock in the corner every 40-60 seconds.  I need to work on the prioritization of the interrupts in the system and implement a series of if/else and/or case statements where I can service temperature, screen updates, and time tracking and use all of those checks as part of the delays required reading various sensors etc.  For example if it takes 100ns to service one sensor telling it to read a temperature or something but I need to wait 100ns to do another function then I can initiate the read request, perform the other function, and then return at the end to pickup the temperature result.  Some functions are more critical so they will take priority over other functions.  Those functions will take place on a tighter schedule while the other functions will “squeeze in” anywhere they can and take place based on a “true/false” tracking of whether they’ve run recently.  Once everything has run then everything will reset and things will start looping again.

The roast control system also has a series of buttons down the bottom for returning to the main menu, adding or removing time from the timer, as well as buttons for heat and fan control.  I expect to put more sensor readings as time goes on to display on the empty space.  I’m hoping to get the fan and heat controls to pop up over top of the roasting screen, allow adjustments, and then drop back to the bottom “tray”.

So far the SHT15 is winning. It mocks me.

By | |
Leave a comment

My next step I wanted to try out some ambient measurements to add to the history of roasts once I get things logging. I’ve seen plenty of roast master setups having humidity and temperature readings around the area they work in and figured…. might be a good idea of something to try logging at the beginning of the roasts. One of the options was the SHT15 sensor. After about a day of poking around and reading data sheets I got it wired in and read a bunch of PIC16 and PIC18 and one PIC24 set of source code written for the SHT15. Upon looking through their code I can’t even begin to understand why most of that code even works because many times it does NOT conform to the requirements as stated in the data sheet. I’m pretty certain that most of that code got it to work “by accident” rather than by design.

As of now I’ve managed to get the SHT15 to report temperature readings reliably back to back in a loop for several dozen hits but could not get humidity to respond during that run. It responded appropriately when warmth was applied in the area of the sensor and then….. I rebooted the circuit after inserting a set of formulas to convert the reading to a real temperature number. I figured it was working and I didnt want to have to manually do the math. Upon starting it I found it immediately went back to 65535. I did an undo, recompile, and program and nada. Still 65535.

Wheeeeee

I’m pretty sure this is some sort of timing issue but it could be an issue with the pull up resistors too I suppose. I need to read more about the voltage I’m using vs the resistors on the bus and the length of wiring involved as well. I may be getting some sort of interference with all the gear on the desk right now and there were a few forum conversations talking about the length of wiring being somewhat sensitive for some people.