HeaterMeter + LinkSys WiFi Router = LinkMeter


 
Originally posted by RJ Riememsnider:
For those of you that have rolled your own solution and have put a bootloader on your Atmel, how is this done (FTDI, JTAG)? Do you think there is any likelyhood that I could get the arduino bootloader on the echo-6 device? I know the chances that the display uses a shift register and that the buttons are compatible are Zero but for $17 I may just get one to see.
Click to expand...
I usually do it using the ICSP header and a USBtinyISP, which is incredibly slow. I've also done it using another AVR as the SPI host attached to the destination chip's ICSP header. ICSP is just Power/Ground/Reset and 3 SPI Data lines so it isn't all that tough to do.

The ATmega32 he says is in it isn't the same as the ATmeg328 we use, so I'm not sure how to compile for it. If it uses a full 4-bit LCD control though, it would be trivial to change HeaterMeter to use that instead. The larger problem would be building the firmware properly for that target I think. Not that I think it would be terribly difficult, but you may have to do it outside the Arduino IDE.
 
Thanks Bryan, I didn't even pick up on the 32 vs 328, I was thinking arduino used the 32. I may still pick one up though for $17.

Will keep you posted if I do.
 
I ran across this and thought it might be a replacement for the SD card - this will work as long as as connected to the internet.

Arduino to Google Docs spreadsheet

I haven't introduced myself, but I've been hacking away at LinkMeter off and on for a few weeks. I almost have the HeaterMeter part working, I have a moderndevice LCD module working with a 4X20 LCD (uses a single Analog pin) and I just need to finish soldering my jacks for the probes and the blower relay. I have a wrt54GL sitting in a closet as back-up unit.

Dave
 
Originally posted by Ed Pinnell:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">For those of you that have rolled your own solution and have put a bootloader on your Atmel, how is this done (FTDI, JTAG)?
Click to expand...
RJ, keep in mind the primary function of the bootloader is to allow us to program the ATMega chip or Arduino over the serial port without an external programmer. When you use the ICSP method of programming, unless you are using it to transfer a bootloader program, any other program you transfer will overwrite the bootloader...but think about it for a minute. If you have an external programmer, why do you need a bootloader, unless you have a need to program the chip via the serial port (UART) at some point.

But to answer your question, there is a tutorial about using an Arduino to program an ATMega on a breadboard. That's about as easy as any I've seen and could easily be extended to the ATMega32 on the echo-6.

I didn't read the whole article, but was the author able to re-program the chip? If not, it could be that the fuses are set to prevent this. Most OEMs are pretty protective of their intellectual property and secure it against those that would try to reverse engineer their products. I think, if it were me, I would be inclined to scrap the entire PCB and make another one to replace it using the ATMega328. </div></BLOCKQUOTE>

Thanks Ed, my original thinking was that I would need a new bootloader to make this arduino compatible but the more I think about it that is wrong. The IDE compiles the code. Thanks for the sanity check, now to see about compiling for an atmel32 vs the 328.
 
Originally posted by John Bostwick:
you must be talking about a new program build for the router.
Click to expand...
Oh yeah. I'm talking about the new LinkMeter process. My router keeps dying and I can't tell why.

I thought I had fixed the problem (I was writing a debug log that would fill RAM and then die) but it seems even without that, I'm right on the cusp of running out of memory when logged in via SSH and launching 4 web server processes. I haven't been able to get it to crash since, but once is enough for me to know that it can still crash.

EDIT: Well it appears to be that browsers are so non-HTTP/1.1 compliant these days that they open up a crapton of connections to the server. The spec says "no more than 2 simultaneous connections to a single serveR". Latest Google Chrome opens 4, Firefox opens up to FIFTEEN. You try to open 15 connections to a poor little WRT54GL which only has about 2MB of free memory, the router fork()s all the child processess, they start mucking about in LUA and need their own private copies of the memory manager and BAM you run out of memory.

Florping browsers, in their attempts to be "the world's fastest browser" are killing my poor LinkMeter!
 
Chrome is hard-coded in the source it seems, Firefox you can change it in about:config but it affects all sites. I may try forcing the server to output HTTP/1.0 responses and see if maybe that helps.

If not I have a couple other options like letting the socket's accept() call wait until there's a thread available. Basically cap the number of processes the server will spawn at once. That wouldn't be impossible. It currently limits the count at 10 processes but A) just kills the requests that are beyond that B) never gets to 10 before crashing the router.

The other option is to limit the amount of memory used by each request. The server fork()s a new process to handle each request. The problem being that each one now gets its own copy of the "lua state", including the memory manager which is quite large (500k-1MB). That's not terrible because the child processes will share the parent's memory pages until they modify them. So when one of the child processes decides it wants to garbage collect it basically is going to swell in actual memory usage dramatically even though the garbage collector is theoretically trying to decrease memory usage.

So to get around that I can try handling all the requests from a single process and implement the serving in lua coroutines. I'm not sure how well that will work performance-wise or if it is even possible without a large rewrite of the lucid. We'll see!
 
Originally posted by Ed Pinnell:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content"> Posted June 17, 2011 04:28 PM
Oh sweet checking my kernel log on my LM I see that the kernel has been killing processes because it was running out of memory. That's not good.
Click to expand...
It appears you've been pushing the memory limit for at least a month now. I wonder if John's lock-up problems are memory related instead of MOSFET-related? I can't figure out why the MOSFET would cause a lock-up.

If you don't access the LinkMeter from a browser, say like on an overnight cook, would you still run the risk of running out of memory at some point? Would accessing the LinkMeter from a cell phone (an EVO, I think John said) open up the same crapton of connections?

Also, since I upgraded my memory to 32MB, does that mean that I am immune to these out-of-memory lock-ups, or does it just prolong the process? </div></BLOCKQUOTE>

I have to believe my lock up was from the mosfet, last weekend, before changing the mosfet in the morning with the bigger fan, it locked up.

After, I changed it out I have had no problems at all with the fan and I tried to lock it up by turning it on and off(fan). So, I do have to say the mosfet was the problem.
 
Originally posted by Ed Pinnell:
It appears you've been pushing the memory limit for at least a month now. I wonder if John's lock-up problems are memory related instead of MOSFET-related? I can't figure out why the MOSFET would cause a lock-up.

If you don't access the LinkMeter from a browser, say like on an overnight cook, would you still run the risk of running out of memory at some point? Would accessing the LinkMeter from a cell phone (an EVO, I think John said) open up the same crapton of connections?

Also, since I upgraded my memory to 32MB, does that mean that I am immune to these out-of-memory lock-ups, or does it just prolong the process?
Click to expand...
I actually hadn't seen the oomkiller (what Linux calls the out-of-memory emergency process) since then. It is possible that some web requests were failing when their clients ran out of memory. I don't actively check it unless I am doing something else on the router. It would be still alive every time I tried to connect to it, up until it got "slashdotted" that Friday a couple weeks ago. The problem has started since I switched the system around to (conceptually) fork the HTTP process from the LinkMeter process.

HeaterMeter has still never locked up for me, it is just the router which runs out of memory so it will stop monitoring it. The HeaterMeter always keeps running, it is its own thing, and the router around it is just there to write down whatever HeaterMeter says. If noone is listening, HM doesn't care, it just does its job. It is a nice sort of redundancy built in with this two part setup.

I can't tell how many connections a cell phone opens up but I assume it is probably around 4 as well. I don't have the tools to be able to determine how they work without going through a bunch of effort (ugh EFFORT!). 32MB routers should be fine. It is just "close" right now. Each child process can allocate up to 1.2MB each. Some of that should hopefully be shared with the parent but no more than ~500KB. I've started a dialog with the LuCI developers regarding the prudence of fork()ing a child process with a dirty LUA state. We'll see if we can come up with a better process.
 
and to add a little more about my lock ups. The router continued to monitor the heatermeter but the screen was lock on whatever it last received from the Arduino. So if I logged into the webpage at 4pm and my heatermeter had locked up at 3pm, the screen would start at 30 seconds before 3pm and then go to 3pm and stop. on the heatermeter, the lcd would not respond to any button press, the blower would be still blowing at whatever the last command was at the time of the lock-up. hitting the reset button would fix it until the next lock-up.
 
Originally posted by Ed Pinnell:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content"> I have to believe my lock up was from the mosfet, last weekend, before changing the mosfet in the morning with the bigger fan, it locked up.
Click to expand...
Ok, was it the router that locked up or the HeaterMeter board?...ie, could you access the router admin page? </div></BLOCKQUOTE>

Yeah, i could access the router without any problems, i could even log in and try to change the tempeture and thats when I would know it was locked, because it would not except the change and go back to the setting it last received from the heatermeter.
 
Originally posted by Ed Pinnell:
And John, that time when all you had to do was touch the ATMega chip to cause it or the display to start working, did that go away with the MOSFET change?
Click to expand...

im not sure as I had not that problem in a while now, I do have a delay in the lcd of 500ms, to help with my Optrix LCD. I have been wanting to remove that delay to see it would be ok without.

When i plug in the router, I have to wait for the router to finish its setup and as soon as all the lights light up on the router then a second later the LCD turns on and everything is fine. I have not had to touch the #2 pin since hooking up the router to it.

Now when the router is not connected then yes I have to touch the pin to turn it on.
 
Originally posted by Ed Pinnell:
So Bryan, is this just another bump in the road of life or something more serious? Would the SD card mod be of any help? I think the memory mod would be out of the question for some/most/all, and only the very earliest models of the LinkSys came with 32MB.
Click to expand...
It is just something else to work out. There's a lot of "try it and see" that comes from not knowing what the limitations of the system are.

I've made some changes to the thread counts and I haven't been able to lock it up all day, with some sporadic refreshing.

Your homework (everyone) is to see if you can lock this up:
EDIT (test over now working on mem leak)
 
Originally posted by Ed Pinnell:
EDIT: Aw, shucks. It looks like they are all starting to reload...slowly...
Click to expand...
Oop! I think you killed it. The web server isn't running any more but I have like 1000 sockets half-connected on my side. Well I guess it proves it can handle 1 user (with 15 connections) without crashing.

EDIT: Ok who has the script pulling a page every second? Apparently it can not handle that either.
 
After a very short discussion with one of the LuCI developers, it looks like my collect-before-fork idea may be rolled back into their trunk. With this change, my instrumentation is showing that each child process inherits on average 300KB less (380KB vs 680KB) LUA state. Overall response times seem unchanged overall. Serving a call() page that just returns a short string still takes ~310ms ±20ms from accept() to data coming out.

I grabbed a screen capture of a LUA state memory usage graph (shown in the bright green). The oscillating pattern is before the change, going from 470KB to 890KB and the flat part a the end is after the change where it hovers around 380KB-390KB.
https://picasaweb.google.com/l...lUv8?feat=directlink

I think I can check this off as being practically solved for now. Unless someone hits the thing with multiple clients at once it shouldn't happen.

EDIT: Definitely looks like there's a small memory leak somewhere. Need to track that down now.
 
I'll tell ya John, it is actually confusing when I see someone's screenshot because I can't tell if it is me or not. Blows my mind for some reason.
 
Hello,

this Hack a Day - Arduino PID seems promising
icon_smile.gif
Any plans to integrate?

Dve
 
Originally posted by Dave Landry:
this Hack a Day - Arduino PID seems promising
icon_smile.gif
Any plans to integrate?
Click to expand...
I'd consider it, but we already do 6 out of 7 of his things.
1. Monotonic sample time - PID interval is fixed at the sample rate of the probes, which is 8 times over 2 seconds.

2. Derivative kick - I must have misread how PID controllers work because I implemented this in my first version. Our derivative is based on delta T instead of delta Error.

3. Prescaled integral - We convert integral to control each cycle. Also in the first version I believe, because that what I thought you were supposed to do.

4. Windup elimination - Also was in first version. Stole this idea from Bob's original code.

5. Manual Mode - Yup got this too 100% of pitfalls covered as offfffff I dunno, like December I think.

6. Init - Is really just #5 for idiots.

7. Reverse control - Not implemented I guess if you wanted to make a controller that cooled a grill this would be useful but not in our use case.

So there ya go, all the good stuff is already built in. Yay me! Although this would have been helpful back when I was getting my head around it over a year ago.

EDIT: I was thinking in the car today that we already do #3, and we do. He calls it "on the fly tuning" but in my mind it is a "pre-scaled integral term" so I thought they were different.
 
Still working on this memory leak thing. It is taking a while because it takes a pretty long time before it leaks enough to become noticeable. I also fixed a bug with the graphs from the archive starting with an incorrect auto scale. Workaround until this gets pushed is to just set the scale manually when viewing archived graphs.

I did have some wobbles going on on the controller. I think the Kd might be too high but it still stayed with in 5 degrees of target.
butt-20110724.png
 
Hi all,

I just started messing around with this project. I got interested in the 4-position switch and came up with this:

Switch_Board.jpg


Designed with eagle and sent off to Dorkbot PCB. I got three for $11, I think. It's 1.5" square. I probably could get it down to 1x1 by moving around the resistors. I'm thinking about working on the main board too.

Bryan, any idea how much the resistor values can vary?
 
You must log in or register to reply here.

 

Back
Top