IN-8-2 Modular Rev 3 build - feedback and questions

More
1 year 4 months ago - 1 year 4 months ago #9867 by Ty_Eeberfest
I have the original 2.2uF cap in mine. I remember I changed it to something bigger once - probably 10uF - and it did help with flicker. trying to remember why I put it back to original - it wasn't a performance issue, probably it was because I wanted to go back to a totally stock clock while discussing HVG with somebody on here. I think. This would seem to be a case of "bigger is better" but I wonder how big we could go before the MOSFET blows up from the inrush charging a huge cap at power-up.

I'm more inclined to increase the cap value than keep chasing perfect HV algorithms in the software at this point. After everything I've tried (except Phil's TCNT1 fix) I don't think I've improved things much at all. Also, Ian has said - and so have I - that checkHV is intended to act as a sort of "trim" over long periods of time. And yet we (I include myself) keep trying to make it smooth out the short term flickers. I feel like I'm just chasing my tail. I'm afraid that the truth is that regulator code that's processed ~100 times per second is never going to provide regulation fast enough to take out the flickers without adding overshoot in the opposite direction. As a process control guy I should have admitted defeat on this ages ago because simply put the cycle time of the controller is longer than the period of the process. The solution would be to drastically reduce the cycle time of the controller which in this case means calling checkHV much more often (in a fast interrupt?) but I hate to even think of the impact that will have on the operation of the rest of the code.......

EDIT: Having said all that, maybe after I finish writing this article I'm working on I'll code up a fast interrupt for checkHV just to see what I can break next.

Look into it later when the dust is clearing off the crater.
Last edit: 1 year 4 months ago by Ty_Eeberfest.
The following user(s) said Thank You: Phil_Mod3

Please Log in or Create an account to join the conversation.

More
1 year 4 months ago - 1 year 4 months ago #9869 by MikeS

Ian wrote: I ship a 2.2uF with a fairly good ESR. For my own use I use 10uF, but they are bulky. I used to ship 1uF, and they worked fine, but seemed a bit too small.

The footprint on the board is one of my own designs and will accept just about anything. There are the 3 main radial spacings in the one footprint.

Yea, I remembered wrong. Looking in my "old parts" bin, it was a Chenxing 2.2/400, about 8x13mm. I used a Wurth WCAP-AT1H (10/400), which is about 10x16mm. My EVB ESR meter says 3.7 ohms on a new one - 3.0 in-circuit after "forming" a while. Wurth says ~2.75 @ 100 KHz. The Chenxing measures 15 ohms - I couldn't find a datasheet.

edit: I also used a Wurth 744743101 inductor, which had the highest saturation current (1.6A) I could easily find in a package which would fit. Coilcraft DR0608-104L is half the price, but just 1.0A.
Last edit: 1 year 4 months ago by MikeS.

Please Log in or Create an account to join the conversation.

More
1 year 4 months ago - 1 year 4 months ago #9870 by Phil_Mod3
I felt brave enough to go the route Ty proposed:
I moved the checkHV() right into the outputDisplay() function
for (int timer = 0 ; timer < dispCount ; timer++) {

      if (timer == digitOnTime) {
        digitOn(i, currNumberArray[i]);
      }

      if  (timer == digitSwitchTime) {
        SetSN74141Chip(NumberArray[i]);
      }

      if (timer == digitOffTime) {
        digitOff();
      }
    }
    checkHVVoltage();
This means, that it'll be approximately called (impressions per sec * 6) times per second.
I modified the checkHVVoltage() function to become more responsive and to do only the smallest possible adaption.
void checkHVVoltage() {
  if (getSmoothedHVSensorReading() > rawHVADCThreshold) {
    setPWMTopTime(pwmTop + 1);
  } else {
    setPWMTopTime(pwmTop - 1);
  }
}
Since the function now could only adapt PWM_top in very small steps, I didn't care about possibly noisy measurements of the HV and set
int sensorSmoothCountHV = 1;
Otherwise no adaptions of the code. I had two IN-3 neons attached, each with 220k resistors (to make it a little harder, normally I use 470k).

Here are the results:
As always, HV in blue. There are also measurments for "noisiness" and peaks of the HV.

SuperFastAlgo(TM) at full brightness


SuperFast at minimum brightness (MIN_DIM_DEFAULT = 100 )


SuperFast when trying to handle the date swing (I think we need to do something about these conditions anyway, irrespective of the algorithm).


And here the same scope readings at stock configuration.
Full brightness


Minimum brightness


Date swing


Of course, this is only representative of my clock. The impressions per sec were at 94. But I think we could optimize that?! (would it be faster to set & read the ADC registers directly?)
Attachments:
Last edit: 1 year 4 months ago by Phil_Mod3. Reason: Typos, clarifications

Please Log in or Create an account to join the conversation.

More
1 year 4 months ago #9872 by Ty_Eeberfest
Phil that looks promising! A few things...

By changing checkHV to such a small increment you may (may - I haven't tested yet) have broken the initial HV Calibration, which uses checkHV heavily when "feeling around" for the right PWM frequency etc. Might be better to make a second checkHV type function to handle the ongoing checking & adjusting.

That blank interval before the date appears is the subject of a current email exchange I'm having with Ian. I'm of the opinion the blank interval is the unintended result of a subtle bug in the transition code. If Ian agrees with my findings there won't be a blank interval there much longer.

It looks like that multiplexing routine is running even when the tubes are blanked by PIR or time of day. Thus you probably still need to put if(!blanked) or maybe if(!blankTubes) in front of the call to checkHV. Otherwise you have the checkHV code trying to adjust a turned-off HVG, resulting in a big overshoot when the HVG is turned back on.

CheckHV as it is now still makes an adjustment even when it isn't needed:
void checkHVVoltage() {
  if (getSmoothedHVSensorReading() > rawHVADCThreshold) {
    setPWMTopTime(pwmTop + 1);
  } else {
    setPWMTopTime(pwmTop - 1); // THIS LINE decreases pwmTop even when getSmoothedHVSensorReading() == rawHVADCThreshold
  }
}

// SOMETHING LIKE THIS WOULD RUN SMOOTHER

int err = getSmoothedHVSensorReading() - rawHVADCThreshold;

if (err > 0) {
  setPWMTopTime(pwmTop + 1);
} 
else if (err < 0) {
    setPWMTopTime(pwmTop - 1);
}

// If err == 0 it does nothing

Look into it later when the dust is clearing off the crater.

Please Log in or Create an account to join the conversation.

More
1 year 4 months ago - 1 year 4 months ago #9874 by MikeS
Looking at your "stock" sweeps - if I read the scope right, vertical is 10V/div. So, I see about 10V p-p normally. Then, the "date" swing looks like a 50+ V drop, followed by ~15 V spike.

Here's mine:


Normally, ~2V p-p.
Edit: original 2nd picture was misleading, because I used AC coupling to make a magnified setup easier. That works with high frequency signals, not so much here. Replaced with a DC coupled sweep. I see less drop (~45v), and very little overshoot after.
Last edit: 1 year 4 months ago by MikeS.
The following user(s) said Thank You: Phil_Mod3

Please Log in or Create an account to join the conversation.

More
1 year 4 months ago #9875 by Ty_Eeberfest
Phil, I tried putting checkHV in a sort of fast (every 1 mS) interrupt handler and it failed miserably. The problem is that calling analogRead() so often absolutely chokes the CPU. Everything falls apart - you can actually see the multiplexing "walking across" the tubes in slow motion. Fail. Process of elimination narrowed it down to the analogRead and not anything to do with writing to pwmTop.

I also tried your SuperFastAlgo(TM) and it worked for me with a few tweaks. First, because it tries to adjust the HV on every display refresh, it was fighting with the HV Calibration routine when starting up after a reset. I bodged it by making a global boolean flag that gets set after calibration is finished. checkHV doesn't get called at display refresh until the flag is set. Also I made my own "checkTYVoltage" routine with your tiny increments code amd left the original checkHV function unmolested. The HV Calibration routine still calls checkHV and the fast calls at display refresh use checkTY. I tinkered with the increment size and tried a few different places to put the call. I didn't make any great discoveries. It works reasonably well here, about the same as your last scope shots show.

The kicker: I finally got tired of fooling with the code and feeling like I wasn't really getting anywhere. So I ripped out the 2.2uF filter cap and stuck in a 33uF. Nothing special about the value, that's just the only "bigger but not stupidly big" cap I had on hand. No idea what the ESR is but I'd guess it's pretty average for an electrolytic. That cap made more difference than all our code tweaking ever did. Using a slightly modified version of Ian's original checkHV algorithm, called once per iteration of loop(), HV is stable to within about 500mV under all the usual test conditions (except the date drop).

This is the "slightly modified version" of Ian's algorithm.
int getInc() {
  int diffValue = abs(getSmoothedHVSensorReading() - rawHVADCThreshold);
  int incValue = 0;
  if (diffValue >= 3) {
    if (diffValue > 20) incValue = 35;
    else if (diffValue > 10) incValue = 5;
    else incValue = 1;
  }
  return incValue;  
}

Look into it later when the dust is clearing off the crater.
The following user(s) said Thank You: Phil_Mod3

Please Log in or Create an account to join the conversation.

Moderators: AccutronTy_EeberfestIan
Time to create page: 0.234 seconds

Search

Tube Suppliers

Go to top
JSN Boot template designed by JoomlaShine.com