Devils Advocate: Mega2560 or MB/DB combo

I've posted a thread with the Mega2560 concept, and after letting it perk for a few days, I have a question for everyone:

Is the problem with the approach the Mega2560, or is it the fact that there is a Motherboard/Daughterboard combination? We've got a couple of respondents on the thread, but not an overwhelming response with 580 views as of today http://tvwbb.com/showthread.php?43312-Heatermeter-on-Mega2650.

Let me pose an alternate approach that doesn't involve the Mega2560 for the sake of a healthy/constructive argument:

What if we used the 328P chip instead of the Mega, and move to a motherboard/daughterboard architecture? This would permit us to segregate functions between a main motherboard (MB) HM4 and a daughterboard (DB) HM4.

The Main HM4 would benefit by no longer having to interface with any ancillary equipment. No more probes or fans, freeing up some IO for other things, like a second rfm12b for another pit, etc. Power consumption goes down as well. I really like this - especially the possibility of a completely wireless HM. The code in this module would do several things:

• Interact with rPI
• Drive menu operations
• Figure out "what to do"
• Communicate "what to do" to the daughterboard
• Get status of what is happening from daughterboard

The DB HM4 would benefit by no longer having to support the LCD, button or alarm. This additional IO could be used for servos, thermocouples, etc. The logic here could be customized, depending on how clearly it was coded and documented - we could move towards a code base here that was easily modified for customized needs. For example, we could handle HI temp digital probes in this codebase, leaving the MB codebase untouched.

The code in this module would do several things:

• get commands "what to do" from the MB
• interpret and do those commands "how to do it -> doing it"
• get feedback (temperature from Maverick, or high temp thermocouples, or hell, IR temps (lets dream).
• Communicate "what is happening" back to the MB

As an added bonus designing cheap, purpose-built daughterboards for specific applications would be easy, so long as they follow a set of common pinout rules.

We could offer two different configurations - a MB/DB combination that you could stack in one package/case, and/or one that was connected via RJ45 or wireless connection.

The downside: to be completely honest, it's a complete re-write of Bryan's 328P code. The question is - are the benefits large enough to justify this change? I totally understand if Bryan just does a complete thumbs down to the discussion, but I'm putting it out for that public exposure.

Anyhow, I'm posting this for argument's sake, in the hopes of trying to figure out what would make the HM4 group happy.

Let me know your thoughts? I understand if this seems outlandish to group members, but i wanted to stimulate a good group discussion.

Cheers,

Dave

To take the design even further: throw out the MB altogether and use the rPi to do all of its functions.

I love the idea of adding more inputs/outputs, but I hate the idea of motherboards/daughterboards and RJ45 connected anything. I was hoping for more of a single unit box with inputs on one edge and outputs on another. Basically replicating the current architecture but with a beefed up chip. Do you necessarily need the Atmega board along with a pi and a heatermeter shield or could you simply update the heatermeter to use a more powerful chip? Sort of analogous to what the reprap gen7 guys did.

Bryan,

I think that is the real direction to go in - interface the peripherals directly with the Rpi and communicate wirelessly to the IO board at the appliance being controlled.

I like it.

Simpler, cheaper and more flexible. All together it's a win-win.

There should be enough GPIO to support button + LCD + Buzzer + rfm12b.

That setup would rock.

Ok, I'll bite. What's involved with this change?

Cheers,

Dave

Bryan Mayland said:

To take the design even further: throw out the MB altogether and use the rPi to do all of its functions.

Click to expand...

M Miller said:

Bryan,

I think that is the real direction to go in - interface the peripherals directly with the Rpi and communicate wirelessly to the IO board at the appliance being controlled.

I like it.

Simpler, cheaper and more flexible. All together it's a win-win.

There should be enough GPIO to support button + LCD + Buzzer + rfm12b.

That setup would rock.

Click to expand...

I will second Matt.

On a big cookout, I can have as many as four different grills going.

If the rPi can be serving multiple wireless daughterboard clients, each one can have it's own power source (solar, battery, wall wart) depending on its draw, multiple inputs (wired or wireless), and whatever it wants for outputs (SSR, Fan, Servo, ....).

4 grills, sous vide and beer fridge monitor on their own daughterboards within a one stop monitoring shop without having to build a full rPi/Heatermeter for every device.

With this, can we pretty please get shairport??? (Or at least shutdown.)

Best,
Phillip

Why not just make up some 2.5mm extension cables? I doubt you'd see any real drop in resistance if you made up a few 10-20 foot extensions.

Steve, IDK, maybe it's just me, but even if it worked, having 20 foot cables running from my BBQ to wherever the HM is doesn't sound nearly as good as wireless to me...

Phillip, Shairport is an app to play music right? On my HM the audio plug of the rPi is pretty well buried into the shift register IC chip, I don't think it could be used while in this position? I guess you could pull it off the board, or tap onto the solder joints to make an extension jack for audio, but it's not gonna be easy as "pi"...
EDIT: I guess if the hardware platform changes the obstruction of the audio jack may go away as well....

Since Bryan has reworked the HM to support simultaneous use of the fan and servo I have cooled my jets on the Mega2560 project a bit, cause it seems the HM can do everything I want right now pretty much. One thing that would still be very attractive to me is if the Mega2560 HM would have a wireless connection from daughter board at the grill so I can leave the HM inside while I cook. Sometimes I get the food off the grill and by the time I'm done eating I forget all about the HM and leave it outside. I generally have a cover over it that will stop the rain, but sun and heat can play hell on the HM the next morning...

I know I mentioned this before.... If this new Mega2560 platform were wireless and running on a rechargeable battery that would just be awesome. You could have it in hand when setting up your pit(s), then walk with it into shelter where you could plug it into the wall for long cooks or to charge the battery when needed. I also like the idea of being able to control several pits. If this new Mega2560 platform would have these features I would jump right on that bandwagon in a minute....

Shairport will never* happen. It won't work even if you could get the audio jack plugged in, because the openwrt kernel doesn't have audio support, there's also no userland audio manager like ALSA or pulseaudio. Your next hurdle would be that the headphone jack only puts out enough power to drive headphones, not speakers, so you'd also need powered speakers to have the audio be at more than a whisper. Interesting concept but I think it to be rather impractical in practice. Not to mention the massive software changes that would take.

Regarding a wireless Mega2560: The existing platform _is wireless_. Not only in one way, wifi, with any device with wifi being able to monitor and control it, but also with the RF chip in it. One could use RF probes (lmremote) and have it be displayed on any ITPlus weather station, or cut the cord entirely and build the lmremote with output support because the HeaterMeter already sends output % to anyone listening. I'll build a prototype to show how to do it, but will be a few weeks because I need parts and I also have family vacation starting Friday.

Multiple pits, all I can see is probe wires and blower connections like a spiderweb...

Bryan,
When I did something similar, and used lmremote to run my servo wirelessly for some reason I thought I couldn't plug a pit probe into it. Am I just remembering incorrectly?

thanks
dave

It's supposed to work, although I haven't tried it in over a year.

Well, to me wireless is only useful if the probes AND the fan/servo can be (connected to the HM via) wireless. I've heard about the RF wireless probes, but this is the first I have heard about the possibility of wireless output (wireless control of fan and servo). If this can be done I would really dig it....

My vision is a completely wireless HM control box, with built in rechargeable battery. The probes, fan and servo would connect to a remote "daughter board" at the grill that would be powered by a wall wart. (or 12V battery if you need full wireless)

As for multiple pits, if the wireless system detailed above could be configured to use different channels you could put a daughter board on each pit set to a different channel. The wires at the pit(s) would run neatly to their respective daughter boards and the HM would be completely wireless.

IDK the ins and outs of the RF system, haven't used it (yet), so I am not sure if the multi-channel thing is possible? Or perhaps the daughter board could be WIFI connected and communicate with the HM through the network? To save cost on a multiple pit scenario, only one daughter board could be WIFI connected and the daughter boards on the other pits could connect to the main WIFI connected daughter board to get their marching orders. Connection between daughter boards could be either wired or RF wireless. Personally I think wired would be fine, if I have multiple pits running they are most likely gonna be all located in the same place. Perhaps the main daughter board at the pit could use the shield design and you would just add another shield for each pit? On second thought, a daughter board at each pit to connect the probes, fan and servo to that has just one wire linking it to the main daughter board would probably be the best scenario....

It seems the above scenario might work well with the idea to get rid of the main HM board altogether and run just the rPi in the main HM box. You would have to interface the display and button (or other input device) directly with the rPi, and the rest of the functions (temp sensing/output control) could be handled out at the daughter board. This would reduce the power draw in the main HM box making it easier to power via battery, the display could be programmed to "sleep" to save more power, while a DC wall wart is powering the fan/servo and other hardware out at the pit...

If I was driving this ship that's the direction I would steer her...

As a side benefit, with this scenario you would basically have a wireless rPi in a box with a display and input device connected. This box could easily do double duty as for instance a media center or whatever else you can dream up to do with a rPi by simply swapping the SD card...

Yeah the lmremote handles up to 4 probes (theoretically) and can do blower servo output (if the code is added). The disadvantage is that the blower min / max speed, and the servo min / max position have to be compiled into the lmclient code. No configuration goes through the wireless interface, only status data. That makes it not very user friendly. There's very little chance of that being changed. It isn't as easy as saying "hey change your configuration to this" because RF packet formats aren't like a serial connection. The other giant problem with that system is that you can't get up and walk away with the HeaterMeter even if it is wireless-- it's the brains. If you walk out of RF range (which you can't tell without the web interface) the Pit's going to keep at whatever output it is at until you get back in range. This distance can be anywhere from 100ft to 20ft depending on walls and things.

Different channels are theoretically possible although the current code is hardcoded to be compatible with LaCrosse ITPlus transmitters/receivers. That gets around the HeaterMeter problem but you'd still need one Pi per HeaterMeter because there's only one serial port in a Pi. Even if it could connect, the linkmeterd and web UI would need massive amounts of rewriting to support multiple devices at the same time. I wouldn't even want to see what that web interface would look like. You couldn't put all the data on the same screen, so you'd need to only be looking at one device at a time. If you're only looking at one device at a time, then there's no point in making them all go to one Pi. One pi per device, one browser tab per pi, you can't get any better than that.

You can't "get rid of" the HeaterMeter board either. You can, but throw out nearly every line of code and write it again from scratch to run on the Pi. At that point, design a new system. There's no point in trying to shoehorn the old system into a completely rewritten system. And because you're now created completely different hardware, it's a completely new project. The power usage of the Pi grossly outweighs the HeaterMeter. HeaterMeter pulls MAX 50mA, the Pi model B pulls up to 700mA + wifi = up to 1200mA. Even with a giant chunky battery you're not going to keep that powered through a whole cook and it doesn't even have a graph on it. Get a super-cheap android 7" or 5" tablet for $60-70 and control it all with touchscreen. A lot more impressive looking than a 20x4 character display.

Well, wouldn't a Mega2560 based controller be a major departure from the HM as we know it to start with? The 2560 has USB, so I assume it can support a WIFI connection? I guess all the "thinking" could just be done out at the 2560 and there would be no need for the rPi, and a tablet device or smart phone could be used as the controller as you suggest.

I'm kinda surprised at the power consumption data you presented, do you include the draw of the fan and/or servo in your estimate of what the HM board draws?

The USB port on the 2560 is a client port, not a host port, so it can't host a USB device such as a WiFi adapter.

The power estimates I listed are for the HeaterMeter board only. The standard fan adds 150mA to that if I remember correctly. The servo I have no idea, up to 1A I think if it needs it to hold, but a lot lower if there's nothing providing resistance. The HeaterMeter itself is roughly 10mA for the CPU, about 5 for each LED that's lit, 10mA for the LCD, then about 10-30mA for backlight depending on the brightness. The RF module adds about 25mA when transmitting, 15mA when listening.

The LMRemote code, with just 1 probe and transmitting every 10 seconds pulls under 1mA. A single AA battery boosted up to 3.3V can last up to months running continuously, in fact in my original testing it lasted over 6 months before I took it apart.

Speaking of, just placed an OSH Park order for one of these. LMRemote board with fan and servo support (with both 2.5mm barrel and phone jack). I wanted to test some new ideas I had for the blower output. Regular phone cables they sell at my grocery store are only 4 conductor, so in the interest of making it easiest to connect, I redesigned the blower section so maybe it will work with a common ground to the servo. The down side is you can't push as much power through it, but I think 1A shouldn't be a problem in practice. (Assuming the design itself works at all)

Bryan Mayland said:

The USB port on the 2560 is a client port, not a host port, so it can't host a USB device such as a WiFi adapter.

The power estimates I listed are for the HeaterMeter board only. The standard fan adds 150mA to that if I remember correctly. The servo I have no idea, up to 1A I think if it needs it to hold, but a lot lower if there's nothing providing resistance. The HeaterMeter itself is roughly 10mA for the CPU, about 5 for each LED that's lit, 10mA for the LCD, then about 10-30mA for backlight depending on the brightness. The RF module adds about 25mA when transmitting, 15mA when listening.

The LMRemote code, with just 1 probe and transmitting every 10 seconds pulls under 1mA. A single AA battery boosted up to 3.3V can last up to months running continuously, in fact in my original testing it lasted over 6 months before I took it apart.

Speaking of, just placed an OSH Park order for one of these. LMRemote board with fan and servo support (with both 2.5mm barrel and phone jack). I wanted to test some new ideas I had for the blower output. Regular phone cables they sell at my grocery store are only 4 conductor, so in the interest of making it easiest to connect, I redesigned the blower section so maybe it will work with a common ground to the servo. The down side is you can't push as much power through it, but I think 1A shouldn't be a problem in practice. (Assuming the design itself works at all)

Click to expand...

Bryan, if this board handles all of the I/O, can the main HM board connected to the pi be reduced to just a 328p, radio transmitter/receiver, button, and LCD to create a smaller form factor?

Yeah although I'm not sure how much space you'll end up saving:
5 resistors
1 diode
1 elec capacitor
1 MOSFET

The physical jacks take up a ton of space though, so I suppose if they're gone you'll have a lot more space to work with. You also won't be constrained to making a board as wide as the rPi form factor, because none of the jacks need to poke through the side.

You also can use the analog pins as digital to work the LCD without the shift register... but then you'd lose the LEDs... so yeah code changes at that point.

Bryan Mayland said:

Yeah although I'm not sure how much space you'll end up saving:
5 resistors
1 diode
1 elec capacitor
1 MOSFET

The physical jacks take up a ton of space though, so I suppose if they're gone you'll have a lot more space to work with. You also won't be constrained to making a board as wide as the rPi form factor, because none of the jacks need to poke through the side.

You also can use the analog pins as digital to work the LCD without the shift register... but then you'd lose the LEDs... so yeah code changes at that point.

Click to expand...

It would be cool to design a board keeping in mind layout for a case so that there is minimal expansion over the dimensions of the pi itself. You could then make a compact case for the main unit and smaller satellite cases for the daughter boards. The satellite cases could probably be made to withstand most weather conditions with proper mounting. I would probably make one to mount permanently on the underside of my grill table and then keep the main unit inside where it is safe.

The LCD is gigantic when compared to the size of the rPi, it takes up most of all the space. If you put through-hole components under the LCD, you'd better hope you got them right the first time, because it is a pain to desolder 16 pins to fix any mistakes you've made. That's why the HeaterMeter v4 extends down rather than using all that primo space over the Pi. I've you're going surface mount then that point is moot.

I feel I would be remiss to not bring this up again and again, the RF wireless approach is incredibly dangerous. The part that controls your grill is a slave and all the logic you're walking away with. If you get too far away, the slave will stop working.

Bryan Mayland said:

I feel I would be remiss to not bring this up again and again, the RF wireless approach is incredibly dangerous. The part that controls your grill is a slave and all the logic you're walking away with. If you get too far away, the slave will stop working.

Click to expand...

Valid point.