HTCC (Hydra Tesla Coil Controller) / Tesla Coils / Forums

Forums

4hv.org :: Forums :: Tesla Coils

« Previous topic | Next topic »

HTCC (Hydra Tesla Coil Controller)

previous 1 2 3

Move Thread

LAN_403

Goodchild

Tue Apr 22 2014, 03:05PM

Registered Member #2292 Joined: Fri Aug 14 2009, 05:33PM
Location: The Wild West AKA Arizona
Posts: 795

Hydron wrote ...

The $10 difference in FPGA price is pretty insignificant in the bigger scheme of things. More important is how DIYable it ends up - avoiding a big BGA which can't be inspected after soldering is worthwhile.

Out of interest, are 100-QFN Spartan 3ANs even available? A quick check on digikey/xilinx sites showed a 144TQFP as the lowest pin-count package, no QFN to be seen. QFP would probably be a bit kinder anyway to those without hot air/reflow ovens, but is a bit bigger (22x22 vs 17x17 mm footprint for the BGA).

ahh you are correct the 144TQFP is the smallest one, for some reason I thought it was in a QFN100. The plan is to move down to the XC3S50AN (144 TQFP), however under further observation it only seems to have 3 multipliers. My current phase lead FIR filter design uses 4 taps (4 multipliers). It will probably still work with 3 but I hate to degrade performance.

And yes price is not the driving factor, using the smaller part makes it solderable via iron or hot air, a lot more common than the big old IR reflow ovens/BGA rework station needed for BGA work. The last reason is that the other part is very much overkill, I'm currently utilizing less than 2% of the gates on the 200AN.

13970874794 A79cfc21d0 C

Steve Conner

Tue Apr 22 2014, 04:27PM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

Could you use some sort of state machine to make one multiplier compute several taps?

Hydron

Tue Apr 22 2014, 10:44PM

Registered Member #30656 Joined: Tue Jul 30 2013, 02:40AM
Location: UK
Posts: 208

Steve Conner wrote ...

Could you use some sort of state machine to make one multiplier compute several taps?

Hah, it's much easier than that! You just use too many multipliers and the logic synthesis tool will transparently make more out of standard gates.

I once made a colour space (gamut) converter in an Altera Cyclone 2 5k logic element FPGA which required 18x 18-bit multipliers running at ~150MHz. Despite only having 13 in hardware it synthesized and ran fine, just used a decent chunk of logic to make the rest. I can't recall exactly how much it used but I had easily enough space. I was however surprised they ran quick enough, even when optimizing for speed rather than size. You could easily test if your 4-tap design would fit in the smaller Spartan 3AN by compiling your existing design for the smaller chip.

Do you have any design info you'd be willing to share at this stage? I'm currently designing a new (DR)SSTC driver largely based on Steve Conner's PLL circuit, but all the FPGA talk is inspiring me to ditch all the discrete logic and put in a CPLD/FPGA, so I'm interested in how you're doing yours. All good if you're not ready to release anything, I know what I'm doing and my design would be substantially different anyway.

Steve Conner

Wed Apr 23 2014, 08:05AM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

As it happens I am also interested in "porting" my PLL driver to a FPGA.

The PLL can be done on a microcontroller, it doesn't really need the power of an FPGA, but I think the FPGA is the way forward generally.

I'd like to see different kinds of drivers available as open-source IP cores for hobbyists to modify and tinker with.

Hydron

Wed Apr 23 2014, 12:10PM

Registered Member #30656 Joined: Tue Jul 30 2013, 02:40AM
Location: UK
Posts: 208

Steve Conner wrote ...

As it happens I am also interested in "porting" my PLL driver to a FPGA.

The more I look at this stuff the keener I am to have a play with it. Given that we're unlikely to be playing with frequencies higher than a few hundred kHz, all the crusty analogue/4000 series stuff should be replaceable with a bunch of glue logic in the FPGA and an all-digital PLL made of a phase detector, digital filter and a numerically controlled oscillator. A PLL based driver doesn't even need a fast ADC like Eric's (though it's probably worthwhile to add for implementing current limiting etc and general flexibility). Obviously there are some limitations like the lack of phase lead on the first few cycles (I'm assuming the PLL takes a while to lock into perfect zero-crossing switching), but the flexibility of the digital implementation should let us do stuff on the fly that's impossible with trimpots etc.

I can guarantee there will be some gotchas along the way (and a fair bit of work), but I think I'll put off building an analogue/4000 series driver and have a play with some FPGAs first.

Steve Conner

Wed Apr 23 2014, 01:03PM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

Yes. My Mk2 PLL driver is 8 years old, well due for a redesign, and FPGAs are much more accessible now.

From what I hear, Steve Ward has now gone over to a digital PLL implementation for the Arc Attack coils and likes it. He did it exactly the way you said, except using a microcontroller. The NCO is one of the timers, and the digital loop filter is done in software.

The Prediktor style phase lead drivers also suffer from hard switching on the first few cycles.

I found that I could tune out the hard switching with the PLL, but at the cost of making the system unstable. When tuned for no hard switching on the initial cycles, it starts out balanced exactly between the two pole frequencies and can't decide which one to settle onto.

I think the same limitation applies to the Prediktor even if the phase lead circuit were mathematically perfect. It's not an issue in practice because the primary current is low during the first few cycles.

Goodchild

Wed Apr 23 2014, 03:09PM

Registered Member #2292 Joined: Fri Aug 14 2009, 05:33PM
Location: The Wild West AKA Arizona
Posts: 795

I have found that will a FIR filter the first cycle is no longer an issue. The driver will lock into phase lead near instantaneously. The other nice thing about the FIR is that itâ€™s inherently stable, however this comes at the cost of large hardware implementation due to the big multiply/accumulates needed. This is typically why you donâ€™t see them implemented in MCUs, rather you see it's cousin the IIR filter instead.

I could implement the FIR with 3 taps and have it work without issue most likely. Pipelining could also be added at the cost of speed.
In regards to the ADC, the FIR that can also tolerate a much slower ADC than what Iâ€™m using now. I may downgrade to maybe a 10Msps ADC from the 100Msps. This would help with cost significantly as my current ADC is about $24 per unit.

Wolfram

Thu Apr 24 2014, 08:34AM

Registered Member #33 Joined: Sat Feb 04 2006, 01:31PM
Location: Norway
Posts: 971

Excellent project! I can only start to imagine the things which will be possible with such a flexible controller.

Have you looked at the Lattice MachXO2 series of devices? Like the Spartan 3AN, they come with built in configuration flash, and they are available with up to 2k macrocells in TQFP100 and 7k macrocells in TQFP144. It's difficult to compare FPGAs across different families, but I believe these chips are similar in capacity to the XC3S50AN and the XC3S200AN respectively, in a smaller package. They don't seem to have built-in multipliers, but they have almost twice as many macrocells, which should make up for that. They also come with a built in oscillator, and the -HC ones have the core voltage regulator internally as well.

I've bought a couple of very cheap developement boards with these devices mouser.com/ProductDetail/Lattice/LCMXO2-7000HE-B- EVN/?qs=sGAEpiMZZMsnjpsy% 2frzfANGJheEjgAAzmuF4C2z9mA0%3d . I've done some quick tests with them, and the free version of the toolchain seems to be quite similar to ISE and Quartus.

Out of interest, how many taps do you use for the phase lead FIR filter? I would be very interested in looking at the HDL and checking how much resources it uses on these FPGAs without dedicated multipliers, if you're willing to share the code.

previous 1 2 3

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob