The LinkMeter Snapshot and YOU


 
In reply to http://tvwbb.com/showthread.php?46004-INTRODUCING-the-quot-Roto-Damper-quot&p=705356&viewfull=1#post705356

I didn't want to hijack Ralph's thread too much.

I'm not sure if the issue was the ADC ISR or the Serial ISR. Either way there are enough ISR events to mess up the determinism of the system.

This code matches the original servo movement more or less

ISR(TIMER1_CAPT_vect)
{
unsigned int cnt = OCR1B;

digitalWriteFast(PIN_SERVO, HIGH);
cnt = TCNT1;
OCR1B = cnt + pid.getServoTarget();
}

RC Servo's are far more sensitive to pulse width than refresh rate assuming there is no mechanical binding holding the servo from moving. Basically I'm finding out how long the ISR got delayed and adding that to the turnoff event so the length of the pulse should be more consistent. Unfortunately this only corrects 1/2 the issue as the turn off event may or may not get hit.

Doing some simple count measurements. The original ISR would vary the pulse width between 0 and 25 counts of desired. Modified is around 0-12 counts. Two counts is about 1uSec if I recall right. So 25 counts is ~12 uSec which exceeds the deadband of most analog servos which cause them to start trying to move. 12 counts is ~6usec and should be fine outside of a digital servo. Digital servo's can go down to <1 uSec deadband on really good ones.
 
Oh very interesting approach! I am out of town on business so I can't test it but I think with your contribution I can update the new movement code to reduce the chatter.

It is without a doubt the ADC code. That code is doing way too much long math to in an ISR to have the other ISRs fire in a timely manner. If you turn off the interrupt for the ADC, you'll see that the servo pulse width becomes pretty consistent. I posted a screenshot from my scope of the comparison of the two at one point but I can't find it now. I wonder if there's a way to somehow cadence the servo and ADC interrupts so they never end up stepping on each other. Probably not because the duration is variable depending on the 50/60Hz noise reduction mode.

In any case, I can't wait to get home and try out your code mixed with mine!
 
Praise be to Rob! It works with the current servo slewing code as well.

Before: Note that we are producing pulses a few microseconds too short all the time, and there's about a -10us to +10us variation in the pulse width.
XTL2s0L.jpg


After: 0us to +10us, with probably 95% under 6us and a pulse width within 0.8us of expected length.
1DkLqQE.jpg


It is important to also say that the ADC is off during this testing because it really makes a mess of the servo. More on that later though!
 
Continuing on, here is what the servo output looks like with Rob's code and with the ADC turned back on. câlisse! It ees ruined!
xehydBJ.png


So I spent half the day disassembling the firmware and rewriting the ADC interrupt handler to reduce the jank it induces in the other interrupt handlers. Here's where we ended up. The code functionality is the same, but it has just been re-written to slice up the code so no single interrupt executes more than 36 clock cycles (2.25us).
CyC9fRr.png


New snapshot code will be up later today once I verify it is all working identical to before.
 
That is encouraging! Does this mean the servo can remain powered now?
I really like the latest snapshot firmware, except the servo move and rest scheme... Also, it seems like the HM isn't moving the servo for small changes, for instance, when I nudge 5% it doesnt move but when I nudge 10% it does? This sometimes makes the servo not find it's closed position, if that move is small it may be ignored and leave the servo slightly opened when it should be closed. I went back and forth between the release firmware last night and the latest snapshot, the servo always landed in the right place with the release firmware but not always with the snapshot firmware. Small movements in the middle of the servo range may be insignificant, but moves to the closed position are critical, it's really important that the servo is closed when the HM thinks it is otherwise the HM may lose control of the pit.
 
2.25 uS is awesome. I'm curious what you changed.

I tried to move some of the code from the ISR to Read function ( kind of a top half / bottom half from Linux). As I don't have an oscilloscope I gave up when I couldn't see if anything was improving.

Spent yesterday writing a LinkmeterD plugin(Very long white paper if your bored). Debugging Lua is a nightmare. Wish I could make that process run in the foreground to see the Stderr output.

If it works I'll submit it to you. It not well I learned a ton about Lua.
 
No, the servo won't stay powered up now, I don't see a reason to keep it active all the time. The servo does move for small changes, however you have to be patient. There's up to a 10 second holdoff between moves to prevent it from just rocking back and forth between the same two percentages. It will close all the way from 2% to 0%, or open to 0% to 5% if given time.

@Rob: There's already a PID tuning plugin although there isn't any UI for it (peaks plugin was designed for this purpose). You can make lucid run in the foreground as well with `uci set lucid.main.daemonize=0`. Be careful leaving it like this though because your bootup will hang at starting the lucid process and leave you with no ssh (unless you go into the webui and start it manually). Also I will note that I didn't get the delay down to 2.25uS, just that the user code is cut down to that length. The actual output you see in the scope picture above, with a max error of about 8us. You do hear a bit of noise every so often, just not the kind like the 50us random pulse stuff there was before.

Lua is awesome as all heck too! It is so simplistic and so powerful. Tables and tables and tables!
 
Bryan Mayland said:
There's already a PID tuning plugin although there isn't any UI for it (peaks plugin was designed for this purpose). You can make lucid run in the foreground as well with `uci set lucid.main.daemonize=0`.
Click to expand...

Sigh. Facepalm moment as I think I looked at the lucid file previously. I've studied the peaks plugin difference would be an active verse passive attempt. It's interesting either way.
 
Looks good Bryan. I too, like Ralph, installed the newest snapshot recently and noticed the phenomenon he is speaking of. I found it quite tedious to calibrate a new dampers full open and full closed position.

Note - I didn't try flashing the release firmware to see if maybe something is wrong on my end. Didn't have the time to check yet.
 
Last edited:
Rob Burk said:
Sigh. Facepalm moment as I think I looked at the lucid file previously. I've studied the peaks plugin difference would be an active verse passive attempt. It's interesting either way.
Click to expand...
Yeah the idea was that once I could tell the peaks plugin was working, I'd add some code to allow you to "turn on" active mode.
#1 Set Pid I and Pid D to 0, Pid P to some value (?) save the previous values in the config file for restore
#2 Let the grill oscillate for 2 complete cycles.
#3 Check the amplitude and gain. If amplitude is increasing by more than X% per cycle, decrease P. If amp is decreasing by more than X% per cycle, increase P. Go to #2.
#4 Amp increase is ok? Testing is complete. Apply new coefficients using P, Ku, Pu, clear those stored in config file.

SteveCK: When you set the endpoints the servo should automatically adjust to the new calculated position (within 1 second), unless the new position is the exact same position as it was before. You should just be able to change the endpoint value in the conf page, Alt+S, immediately see the change.
 
Bryan Mayland said:
SteveCK: When you set the endpoints the servo should automatically adjust to the new calculated position (within 1 second), unless the new position is the exact same position as it was before. You should just be able to change the endpoint value in the conf page, Alt+S, immediately see the change.
Click to expand...

Turned out to be a problem on my end (failing power adapter), thanks Cap'n.
 
Last edited:
Good to hear! I ran through some tests yesterday though to make sure I hadn't broken anything since adding the code and verified it does still work as described.

I've posted a new snapshot with some changes
  • Servo idle time time is now taken into consideration when determining if a small move should be made. It used to be that if there was a small move to make, it would delay making that move up to 10s. Now small moves are held off at most 10s from the previous move, which means if we're sitting there at 0% for 30 seconds and we now need to go to 1%, it will go immediately. If we then need to go back to 0%, THIS write will be delayed 10s rather than the first.
  • The integral sum, PIDI, could go negative when decreasing the setpoint, which would extend undershoot recovery times. Fixed.
  • BUG: Setting fan active floor without setting servo active ceiling would cause the servo to be set to the fan percentage. Fixed.
 
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?
 
I haven't done any testing to figure out what's going on, but after updating to the snapshot on Saturday I had stability issues with my Heatermeter. For the first few hours of the cook everything was fine. But after maybe 5-6 hours I was unable to reach the Heatermeter. It was still monitoring the pit (new cooker, no hookup to mount the fan made yet) but the web services were not reachable. I unplugged the HM for 30seconds and plugged it back in. It worked ok for a short period of time, maybe an hour or 2 and then was unreachable again. I did this 2 more times during the cook.

I'll try reflashing the SD card and see if I can figure it out. I also have a second wifi USB I'll try. It was raining out, but my cooker was under the balcony and the Heatermeter was under the cooker and dry.

Maybe I need to get around to making those RDTC boards?
 
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.
Click to expand...
A) I wish I could. The quality is pretty hit or miss on every adapter I get and even buying the same amazon link doesn't guarantee what you get, because several vendors use the same product ID despite not having the same product.

B) The integral sum no longer resets when changing the I constant (since at least 3 or 4 months ago), unless you're setting it to 0. The sum also no longer resets when changing setpoints (as of Jan-22).
 
Benjamin Thibault said:
I haven't done any testing to figure out what's going on, but after updating to the snapshot on Saturday I had stability issues with my Heatermeter. For the first few hours of the cook everything was fine. But after maybe 5-6 hours I was unable to reach the Heatermeter. It was still monitoring the pit (new cooker, no hookup to mount the fan made yet) but the web services were not reachable. I unplugged the HM for 30seconds and plugged it back in. It worked ok for a short period of time, maybe an hour or 2 and then was unreachable again. I did this 2 more times during the cook. ?
Click to expand...
You should try seeing if you can SSH into the device when it goes offline, to determine if just the web server is crashing, or the wifi is dying. If it is the web server, we can maybe fix that, but I run my HeaterMeters here in the lab 24/7 and haven't seen one crash so I do not believe it to be that.
 
Bryan Mayland said:
B) The integral sum no longer resets when changing the I constant (since at least 3 or 4 months ago), unless you're setting it to 0. The sum also no longer resets when changing setpoints (as of Jan-22).
Click to expand...

Awesome. I've been using release software, and the newest snapshot is the only one I've flashed so far... haven't played around with it much yet. Stupid powers adapters :mad:
 
There was a bunch of minor problems with the tooltip going away and appearing in the right place when there was no data for the selected time. Fixed? Also some cleanup of redundant calls and RF status queries happening on the conf page, which may also now be fixed. Just cleaning up some small bugs here and there.

When I get back from my next business trip, maybe this is release? LinkMeter v13 RC1 out now!
 
All updated. Getting ready for an overnight smoke tomorrow night for some Super Bowl pulled pork!
 
Previous 13 HM.hex with continuous operation was really starting to bug me with the roto damper sitting on my desk twitching. Actually found I could vary the twitch depending if I was using 60hz, 50hz, or no filltering on temp probes

I just synced your master fork into mine. Compiling 13.1 HM.hex for continuous servo operation. It totally quiet now regardless of what filter is used on the temp probes.

Grill will be smoking tomorrow :)
 
You must log in or register to reply here.

 

Back
Top