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

1 year 8 months ago - 1 year 8 months ago #10045 by Phil_Mod3
Ian: I think there is nothing wrong with the design goals. We have a flexibility that most likely wouldn't be possible with purely"hardwired" HV generation.

Mike: You are absolutely right on the voltage divider. I have no idea what I calculated on that evening.

On HV stability/ripple:

I followed Ty's recommendation and finally put another 2.2µF capacitor in parallel to the one already on the board.
My config:
-Six IN8-2 tubes
-Two IN-3 neons with 330k resistors each
-12V power supply
-PWM_ON is set to 180
-PWM_TOP_MIN is set to 400 (to lessen HV overshoot in some situations)

Let's start with scope readings of the "stock" (=2.2 µF) configuration of my clock.
You see considerable ripple on the HV "main signal" (strong blue shade) and spikes from the induction (light blue shade). The spikes go about 20V above the main signal.

When switching from time to date, the current FW causes an overshoot of the HV (over 200V in my case, although I increased PWM_TOP_MIN already).

When adding capacity to a total of 4.4 µF, the signal ripple and especially the spikes improve a lot.

However, I had some problems with ringing at the lowest dimming level (min brightness = 100).

I have adapted the implementation of the SuperFast(TM) algorithm and the results are as follows:
Considerably lower ripple on the main signal. (The spikes itself are most likely too fast, that an algorithm could do anything).

Also the adaption of HV is fast enough to lessen the extent of the HV overshoot when changing from time to date.

And fortunately, it also works at the lowest brightness.

Implementation details of SuperFast 1.1
-define following variables
int iHVADCRaw;
byte ADCRegFROn = 0;
byte ADCRegFROff = 0;
byte ADCRegMux = 0;
unsigned int hvStep = HV_STEP_SUPERFAST;

-add at the end
ADMUX = (1 << REFS0) | (0 & 0x07);    // set correct input pin and reference voltage
  ADCRegMux = ADMUX; //save register for later use
  // A conversion takes 13 clock cycles, current clock speed 16 MHz
  ADCSRA |= (1 << ADPS2) | (1 << ADPS1) | (1 << ADPS0);    // 128 presc is read out 9615 times per s
  //faster presets for ADC are not necessary, since we need values at a maximum of 100 imp/sec * 6 = 600 times per sec
  //ADCSRA |= (1 << ADPS2) | (1 << ADPS0);    // 32 presc
  //ADCSRA |= (1 << ADPS2);                     // 16 presc
  //ADCSRA |= (1 << ADPS1) | (1 << ADPS0);    // 8 presc
  ADCRegFROff = ADCSRA; //save register with free running disabled

  ADCSRA |= B00100000;
  ADCRegFROn = ADCSRA; //save register with free running enabled

  ADCSRA = ADCRegFROff; //set FR to off

-remove/comment out checkHVVoltage

-add at the beginning
ADMUX = ADCRegMux;  //set to correct input pin
//enable free-running mode
  ADCSRB &= B11111000; 
  ADCSRA |= (1 << ADSC); //start sampling

-change to:
if (timer == digitOnTime) {
        digitOn(i, currNumberArray[i]);
-add at the end
ADCSRA = ADCRegFROff; //disable free running

-add at the beginning
hvStep = 0; //disable fast HV adaption

-add at the end
hvStep = HV_STEP_SUPERFAST; //re-enable fast HV adaption

add new function:
void checkHVVoltageFast() {
  //read the ADC value, need to read low byte first
  iHVADCRaw = ADCL | (ADCH << 8);
  int iDelta = rawHVADCThreshold - iHVADCRaw;
  if ( iDelta < 0 ) {
    setPWMTopTime(pwmTop + hvStep);
  if ( iDelta > 0) {
    setPWMTopTime(pwmTop - hvStep);

Altogether this enables the free-runing mode of the HV sensing ADC right at start of the outputDisplay. It'll sample new voltage readings at about ~9600 timer per sec. However, the registers that hold the ADC results are only read out in checkHVVoltageFast(), right before the HV should be adapted. When leaving the outputDisplay() function, the free-runing mode is stopped, in order to not interfere with e.g. the LDR readout. The regular checkHVVoltage() is left unchanged, so that the HV calibration routine should remain functional (not tested yet).

The proposed algorithm would run at 97 impressions/sec on my clock, which should be the same value as for the stock firmware. However, the HV is now adapted not 97 times per sec, but 582 times per sec. (which is e.g. fast enough to catch the HV overshoot at the time-date change. On the HV read-out side is still headroom for increasing the HV adaption frequency further.)

I'll most likely leave it as it is now and I'd definitely recommend a >2.2µF cap for everybody that is sensitive for flicker. I'll get a 6.8µF cap at the same dimensions of the current 2.2µF and will add scope readings for that asap.

Thanks for reading!
Last edit: 1 year 8 months ago by Phil_Mod3. Reason: potential solution for hv-calibration bug
The following user(s) said Thank You: Ian

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

1 year 8 months ago #10046 by Ty_Eeberfest
Interesting stuff Phil. Thanks for posting. I'll play around with your latest code as soon as I get a little time. Two things for you to consider:

1) During HV calibration all the display update stuff is running, therefore SuperFast will conflict with HV calibration because both will be trying to adjust the HV. SuperFast really shouldn't be allowed to run until you get out of setup() or at least until you know HV calibration is not running. A couple things you could consider would be simply setting a flag variable at the end of setup() or doing something involving EE_HVG_NEED_CALIB in the EEPROM (probably slow).

2) The display "blackout" when switching to date was a bug that was fixed in the latest firmware revision. I'm not sure if Ian has fixed it in Ver.2 firmware yet but I have seen that it is fixed in the current Ver.1 release. Instead of blacking out the time now scrolls away a digit at a time and the date scrolls in, which is what it was intended to do in the first place.

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

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

1 year 8 months ago #10047 by Ian
I pushed the "blackout" fix last night to V2, along with a 4-Digit mode, for people who want that. It's not tagged yet, so is still considered as "Dev" mode.

@Phil, nice work, the traces look like yet another improvement over what was already there. If you take the "blackout fix" you should see that the voltage is totally stable around that area as well now.

I love this stuff: when people dig into problems and follow them through to the end, thanks for all the work guys. :-D You make me believe in open source again...
The following user(s) said Thank You: Phil_Mod3

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

1 year 8 months ago #10051 by Phil_Mod3
Ty: I adapted the code in order to remove interference of checkHVVoltage() and checkHVVoltageFast() in calibrateHVG(). But I still didn't test the calibration routine.

Ian & Ty: Thanks for the fix, I'll test it on the weekend.

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

Moderators: AccutronTy_EeberfestIan
Time to create page: 0.115 seconds
Go to top
JSN Boot template designed by