Syntherrupter - A Feature-rich, Polyphonic Interrupter

[Mads Barnkob]

@Mads: Urks - more bad news... Do you know by chance whether lvgl is a viable alternative?

I did not know about that one, so I got nothing to say about that

Since I have currently no new features that I'm working on, I made a very small update that fixes a bug introduced with the last release. Details as always in the notes. https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v4.1.0-beta.7
TBH I hadn't much time for extensive testing. So there may still be other MIDI bugs. Let me know if you find any!

Kind regards,
Max

I ran upon that in simple mode, with standard settings of 200us, 1000Hz and 10% dc limit, I can play with the us/Hz sliders in a way so that dc says 10% on the display, but only 7.3% on the oscilloscope measuring the output. I am not sure if this has to do with the settings for minimum off time?

This does however only seem to happen if changes are done fast, properly too fast for TIVA and Nextion to communicate properly?

[Max]

Interesting issue. I have not been able to reproduce this on my own. I should probably say that I didn‘t verify he output signal with a scope. I looked at the data with the debugger - at core level (see my graphic above). Highly unlikely that those values don‘t match what‘s actually on the ouput.
Even when I move the slider very fast for a couple seconds, everything is fine; the tones send to the core match the values on the screen. For 1 coil as well as for 6 coils.
There‘s one crucial difference between your setup and mine: your Nextion display has a 200MHz CPU, mine has a 48MHz CPU. Yours likely fires those serial commands much faster than mine - possibly too fast as you suspected. To test this hypothesis I attached a modified Tiva firmware with a bigger receive buffer size.

While testing this I noticed another bug related to dark mode. Actually not a bug of mine but one of Nextion. When switching to dark mode, hiding components doesn‘t work anymore because it always overdraws the component with the original background color - white. So I have to manually draw a rectangle in the correct color every time I hide a component... Even this is only half of the problem; the flickering remains, because Nextion draws a white rectangle before I can overdraw it with the righ color. I have to check whether I‘ll find a workaround for this, too.

Finally, while I investigated Nextions issues I found a couple minor oopsies of mine, too. The QR code was supposed to have a lighter color in dark mode for better contrast and the position of the Manual/Apply buttons in Lightsaber mode didn‘t match the positions in the other two modes. Both things are now fixed and will be available soon.

Edit: Attachment fixed. somehow it shrunk to 0kb during the upload..


Kind regards,
Max

[Max]

Some progress here.

I tweaked the colors of Dark Mode. I think it looks quite a bit better now
Wiki is mostly complete, lightsabers won't change/improve anytime soon, and no other bigger upcoming changes either. So I made some efficiency tweaks under the hood and released v4.1.0.
Neither futurists reported issue (not here, PM), nor Astriis, nor Mads issue have been addressed. Either it were (too) small issues or I haven't got enough info so far to find and fix them.

Release v4.1.0: https://github.com/MMMZZZZ/Syntherrupter/releases/tag/v4.1.0


Happy new year!
Max

[Mads Barnkob]

Great to see some updates on this wonderful project

I am planning to release the videos about my built on this in 7 and 14 days from today, still working on 3rd video as I am awaiting parts to arrive. 4th video is about the syntherrupter mounting and in that video I will include a firmware update, if I find anything before that I will let you know

[Max]

Thank you! Can't wait to see those videos! Hope everything goes well and that your audience will like them, too.

Kind regards,
Max

[futurist]

I finally got footage of my MIDI experiments with two coils, recorded on 01.11.2020.
I didn't have any two channel MIDI songs unfortunately

Everything performed exceptionally well although it was set up in a hurry

It seems that quite some time has passed since last experiments, however I'm only home at weekends and I'm doing experiments outside, borrowing power from a guy who has a workshop in abandoned industrial complex, so I'm dependent on good weather and on the owner who isn't always available

Check out youtube playlist I made
https://www.youtube.com/playlist?list=PLlkH_ZpBGiexB1ahBjtajvHqJAfMIxrB1

[Max]

@futurist:
Thank you very much for sharing! Couple good songs among those clips. And some really intense arcs as well. Did you push the limits or are these coils capable of even more?
What happened at 1:47 in this video??

What do you mean by „two channel MIDI“? Or in other words, what midi are you looking for?

Recently I noted that Syntherrupter still seems to have timing issues. In simple mode, some frequencies just don‘t sound right, 850Hz f.ex. Well it turns out this is caused by a delay of only 30us every couple periods. It obviously happens when the periodic checks for new data, effects, etc block the pulse generation. Tbh I didn‘t expect 30us jitter to have such a big impact. I have an idea how to solve this using some kind of buffering but it‘d take me quite some time to develop and test - time I don‘t have at the moment.
In the meantime I might try to randomize the periodic stuff a bit. If those things are checked every 800us-1200us instead of precisely every 1000us there shouldn’t be such a severe interference with specific frequencies anymore.


Kind regards,
Max

[Mads Barnkob]

I posted a new update to the Syntherrupter build. Watch me go through guide, programming and testing

https://highvoltageforum.net/index.php?topic=1417.msg10855;topicseen#new

[futurist]

@futurist:
Thank you very much for sharing! Couple good songs among those clips. And some really intense arcs as well. Did you push the limits or are these coils capable of even more?
What happened at 1:47 in this video??

Bigger coil runs bellow it's limit, although it's limited by the streamers hitting ground. I'm happy how it performs, it's powered only with one SKM400 half-bridge module
Smaller coil is powered with double TO-247 half-bridge with 300 Apk OCD, which is near it's limit. I still have to tune it properly and I'm sure it'll do ground strikes without triggering 300 A OCD
I hope that forum thread with build details for smaller coil will be finished soon

I'm not sure what happened at 1:47, it happened a few times before that, and I had to restart midi to serial converter to get it working again

What do you mean by „two channel MIDI“? Or in other words, what midi are you looking for?

MIDI files edited so that one coil can play one set of notes and other coil can play other set of notes

[davekni]

Coil/arc fields probably confused something in the interrupter at 1:47.  Last time I had live-music configured (last July 4th) I had to move my synthesizer keyboard farther away from the coil.  Not sure if the issue was in the keyboard or in my MIDI interrupter circuit (which was optically-coupled, but not well shielded).  Every so often a note-off command would be missed, so a note played indefinitely.

[futurist]

I experienced stuck notes with my previous interrupter, but this is different. MIDI is playing with different pitch until I restart midi to serial converter

[TMaxElectronics]

MIDI is playing with different pitch until I restart midi to serial converter

That seems very odd to me... I have used that for my first interrupter too, and never had issues like that. Did the song you play when the error happened use pitch bend? I suspect that the message setting the offset to zero might have gotten lost. I'm guessing you could test this by using something like vmpk,  slide the pitch bend slider around a little after that error has occurred and listen if the pitch resets.

I don't think the coil will be interfering with the interrupter much, since the data comes in via usb and then has some probably quite short traces on the dev board itself after being converted to serial. USB doesn't really care about the interference from coils as far as I have noticed, and I doubt that the loop area of the serial line is large enough to pick up enough noise to confuse it.

[Max]

The weird thing is, I know that issue I just can't remember when it happened and why. I think I might have seen it in the early days of v3.x.x when I was messing with the serial processing. I also think it went away when I improved it to the point where no overflows would happen anymore. However I'm not sure at all. Either I never found the true cause of it (likely) or I can't remember what was causing it (not impossible). I've changed quite a lot of stuff since then, hence I was pretty surprised to see it in your videos.
Somewhere in the v4.1.0-beta.x testing I sent loads of random serial data to Syntherrupter. This caused some weird noises obviously but it did not exceed the limits and worked just fine after that. Now that I'm writing this... It might be that test that I remember. Which would explain why you had to restart the MIDI/Serial converter and not Syntherrupter. That would be good and bad news. Good: no bug in my code, bad: nothing I could fix in my code to help you...

One issue I know from some of my test runs is that I could not have my notebook plugged in. Once i connected it to its charger my Arduino interrupter* would randomly crash during operation.
*yeah that was before Syntherrupter existed, in a time where corona was just that blueish thing making ozone.


Kind regards,
Max

[TMaxElectronics]

I highly doubt that is an issue with the usb to serial converter software. The bug would mean that it still sends data fine, but actually looks into the packet, modifies only the note on message and sends it out like nothing happened. For a software that doesn't care about what is in the data, and has no way of adding a note offset I can't think of a way for it to do this. If suddenly no data made it through sure, but it 100% repeatably changing one field in only one message is damn near impossible I think.

So I'd look at either the interrupter and all of the midi commands it supports that change tuning, and potentially the midi player, as that might support transposing of the output that gets reset when the midi output device chagnes.

[Max]

I repeated the fuzzing experiment and I can confirm that it was indeed the sound I remember. So based on that I‘d say Syntherrupter receives garbage. Whether that comes from the onboard USB to serial converter or or somewhere upstream I don‘t know. I could imagine that for some reason the baud rate could get messed up. It‘s the only thing that would explain why all bytes becomes garbage.
In theory it is also possible that it is the UART of Syntherrupter whose baud rate (or any other receiver setting) gets messed up but I don‘t know how this could happen... and it‘s still nothing I could fix either.
If you want to investigate the issue, futurist, you could capture some serial data with your scope when it happens then we can analyze if it‘s valid serial data or not. The MIDI serial data can be scoped at the input pin, the USB serial data can be scoped at the 2x7 groups of solder pads between the debug chip and the jumpers.

I realized that apparently I did not fuzz enough when I did the experiment last time. Repeating the experiment now revealed two issues. A minor issue in the serial buffer makes it return 1 garbage byte if the buffer overflows at a specific moment. More interesting is that the fuzzing goofs up the internal list of active MIDI notes. It‘s a doubly linked list and for some reason it always ends up with two notes pointing to each other, such that the iteration over the entire list becomes an infinite loop. It seems to be related to buffer overflows because it only happens at higher data rates. Will be interesting to find the origin of that bug...

Neither of those bugs does btw explain futurists observations. As I said in the beginning, as long as Syntherrupter processes the random data it sounds pretty much exactly like in his video. As long as that note lockup thing doesn‘t happen, no funny business going on here. I can stop the random data stream and play a MIDI file without any issues, resets or reconnects.


Kind regards,
Max

[Mads Barnkob]

To find out if the problem lies in software, would it be an idea to install a 5-pin MIDI connector at the Syntherrupter and try to use a USB-MIDI thing. I saw it in the schematics, so that could at least rule out parts of the software and then maybe start looking into protocols/packages later.

[Netzpfuscher]

The board has Ethernet, what about adding MIDI RTP (Apple MIDI) there is a Arduino library which does that very easy. I used this library and it works well. Ethernet is by far the most stable copper connection in a Tesla coil environment and every computer has Ethernet.

https://github.com/lathoub/Arduino-AppleMIDI-Library

[Max]

@Netzpfuscher:
Thanks for the suggestion. I‘ll keep it in mind but at the moment I don‘t have the time for working on the project.

Kind regards,
Max

[Georgios]

Good morning from Greece! You have my gratitude for the design of Syntherrupter, Max. You can check out this video I uploaded on YouTube, where you can listen to a piece using Syntherrupter.

[Max]

Hi and welcome Georgios!

Thank you very much! Quite a fast MIDI file you got there; works nicely with the tesla coil sound. I hope we'll see more of this in the future
Mind if I link/embed your video on some of the Syntherrupter pages?


Kind regards,
Max