How are variable LED brightnesses acheived for RGB mixing?

A lot of cheap RGB LED setups use PWM to vary the brightness of each component for RGB mixing to produce the full rainbow of colors.

If the carrier frequency of the PWM is too low, a visible flicker can be seen, especially in your peripheral vision.

The real way to vary the brightness is by varying the voltage to the LEDs, of course, but my understanding is that circuitry to do that well is much more complicated, and requires a lot more than just a 5V pinout on a digital IC.

How is RGB brightness implemented in the Procyon and Kasina?

Greetings--LED brightness vs. voltage is nonlinear, moreso if you vary the current with a constant rated voltage. It is most common to use PWM to control brightness, which all of our current and past products have used. For the Procyon and Kasina, the PWM varies with the audio sample rate, so no chance of visible flicker due to that update rate.

BTW I wouldn't advise using the direct output from a 5 v pin--unless it's specifically configured to drive LEDs as is the case with some microcontrollers as the usual voltage rating for most is in the 3v range and you might burn them out. A simple voltage divider using resistors would remedy that issue.

Hope this helps!
Robert

Wow, thank you for that great info. Yeah, I hear you on driving LEDs with 5v. It was just an example (I meant driving them digitally). I agree that high frequency PWM is probably the best way to go, though I'm mystified by how many people use low frequency PWM for this purpose.

Since I've got your attention, another question, as an engineer who will be tinkering with making my own sessions:

I'm attracted to Procyon for its robust and flexible file format (fully separate control of R, G, and B, with separate eye-phases for each, is pretty darn powerful, and some very complex flash patterns are possible), and the fact that the values in the file are interpreted by the device precisely, without any filtering necessary. However, the format doesn't offer fully independent control of each LED. In particular, there's no way to control the left and right eye separately, and I imagine that some interesting effects are possible by sending different frequencies to each eye. Also, the programming is limited to a sequence of frequency and brightness ramps (and yes, ramps can probably be used to achieve most desired effects, with some cleverness).

The SpectraStrobe format supported by Kasina obviously offers complete control, and literally any flash pattern is possible, independently for all 6 LEDs. This goes beyond ramps, because you can use the format to turn an LED on and off whenever you want, in whatever pattern you want. For example, you could have a "chase" pattern like RGBGR, which would be much trickier to encode with ramps.

That said, the way SpectraStrobe is encoded and decoded seems way less precise. Sharp transitions (like flashing a light on and off) will create discontinuities in the carrier waveform, and discontinuities are full-spectrum frequency artifacts, which will interfere with the other encoded channels. That's just a simple example that comes to mind for me (and I'm sure you have some way of dealing with it), but it sounds like SpectraStrobe has had some growing pains, and is widely recognized as being "less precise and more organic."

Obviously, smoother light transitions might be desirable sometimes, but not all the time (that's what the sine option is for in the Procyon format).

But I get it: if you're going to support full control of 6 channels, there has to be some trade-off. Actually encoding that raw data would require 48 bits per sample, and would take a lot of space, depending on the sampling rate you wanted to support. SpectraStrobe is a clever solution.


So, my question: as an engineer, how frustrating do you think I'll find the imprecision of the SpectraStrobe format? Obviously, most end-users are just using pre-made sessions, which were made by you guys with these limitations in mind.

Have some of these issues been ironed out? If I really try to do crazy things with the format, am I going to hit a bunch of walls?


And is independent control of the two eyes in Procyon permanently impossible? Not even with a firmware upgrade?

Hi, Jason-

The reason that the Procyon left and right LEDs are always set to the same frequencies had to do with wire and connectors--we could not find adequate 7 conductor cables that were both thin enough and reliable. And I had read a single study that showed smaller EEG effects with left/right alternating stimulation than both eyes on/off. We really did focus on providing as much flexibility with visual programming with the Procyon as possible with an 8 bit MCU. And you should be able to jump between frequencies by editing the start and finish frequencies, even if the Editor assumes you are going to ramp between those frequencies.

It's not possible to upgrade the Procyon firmware to add more channels as we've pretty much maxed it out with all the varying parameters, and using an 8 bit controller to generate 16 bit sine wave audio. The original designer is long gone, and I spent a couple evenings sifting through his 14,000 lines of assembly language code to attempt to find how the memory IC was addressed, with the goal of replacing it with a larger one, but unfortunately his comments were... sparse (larger memory IC had a different block r/w size).

You could use two Procyon consoles to drive glasses with independent l/r LEDs, and maybe wire them together such that pressing one start/stop button would trigger both to start the same instant...

The Kasina gives independent control over all LEDs using 4 wires by having the right side LEDs in opposite polarity to the left, and they alternate rapidly left/right. This reduces the max. brightness from the Procyon a bit, though the current limiting resistors allow more peak current (ca. 23 ma) to help compensate for that. And because the visual control waveforms are audio signals near the top of the frequency range, the waveforms are smoothed a bit/less "pulse-y". Most users don't really notice the difference unless they happen to have both models to do a side by side comparison.

The SS encoding options in MWS (if you have a working copy) allow quite a bit of flexibility for experimentation. I haven't tried the SS-encoding VST/AU plugins to a DAW yet but I understand they are working well. One way or the other, I hope your frustration level going forward is minimal!
-Robert

Thanks!

This is all fascinating stuff.

Sounds like for Kasina, you're essentially controlling 6 colors independently with only four wires with what is effectively PWM, using inverted voltages to "address" the L or R side. That's very clever!

I wonder with persistence of vision in the retina... if it's even possible to detect the "smoothed shoulders" of the Kasina pulses in a double-blind compassion.

One final question: how replaceable is the built-in Kasina battery when it dies someday? Is it a normal 18650 that you can access easily with a screw driver, or a custom-made flat battery? If the battery dies completely, is the unit still usable via external USB power?

I really appreciate your time in answering this stuff.

The Kasina Li battery is soldered to the PCB - not hard to take apart and replace if you're handy with a soldering iron, but should last for several or more years (I have one in office from late 2013 that still holds a charge). I should probably find a local tech who can perform this simple operation, though hard to find on the small island we live on. The battery is rated 1200 mah at 3.7vdc and is 58 x 42 x 3 mm and the ones I have are stamped EPT 454360. And somewhat surprisingly, the power controller IC won't allow external power if the battery is not charged.

Yes, the left/right ground-flipping used in the Kasina ganzframes is a clever idea--wish I had thought of it when we were designing the Procyon. Tomas gets the credit for that one. :-)