Tag Archives: electronics

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.

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.  😀

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”.

MAX6675 with PIC32MX795F512L

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

As I mentioned earlier I’m using the USB Starter Kit II, the PIC32 Expansion Board, the SSD1926 PicTail Plus board, and a Truly 3.2″ 320×240 LCD display board to develop the roaster system. This has resulted in some “fun” trying to figure out which pins are really going where on the board and the PicTail cards that you can build your own circuits on. Occasionally some of the pins are not exactly labeled the right way or else there are a few pins that are wired together on the circuit boards making you unable to use one of the pins that are wired together or in some cases both cannot be used etc.

I’ve been working through various demos and trying to understand some of the libraries and still trying to identify all of the pins on the expansion board that are already attached to the LCD / graphics chip. So far I have not found any that involved the SPI1 Pins, which I’m sure is incorrect now.

I’ve now managed to get real time readings to occur while using SPI2 instead of SPI1. Originally I was using pins B2 (SS1), C4 (SDI1) , and D10 (SCK1). to communicate with the MAX6675 thermocouple. When the system launched it would begin to read temperatures from those pins properly but only while in animate debug mode. As soon as I would let it run in full speed to get to a break point later it would be partially or completely erroneous in the received readings. I’ve now switched it to the SPI2 pins and using G9 (SCK1), and G7 (SDI1). (The MAX6675 does not use the SDO pins since it only transmits readings and does not receive using SPI data)

I’m now opening the SPI port to communicate with the MAX6675 using 16bit word mode:
OpenSPI2(SPI_MODE16_ON | SPI_SMP_ON | SPI_CKE_ON | MASTER_ENABLE_ON | CLK_POL_ACTIVE_HIGH | SEC_PRESCAL_8_1 | PRI_PRESCAL_16_1, SPI_ENABLE);

[After I clean up all the “Dead code” that I’ve been testing various things with I’ll insert some additional SPI stuff HERE]

Which appears to work properly talking to the MAX6675. Further I’ve gotten the text to display on the screen of the current temperature where it runs a rolling average of the last 3 readings updating the screen after each additional reading. At the moment it flips on one of the starter kit’s LEDs based on the temperature when it needs to heat and turns it off when it’s reached a preset temperature.

I need to work more on getting the LCD display to show the activity that is going on in terms of heating/cooling and run a timer to begin estimating what stage the roast would be in based on temperatures and time-wise. Additionally I’ll need to figure out how to graph the temperature across the bottom of the screen too. I’m thinking screen real estate is somewhat limited so I may want to upgrade the LCD to the wider board to move some of the data to the side leaving a larger graph area to represent the roast curves.

I’m not dead… And finally having SPI progress.

By | | , , , , ,
Leave a comment

So with all the holidays and other things going on I didnt get to spend much time working on the roaster. In addition due to the complications with the SPI not working all this time I wasn’t feeling very motivated.

Last night after spending hours over many days reading blogs of people who regularly participate on Microchip’s forums I finally managed to get the MAX6675 to start transmitting actual temperature data to the PIC32. I’m not entirely sure why it works now but need to emphasize that it only works OUTSIDE my prototype roaster programming. In other words it is literally a single purpose program that reads a single temperature value from the MAX6675 chip.

It seemed almost reliable by reporting similar temperatures most of the time for each reading for air temperatures and then goes up when I press the thermocouple against my hand and then drops significantly when I press it against a cold soda can. There was a rare spike to 120 plus degrees here and there but infrequently. Otherwise the temperatures appear to be pretty close.

When I return to my roaster program there appears to be something significantly wrong with the speed it communicates with a potential “shift” to the left. If I drop off several of the rightmost (0) bits the resulting numbers are what they are supposed to be with a random wrong bit mixed in. About 60% of the time the results are completely erroneous no matter what. I’m pretty sure now that there is a setting somewhere affecting the communication speed that I’ve lost track of that is disrupting things.

I’ve found that adding some longer delays around the CS changes seems to make the temperatures returned significantly more stable eliminating the 100 plus degree spikes and need to try them out in the roaster code too.

At the sound of the beep the current time is….

By | | , , ,
Leave a comment

So this weekend I consulted with another person on the Microchip.com Forums page about their I2C routines they had mentioned. After reading through their routines I looked at mine and found pretty much nothing different logistically except that he was accessing the bits directly rather than through the Peripheral Library. I scratched my head and modified the open command to use direct bits for the options I was enabling and suddenly noticed I had data in one of the slots with no collisions while running in regular mode that was always empty previously.

I had set the system up with a series of breakpoints to test I2C at full speed in one location and then break at the beginning of another set of data requests after closing everything out and resetting it. I always failed the first request and then worked in the second ones ONLY while they were in Debug mode. The second requests were always empty like the first one when they were allowed to run full speed / non debug. With this piece of success I then duplicated the change into my main routine instead of the initial test one and suddenly I had a full array of time and date filled and running properly.

While getting ready to blog this I was thinking of a title to use. The first thing that came to mind was the “Time Lady” that you could get the current time by dialing one of those XXX-1212 numbers in the phone book. She would say something like “At the sound of the beep the current time is 3:00…..exactly” or something like that. Upon googling to find the phrase she used I found this article. At the tone the time lady will be gone

Unfortunately it sounds like technology has caught up with the Time Lady. She was always there ready to serve us. RIP Time Lady.

Next up figuring out why my time in the CORNER of the LCD (not the memory slot being fed to the PIC32 RTCC) is showing funny things. Apparently there is some sort of Binary/Decimal/Hex/Whatever craziness going on. I need to find all the references and place Decimal to Binary conversions and hooking up SPI sensors.