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

More
1 year 4 months ago #9837 by Ian
Hi Phil

that's great analysis, and a fine solution to something that has been at the back of my mind for maybe 2 years. I was aware that there are occastional "farts" in the HV generation, you can hear them as a faint "click" every now and again, but I had never, (im my psychotic rush for new features), analysed what exactly what going on.

I also only have a crappy analogue scope that never quite manages to trigger how it should. Perhaps it's time to upgrade myself into the 20th Century.

What was that saying about "a bad workman always blaming his tools"?

Anyhow, I'll work on that next week, and I'm also tending to take a middle route on the checkHVVoltage() call. Instead of checking it once per inner loop (100Hz) I'm looking at moving it to once per second. I can't bring myself to totally can it just yet...

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

More
1 year 4 months ago #9839 by Ian
I made the changes and pushed them. I'll tag it for release as long as no collateral effects are found.

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

More
1 year 4 months ago #9840 by Ty_Eeberfest
Interesting stuff here. When I was experimenting with the HVG code I was focused so much on how PWMTop was being controlled that I never thought to look at how the counter itself was being managed. But then I wasn't looking for spikes and noises - I was trying to get smooth but responsive regulation.

Putting the CheckHV call in the once-per-second function might be a good idea. My efforts were aimed in the other direction: trying to make it faster so it would respond more like a "real regulator" rather gradually applying what amounts to trim.

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 #9841 by Ian
I spent ages on getting it to be a "real" regulator, even going to the point of using a controller dedicated just for that. I didn't manage to get good results.

That doesn't mean that good results are not possible, just I didn't find the ray of moonlight that showed me the door.

In the end, I went back to the idea of using a 34063: they are jelly bean parts, well understood and reliable. With the Wemos designs I didn't even try to use them for the HV.

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

More
1 year 4 months ago - 1 year 4 months ago #9842 by Torsten Lang
Hi Ian,

Ty_Eeberfest wrote: Yes, I like my boost converters to be implemented in hardware :cheer:

Ty_Eeberfest wrote: Seems to me that a 6 tube clock running on 5V will be on the hairy edge, current-wise, of what some USB ports will happily deliver. But I guess the whole world runs on USB-C connectors now.

I'm with Ty and also do prefer the hardware solution as you have seen from my project although the bigger family members of the ST Micro controllers I use for my projects do have special motor control units that possibly could be used in conjunction the the comparator to implement a boost converter.

The major problem you will run into are the extreme duty cycle values you will get when having an extreme Vout to Vin ratio. Even for the prototype of my VFD clock project which used another driver implementation and required only one positive anode voltage of 50V I did create it by stepping up from 5V to 25V and doubling the voltage as otherwise I would have required a duty cycle of over 90% which all converters which were proven to be working stable and flawlessly in our various projects didn't support. The TPS61175 was only a tight miss but nevertheless I decided it was too risky to try it.

For stepping up from 5V to 170V it would be over 97%. I think it will be difficult to find a boost converter that can handle this.

And the currents drawn on the 5V line become quite high. You would need a real USB interface and check if you're connected to a charger or a charging downstream port.

This is why I implemented a full USB interface even in my clock so that I can check if I'm allowed to draw the required power. Even small controllers nowadays have USB and with the model I use I can detect regular downstream ports as well as ACA, CDP or DCP and even PS/2 interface and in case of any real USB port can wait until the interface is configured before allowing the converters to start up.

Ian wrote: Transformers. Strangely, it makes the electrical design easier: you don't need special MOSFETs, because they only have to deal with the primary side, and with a 1:5 or 1:10 step up, we're talking about max 40V. However, that is more than offset by the extra fiddling that transformer circuits bring on the placing of components and getting the efficiency.

A flyback transformer will reduce the requirements for the boost converter. I think this is what I will use for my first nixie project.

Ian wrote: I spent ages on getting it to be a "real" regulator, even going to the point of using a controller dedicated just for that. I didn't manage to get good results.

As said, I thought about testing a cheapo version implemented in the controller but I'm not sure if it's worth the few saved bucks.

With best regards,
Torsten
Last edit: 1 year 4 months ago by Torsten Lang.
The following user(s) said Thank You: Ty_Eeberfest

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

More
1 year 4 months ago #9843 by Ty_Eeberfest

Phil_Mod3 wrote:
Would be good if anybody could try to replicate this.


All I have on hand is a Fluke portable scope. It's a decent scope for basic stuff <= 25MHz but doesn't have much for features.

I tried replicating your experiments and had mixed results:

I found the HVD signal to be glitchy, same as what you found. Adding your TCNT1 = 0 patch resulted in glitch-free HVD as expected.

Even with glitchy HVD my HV didn't look nearly as bad as yours. I couldn't see any inductive spikes although there's a chance they were present but too fast for my scope. Your HV shows more cyclical wandering than mine too. NOTE: I was running a clean copy of the code, so checkHVVoltage() was being called on every iteration through loop().

With checkHVVoltage() called from loop() the drop and overshoot going into the date transition was the same as what you observed. Putting checkHVVoltage() in the once-[er-second function reduced the overshoot to almost nothing.

With checkHVVoltage() commented out so as to never get called during normal operations I find my HV jumps around by approximately 5v as the separators blink and digits change. Oddly my display looks less flickery this way than it does with checkHVVoltage() being called either in loop() or once-per-second.

As a side note, checkHVVoltage() changes pwmTop every time it's called, even if the error is zero. I think the else should be something like "else if (getSmoothedHVSensorReading() < rawHVADCThreshold)".

The whole checkHVVoltage() thing bothers me but I don't have a good solution to propose (yet?). Whether called every time thru loop() or only called once per second, it is always called when the HVG is OFF. This is the root cause of the overshoot going into date display. HVG is off for an unusually long time during the start of the "slots" transition to date. If checkHVVoltage() is called every time thru loop() this results in pwmTop "winding up" as the code tries to pull up the falling voltage, and when the HVG comes back on pwmTop is too high and has to "wind back down" to kill the resulting overshoot. Calling checkHVVoltage() only once per second makes the problem go away but it just feels like a dodgy fix that doesn't really address the cause.

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.182 seconds

Search

Tube Suppliers

Go to top
JSN Boot template designed by JoomlaShine.com