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 #2292
Joined: Fri Aug 14 2009, 05:33PM
Location: The Wild West AKA Arizona
Posts: 795
Bushman wrote ...
Thanks Eric, I am using the Mini MIDI/DR controller from Paul Slawinski which does the job. Then between the computer and the controller I have the dreaded USB cable Trying to picture your setup and how it is different from what I am doing?
I can not speculate on problems of hardware built by others, however my design has no need for USB to MIDI converters. I plug my controller into the computer via USB directly and it shows up as a HID MIDI device.
The MIDI serial is confined to the PCB inside the metal case making it very noise immune. Only the USB link is external, which being fully differential is not bothered by the coils EMI, I have yet to get this controller to hang.
As seen above I have two USB ports, one is for MIDI IO the other is for programming/data.
Partly assembled board, for some reason I can't find any photos of a fully assembled board.
This board also has charge management built onto it for single cell LiPo batteries. Also because this is a fully USB compliant device it can be powered from the USB bus directly, as well as charge LiPos.
The PCB and concept behind this controller I plan to distribute under the share alike non-commercial licence in the future.
Registered Member #6038
Joined: Mon Aug 06 2012, 11:31AM
Location: Salado, TX
Posts: 248
Wow - very cool indeed. Thanks for sharing the photos. Does sound like a solid solution and makes a lot of sense. probably the only guaranteed method to solve the problem.
Registered Member #30656
Joined: Tue Jul 30 2013, 02:40AM
Location: UK
Posts: 208
The specific issue with these midi controllers is likely due to poor design, so there are probably other solutions too, but Eric's looks like a particularly classy way to do it.
Note that MIDI inputs should be opto-isolated (no gavlanic connection for either ground or signal) by specification, so no ground loops or anything - the USB-MIDI converter should be able to deal with EMI by clamping any induced voltages, but probably doesn't cos it's cheap chinese made garbage. If done inside the equipment like Eric's then you don't need to worry about any of this, as it doesn't pick up anything anyway.
USB is only mostly differential by the way, there are single ended reset and end-of-packet states (both lines low, see , but when done well should be okay as long as it doesn't get too close. USB definitely causes issues in some circumstances, and is nowhere near as EMI immune as stuff like ethernet, so should always be regarded as suspect when things aren't behaving as expected around a tesla coil.
Edit: Looks like nice work Eric! Looking forward to having a look at the design if/when you release it.
Registered Member #2292
Joined: Fri Aug 14 2009, 05:33PM
Location: The Wild West AKA Arizona
Posts: 795
Hydron wrote ...
The specific issue with these midi controllers is likely due to poor design, so there are probably other solutions too, but Eric's looks like a particularly classy way to do it.
Note that MIDI inputs should be opto-isolated (no gavlanic connection for either ground or signal) by specification, so no ground loops or anything - the USB-MIDI converter should be able to deal with EMI by clamping any induced voltages, but probably doesn't cos it's cheap chinese made garbage. If done inside the equipment like Eric's then you don't need to worry about any of this, as it doesn't pick up anything anyway.
USB is only mostly differential by the way, there are single ended reset and end-of-packet states (both lines low, see , but when done well should be okay as long as it doesn't get too close. USB definitely causes issues in some circumstances, and is nowhere near as EMI immune as stuff like ethernet, so should always be regarded as suspect when things aren't behaving as expected around a tesla coil.
Edit: Looks like nice work Eric! Looking forward to having a look at the design if/when you release it.
Thanks for the kind words!
Part of the problem with those cheapo china made USB-MIDI things is the way they handle termination of the ground and shield on both the USB and the MIDI. I have seen it range from tied together to nothing connected with everything left floating.
USB standards don't really spec any defined way to terminate the shielding on USB slaves, as a result every manufacture handles it differently. I handled it by tying it to chassis ground, while also terminating chassis to DGND in a single location. This keeps the chassis from floating but helps prevent ground loops in the shield/GND line in the USB cable.
In addition filtering is employed on the USB data lines before being fed to the chassis grounded USB transceiver.
EDIT I have always been torn on how to handle the shield with MIDI, because it's data lines should be isolated and your DGND should also tie to chassis in at least one point to prevent a voltage from building up on the chassis. However if this is done, typically this makes your galvanic isolating opto pointless, because USB to MIDI converters typically tie their shield to their local ground.
Registered Member #30
Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
I think optoisolators are pointless for actual galvanic isolation around Tesla coils. Any half decent Tesla coil should be able to induce enough voltage in its surroundings to break an optoisolator down. When I've used them, it's in the way Eric described, with both sides grounded to more or less the same ground. In this configuration the opto basically acts as a sort of common-mode choke, protects sensitive logic from overvoltages, and also strips out high frequency spikes in the differential mode due to its slow response time.
Registered Member #6038
Joined: Mon Aug 06 2012, 11:31AM
Location: Salado, TX
Posts: 248
I wanted to resurrect this thread as I was still having trouble with the nasty USB MIDI problem. I figured that sending the MIDI signal over ethernet would solve that problem. So I thought I would give it a try. The core of the solution is an ethernet shield on an arduino microprocessor. I hooked up an old wireless router that the arduino connected to via a patch cable. The laptop plays the midi signal via an rtpMIDI port (a virtual ethernet port) that is then sent wireless to the router. So no physical connection between laptop and MIDI controllers.
The arduino code is essentially running AppleMIDI library and when it sees a noteOn command I output the same note to the MIDI port which connects to the regular MIDI controller. Same for a noteOff. Essentially passing the ethernet MIDI stream from the laptop to the hardwired MIDI port. It allows me to run the laptop from anywhere safe via the wifi. There may be more elegant ways to do this, but it works and has eliminated my hanging note problem from the USB connection. Total cost was for an Arduino, ethernet shield, aluminum project box and some LEDs. Code was pretty simple.
One cool benefit is that now I can theoretically operate the coil from anywhere on the LAN, or open it up and play from anywhere in the world More geeky than practical.
Hope this provides an alternative to anyone else experiencing similar problems with the USB-MIDI.
Registered Member #2292
Joined: Fri Aug 14 2009, 05:33PM
Location: The Wild West AKA Arizona
Posts: 795
Graham Armitage wrote ...
I wanted to resurrect this thread as I was still having trouble with the nasty USB MIDI problem. I figured that sending the MIDI signal over ethernet would solve that problem. So I thought I would give it a try. The core of the solution is an ethernet shield on an arduino microprocessor. I hooked up an old wireless router that the arduino connected to via a patch cable. The laptop plays the midi signal via an rtpMIDI port (a virtual ethernet port) that is then sent wireless to the router. So no physical connection between laptop and MIDI controllers.
The arduino code is essentially running AppleMIDI library and when it sees a noteOn command I output the same note to the MIDI port which connects to the regular MIDI controller. Same for a noteOff. Essentially passing the ethernet MIDI stream from the laptop to the hardwired MIDI port. It allows me to run the laptop from anywhere safe via the wifi. There may be more elegant ways to do this, but it works and has eliminated my hanging note problem from the USB connection. Total cost was for an Arduino, ethernet shield, aluminum project box and some LEDs. Code was pretty simple.
One cool benefit is that now I can theoretically operate the coil from anywhere on the LAN, or open it up and play from anywhere in the world More geeky than practical.
Hope this provides an alternative to anyone else experiencing similar problems with the USB-MIDI.
Beware the latency that you will be adding with the Apple MIDI over ethernet protocol. I have used it before and it has a lot of latency.
I still attest to doing direct USB to MIDI in the microprocessor. It's more work upfront, because of the need for a micro that can has USB and the need to write the embedded MIDI USB driver. However it's fare worth the investment in time.
Registered Member #6038
Joined: Mon Aug 06 2012, 11:31AM
Location: Salado, TX
Posts: 248
I have not noticed much latency at all. As long as the latency is consistent, then a delay between the computer generating the MIDI signal and the Tesla actually playing it, doesn't bother me too much. It could be a problem when splitting channels between audio device and the DR. That could be corrected by adding latency into the audio channels, but it starts getting messy trying to sync the two - been there
I definitely do prefer your approach of USB directly to the micro. Maybe I will try that next.
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.