The Development Log


 
It's been a while since I've updated but there hasn't been a lot going on. You can thank Matt and Tom for that, as I've been spending most of my time working on my printer, staring at it while it prints, and contributing to some of the 3D printing projects such as OctoPrint. I have been doing some things, very little though.

I've fixed some hair-pulling bugs in the autobackup which would have really gotten your goat if they had gone out into the real world. Sometimes the backup wasn't going, sometimes it was restoring over the running database. Stuff you'd really hate.

I've also found the bug that caused the avrupdate to only be able to go up to 2MHz SPI speed. 4MHz is now possible, which is the theoretical maximum. The slow part of the update is waiting for the avr flash to write though, so it only can really save about 0.1 seconds.
 
Bryan, what ever happened to the work you were doing on the (FLOT?) based mobile UI you had running a while back, did you give up on that? I haven't been firing up my smoker as much as I'd like lately, but having an iPhone friendly version would be pretty sweet. IIRC, the only issue I ran into before was the graph getting a little janky if the orientation of the device changed.
 
I haven't had time for it so there was only the prototype ever made. The home page needs to be refactored into two parts, the code and the view so I don't have to copy-paste code to keep both views in sync. It is kind of a biggie so it just hasn't been done yet. Still on my TODO though!
 
I replaced the fan or servo code last night with fan and servo code so they both can run at the same time. I thought I'd be all clever and have them both use TIMER1 set to 9-bit fast PWM and a 64 prescale, which would give me the same 488Hz the fan has always used but also give 2us resolution on the servo channel. Then I'd simply run the servo first 2.048ms of period, then turn it off for the next 9 giving me a ~perfect 20.48ms servo refresh period. You're a genius!

Yeah well it worked but the code ended up being a little large thanks to 9-bit PWM mode masking the values of OCR1A/B to 9 bits, meaning that to get the PWM to run 100% you'd actually have to have special code to prevent it from turning off (because setting the output to 100% actually sets it to 0% thanks to masks). I'll go through and replace the single timer1 with one timer for each, which ends up being smaller because one pin can use hardware PWM.

Still need to do the webui for it too, but that's pretty easy.
 
Last night and this morning I added the ability to have the fan only come on when the PID output is 100% and an option for the servo to be a simple ON (if >0%) OFF (if 0%) switch. I also finished the webui for the configuration.


Ralph also found a bug that could cause your configuration to become not-what-you-expect if you "Save & Apply" with no changes made. Fixed that.

I've also patched LuCI to allow doing a firmware upgrade through the internets (via URL). Not that downloading the firmware file was so difficult, but two steps is a total pain in the *** right? The ability to not restore the configuration after flash still needs to be done.

I am on the fence about what should be displayed as the "Blower %" in the web UI as well as the LCD output now that there's 3 different numbers. There's the actual PID output 0-100%, the blower speed (0-max), and the servo position (0-100%). I have initially coded it to be blower % because that's what you see now. However this means that you can't ever see what the servo is doing, if your maxfan is < 100% (because the display will clip at your max fan %). This also raises the question of what "manual fan mode" means for the same situation. Are you setting the fan speed? Does it stop at the max %? What does the servo do in that range?

I'm pretty sure I'm going to change it to display and record the PID output, and manual mode will control the output which will then be scaled into the max fan speed and servo position. That way the behaviour is consistent across all 3 values. I might add fan speed as a separate item to the web ui as well.
 
Bryan, I really like these two new "Max Only" settings. If I am understanding what you have done correctly, these settings along with the ability to run the fan and servo at the same time should be a nice improvement. I do like the servo control over the pit on my FauxMado compared to the forced air, Kamado grills are designed for low flow and so pumping air through them with a fan is a bit contrary to the concept. With these settings I can (hopefully?) run the servo damper with my fan on the end of it, set the fan to "Max Only" and the fan will help stoke the pit to temp and then turn off, and will help recover the pit temp after lid is open and then turn off and let the servo take over. Sounds like a nice hybrid of the two systems to me... I'll have to give it a try and report back next time I do some lower temp cooking. This weekend it's gonna be high heat cooking for pizza, I do like the blower for getting the FauxMado up into pizza oven temperatures...
 
I'm "patiently" awaiting the next release that has the servo and fan enabled, any idea when you might be putting that out?

My ping pong valve is working really good, but I do prefer the natural draft method of control with the servo damper. It seems if I can have the fan run when the servo is wide open that would give me the best of both worlds... Is there any chance we could choose at what percent the fan turns on instead of it just coming on at 100%? Seems like that would be useful for tuning certain pits and in some cooking scenarios like high heat cooking where fast recovery is needed...
 
RalphTrimble said:
Is there any chance we could choose at what percent the fan turns on instead of it just coming on at 100%? Seems like that would be useful for tuning certain pits and in some cooking scenarios like high heat cooking where fast recovery is needed...
Click to expand...
No plans for this. In what situation would you need no fan for the first N% but fan for the rest of the of the percentage? From 0% to 50% you want just damper and then from 50% to 100% the blower should also run 50% to 100%? Or should the blower scale from 0% to 100% between 50% to 100%? It's just getting carried away with options. You'd be better off setting other parameters to better suit the situation than adding yet another variable to the equation.
 
Well, my thought was this. I would take my servo damper and connect the fan to the end of it. When the grill needs a lot of heat the damper will open fully (to 100%) and the fan would come on along with the fully open damper. (If I understand what you said you have done already correctly)
So, I was asking, is it possible to make it so you can set the fan to come on at XX% instead of just at 100? This would mainly be helpful for high heat (pizza) cooks where the fire needs lots of air and fast recovery from lid open. Unlike low and slow cooking where it doesn't really matter how long it takes for the grill temp to recover (because the food is going to sit in there for hours), when you cook pizza's the food is in there for just minutes. If it takes minutes for your grill temp to recover from an open lid you are never really cooking at the target temperature, cause the food is coming out before the grill temp can recover. I thought it would be useful to have the ability to turn the fan on a bit before 100% so it will come on early and stay on longer (than just coming on at 100%) to aid in stoking the pit to temp when doing high heat cooking.
As far as what speed the blower turns, doesnt really matter. If it could be set to come on below 100%, say we set 90%, it would be OK if the fan came on at 90% and scaled with the servo percent, or the fan could just come on and blow at 100% speed when it is turned on (even if the damper is open at 90%). Whatever is easiest... If the damper is opening more than 90% the fire clearly needs more air, so the fan could help deliver it.
So the only option I was asking for was instead of having just the "At max only" option for the fan, you could choose to have the fan come on "at XX% and above only " instead of just at 100%.
I haven't been able to use this fan + servo mode yet to test, but I'm thinking the fan may bounce on and off a bit becuase a little bit of stoking from the fan and the vent will back off from 100%, then without the fan blowing it will probably open back up to 100%. So the fan may be going on and off a bit when it would be better if it could just blow continually until the pit is warm enough for the damper to move significantly from 100% rather than just to 99%.
I don't know the ins and outs of what makes this work, so I dont even know if it is possible. I was just thinking about how this might work. I was surprised you came up with the fan + servo option in the first place (something I have always wanted), and figured I would ask, cause it seemed if you could make the fan come on at 100% you could probably make the fan come on at XX% and above instead?
 
Last edited:
Oh yeah I understand what you're asking but my perspective is that there's no reason this can't be solved with using the existing knobs.

In your example, Fan on at >90%. Ok the damper has worked its way to 90% now our options here are that the PID constants you have are adjusting slowly, in which case the amount of time it takes to reach from 90 to 100% isn't important, so it doesn't matter if the fan only comes on when it gets to 100. The other option is you have "fast attack" on your PID constants so the output value is very rapidly ramping up. In this case, it will be a very short amount of time before the fan hits 100% so that 90-100% time really wouldn't have added much.

The complexity of the config page is already daunting so I'm trying to keep it just as simple as it needs to be. I just can't see the case where the same results can't be achieved using the existing config items. For high heat cooking, unless you've got a really big damper, you're going to need the fan anyway. To keep my BGE at 600F it has to have, guestimating, 9-12 square inches of intake open. Unless you're going to build a damper even larger than that, you're going to need always forced airflow, and that means using the blower + servo always at the same time.
 
Fixed the bug that was causing the HeaterMeter software to not be loaded on first boot properly. Finally! I love loosely typed languages that allow a misspelling to silently prevent code from ever running.

Changed all the display percentages to be PID output rather than blower or servo output.

Worked on the sysupgrade procedure to make sure both the "keep settings" option worked properly. I've also added a bit of code to backup the default configuration on the first boot so maybe there will be a way to have a quick "reset config" from the web UI.

Looked at changing the default configuration to have eth0 be both static and DHCP client. You can access it by 192.168.200.1, you can access it by the DHCP address your network gives it (which will be displayed on the LCD). I think this is going to work, and by that I mean create more problems than it solves. "So I went in and changed all the IP addresses to the IP address of my router..."
 
Don't you already have that?

EDIT: Oh I guess the servo part of lmremote is sort of DIY. I can tell you that the lmremote will probably never receive configuration from the HeaterMeter base, so you'll have to compile in the servo range.
 
OK.

Dave Peart mentioned that he only had 1 probe working wireless.

You should bring this project up to makerfaire in NYC this September. People would love it.
 
Back from my week's vacation in the Florida Keys, where the seas were high and the sunshine was merciless. After spending 5 days in a row on a boat bobbing up and down in anywhere from 3-6ft seas, I think I have some sort of post-traumatic vertigo. That might just be the alcohol detox though, I'll make sure to drink plenty of beer tonight as medication.

Before I left I was working on refactoring some of the lmremote code to split off the measurement and transmit loops from the rf receive loop from the control loop. That still has some work to do. I'm pretty backed up on things to do coming back from vacation so I probably won't get back to it until the weekend. The extra time away from the keyboard has also given me some more ideas to work on for the webui and possibly an easy-to-use alarm ui.
 
If there is any way possible to move the RF remote system over to work like I had mentioned before, using two HM boards with RF units on them, splitting the hardware so the HM at the grill reads the probes and controls the servo/fan and the other one interfaces with the rPi, display and button, that would be really great...
 
I was in Marathon. My sister found a 3 bedroom house for rent on the water ocean side (about 20m of canal off the water actually) with a pool, for something like $1500. It was a great time snorkeling, fishing, kayaking, kayak fishing, and of course eating seafood every night. We usually stay on Duck Key for around the same price for 3 nights. I think this is my longest vacation I've taken in 10 years!

I think we maybe can do what you're talking about. The analog ports are backward but I should flip those to be like the HeaterMeter has them. The blower and servo are on the same pins, the LEDs won't work though unless you solder some jumper wires.

Ah crap I just noticed that the blower is on the wrong pin on the lmremote schematic. It was supposed to go to atmega pin 5 but I hooked it to digital pin 5.
 
I am totally in the dark on the Imremote unit, does it exist in a complete state at the moment, or is it a work in progress? Am I right in assuming the Imremote will only work for one probe? Is the reason you keep referring to how Imremote is wired up because it runs it's own code?

If any (or all) of the above is true (specially the not being finished part), may I suggest you take a pause in it's development and examine if it might be more logical to pursue using two HM boards (instead of a special Imremote board) with the HM at the grill running it's own remote code that links the two HM boards together to pass all data required to use all 4 probes and control the fan and servo between the two HM boards? This to me seems more logical, more complete and wouldn't require a special Imremote board, although I know you would have to pretty much toss the existing Imremote code and start from scratch. Still, the end result might be worth the effort? (says the guy that doesnt have to code it!)....

EDIT: BTW, way off topic.... MakerFarm has released a couple updates to the firmware for the i3 in the past week(s), the update made my printer run much smoother. You might want to check it out.
 
Last edited:
The lmremotes exist in a complete state as battery powered transmitters. That was their original design goal, to be wireless probes which is why the code/hardware for them is the way it is. You can use up to 6 probes per lmremote unit, although HeaterMeter can only track 4 at a time. The code is written to be as efficient as possible at this job, so a pair of AA batteries could last "a long time". That long time turns out to be maybe a year of continuous usage, whereas running the full HeaterMeter code on them would drain a battery in a few days. Battery life that awful would be problematic because you'd need to change them every 2 or 3 cooks for it to be reliable.

The part where it actually has an output is new concept, where the remote unit would actually have infinite power and have to receive in addition to transmitting. The PCB was supposed to be designed so that the outputs used the same pins as HeaterMeter, but the analogs were kept the same for compatibility with existing lmremote units. After you brought up the idea of them being the same as the HeaterMeter pins as well, I think that's a better idea because then you can just use the same PCBs for one or the other. I still think the software should be different though, because the same firmware work both ways adds complexity to the standard firmware and there's really no practical way you'd want it running as HeaterMeter, attached to a Pi, and then use the web interface to switch it to a lmremote.

Mainly though it would be too much work to convert the main HeaterMeter loop to be energy efficient without making it unreadable. I also still think there's a use case for having a battery-powered transmitter so I don't want to throw that out. I do see a case for making the hardware compatible though, so that you can use a spare HeaterMeter PCB to make a lmremote node.

I'll have to check out that new i3 firmware. I have my own version of Marlin I've been playing with for various reasons so I'm off the standard firmware.
EDIT: For the record, the firmware differences:
Code: 
Old / New
ESteps: 945/841
Max Rates mm/s(X,Y,Z,E): 500,500,5,45 / 250,250,2,22
Max Accel mm/s/s (X,Y,Z,E): 9000,9000,20,10000 / 1000,1000,5,1000
Default Accel: 3000 / 500
So the Esteps are closer to actual, the max speeds are closer to what the device can actually do, and the acceleration is turned way down.
 
Last edited:
You must log in or register to reply here.

 

Back
Top