HeaterMeter + LinkSys WiFi Router = LinkMeter


 
Well, I have my Heatermeter in the case and all screwed down and it works Beutifully
icon_cool.gif


I tried to use a transistor on Pin 11 (backlight) I got a NTE123AP as NTE said the one Bryan recommend was a subsitute for it.

I did a pin 11 > 1k> B
E> GRD
C> LCD
no back light

Did i need to add a +5 volt to the C gate like what was done with the fan and the IRL510 but ommit the diode and cap.

Even with my smaller display, could not get a light. So, I just clipped the GRD connection and shorted out the Transistor until i can figure it out a bit more. im using the small display until then. I still have the 1 k resister on the pin 11 and the backlight looks to be about half as bright. but to me its ok for now.

Im just glad its usuable as is.

I plug in the router and the screen just shows one line of squares, and when the router finishes its setup the LCD finally turns on without having to touch the ATMEGA, which is good.

Sunday after work, I am going to smoke up some ATB's and some baby back ribs
icon_cool.gif


Thanks ED and Bryan for all that you have taught me, This has been fun and kinda expensive on my end but well worth it, in the end.

If my Dad were alive now, I think he would be proud at what I had made, as he was a worked with electronics, building Calculators and what not in the 70's.
 
Will we soon be needing the SD card on the OpenWRT build or or is it just for storage in the unforeseeable future.

I still have not put it on the V.2 router, Might do it next weekend.
 
The connection to your LCD for the backlight: the transistor collector connects to the LCD backlight ground and 5V is wired up separately to the 5V backlight input. So +5V goes to pin 15, then a wire from pin 16 to the transistor collector. Your emitter and base sound right. This is a "low side driver" so we're basically strobing the ground on and off and leaving 5V connected to the LCD at all times.

The SD card I doubt will ever be needed for anything besides storage, unless there's some massive thing we come up with that's going to eat a ton of space on the router. I figure we have at least 300kb left at a minimum. So if you don't want to do the SD card mod, you don't have to. I only did it to see if it worked for me.
 
I've pushed up some new code that adds a section to the OpenWrt admin pages for LinkMeter. From here there's not much to do yet but you can use the "Raw set" page for a semi-convenient way to set parameters. For example if you want to set the backlight to 10 you just put lb=10 in the box and hit "Set". You can put multiple items in if you want too, like to zero out all the probe offsets: po0=0&po1=0&po2=0&po3=0. There's also a page to update the AVR firmware from a HEX file that's a little nicer than the old fw.html.

On the back end, the CGI script for pulling the graph data is now rewritten into LUA and as a bonus it only transfers the valid data now instead of dumping the whole database for every call. The amount of data transferred is also much smaller because of the new float format
Old: 1309625820: 7.5000000000e+01 7.7700000000e+01 nan 1.4752000000e+02 9.1206666667e+01 0.0000000000e+00
New: 1309625820: 75 77.7 nan 147.52 91.206667 0

You can upgrade your linkmeter package from the webui /admin/system/packages and just put in the url of the LinkMeter package
 
Originally posted by Bryan Mayland:
The connection to your LCD for the backlight: the transistor collector connects to the LCD backlight ground and 5V is wired up separately to the 5V backlight input. So +5V goes to pin 15, then a wire from pin 16 to the transistor collector. Your emitter and base sound right. This is a "low side driver" so we're basically strobing the ground on and off and leaving 5V connected to the LCD at all times.

Ahhh, ok Now that makes sense, I have another transistor, I will give it a try tomorrow.

That NTE crap is expensive. I was looking at Jameco catalog and it had the B337 transistors for .07( order 10) and the NTE123AP was like a 1.30 per. The only good thing I dont have to pay for shipping and I can get stuff quickly.
 
Originally posted by John Bostwick:
I do have a question about boot time. mine Boots up in about 2 minutes it seems and when the router connects starts getting info from the Arduino, the lcd then turns on. Is that how it usually turns on I don't understand why the ATMega does not Turn on sooner then the router. Does the Router send a command to the controller to turn on?
Yeah that is pretty odd. When it boots, the Arduino should start immediately at power on (in less than 1s). Once the router boots and the linkmeter daemon is started it does send some commands to the Arduino to get the current configuration (probe names, rf maps, pid parameters, etc). Now here's the interesting part: when the router is sending data to the AVR, it is toggling pin 2. Didn't you say that if you touch pin 2 the LCD starts working? Sounds like the same thing.

Still doesn't sound right, mine turns on immediately and I haven't ever gotten gibberish on the screen. I run my linkmeter continuously and walk by it all the time and never see anything unexpected.

Was the temperature varying when the lid mode was activating or was it just doing it for no reason? Could possibly be a false button detection. As far as manual lid mode, it will auto-cancel lid mode if the temperature exceeds the setpoint is that what you were seeing? If not it could be, again, a false button detection. I'm off to start my grill too! Brisket hooooooo
 
Yeah, it will turn on after the router connects to the network. I only see the Atmega and Lcd turn on as soon as the power was turned on, when the power is turned off for a fraction of a second, like unplugging the cord to the router and then plugging it back in within a second. Thats why i think its capacitance related.

When I first got the heatermeter working, it would turn on as soon as power was applied. I know its not the Atmega because i changed to a new one when my lcd burned out pin 11 and it too had the same delay.

As long as it turns on, i really don't care when it turns on, as long as it does, lol.



The LCD screen has perplexed me to no end. The smaller display, does not get the gibberish either, only on the Optrex. Doing some Googling, I did find a thread for a 20x4 optrex that the person had the same gibberish problem and said all that was needed was to add a delay(http://blog.workingsi.com/2010/09/trick-to-get-20x4-optrex-display.html).

Monday morning all I was getting was gibberish and then I started it up outside on the smoker and it had the gibberish, unplugged the power and plugged it back in and it was fine from that point on.

Im looking for other displays in that size to try, found one and i might order it to see if it works better.
 
Interesting about the display delay. There are already a handful of delays in the LCD initialization routines. 50ms before the first command it sent, then 4.5ms, then 0.15ms. The the display is cleared (+2ms delay), and the cursor is homed (+2ms delay). Maybe one of those needs to be longer.

If you want to try the delay thing, we don't have an explicit init() so you can just add the delay(500) to the first line of setup() in the pde file.
 
Great work all.
Bryan, I downloaded and installed your latest router image and it worked perfectly with no additions.

Ed, back to hardware, are you thinking of offering your boards for sale or should I get ready to build my own? For those that don't use the pre-built arduinos, do you get your Atmels pre-programmed or do it yourself? Im thinking maybe something like the Bare Bones Board from Modern Device.
 
I test a lot of things with the Android browser, because I use either my Nook tablet or my phone to check the temperature a lot. Changing the setpoint is a bit messed up, but it works even if it is a hassle. I'll come up with a better way to do it at some point.

I make some brisket for 4th of July so that meant sitting around staring at the graph for a few hours and I fixed a few gap-inducing bugs, increased the load performance by about 10% and then added some basic archive functionality
p3XLw.png


"Stash" basically means "take the current running database and store it into the archive area". The area below that allows you to view things from the archive without interrupting the current running database. This will get a lot more user friendly over time, with the ability to add keywords and descriptions and annotations once that's in. Also searching and sorting.

There may be an issue loading the page for people who upgrade. I haven't had a chance to test how a configuration upgrade works so I'm not sure how to deal with the fact that there's a new configuration variable. If you get a broken page when you try to load the archive page ('attempt to concatenate a nil value' or something) the workaround is to edit /etc/config/linkmeter and add a line that says "option stashpath /root".
 
Originally posted by Ed Pinnell:
Your last question first: I program them myself, using the STK500 that I bought some years ago. If you have two Arduinos, you can program the bootloader that way, or if you want to solder a pin header on the Arduino Dieciwhatever or Deumajiggy you can bit-bang it as shown here and here. I've done this and it works well but I haven't tried to get it working with the new Optiboot bootloader, and it's a slow process that takes several minutes.
Yeah it is slow as the dickens! I've flashed this way before and it is painful. jcw over at Jeelabs has an isp_repair sketch that supposedly can flash the bootloader and the blink sketch in a few seconds using a similar process.
 
Ok, one little snafu, after I upgraded to the newer linkmeter code, I now have 2 Linkmeter tabs in LuCI. One with and one without the Archive option.
 
I use the Usbtiny and a Uno board to program and for some odd reason i havve to use two different computers(desktop to program Atmega after my laptop does the bootloader)

Byran and Ed
I found a pdf doc on Optrex and been reading it.
When operating in 4 bit mode, data is transferred in two 4 bit operations using data bits DB4 - DB7. DB0 - DB3 are not
used and should be tied low. When using 4 bit mode, data is transferred twice before the instruction cycle is
complete. First the high order nibble is transferred then the low order nibble. The busy flag should only be checked
after both nibbles are transferred.

Before I try this, I wanted to verify that it says to pull the unused data lines to low, GRD, correct. If this is the case then this could be the reason why I am seeing this on this display as the other data line not being used are getting confused and there by giving me the gibberish I see at random times.
 
That is what it says, pull the other lines low. I've never heard that for the other displays but it is certainly is a possibility. We do transfer the 4 bits in two nibbles, but never check the busy flag. That would require a wire for the R/W line, and the ability to ready DB7, which we can only write with the shift register. I'd say try grounding those DB0-3 pins. Who knows it could be something all our displays just tolerate and yours doesn't!

@RJ: Thanks for the report. That's probably due to the fact that I renamed config.lua to admin.lua and now you have two copies. I'll need to figure out why it doesn't remove the old file when upgrading. I would have thought it would uninstall the old package then install the new package as part of the upgrade. Maybe that's not the case? In any case, you can remove
/usr/lib/lua/luci/controller/linkmeter/config.lua
/tmp/luci-indexcache
and that should get rid of the double entries. I appreciate you checking back in, it is hard to tell what is *supposed* to happen when doing all this router programming so hopefully we can locate all the pitfalls and I can code around them.

If you stash your database then go back and refresh the page, does it show up or give you an error?
 
Even more odd is that they're using an NPN transistor on a high side driver which is confusing because I thought PNP transistors were used in that setup. Well the grounding of the extra 4 pins seems like the way to go though.
 
Originally posted by Bryan Mayland:
Even more odd is that they're using an NPN transistor on a high side driver which is confusing because I thought PNP transistors were used in that setup. Well the grounding of the extra 4 pins seems like the way to go though.

Bryan, have you though about any long term linkmeter goals as far as adding additional or different displays? I for one would love a large 7 segment display for temperature, or maybe just the ability to do large text on the existing or a graphical display. Going back through the pages of this thread and the others I see a lot of display related issues. With the removal of the wifi code on the arduino, is there still a decent ammount of available storage for more code?

Just curious.
 

 

Back
Top