If you need assistance, please send an email to forum at 4hv dot org. To ensure your email is not marked as spam, please include the phrase "4hv help" in the subject line. You can also find assistance via IRC, at irc.shadowworld.net, room #hvcomm.
Support 4hv.org!
Donate:
4hv.org is hosted on a dedicated server. Unfortunately, this server costs and we rely on the help of site members to keep 4hv.org running. Please consider donating. We will place your name on the thanks list and you'll be helping to keep 4hv.org alive and free for everyone. Members whose names appear in red bold have donated recently. Green bold denotes those who have recently donated to keep the server carbon neutral.
Special Thanks To:
Aaron Holmes
Aaron Wheeler
Adam Horden
Alan Scrimgeour
Andre
Andrew Haynes
Anonymous000
asabase
Austin Weil
barney
Barry
Bert Hickman
Bill Kukowski
Blitzorn
Brandon Paradelas
Bruce Bowling
BubeeMike
Byong Park
Cesiumsponge
Chris F.
Chris Hooper
Corey Worthington
Derek Woodroffe
Dalus
Dan Strother
Daniel Davis
Daniel Uhrenholt
datasheetarchive
Dave Billington
Dave Marshall
David F.
Dennis Rogers
drelectrix
Dr. John Gudenas
Dr. Spark
E.TexasTesla
eastvoltresearch
Eirik Taylor
Erik Dyakov
Erlend^SE
Finn Hammer
Firebug24k
GalliumMan
Gary Peterson
George Slade
GhostNull
Gordon Mcknight
Graham Armitage
Grant
GreySoul
Henry H
IamSmooth
In memory of Leo Powning
Jacob Cash
James Howells
James Pawson
Jeff Greenfield
Jeff Thomas
Jesse Frost
Jim Mitchell
jlr134
Joe Mastroianni
John Forcina
John Oberg
John Willcutt
Jon Newcomb
klugesmith
Leslie Wright
Lutz Hoffman
Mads Barnkob
Martin King
Mats Karlsson
Matt Gibson
Matthew Guidry
mbd
Michael D'Angelo
Mikkel
mileswaldron
mister_rf
Neil Foster
Nick de Smith
Nick Soroka
nicklenorp
Nik
Norman Stanley
Patrick Coleman
Paul Brodie
Paul Jordan
Paul Montgomery
Ped
Peter Krogen
Peter Terren
PhilGood
Richard Feldman
Robert Bush
Royce Bailey
Scott Fusare
Scott Newman
smiffy
Stella
Steven Busic
Steve Conner
Steve Jones
Steve Ward
Sulaiman
Thomas Coyle
Thomas A. Wallace
Thomas W
Timo
Torch
Ulf Jonsson
vasil
Vaxian
vladi mazzilli
wastehl
Weston
William Kim
William N.
William Stehl
Wesley Venis
The aforementioned have contributed financially to the continuing triumph of 4hv.org. They are deserving of my most heartfelt thanks.
Registered Member #33
Joined: Sat Feb 04 2006, 01:31PM
Location: Norway
Posts: 971
I'm starting to like Joshua's idea of using a softcore in the FPGA, depending on how much room it takes up in the FPGA. According to some site I found, microblaze used up around 1k LEs, which is around 1/9 of the SLX9. I don't know what the compilers for it are like, but if they are usable, I think we should consider it.
Registered Member #3900
Joined: Thu May 19 2011, 08:28PM
Location:
Posts: 600
I've only tried FDD8424s in the PN driver and I've had no trouble at all with it. Do you have any good suggestions on alternate drivers? UCCs are fine but a bit weak if the board is used to drive bricks. Maybe a fullbridge of n-channel FETs with high-side gate drivers could be used, it would add a lot of parts though.
i have had no problems with it, but i can see that using mosfets with slightly different delays would cause problems like that. i use the FDB8030L and NDB6030PL. they work just fine. my problem is with bootstrapping in general. i don't like the fact that it has a minimum frequency. same with gdt's. i will look into an alternative, the ucc chips use paralleled bjt's and mosfets to fix some of that. an optocoupled on board high and low side driver might be key as long as space isnt too much of an issue. where trace length isn't a problem, standing a pcb off from a pcb is an option. there could be a layer for power, fpga, and gate drive.
and what about labview? i know its used for the spartan fpga's used in the frc cRIO modules. it seems like having a software program that not only displays code in the same format that the fpga physically works in, but also can simulate it real-time could be an asset.
Registered Member #89
Joined: Thu Feb 09 2006, 02:40PM
Location: Zadar, Croatia
Posts: 3145
Hi guys
fastish ADC like the AD9280
Fastish? More like sluggish and low-resolution in my opinion - I'll be testing this with 200MSPS 14 bit ADC's! Might be a huge overkill indeed
Then you can easily implement the Prediktor as an IIR filter, just a digital simulation of the actual circuit. That's much harder if you only know the zero crossings and not the whole waveform.
Well, that is another thing I now consider obsolete. I no longer see merit in using a phase lead compensating filter for this purpose - instead, I intend to design the whole loop as a stable system - that is, with 180 degree feedback instead of 360. Then, I'll add transport delay until it becomes unstable and oscillates! Maybe I should call it "kontradiktor".
On the other hand, I probably will have a digital band-pass filter immediately after ADC.
Later, I might even explore possibilities of digital PLL and assorted other ludicrosities!
I like this idea because it's faster than RS232, and you could drive it off a laptop with a digital audio output.
Hm, if you intended to control the whole thing over PC RS-232 port, then it probably is rather slow. On the other hand, if you use MCU UART, you don't have to be limited to 19200baud or whatever, you can go into megabits if you like (shouldn't be too problematic with fiber optic link)
I wouldn't use toslink over PC as my primary control method (how many laptops even have it?). I'd rather use connection of my remote controller to the PC (if you use a bigger microcontroller with USB bootloader, then USB obviously is a method of choice)
I'd also absolutely have duplex link, which would be kind of cumbersome with two toslink cables. Also, DC level possibility is a bonus for my design (which I'll explain later)
I've also considered those gigabit ethernet devices you talked about: for just about any microcontroller, they are just ludicrous even if you use serializer/deserializer chips. But then I thought of something: if you can get and use those chips, you could run everything from a single microblaze or whatever system from FPGA, and have everything in your remote controller simply connected to the multiplex chips.
I've only tried FDD8424s in the PN driver and I've had no trouble at all with it. Do you have any good suggestions on alternate drivers? UCCs are fine but a bit weak if the board is used to drive bricks. Maybe a fullbridge of n-channel FETs with high-side gate drivers could be used, it would add a lot of parts though.
Well, I'd like to do more research into this mosfet thing first which is time consuming. Other than that, I'd most rather use surefire drivers, such as the new IXDN614 (they are now compatibile with 3.3V unlike their predcessors). I have the same trouble getting them as with FPGA's though.
Having boards professionally made is exceptionally cheap these days. 10 10x10cm double-sided boards with 6mil clearance and silkscreen on both sides costs less than 30 dollars including shipping.
What/where/omg linx?
Digikey seem to have a good selection of FPGAs, and I think they do free shipping for orders over a certain size. Some FPGAs can be had cheaper on eBay, like the EP2C5T144 that I mentioned earlier, which can be had for 10 dollars with free shipping.
Free shipping for you, $120 flat to croatia regardless of quantity. Same with avnet, the other xilinx fpga distributor I know. There didn't seem to be an option for a cheaper shipping option.
I guess my only real hope is some sort of a group buy since I only need 2-3 FPGA's for experiments!
I'm starting to like the idea of using a softcore instead of an external microcontroller, as long as it doesn't mean that we need a much more expensive FPGA. Do you know the typical resource usage of a minimal microblaze/picoblaze core?
I'm currently working on a picoblaze system, and I think it's more than suited for the low level work it has to do here - just a couple hundred asm lines. Picoblaze only takes about 8-10k gates; can fit dozens of them even on the smallest of fpga's!
Microblaze is probably like 100-200 k gates, depending on what pheripherials you put in, IIRC. I didn't even know it has been made free in meanwhile.
I suppose one feature of this project would be that the "brains" would all be HDL, so you could theoretically put it on a FPGA from any vendor. I guess that was why the Department of Defense invented VHDL in the first place.
Meh, and it failed - just like with any other programming language in existence. WIth any project slightly more complex than blinking a led you'll need to instantiate unavoidable primitives that xilinx designed into chip as ahrdware - for example DCM's, or LVDS transcievers.
The FPGA I use for my work projects is the XC3S100E-TQG144, with the XCF04S config PROM. It's available from Farnell for £10. I made an Eagle footprint for it.
Well, spartan 3 are about to become obsolete, and spartan 6's now offer more power at even less price - hence the desire to transition to them. Those JTAG configurable EPROM's are expensive as hell - that's why I'll avoid using them too :)
I soon figured I don't really want to stick my PC onto the tesla coil every time I want to change something - I really want the downloading procedure to work over fiber optics too. You might ask yourselves how I intend to do it without any onboard eeproms and just two fiber optic lines - this is where one of more hardore hacks comes in:
The neat possibility with ATmega's is that their USART can be actively reconfigured to work in synchronous mode. The rx pin will be connected to the clock input pin for the usart.
On the FPGA side, the fiber optics will terminate on the SPI configuration port, with Rx line being data and tx line clock - this allows the fpga to take over the line as a master and treat the mcu like any other flash chip it would normally downlaod from. Due to automated USART operation, MCU will have plenty of time in meanwhile to retreive data from SD card.
Once download is complete, both SDA and SCK pins on fpga can reconfigure to work like normal IO and be connected to normal communication UART.
I found the AD9280 inside a Cambridge Audio DAB tuner, it seems to hit about the right price/performance spot for a TC driver. I believe only one channel is required, but a second one would be nice. (say for instance you want secondary base feedback and primary current limiting, or you want to see the H-bridge output voltage, though isolation would be a real pig)
There are several SPDIF transmitter chips from Crystal and AKM. Crystal released several versions, I think they started with the CS8402 and ended with the CS8406. Higher end MCUs like the dsPIC may have a SPDIF transmitter built-in nowadays.
Hm, is there any special reason you favour SPDIF protocol so much? In my opinion getting all those chips would just be another major pain in the but. If the inherent redudancy of commands I intend to use doesn't help, I guess I'll have to implement some sort of eror correcting code - but I highly doubt that will be necessary at just 1Mbps or so.
I'd certainly have at least two ADC channels, and more the better - not all necessarily have to be too fast. I don't want to limit this system just for tesla coils; I want, for example, to be able to control several control loops at once. Two ADC channels + two gate drivers are probably good enough for start, though.
For example, for QCW coil it'd be very useful to monitor DC bus voltage - which would be a good job for HCPL7800 isolation amps.
Any thoughts on a microcontroller for the other end? STM32, ATMega or the like? I'm hoping for control by a laptop with some simple software, but I think many people would want a traditional remote control box with a LCD or VFD screen.
Well, for start I'll go with ATmega 16, but in future I'd like to try some ARM's from NXP. The AVR system will be retro style and cumbersome with a big monochrome 128x64 graphic LCD, fire and power button, an SD card slot and perhaps some sort of a keypad.
Registered Member #30
Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
The reason why I like SPDIF is because it fits into my plans for world domination. I want to make the ultimate Tesla musical instrument, and the signal processing part of it will basically be a soft synth running on a PC. If I use digital audio as the control data stream, I can reuse the PC digital audio infrastructure.
One use case might be: Guitar with 6 individual pickups -> Off-the-shelf 6-channel audio interface -> Bunch of OMG DSP plugins written by me that transform the audio into Tesla coil control signals in real time -> Audio interface's SPDIF output -> New FPGA driver -> Awesomeness on an epic scale
Of course we could do a group buy on the hardware and customise the firmware (or whatever you call the stuff inside a FPGA) to our tastes. SPDIF for me, SPI for Marko (don't forget a third fibre for the clock :p)
One final thought: I don't like the idea of having the main processor inside the Tesla coil. I'd prefer to keep the guts simple at that end. How about using the GbE transceivers and serdes chips like someone suggested, but the other way around, put the FPGA and all the other brains inside the remote, which would become a seriously hefty "power electronics computer", while the coil end was just a bunch of ADCs and gate drivers.
Registered Member #89
Joined: Thu Feb 09 2006, 02:40PM
Location: Zadar, Croatia
Posts: 3145
Of course we could do a group buy on the hardware and customise the firmware (or whatever you call the stuff inside a FPGA) to our tastes. SPDIF for me, SPI for Marko (don't forget a third fibre for the clock :p)
Well, fpga configuration is unidirectional, hence the return fiber serves for clock!
One final thought: I don't like the idea of having the main processor inside the Tesla coil. I'd prefer to keep the guts simple at that end. How about using the GbE transceivers and serdes chips like someone suggested, but the other way around, put the FPGA and all the other brains inside the remote, which would become a seriously hefty "power electronics computer", while the coil end was just a bunch of ADCs and gate drivers.
Well, I considered the same at first, but keeping it close to adc's and gate drivers still makes more sense than moving it to battery powered box.
Any way around, It's still kond of esoteric proposal as I think.
Registered Member #2288
Joined: Wed Aug 12 2009, 10:42PM
Location: Cambridge, MA
Posts: 179
As for the PN driver, I have found that the drive voltage is what matters. I put an LM317 with a pot on the chip driving the PN bridge, and there is a certain voltage where the output squares up (usually around 7-8V), and then above that there is a voltage where shoot-through begins (usually around 9-10V). If you run between these, there are no issues. All FET combinations will have slightly different voltages here, since the issue is the threshold voltages of the two FET's. If the control voltage is too high in magnitude, there will be significant time when both FET's are on.
Registered Member #89
Joined: Thu Feb 09 2006, 02:40PM
Location: Zadar, Croatia
Posts: 3145
Hi dude500,
In the end I intended to use several parallel 74HCT540/541 gates for pre-drivers, which would limit the voltage to about 5V which should be enough for logic level mosfets. Do you think this would work and prevent shoot through as well?
Failing that I could route two extra wires to the pfga and add delay circuitry to minimize shoot through.
Registered Member #30
Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
Dude_500, I'd be worried about temperature dependence and variation between MOSFET batches on that voltage, since it's obviously related to the MOSFET threshold voltage.
This site is powered by e107, which is released under the GNU GPL License. All work on this site, except where otherwise noted, is licensed under a Creative Commons Attribution-ShareAlike 2.5 License. By submitting any information to this site, you agree that anything submitted will be so licensed. Please read our Disclaimer and Policies page for information on your rights and responsibilities regarding this site.
FPGA TC driver board
