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

More
1 year 4 months ago #9876 by Ty_Eeberfest
Top trace is just the HVD - nothing really to see there. Bottom trace is the HV at the test point. 1 volt / division.

Normal clock operation, neon separators with 330K resistors


Normal clock operation, neon separators disabled


The drop before the date appears

Look into it later when the dust is clearing off the crater.
Attachments:
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 #9879 by Phil_Mod3
Mike: I read from your first scope image, that the sweeps under normal operation is between 4-6 V p-p, is that correct? So that would'nt be much different from what I see (8V p-p). I think it depends also difference in power consumption of tubes (I have IN-8-2s) at different digits and on the neons. If I remove neons or put in higher resistors, the p-p is significantly lower. On the date swing, I agree that your signal looks more benign than what I have. However, I have no idea why. What is your PWM_on?

Ty: I agree that "my" code is rather an alpha than a beta version. I wanted to have a quick look at faster adapting of the HV, so I removed everything from the update procedure that I regarded as time consuming. I thought "if" statements are time consuming, but might be terribly wrong (will try it on the weekend most likely). But I agree, that the HV shouldn't be changed if there is no deviation from target voltage. How were your impression per sec with checkTY() ? Do you see any chance making analogRead() faster? Were the last scope readings obtained with the bigger cap?

General:
-If I understand the voltage sensing correctly, we could read HV voltages in a range from 0 to ~2486 V. The smallest step (one unit) in the output from analogRead() equals 2.43 V in HV. Given that on-top come several other inaccuracies, it will be hard to achieve more stable HV just in software. (e.g. analogRead compares the level of the input to the level of a reference voltage, which is (presumably) the 5V of the LM2596T-5, which is not noise free.)
-My clock came with a 2.2 µF 400V cap, which I replaced by another 2,2 µF 350V cap when I was searching for a faulty part in the HV generation. I didn't mind secondary cap parameters at that time. Unfortunately, I'll have a hard time placing a larger cap in the clock-case that I plan. Maybe I'll have to mount it on the bottom side of the PCB. Would be interesting to see scope readings for different sizes of caps. (Ty, I am not sure if I would recommend that you try swapping caps again ;) )

(Edit: I wonder if I should give this one a try?! :pinch: )
Attachments:
Last edit: 1 year 4 months ago by Phil_Mod3.

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

More
1 year 4 months ago #9880 by MikeS

Phil_Mod3 wrote: Mike: I read from your first scope image, that the sweeps under normal operation is between 4-6 V p-p, is that correct?

Yea, I started to write "~+-2V", but actually wrote "~2V p-p" because the former looked ugly. :)

Phil_Mod3 wrote: If I understand the voltage sensing correctly, we could read HV voltages in a range from 0 to ~2486 V. The smallest step (one unit) in the output from analogRead() equals 2.43 V in HV.

It's a 10 bit A/D, across a voltage range of AVcc = Vcc = 5.0 V. So, that's 5/1024 = 0.004884 V/step. The voltage divider is 1/83.98. So, the A/D is ultimately sensitive to 0.004884 * 83.98 = 0.41 V.

But that brings up something else - any noise on the 5V side will be reflected in the A/D output, since it's used as the reference voltage. And that's a noisy switcher, too.

A 180V, 5W Zener is <$0.50. Hmmm.

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

More
1 year 4 months ago #9883 by Ian
A Zener would have been a simple fix, and would have made the whole thing so much easier, but it went against the idea of the integrated power supply, so it was not considered.

On retrospect, whether it is important to have a variable power supply using software is questionable, but that was the design criteria. I wanted to have the ability to get a few volts more for subborn tubes, and allow the board to adapt to any number of conditions. Any fool on his own can design a power supply that works with a potentiometer in it, but it takes a whole chat room full to design one in software... :laugh:

One point: the ADC could be configured to use the internal Voltage Reference, and not the supply voltage. That might be an improvemen in any case.

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

More
1 year 4 months ago #9885 by Ty_Eeberfest
Ian,
I beg to differ... we aren't a chat room full of fools, we're a chat room full of experts (at picking to pieces other peoples' work!) :evil:

Phil,
Scope shots: 33uF capacitor, code as described in my post directly above the scope shots. Sorry, I should have been clearer about that.

With checkTY() being called "fast" (like your fast example) impressions dropped to 95 - 96 per second. I conditioned the call like this:

if (!blanked && didSetup) checkTY();

where didSetup is the bodged-in flag I mentioned above.

Yea, IFs cost a few cpu cycles (not all that many really) but the real killer here seems to be calling anything that involves analogRead(). There is probably a much faster way to read the ADC, I just didn't have time to look into it yet. Actually I know from previous projects the ADC can be read much faster but those projects were done on ATMega chips in plain C - no Arduino core. analogRead() is an Arduino core function and I have not yet looked at how they implemented it, e.g. why is it so slow, and does its existence get in the way of accessing the ADC more directly.

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 #9962 by Ty_Eeberfest
Found the time to dig into the Arduino core. What I found is that analogRead() is built for comfort, not for speed. It does a good job of being versatile and shielding the programmer form the details of the ADC, but it does so at the expense of using the ADC in a pretty slow manner. Looks like every call to analogRead() eats about 200uS.

If all we needed to do was be a voltage regulator I could certainly write something that handles the ADC a whole lot faster. The trouble is, I can't see a way to do it that wouldn't break analogRead(). Since this isn't just a voltage regulator analogRead() is being used for other things like reading the LDR and detecting the PIR.

So... I don't have a solution to offer, but I kind of feel like this is a non-problem anyway since stucking a bigger capacitor in it has stabilized the voltage to the point that I can't detect any flicker at all.

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

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

Moderators: AccutronTy_EeberfestIan
Time to create page: 0.206 seconds

Search

Tube Suppliers

Go to top
JSN Boot template designed by JoomlaShine.com