Originally posted by Ed Pinnell:
RJ, what are your thoughts? Netduino, router, RTC? Use a Heatermeter with a ToughBook?
There are a lot of variables here and I think a lot of goals as well. What you are looking for is different than what I am looking for so in order to satisfy all it increases cost and complexity. That said I think there are some fundamental truths here that we can all agree on which I humbly think we should use as a basis for the ongoing design.
I like many things about the Netduino/Netduino Plus. It is more robust, has more IO more powerful, is native 3.3vTTL serial, has SD capability, arguably a better dev environment, and a better IP stack. Unfortunately I don't think it is quite ready for prime time, there is still a lot of alpha code and not nearly as may options as the arduino platform.
I think the ideal solution is the WRT router to host the IP stack, manage the data, and act as a case. I can't think of a more cost effective solution with robust wireless and TCPIP support. Thanks for the great idea Ed! This would be interfaced via serial to an arduino that handles the temp monitors, the LCD, and blower/electric element control. I like the idea of an RTC mainly because I think it simplifies data collection/storage for those that would want to have a historical record of cooks. Besides, it's $10 and easily made an optional component.
That said, I think we should consider what are the crucial features and make sure that are implemented on the Arduino UNO/duemilanove board. Since the newer Mega 2560 is pin compatible it could support all those functions but also have plenty of IO for those want to be able to add more options like fancier displays, more temp probes, humidity probes, alert buzzers/strobes, low fuel warnings, etc. The mega is really overkill but I just don't think the UNO/duemilanove is up to the task and there isn't a step in between.
Last we have graphing. This isn't crucial for me but I want it really really bad. My fear in having the router render the images is the effect on cpu and possibly taking away from time sensitive operations like reading serial data. It may not even be an issue but that's the only real caveat I can think of other than just being generally slow. The way I see it is we have 3 options. Router renders on demand, router renders in background and serves on demand, or router supplies raw data to browser and client renders on demand. Each has pros and cons, I would say to render on the client but my client will be an android phone or ipod touch and I'm not sure what the speed will be. This may also be a non-issue with faster hardware. E2100L routers can be had in the $60 range and have much larger memory and a faster processor. I look forward to seeing how this turns out.
Thanks again to Ed and Bryan for really getting this project moving forward. Your work and talents are greatly appreciated. I look forward to replies and contradictions as I feel an open discourse helps everyone (especially me) learn.
RJ
</div></BLOCKQUOTE>