The LinkMeter Snapshot and YOU


 
SteveCK said:
I've got two questions.

A) can you recommend a quality power adapter? I'm thinking maybe just buy a laptop style this time around.

B) Currently when you change your I value in the PID it drops that sum to zero and you have to rebuild the value. How difficult would it be to prevent that? In the past I would manually change the B value every so often so that the cook wouldnt have to go through a cycle to see where your new settings land. I think if this could be done it would making tuning your pit a little easier. Thoughts?
Click to expand...

If you mean a switching power supply when you say "laptop style", I had lots of weird problems when using one of those. I have seen comments by others saying the same thing.
 
David Crawford said:
If you mean a switching power supply when you say "laptop style", I had lots of weird problems when using one of those. I have seen comments by others saying the same thing.
Click to expand...

Yeah, talking about a brick style. I did order one through Amazon. I guess I'll return it and get a different one then. Thanks Dave
 
David Crawford said:
If you mean a switching power supply when you say "laptop style", I had lots of weird problems when using one of those. I have seen comments by others saying the same thing.
Click to expand...
Every power adapter I've seen from Amazon is a switching power supply. Did you find one that isn't? I thought pretty much every "wall wart" made in the past 10 years is switching.
 
Bryan Mayland said:
Every power adapter I've seen from Amazon is a switching power supply. Did you find one that isn't? I thought pretty much every "wall wart" made in the past 10 years is switching.
Click to expand...

Generally if the power input on the supply is specified as something like 120-240VAC you can be assured it is a switch mode power supply. If it is specified as 120VAC only it is probably a linear type supply. The switch mode supplies can easily modify their operation to accommodate a wider input supply range but the linear type supplies can't deal with this. The other telltale sign is the switching type supplies are usually light in weight compared to the heavy linear type. My problems may have been from the particular switchers I was using, but since I have been using the linear type that I found in my junk I have not had any problems.
 
Last edited:
What are the chances that we are going to see a different way of viewing the fan speed vs servo on the graph? Sometimes I wish that the fan % scaled based on max and mins that are set in the configuration. For example, my fan is limited to 40%, but the way I see it, that should be 100%. It gives me the wrong impression as to the amount of fuel in my cooker at times, until I sit down and think about it. I know this probably won't happen, was just a curiosity of mine. Also, I wouldn't mind seeing the servo open % on the graph at the same time, or markers for when the HM is in startup mode!

Charles
 
I missed this question! I don't think I'll be adding the servo and fan speed to the graph, which only displays the PID output in the database. Adding more fields to that means the data files become incompatible and the graph becomes even more overloaded with information.

As far as I see it though, if your fan is limited to 40% then it is 40%. Calling it 100% would be redundant because then the fan output is always the PID output. As far as the servo output, until only the last snapshot the servo position was the same as the PID output a well so there was no point in displaying that either. The fan floor is also a new addition as well so that's not really visualized either.

I can definitely see the benefit of showing the servo position (in percent) on the graph when you're messing around with parameters, but once you've got the "servo max at" and fan min/max/floor set, these values are somewhat static so I might add an bit of detail that says what the current calculated servo position is or maybe displays the limits on the graph.
 
Bryan Mayland said:
Every power adapter I've seen from Amazon is a switching power supply. Did you find one that isn't? I thought pretty much every "wall wart" made in the past 10 years is switching.
Click to expand...

I've had several PS that just plain didn't work(too much noise) and found one in my junk today that I believe is linear, and works awesome. Input voltage is 240V (not 110/240) so I assume it's linear. If you want to source the part, it's made by Linear Electronics Inc. Part number is MV12-Y120100-A3. It's Australian plug style and voltages, but I'm sure they make a 110 version? I'll do some searching.

Also, It's a 1A rating, and but I'm looking for a 2A brick.
 
  • Add support for 2018 Pi 3B+
  • Add support for wifi 5GHz / band selection to wifi-client / wifi-ap / config.txt / dl site
  • Reduce the possible delay when displaying live data loading the webui home page. Previously, if the data coming from the HeaterMeter hadn't changed since the last update, it would hold off on broadcasting an update for up to 5 seconds. This could cause the page to not fill in with live data for 5-6 seconds, especially when using the back button to revisit the page. Now the next update is forced to broadcast when a new client connects which should reduce this to 2 seconds max, less than 1 second typical.
 
I updated a unit with a Model B and another with a zero-w and both went fine, so far... Will let you know if I spot any issues.
 
EXERCISE CAUTION: The latest snapshot uses the latest firmware for the wifi chip present on the Pi 3 (original) and Pi Zero W models. This is intended to fix the wifi disconnect-but-not-reconnect problem, but I am not sure if it makes things worse in that you won't be able to connect at all to it.

  • Update to latest brcm43430-sdio.bin/txt for RPi 3 / Zero W wifi
  • Fix sending SSDP multicast rebinds too often (ssdp-notify)
  • Include latest HeaterMeter AVR firmware 2018-03-27 (leds update immediately when entering/exiting lid mode)
 
  • Include latest HeaterMeter AVR firmware 2018-04-09 (fix for thermocouples going "No Pit Probe" when passing quickly between 400F-500F)
 
There's been some AVR changes recently but I haven't pushed it into the snapshot because I don't know how I feel about them.

Thermocouple Non-Linearity Compensation
The one hour change that lasted for days. Steve_M "Toronto Steve" contacted me about adding compensation for the nonlinear response of thermocouples. K-Type thermocouples are not exactly 41uV/C across their entire range. In fact, they aren't even linear across the range we use them in (ref google "Seebeck Coefficient of Thermocouple vs. Temperature"). However, the error is minor at just +1C at 140C and -1C at around 260C.


Fixing this using a compensation table to adjust the values is fairly trivial so I added it. However, comparing the numbers from Analog Devices AN-1087 compensation tables to the NIST standard reference tables or the formulas in the document didn't match up. This spawned hours upon hours of reading other papers, trying other formulas to compare, and finally just giving up and rolling back to the initial implementation. The newest AVR snapshot now includes this compensation for temperatures between 0C and 320C with accuracy down to 0.01C.

Note: This means if your temperature read 212.0F at sea level and boiling, it will now read 210.596F because there's a -0.78C compensation applied there. There is no way to disable this feature without recompiling.

Less Beepy, Still Too Beepy
You know how when the alarm goes off and you have the action set to Silence/Disable there's still like 2 seconds of beeping? This was something I've wanted to fix for a bit and more of a fix is coming, but now it beeps less! 500ms less to be precise. I was hoping that a simple 1-line change could eliminate the beeping entirely but the processing delay of having to go from the HeaterMeter, into linkmeterd, launch the alarm process, figure out what to do, and tell HeaterMeter not to beep takes too long so it still beeps. As part of some of the LCD UI swaparound, there will be a complete silence mode setting on the device itself so you will never peep the beep again.

Secret Mystery Menus
I do a lot of diagnostics and testing and sometimes I want more information right on the display instead of having to use the webui. In the snapshot now there is a secret menu! Go to the manual mode selection menu and hold the left button. The first screen is Probe0's raw info:
Code: 
N ADCxxxx NZyy -- Line 1
Probe number, ADC raw value, Noise
Type    CurrentVal -- Line2
Where type is the type of probe and the right is the current calculated value
The display does not update on the fly yet, that's where the LCD UI swaparound needs to be finished. It is currently locked to only having one dynamically updatable display, the "Home" screen. A future update will include the ability for any screen to be the one that is updated on the fly so the values will refresh. There's also going to be a bandgap reference and VCC diagnostic screen, the ability to change probe types, buzzer tester, fan feedback diagnostics, and a servo tester mode to center and set endpoints.

Proportional On Measurement mode
Hey Mr. DJ, Pon de Measure-play. Issue #42 was opened suggesting that HeaterMeter also allow a PonM mode for proportional contribution to PID output. This is the first major change to the PID control structure in several years, and it is HeaterMeter's core feature so I'm always excited to try new things here. The concept is that instead of P being Kp * error, P becomes -Kp * temperature, switching from Proportional-on-Error to Proportional-on-Measurement. There are a couple good blog articles to explain why here:
Introducing Proportional On Measurement
Proportional on Measurement – The Code

As with all things HeaterMeter, the one hour change spawned a week's work as there were a whole lot of problems with the first implementations that even when I hard coded some band-aids into the code would still have somewhat poor control response. What I ended up with is "a linear combination of Proportional-on-Error and Proportional-on-Measurement to proportional contribution" as discussed in Instrument Engineers' Handbook, Fourth Edition, Volume Two: Process Control. The current snapshot interprets a negative Kp (the P constant in the webui) as indicating you want to run with this new experimental feature, but the sign is removed before the calculations are made, so the value is still always positive. Right now the code is hard-coded to use a fixed lambda weight of 0.4*setpoint - temperature, although once I get a chance to update the UI, any weight can be used. 1.0 would be the same as what we have now, PonE, because that works out to 1.0*setpoint - temperature, which is just the error. However, a full PonM calculation can be done with a 0.0 lambda as well as any weight in between. Allowing this is blocked by needing support in the UI and I've currently got the Pi firmware torn apart to move it back to OpenWrt from LEDE since the LEDE Project is now dead.

In the meantime however, I've used the PID constants of P=-0.4, I=0.1, D=12 on my big green egg and it seems to do OK. Note the P value is negative (to enable the feature) and a lot lower than the "4" default. The I constant probably needs to be higher than what you have now, as the P doesn't do much heavy lifting any more so we're relying more on the I acting more quickly. The D is much larger to try to counteract over/undershoot caused by I settling. For people used to how HeaterMeter instantly responds when you change the setpoint: In this mode the output is more driven by the I accumulation, so when you change setpoints, expect some time for the controller output to ramp. Also note that this somewhat removes the proportional band so expect to see the output cutting out a lot earlier on startup so if you test, please set your "Max Startup Fan Speed" back to 100, otherwise the startup will be double-limited and might take a lifetime. At the very least set it higher or expect a very slow startup.


So there we have it. Like two months of work that came from what I expected to be just a few hours of coding. I've got such a pile on my TODO list and for every thing that's come off it, I feel like it's not quite done or maybe wasn't a good idea to begin with so maybe you guys will feel like these are better features than I do. There's just so much to work on and it is somehow hard to find the time despite not quite being really employed with a real job, but it does feel good to finally have something to put into your hands. Maybe there should be a new thread for the PonMonE discussion? I'd be interested to hear if anyone feels like it is helpful.

EDIT: Forgot to mention how to get this. Just go to LinkMeter -> AVR Firmware in the webui. Select "From Online Repository" and select the most recent snapshot which is 20180810B.
 
this is an interesting change. looking forward to trying it out today since the temp is out of the 100`s and back down to the 80`s. My main question is, what damper did you use for your testing. Since I have been trying out both a blower type and the cfm type I have just resealed my ceramic grill because I have been using the cfm based damper more and finally did a smoke test and found some large air leaks. I guess that is expected after 10 years of heavy use. So now I am back to the blower style damper and will run that for a few cooks and the go back to the cfm style and tune that. So with that said, what effects are you experiencing with the fan settings in the webui. You recommended raising the startup parameter to 100%. Did you make changes to the other fan parameters?

Looking forward to tuning the grill with this new change, Great work as usual. This is why people use the heatermeter and always recommend it to others looking for controls for their cookers.
 
By "cfm type" I am guessing you mean an axial fan, like a PC fan shape instead of the blower shape? I test with a bench setup of a aluminum block with a ceramic heater in it and a thermocouple tapped into it as well. Once it seems to be OK there, I move to the Big Green Egg with a bit of a modified microdamper and the standard fan that would come with it. That grill is pretty leaky thanks to having fallen over once and the gasket being old. I have the stuff to replace the gasket but it has bee sitting on the counter for a few weeks now. So there's a physical simulated test followed by a real charcoal test on the BGE with the microdamper.

What effects am I seeing in the fan settings in the webui? I'm not sure what you mean by that. There's no changes to the webui, everything is the same there, this is just an AVR firmware. If you're going to try out the PonM stuff, using a negative P coefficient, then I suggest trying it with a higher fan startup max because the startup is somewhat implicitly limited by the D coefficient in this mode and you'll see less output as a result on startup. The temperature can only really rise 100/D degrees per minute, as opposed to before where you'd always be running 100% (or max startup) until you reach the proportional band, which is within 100/P degrees. With my settings (-0.4, 0.1, 12), the startup temperature ramp ran around 8 degrees per minute and didn't reach 100% again after the initial minute or two. I'm sure folks can use their old max startup fans of 50% or so, but the ramp could be super slow which would be impractical or it could not ever reach temperature in more extreme cases. It is better to reset the value to default 100% because the control mechanism behaves so differently the setting doesn't carry over.

The regular system with a positive P coefficient is unchanged so there should be no difference in behavior when using the same settings you had before.

Bug fix to integral sum
This is actually part of the snapshot above, but I forgot to mention it. I hesitate to call it a bug because I sincerely doubt it was ever encountered in the wild, but the "I" contribution could accumulate an artificially higher value in the first second the controller becomes active (switching the setpoint from ambient to a real setpoint). The only time this could be an issue is if the I constant was really high compared to the default (more than 10x higher) *and* the setpoint to ambient was very high (like 500-1000 degrees). If that was the case, it could potentially contribute a little extra to overshoot before becoming unwound. The Isum is now bound on both upper and lower limits to prevent excessive contribution during that single PID loop cycle when the setpoint was just set but the output isn't on yet.
 
I have setup on my test bench and I like what I see. It is interesting how the control works. I am setting up the Adapt-a-damper first. the fan parameters I was curious about were the "on above", "%min", and "%max". As with my tune of the blower style versus the microdamper, in order to get stable good control I adjusted these parameters since the fan`s characteristics are different.
 
Bryan Mayland said:
There's been some AVR changes recently but I haven't pushed it into the snapshot because I don't know how I feel about them.

Thermocouple Non-Linearity Compensation
The one hour change that lasted for days. Steve_M "Toronto Steve" contacted me about adding compensation for the nonlinear response of thermocouples. K-Type thermocouples are not exactly 41uV/C across their entire range. In fact, they aren't even linear across the range we use them in (ref google "Seebeck Coefficient of Thermocouple vs. Temperature"). However, the error is minor at just +1C at 140C and -1C at around 260C.


Fixing this using a compensation table to adjust the values is fairly trivial so I added it. However, comparing the numbers from Analog Devices AN-1087 compensation tables to the NIST standard reference tables or the formulas in the document didn't match up. This spawned hours upon hours of reading other papers, trying other formulas to compare, and finally just giving up and rolling back to the initial implementation. The newest AVR snapshot now includes this compensation for temperatures between 0C and 320C with accuracy down to 0.01C.

Note: This means if your temperature read 212.0F at sea level and boiling, it will now read 210.596F because there's a -0.78C compensation applied there. There is no way to disable this feature without recompiling.

Less Beepy, Still Too Beepy
You know how when the alarm goes off and you have the action set to Silence/Disable there's still like 2 seconds of beeping? This was something I've wanted to fix for a bit and more of a fix is coming, but now it beeps less! 500ms less to be precise. I was hoping that a simple 1-line change could eliminate the beeping entirely but the processing delay of having to go from the HeaterMeter, into linkmeterd, launch the alarm process, figure out what to do, and tell HeaterMeter not to beep takes too long so it still beeps. As part of some of the LCD UI swaparound, there will be a complete silence mode setting on the device itself so you will never peep the beep again.

Secret Mystery Menus
I do a lot of diagnostics and testing and sometimes I want more information right on the display instead of having to use the webui. In the snapshot now there is a secret menu! Go to the manual mode selection menu and hold the left button. The first screen is Probe0's raw info:
Code: 
N ADCxxxx NZyy -- Line 1
Probe number, ADC raw value, Noise
Type    CurrentVal -- Line2
Where type is the type of probe and the right is the current calculated value
The display does not update on the fly yet, that's where the LCD UI swaparound needs to be finished. It is currently locked to only having one dynamically updatable display, the "Home" screen. A future update will include the ability for any screen to be the one that is updated on the fly so the values will refresh. There's also going to be a bandgap reference and VCC diagnostic screen, the ability to change probe types, buzzer tester, fan feedback diagnostics, and a servo tester mode to center and set endpoints.

Proportional On Measurement mode
Hey Mr. DJ, Pon de Measure-play. Issue #42 was opened suggesting that HeaterMeter also allow a PonM mode for proportional contribution to PID output. This is the first major change to the PID control structure in several years, and it is HeaterMeter's core feature so I'm always excited to try new things here. The concept is that instead of P being Kp * error, P becomes -Kp * temperature, switching from Proportional-on-Error to Proportional-on-Measurement. There are a couple good blog articles to explain why here:
Introducing Proportional On Measurement
Proportional on Measurement – The Code

As with all things HeaterMeter, the one hour change spawned a week's work as there were a whole lot of problems with the first implementations that even when I hard coded some band-aids into the code would still have somewhat poor control response. What I ended up with is "a linear combination of Proportional-on-Error and Proportional-on-Measurement to proportional contribution" as discussed in Instrument Engineers' Handbook, Fourth Edition, Volume Two: Process Control. The current snapshot interprets a negative Kp (the P constant in the webui) as indicating you want to run with this new experimental feature, but the sign is removed before the calculations are made, so the value is still always positive. Right now the code is hard-coded to use a fixed lambda weight of 0.4*setpoint - temperature, although once I get a chance to update the UI, any weight can be used. 1.0 would be the same as what we have now, PonE, because that works out to 1.0*setpoint - temperature, which is just the error. However, a full PonM calculation can be done with a 0.0 lambda as well as any weight in between. Allowing this is blocked by needing support in the UI and I've currently got the Pi firmware torn apart to move it back to OpenWrt from LEDE since the LEDE Project is now dead.

In the meantime however, I've used the PID constants of P=-0.4, I=0.1, D=12 on my big green egg and it seems to do OK. Note the P value is negative (to enable the feature) and a lot lower than the "4" default. The I constant probably needs to be higher than what you have now, as the P doesn't do much heavy lifting any more so we're relying more on the I acting more quickly. The D is much larger to try to counteract over/undershoot caused by I settling. For people used to how HeaterMeter instantly responds when you change the setpoint: In this mode the output is more driven by the I accumulation, so when you change setpoints, expect some time for the controller output to ramp. Also note that this somewhat removes the proportional band so expect to see the output cutting out a lot earlier on startup so if you test, please set your "Max Startup Fan Speed" back to 100, otherwise the startup will be double-limited and might take a lifetime. At the very least set it higher or expect a very slow startup.


So there we have it. Like two months of work that came from what I expected to be just a few hours of coding. I've got such a pile on my TODO list and for every thing that's come off it, I feel like it's not quite done or maybe wasn't a good idea to begin with so maybe you guys will feel like these are better features than I do. There's just so much to work on and it is somehow hard to find the time despite not quite being really employed with a real job, but it does feel good to finally have something to put into your hands. Maybe there should be a new thread for the PonMonE discussion? I'd be interested to hear if anyone feels like it is helpful.

EDIT: Forgot to mention how to get this. Just go to LinkMeter -> AVR Firmware in the webui. Select "From Online Repository" and select the most recent snapshot which is 20180810B.
Click to expand...

boy you lost me here!
 
Gary V said:
I have setup on my test bench and I like what I see. It is interesting how the control works. I am setting up the Adapt-a-damper first. the fan parameters I was curious about were the "on above", "%min", and "%max". As with my tune of the blower style versus the microdamper, in order to get stable good control I adjusted these parameters since the fan`s characteristics are different.
Click to expand...
Yeah it definitely behaves in a way different than the standard control scheme. I had several times where I thought there was clearly a bug in the code but checking the math it all worked out. By the time I finished doing the napkin math to verify it, it was doing the right thing. It just takes a while to start doing its thing compared to an instant response with a PonE setpoint change.

On Above - sets the Output % above which the fan starts at 0%. Useful if you cascade your blower with a damper so the damper opens up fully at say 50%, then the fan turns on from 50-100% (as opposed to ramping 0-100% output = 0% - 100% fan).
Min % - Lowerbound for how slow the fan can physically run. If your fan can't turn on at 1% due to having a higher starting voltage bump this up until it turns on reliably every time. For outputs below this value, the fan will pulse on and off rather than slowing down.
Max % - Max power to give to the fan when 100% fan is requested by the controller. Used to reduce the fan's physical output to a certain maximum speed/voltage. 75% would be around 10V instead of the 12.1V of 100%.

@Dave Smith - (nods) This is why the tiny silly features took so much time! Well this seems easyyyy... ah eeerp?
 
So many updates today... to get back to functional really. Spending half the day tracking down weird bugs that were breaking things and forging new code to work around upstream changes are always fun.
  • HeaterMeter REST API back up and running
  • Fix for not respecting allowcors option in the API. Thanks to Robert Spari for reporting this
  • Fix SSDP system startup covfefe which could prevent HeaterMeter from showing up in windows Network device lists
  • linkmeterd log entries are now prefixed with... linkmeterd! I thought I did this before, maybe it was just a dream
 
You must log in or register to reply here.

 

Back
Top