LinkMeter v2 Homebrew BBQ Controller - Part 1


 
Status
Not open for further replies.
Well I'm truly bummed.

I just updated the HM and LM to the latest and my LCD quit working. It isn't garbled, it is just squares. It looks the same with or without the shifter register. Maybe my shift register happened to burn up at the exact same time?

Did the latest code change the LCD timings at all?

thanks,
dave
 
Originally posted by D Peart:
Did the latest code change the LCD timings at all?
If you use the built-in mechanism for updating ("From online repository") you might notice where you went wrong. You want target "v3.1" which is snapshots/trunk/heatermeter.cpp.hexA. The non-A version is for v3.2+ with the different LCD mechanism.


This will be clearer later once I have a better process that builds and labels the variants, but I'm guessing that's where you went astray.
 
Yep that was it. I guess that is what I get for doing it the way I was used to. I wondered what the two different names meant, but didn't see it in the Wiki.

I like this update method way better and I'm back up and running!

thanks you so much,
dave

Originally posted by Bryan Mayland:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by D Peart:
Did the latest code change the LCD timings at all?
If you use the built-in mechanism for updating ("From online repository") you might notice where you went wrong. You want target "v3.1" which is snapshots/trunk/heatermeter.cpp.hexA. The non-A version is for v3.2+ with the different LCD mechanism.


This will be clearer later once I have a better process that builds and labels the variants, but I'm guessing that's where you went astray. </div></BLOCKQUOTE>
 
Originally posted by Andrew Meimann:
OK, thanks. I assume I'll need to insulate between the boards if they are stacked.

I used a ribbon cable to connect my board to the serial port on the router, and just put a piece of gaffer's tape on the bottom of the board so it wouldn't short anything.
 
Originally posted by Kyle Christensen:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by Andrew Meimann:
Does the HeaterMeter board fit inside a WRT54G version 2?

You ought to be able to shoehorn it into pretty much any wrt router. </div></BLOCKQUOTE>

The Linkmeter board is a very tough board to fit in non-GL routers. Mainly because the large n-channel transistors stick straight up and you can't bend them down because there is no room.

I redesigned the Linkmeter board to fit into my WRT54G v3. The design is available through a link a couple pages back. I removed the LCD part of the board so it is a minimalist version of the original board. I haven't tested the final version of the board because I don't get them until Friday.

I was thinking of redesigning the full Linkmeter v3.2 board with LCD to fit into these other routers. I haven't done that because Bryan is working on transitioning to the Raspberry Pi platform. It would only take a couple of hours to redesign the board so I am still thinking I might do that for fun. It seems silly to try to stuff these boards in when you can just design a board that fits.
 
The WRT54G version 4 is the same board layout as the WRT54GL, so it is a good alternative if you can't get your hands on the GL or if you want a lower cost option.
 
Originally posted by Dave S (GeoDave):
Mainly because the large n-channel transistors stick straight up and you can't bend them down because there is no room.
The hell you say! Actually the PCB was designed in such a way that they should be bent down:

If you mount them thusly, the tallest thing on the board is the ATmega chip.

That said, the board was also designed to also be usable in a standalone HeaterMeter configuration (the circle cutout and 2.1mm barrel jack) and also optionally include the all the RFM12 stuff. It could be maybe 20% smaller without those concessions. The Dorkbot board house is really good too, and I haven't seen any mistakes (dead traces, drill misses, botched polygon pours) come out of there so you don't have to be too careful with your designs. Figuring out how EAGLE works takes longer than reorganizing the thing though.
 
Originally posted by Bryan Mayland:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by Dave S (GeoDave):
Mainly because the large n-channel transistors stick straight up and you can't bend them down because there is no room.
The hell you say! Actually the PCB was designed in such a way that they should be bent down:

If you mount them thusly, the tallest thing on the board is the ATmega chip.

That said, the board was also designed to also be usable in a standalone HeaterMeter configuration (the circle cutout and 2.1mm barrel jack) and also optionally include the all the RFM12 stuff. It could be maybe 20% smaller without those concessions. The Dorkbot board house is really good too, and I haven't seen any mistakes (dead traces, drill misses, botched polygon pours) come out of there so you don't have to be too careful with your designs. Figuring out how EAGLE works takes longer than reorganizing the thing though. </div></BLOCKQUOTE>

My bad yo. I don't have a v3.2 so I was thinking in terms of the v3.1. Nice change.

So if you want put the Linmeter board in the GS v2 then you could just put a straight female header pin where the right angle router female header goes. Then it can just sit upside down. No need for tape. I believe the ground is on the right most pin on the GS v2 and on the right on the v3.2 board if you mount it upside down. This should work so long as the transistor doesn't hang over the board too much and interfere with the case closing.
 
Bryan,

Just got back to looking at this along with how to fix my blower causing errors on the serial port. I think I have the blower mostly fixed by putting a huge capacitor across the blower pins. I now only get an error sometimes when I turn the blower on and off, but when it is running I get no errors.

I still cannot set anything temp, toggle the lid, or change a probe name via the web interface. I did the web console and here is what I get:

[10:02:59.797] GET http://192.168.1.141/luci/;sto...473a90/lm/set?sp=100 [HTTP/1.1 200 OK 437ms]

and

--
[10:06:55.393] GET http://192.168.1.141/luci/;sto...90/lm/set?pn1=Test+1 [HTTP/1.1 200 OK 422ms]

I also tried lmclient:
root@OpenWrt:/# lmclient LMST,sp,100
nil bind

Neither changed the HM, it stayed at 225.

dave

Originally posted by Bryan Mayland:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by D Peart:
I use FireFox as well and cannot get the LM to update the HM. I get exactly what you describe so instead I telnet into HM and use the echo command to get it to work. The echo way has always worked for me, but it also reaffirmed that it is LM not my serial connection that is having issue.
I can't figure out how this *doesn't* work. I test on Chrome and Firefox and then get it to passably work in IE before I commit it. Try turning on the web console (Tools -> Web Developer -> Web Console) then doing one of the sets and see what comes out in the log.

Did you say lmclient doesn't work either? (This should set the setpoint to 100)
lmclient LMST,sp,100

I mean I can't even fathom how that wouldn't work if the echo does. If at any point you want to let me SSH into that thing and see if I can figure it out, I'd be happy to. </div></BLOCKQUOTE>
 
Originally posted by D Peart:
I also tried lmclient:
root@OpenWrt:/# lmclient LMST,sp,100
nil bind
Oh man what the heck? If the bind() call fails that means that something wonky is going on with the unix domain socket. That's... crazy bizarre. Is the OpenWrt firmware more recent than 3 months ago? I fixed a bug in UNIX sockets not binding properly back then which may or may not be relevant.
 
Is this what you're looking for?

root@OpenWrt:/# uname -a
Linux OpenWrt 3.0.3 #6 Sat Nov 19 09:15:20 EST 2011 mips GNU/Linux

Not sure if this helps, but I just did this:
sysupgrade http://capnbry.net/linkmeter/s...rcm47xx-squashfs.trx

and it didn't help.

dave

Originally posted by Bryan Mayland:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by D Peart:
I also tried lmclient:
root@OpenWrt:/# lmclient LMST,sp,100
nil bind
Oh man what the heck? If the bind() call fails that means that something wonky is going on with the unix domain socket. That's... crazy bizarre. Is the OpenWrt firmware more recent than 3 months ago? I fixed a bug in UNIX sockets not binding properly back then which may or may not be relevant. </div></BLOCKQUOTE>
 
Originally posted by D Peart:
root@OpenWrt:/# uname -a
Linux OpenWrt 3.0.3 #6 Sat Nov 19 09:15:20 EST 2011 mips GNU/Linux
Yeah you should be on 3.0.12. You may want to try doing a backup of your settings and do a .bin upgrade over tftp then restore the settings backup. It may be a bit of a pain but think of how easy it will be if you don't have to ssh in to change settings all the time!
 
Well I screwed something up.

I tried to flash through the web interface using the trx file and it says it worked, but now I get the fast flashing power led and slow flashing DMZ led, which says the flash was bad.

I then tried to tftp the .bin file and get a bad code message. I'm reading that means it didn't like the bin file. Ideas?

I'm using a WRT54GS v1.

thanks,
dave

Originally posted by Bryan Mayland:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by D Peart:
root@OpenWrt:/# uname -a
Linux OpenWrt 3.0.3 #6 Sat Nov 19 09:15:20 EST 2011 mips GNU/Linux
Yeah you should be on 3.0.12. You may want to try doing a backup of your settings and do a .bin upgrade over tftp then restore the settings backup. It may be a bit of a pain but think of how easy it will be if you don't have to ssh in to change settings all the time! </div></BLOCKQUOTE>
 
Originally posted by D Peart:
I tried to flash through the web interface using the trx file and it says it worked, but now I get the fast flashing power led and slow flashing DMZ led, which says the flash was bad.

I then tried to tftp the .bin file and get a bad code message. I'm reading that means it didn't like the bin file. Ideas?

I'm using a WRT54GS v1.
It appears the GS needs a different header. Here, grab the GS version from my home machine:
http://home.capnbry.net:22674/wrt/
 
That worked!

thanks for saving the day

I can now control everything from the web page however, when I change the set point it changes my temperture readings to C, the only way to get it back is to go to configuration and set the set point with F, then I get my F back.

Can we get it to not change the units when setting the set point from the webpage?

thanks,
dave

Originally posted by Bryan Mayland:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by D Peart:
I tried to flash through the web interface using the trx file and it says it worked, but now I get the fast flashing power led and slow flashing DMZ led, which says the flash was bad.

I then tried to tftp the .bin file and get a bad code message. I'm reading that means it didn't like the bin file. Ideas?

I'm using a WRT54GS v1.
It appears the GS needs a different header. Here, grab the GS version from my home machine:
http://home.capnbry.net:22674/wrt/ </div></BLOCKQUOTE>
 
I can't declare complete victory yet.

After letting it run for a while, and playing with the settings. It stopped responding. When I run lmclient LMST,sp,175F I now get an OK response, so that looks better.

However, it doesn't change. I can change it on the HM without issue, and that reflects on the webpage properly. It appears that I can receive all the information from HM to LM without issue.

I can telnet in and run lmclient commands and get OK responses, but it doesn't change anything.

I reflashed HM from the web gui, but that made no difference.

I'm running:
HeaterMeter Information Version 20120226A

root@OpenWrt:/# uname -a
Linux OpenWrt 3.0.12 #8 Wed Feb 15 15:43:22 EST 2012 mips GNU/Linux

Let me know what you'd like me to try next.

thanks again,
dave
 
Originally posted by D Peart:
I can now control everything from the web page however, when I change the set point it changes my temperture readings to C, the only way to get it back is to go to configuration and set the set point with F, then I get my F back.
Oops little bug I added there when I added resistance mode. Fixed.

As for your unresponsiveness /shrug does setting it directly from serial work? It seems like something's getting messed up in transmission somehow but I've never seen it happen.
 
Status
Not open for further replies.

 

Back
Top