Anyone used a CPLD to manage inrush?

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
I've gone through the kaleidoscope of in-series inrush and current management ideas, and pretty much all end up either (a) sucking power, (b) having a inrush spike on bypass.

I'm both (a) running 600mA class A and (b) charging 6mF of caps to get a smooth 1Vpp ripple. I'd like to have both (ie full load and inrush) so that the voltage regulator and the capacitor are started together to minimise the time to start. (the cap also acts as a low pass filter for the switching)

IXYS did a 'reference' design using a Zilog CPU to manage inrush (Digital Inrush Controller if you want to google) by essentially having the Zilog produce the PWM required to switch to manage the current through the system.

A faster option perhaps would be using a CPLD such as a MACH04 - this even exists as a breakout-style board. The CLPD can generate fast PWM based on an input mapping and trigger signal. The internal clock is 16MHz and so would be possible to create a 100KHz or better PWM.

External zero crossing, triac and mosfets could be used to handle the AC 240V power with high speed galvanic (ie 50Mbps+ capable) could then be used to isolate AC from low level voltages.

My university degree had realtime and embedded as part of this so I understand some of the gotchas in timing, concurrency etc with CPUs hence the interest in CPLD being more realtime focused with minimal boot time, fast response and singular purpose.

Just wondered if anyone has looked into this already?
 
Last edited:
More on the IXYS/Zilog here: http://www.zilog.com/docs/referencedesign/IXRD1002.pdf this includes the source code.

One thing I don't like about this source code is this:

Code:
int read_ADC_ch(Channel)
{
	unsigned int Result = 0;
	
	//while(ADCCTL0 & 0x40); //Wait for current conversion to finish.
	ADCINSL = Channel;       //Select new channel. NOTE: Don't use ADCINSH unless the scanning feature is used!
	ADCCTL0 &= 0x37;
	ADCCTL0 |= 0x40;         //start conversion.
	while(ADCCTL0 & 0x40);   //Wait for current conversion to finish.
	Result = ADCD_H << 8;
	Result = Result | ADCD_L;
	Result >>= 2;  //The 12bit need to be shifted into the right location: 11111111.11110000 >> 4 = 00001111.11111111
	return Result;
}

Note the blocking wait.. as long as the ADC is your only source of input that's fine.
 
Member
Joined 2014
Paid Member
Preset timing works and is simple. So unless it's for the hell of it (which is often the case in DIY) I still don't see the problem being solved. If its part of an integrated power up solution that includes winding up the bias under CPU control then it makes sense (and I believe NP uses this on his mighty meaty monoblocks). But otherwise a resistor and relay seem to work.


I'm super lazy and have considered a 'pre-charge' button.
 
Preset timing works and is simple. So unless it's for the hell of it (which is often the case in DIY) I still don't see the problem being solved. If its part of an integrated power up solution that includes winding up the bias under CPU control then it makes sense (and I believe NP uses this on his mighty meaty monoblocks). But otherwise a resistor and relay seem to work.

I'm super lazy and have considered a 'pre-charge' button.

Actually at one point I'd reverted to designing a NASA 1960s style array of switches in a long line - including a pre-charge bypass step - with timing scribbled on the panel. Only issue is the number of 50W resistors heating the case like a rocket on take off to limit the current so the secondary windings won't melt over the time it takes. The annoying thing is there's still an inrush spike from what I can see with LTspice unless a NTC is used to slowly finish off the final charging on bypass.

The other part was a piece around having cathode pre-biasing (30V) to stop the valves going into full conduction and additionally muting on startup. I had thought about a Arduino style mini screen but I have rather strong feelings about mixing power control and other functions. Perhaps a CLPD with a "power ready" signal and an override for the mute for isolating should it see an current problem.

The CLPD would be relatively easy to test with logic level connections and low power AC (ie 24V AC) before moving to high power.
 
Last edited:
Interesting PWM Example code here: https://www.digikey.com/eewiki/pages/viewpage.action?pageId=20939345

VHDL source code of a PWM generator component
Configurable duty cycle resolution
Configurable number of outputs/phases
Configurable PWM frequency
Modulation around the center of the pulse
PWM inverse outputs

Personally I would be interested if this also could take in a ADC input on one of the pins.. ADC across as a sense resistor and build in the logic to process ADC clocked signals to set the PWM duty cycle.

An on-off switch logic could be setup.
 
It's occurred to me - that one of the papers I read on PWM identified noise being an issue - both in clean detection and timing (ie from noise/distortions).

In the case where sensing of current is done electronically, the zero cross point ends up being a random distribution in time with multiple crossings due to noise, therefore multiple samples are required per sample (ie 10x the rate).
This is ignoring transient noise at the point of cross over,

The current is 90deg ahead so the window we process for current needs to take that into account.

In the end this is all about Q over time and marrying what is available and what is needed.

This means at the edges of the cycle where the current draw if switched on may result in a false zero cross or unreliable zero cross if Q is taken from that area.

A strategy that I think would work best is a zero trust. Where each cycle starts with an off state and needs to consume a duty input from the processor. That way the processor must provide a required duty for each cycle (ie 100 times a second for 50Hz) otherwise no power is supplied. This means if the sensor or CPU is damaged, it doesn't provide power.
This also means CPLD doesn't rely on a previous cycle's measurements.

Also in that paper it also made a point about using parallel separately switched Triacs to cope with ensuring recovery times etc of components didn't limit the PWM. Additionally this extended to rectification diodes on secondary side implementations.

If the CPU is fast enough (use FFTW for example) it could use a DFT on the zero crossing and look for a low frequency change. However that is likely to take ms. CERN used 1000s of FPGAs programmed with a FFT pipeline to process raw incoming signals fast enough to cope with the high data rates. They'd then filter the result and provide a them to the slower processors.

The cycle would then go:
1. Sub sampling of the AC line is done 10x sample rate and each sample averaged to give the sample. This is to average sensor, digital signal noise and high freq AC noise.
2. Sample rate shows a 5 samples average line increasing from V0, the sampling averaging here combats lower frequency noise.
3. V0 cross over deduced to have occurred indicating the +90deg that current is currently at.
4. CPU does a table look up to quantify the Q from the current sensor input and issues the Qduty to the CPLD for this cycle. If the results are outside of the table, the CPU has the option if not providing a Qduty rate thus leaving the power off for this cycle.

If the scheme is enhanced slightly, the CPU could select a mosfet with power resistors to limit current in addition to the PWM.

I need to dig out that paper out of my browser history it was interesting!

The advantage of the CPLD over the CPU performing the PWM is speed. Using the CLPD to perform the PWM itself but recognising it's very limited other than timing and action, then using the CPU for the slower cycles makes the best of both worlds.

The down side in using the CPU for the sensory part is the delay that is incurred, a zero cross to trigger the CPLD directly has more accurate timing.
 
Last edited:
I just found this very interesting phase angle control from ST: https://www.mouser.com/catalog/specsheets/stevalill004v1.pdf

Using an 8bit microcontroller: https://www.st.com/resource/en/datasheet/st7lite09y0.pdf

section 11.2.3 shows it's PWM, so basically it has a auto-reloading timer and can do PWM without taking microcontroller processing time. Essentially the software simply provides the duty time and the chip does the rest - removing the need for the CPLD. Probably not quite as fast but still.

Section 13.11 shows it's 8bit ADC with 5 input channels - enough to take zero crossing, sense resistance both sides for current sensing. Would need to check this more - only issue is that the SPI interface uses the same pins.

Essentially it could sense and perform PWM against a programmed table of duty vs current.

This is interesting because the evaluation board shows (a) it running 270V AC and (b) demonstrated running 500W halogen.
 
Last edited:
With that much capacitance, as well as continuous power consumption, the charging current waveform, and ipso facto the mains current waveform, is going to be very spiky. Why not give the mains supply some quality time and use a PFC input stage with slow start.

I think there's time needed to research this fully rather than rush it.

There's a lot of issues, such as being careful where in the current waveform the power is taken and for how long per PWM pulse. The resulting impact to the transformer and back to the mains supply also needs some thinking.

Almost need three phases:
1. transformer magnetisation inrush handling
2. black cap without load current startup and recharge limiting
3. load current startup

I'm just surprised that there's very few products - the majority of ICs etc are specific to boost/buck topologies so immediately have inductor and a flyback as part of the IC design.
 
With that much capacitance, as well as continuous power consumption, the charging current waveform, and ipso facto the mains current waveform, is going to be very spiky. Why not give the mains supply some quality time and use a PFC input stage with slow start.

I see why you say that - the load causes the current waveform to become spiky with just resistors:

MGckBmF.png


The PFC would help reshape that to a sine wave and help the mains at the same time. Let me have a look and see if there's an off the shelf supply.
 
Going back a step, did you have specific problems or concerns as to why you wanted to include inrush control?

One practical hassle could be tripping a mains feed cb, which can happen as transformer VA gets larger and larger. The same may go for the mains inlet fuse in your equipment. Both of those issues go to detailed awareness of the inrush waveform, and the protective device trip conditions.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.