Stereostim waveform generation.

[diglet48]

I saw your new stereostim feature on reddit and wanted to add some insight on waveform generation to get you up to speed on the progress made the last few years.

I spent lots of time with Restim to optimize waveform generation. The current algorithm was inspired by phx / aquarium parrot, a small creator on milovana. It generates waveforms based on 4 parameters: the carrier frequency and pulse frequency (both in hz), pulse width and rise time (both in cycles of carrier frequency). This algorithm is also implemented in the FOC-Stim and has been colloquially known as Restim wavelets.

The basic idea is to have relatively short pulses with a rest period in between, so the duty cycle of the waveform is less than 100% to improve power efficiency.

• Carrier frequency: Historically with three-phase, changing the carrier frequency resulted in unpredictable changes in intensity, so generally a single carrier frequency would be selected for the entire session. This is less of a problem with dual-channel and the FOC-Stim, but the effect of carrier frequency on sensation is still poorly understood and/or minor. I play with fairly high carrier frequency (1700hz) for safety reasons, but most users seem to be OK using frequencies down to approximately 500hz. (the risk with 'low' frequencies is due to electrochemical effects). The equivalent frequency of the coyote is about 5000hz (~100µs pulse width), However, higher frequencies require higher peak power output, my stereostim box cannot deliver sufficient power for frequencies above 1000hz. In practice this means 500-1000hz is often used.
• Pulse frequency: This parameter has a large impact on whether the sensation feels like a vibrator, or feels smooth. General range 1-100hz. The subjective frequency actually depends on the length of the downtime between pulses, rather than the pulse rate. I'm not too familiar with the coyote, but perhaps you can experiment with this on the coyote?
• Pulse width: To ensure somewhat symmetric biphasic pulses, the pulse has to be at least a certain number of cycles wide. So the pulse width is specified in number of carrier cycles (3-20 in restim, but vales over 10 are rarely used). It is the number of times the 'pulse' is repeated within a wavelet.
• Rise time: Smooths out the edges of the pulse. The minimum in Restim is 2 cycles except when the pulse width is 3, then it's 1.5.

To generate these wavelets, I generate a few cycles at the carrier frequency and multiply that by the pulse envelope to smooth out the sharp edges at the start and end of the pulse (the envelope is defined by pulse width and rise time). Each wavelet has a random starting angle of the carrier frequency. These wavelets are generated at a frequency equal to the pulse frequency (up to a maximum of 100% duty cycle).

Pulse frequency really does most of the heavy lifting. The carrier frequency is less important. The pulse width and rise time are not that interesting. Changing pulse width only seems to change the sensation with very specific moving threephase signals, I doubt you can get any effect with dual-channel. Changing the rise time seems to do nothing. To simplify the user interface, you might hide pulse width / rise time behind a menu. I usually use the values 7 and 3 for width/rise. This means the pulse is 7 carrier cycles long, and the pulse envelope ramps up in 3 cycles, 1 cycle at 100% power, and 3 cycles ramp down. The exact envelope shape does not appear to be critical, but my ramp shape is sin(0) to sin(pi/2).

The combination of high carrier frequency and low pulse width results in the highest power efficiency (joules per unit of nerve activation). High carrier frequency, high duty cycle waveforms should be avoided to prevent thermal burns, above 1000hz is approximately where you run into thermal issues with 100% duty cycle signals. Low carrier frequency, high pulse frequency waveforms should be avoided because having pulse frequency anywhere near to the carrier frequency (pulse width less than ~3 carrier cycles) makes absolutely no sense.

For these reasons I recommend to copy this specification where pulse width is specified in carrier cycles and the pulse frequency is limited to around 100hz, it is quite simple and makes it impossible to specify these waveforms you shouldn't use.

---

Some users have expressed interest in non-sine signals. Certain three-phase signals rely on phase control, which only works when the signal is a single frequency so square waveforms are not possible. For this reason Restim does not support square waves. It is possible to use non-sine waves with dual-channel though.

But there are a couple things you should be aware of. If multiple channels are placed close together (and/or crossing) and the phase is not controlled, you can get unpredictable effects due to interference between the channels. The coyote avoids this by separating the pulses in time, but this requires the pulses to be extremely narrow.

The alternative is to use the same phase-locked carrier on all channels. You may get some interference, but a lot less than if you would use 1000hz carrier on A and 999hz carrier on B.

In lab tests on single nerves, the waveform shape (sine/square/triangle) seems to be completely irrelevant if the pulse width is similar. It is my impression that the debate about sine vs square waves really isn't about the waveform shape, but is all about the pulse width (500hz sine = 1ms, coyote = 100µs) and to a lesser extent, the polarity of the leading pulse and how much time there is between the positive and negative part of the pulse.

The coyote uses square waves with constant amplitude, using the pulse width to control the subjective intensity. Why did the designers do this? I think the answer is very simple: it results in the simplest/cheapest possible output stage. I definitely wouldn't use this as an example of what to do (unless you want to design the cheapest possible output stage ;) ).

---

There are a few devices on the market such as the 312 and 2B that don't do direct audio passthrough. You cannot really optimize the waveforms for these devices without compromising on stereostim functionality, especially when you get into the wavelet generation stuff.

Good luck.

[Amethyst-Sysadmin]

Thanks for taking the time to share that information, it's extremely helpful. I was moving a bit closer to this approach, with the latest alpha build I posted on Reddit using a "pulsed" approach and allowing the selection of different shapes of carrier waves and envelopes. But there's a lot that I hadn't quite figured out, and I was struggling to know where to set some of the parameters. It didn't help that I hadn't been able to directly test any of the audio stuff myself (since I've only got a Coyote 3 and not a device with audio input), and that user feedback on everything was usually pretty mixed. That might well be because some people are using devices that do extra processing and represent the same input quite differently (as you mentioned).

How Howl's patterns work is that we represent everything as periodically generated "Pulse" objects with two channels, where each channel has an amplitude (0 to 1) and a frequency (0 to 1). I more recently learned that this frequency is actually the pulse rate on the Coyote. That setup makes doing generative patterns easier, and we later map those normalised values into the device's range for output. We currently generate those pulses 40 times per second for the Coyote 3 (to match its update rate) and 100 times per second for the experimental audio output (but that's just provisional and can be changed). So the main challenge for audio output is working out how best to translate those periodic pulse values into actual audio samples for output.

I had taken a quick look at Restim (and its very helpful wiki), but didn't understand most of the implementation maths as that's not particularly my area. We're just aiming for a much simpler stereo implementation, since the Coyote can't support triphase effects anyway, and that's what our existing patterns and funscript algorithm are designed for.

On duplicating what the Coyote is doing, as you can see from this Reddit thread I had more doubts about that working as I looked into it more and gathered some technical details. But I threw something together anyway because I'm more of an experimental guy, and oddly the user in that thread seems to be finding it quite good! It might be somehow specific to their setup though, not sure. But the way they've set the parameters with no gap and the length an order of magnitude higher it's not really doing what the Coyote does any longer, it's more just a single pulse of a square wave. So perhaps it's just another way of getting to a similar pulsed output. It's strange that it might seem to work though, given that it's just single pulse based and isn't using any envelope, so has hard edges.

Are you scaling the pulse width with the pulse frequency (as I was doing in my main alpha builds) or is the width static and only the gap changes (as with the weird more Coyote-like approach I was trying)? I'm not really sure which way is correct.

I'd just about worked out that phase issues might cause problems, and tried to add an option for control over that in the latest alpha build. But I screwed it up somehow and realised that my implementation just ended up forcing the same pulse rate on both channels. I haven't really got my head around much of this audio output stuff yet, there's a bit too much maths and trigonometry for my liking! ;)

[diglet48]

Most of the complex math in Restim is to support three-phase which I don't think you are aiming to support.

The 'problem' with the single pulse approach is that there are small differences in nerve activation depending on whether the leading pulse is positive or negative. This can be used to your advantage, but with Restim I decided it wasn't worth the effort. The slow ramp of the pulse envelope eliminates the leading polarity effect. It also goes away if there is sufficient time between the positive and negative part of the pulse, 500µs should be enough. But literature warns against using more than 80-100µs for electrochemical reasons, so pick your poison. :)

I keep the pulse width (in carrier cycles) constant. So at 1000hz, 7 pulse width, a pulse is 7ms and at 2000hz it's 3.5ms. The gap between the pulses changes as the carrier frequency changes.

Since the subjective frequency depends on the gap and not the pulse rate, changing the carrier frequency curiously changes the subjective frequency of the signal. This is something I want to improve in future versions of Restim.

[Amethyst-Sysadmin]

The gap is mainly dependent on the pulse rate though right? Like with double the pulse rate you'd halve the gaps between pulses? So the change from varying the carrier frequency only really matters if you're changing the carrier frequency "live", and it sounded like the idea was to have it fixed. Or am I missing something?

This was my attempt at doing the audio output from the 0.6 alpha 3 build. Not too sure if it was on the right track or not - possibly not as it seems a fair bit different. It's the generateModulatedStereo function that actually generates the audio samples, most of the rest is dealing with Android's AudioTrack API, which seems more complicated than it needs to be (like the playback head isn't continuous and only jumps around in certain steps, which is why we're trying to keep an intermediate queue of Pulse objects ready).

I was varying the width of the pulses based on the pulse rate, and had kind of a 50% pulse to 50% gap ratio for most of the envelopes. There isn't an explicit rise time either and I just figured the shape of the envelopes would take care of that.

Don't think I really understand the phase issue either. The PhaseType thing I implemented there definitely doesn't work, and setting it to anything other than independent just makes both channels have the same pulse rate and breaks the stereo frequency effect. But I'm not actually sure if we needed it in the first place since we do track a single phase for the carrier wave. But how does that fix the problem, surely both channels can still play at the same time?

[diglet48]

Doubling the pulse rate more than halves the gap (With 1000hz 7 pulse width, 50hz is 13ms gap and 100hz is 3ms gap). The smoothness of the signal seems to max out around 10ms gap, with further increases in pulse rate / reductions in gap no longer making the signal more smooth.

With a 1000hz carrier, I found that a 30hz 20-wide pulse signal is indistinguishable from 41hz 4-wide pulse signal (after controlling for signal intensity). The rise time makes it a bit difficult to pin-point when the pulse starts/ends but it illustrates the point that the subjective frequency is different from the pulse rate.

Anyway, you're right that if the carrier frequency is static, these details don't really matter. I think it's a good idea to let users experiment with the carrier frequency, because it's a lot easier to do with dual-channel and I would like to get more information on how different users perceive different frequencies. With three-phase, there is a lot going on and it's very difficult to isolate the individual effects.

I don't think targeting some duty cycle is meaningful. With a 500hz signal at 7 pulse width, you need around 60% duty cycle to get a smooth sensation. At 5000hz it's only 10%. Most signals on the coyote are below 5% duty cycle?

With dual-channel, you're going to get interference between the channels if the electrodes target the same approximate area. Scheduling the pulses in completely separate time slots, like the coyote does, is not feasible with stereostim. But I think that having the same phase makes the interference effects a bit more predictable. Now that I think about it, the least interference is probably when the phases are offset 1/2 pi. I might be over-complicating things here because I spent too much time with three-phase. It's very possible most users use an electrode setup where each channel targets a different body parts, and then it's not an issue at all. Maybe the correct approach is to ignore the problem for now and wait to see if users start complaining about interference?

[Amethyst-Sysadmin]

I think the maximum duty cycle on the Coyote is about 3%, if the timing values I used in the Reddit post I linked 4 posts above are correct (I roughly figured them out from other posts and oscilloscope images, but it's not something I have hardware to validate myself). It can be less because of the thing it does where it adjusts amplitude by changing pulse width. I can't see a reason to copy that for audio generation though, I'm sure as you said earlier it's just a technique that's easier or cheaper to produce in hardware (and we don't necessarily even have the resolution to do it with short pulses, at a reasonable sample rate). I'm sure you're right that having a fixed pulse width makes more sense than having a fixed duty cycle, as it's what both you and they have settled on. It's easy to pick the wrong approach when I'm just taking a guess and don't have a device to A/B test different methods myself. That's probably the first thing I'll look to revise anyway.

My experience with the Coyote is similar to what you mentioned at https://github.com/diglet48/restim/wiki/pulse-rate with the signal feeling smooth at something like 50-60Hz (I realise you're saying it's proportional to the gap rather than the pulse rate directly, but the Coyote's pulses are so narrow that you can almost discount that). There are definitely significant differences in feeling above that though. Possibly it's just due to more energy being transmitted, since the pulses are fixed width and there are more of them. It's possible to set a pulse rate of 1-200Hz via the Coyote API. I settled on 10-100Hz as Howl's default range when the app starts, but the user can increase beyond that. It's not that values above that necessarily feel bad though, it's just that the sensation is a bit too intense if anything, and can have a bit of a numbing effect over time. I quite like having the option to push up the top end of the range a bit above 100Hz towards the end of a session (maybe 150Hz), but I don't think it's a good place to start. The Coyote also has a very strange (to me at least) distribution of pulse frequency values, with a complicated formula to convert from Hz to the 5-240 range the hardware uses. It has loads of values towards the bottom of the range, but there are actually only 5 values that can be set between 100 and 200Hz, giving very poor granularity when near the top of the range. Again I think that might possibly just be down to how the hardware and timers are designed and what it can produce.

I'm really not certain if interference is a practical problem or not. I thought that users having inconsistent results might have been attributable to that, but it might be more down to other factors. Like the fact that we weren't using fixed width pulses, or some users having devices that didn't pass through audio directly. So I'll probably need to try some other changes first to reach any conclusion on that.

I expect I'll spend a bit of time digesting your very helpful advice and then try to put together an improved build.

I've removed all the downloads of early versions for now, as I think we were giving users the option to set frequencies too high, given the high duty cycle we were using (the default range was okay, but there was a setting to override that and allow use of very high frequencies). Your approach of specifying the width in carrier cycles makes a lot of sense to avoid that sort of thing.

[Amethyst-Sysadmin]

I'm curious about why you start each wavelet at a random place on the carrier wave? Did you find that provides a benefit for you over having the wavelets be identical? Or over incrementing the carrier phase every sample and just starting at where it happens to be?

[diglet48]

Do you really feel a difference in sensation with the higher frequencies? I get that the intensity is higher, but when I tested 60hz vs 100hz with the volume controlled so both signals have the same intensity, I couldn't discern the difference between these signals. Although other people claim they could.

The reason for having a random starting angle for the carrier frequency is that each wavelet has a very small DC bias. it almost certainly is too small to cause issues, but randomizing the starting angle ensures that the average DC bias over many pulses is zero. My implementation doesn't actually randomize, but advances the start angle every pulse by some fraction of a prime number, which has the same effect. It seems to have no effect on sensation.

[Amethyst-Sysadmin]

Yes, to me it feels different than just setting the power higher. Higher power is more of the same thing whereas the higher frequencies are... it's hard to describe it. I'd have to say it feels like glowing, which I know isn't much help. Like if you can feel the difference between 70Hz and 100Hz, the higher rate kind of "sparkles" more even though they both feel smooth. It's basically more of that type of difference.

They feel great to me, but I found it was better to use those higher frequencies in moderation because they can be numbing or a bit too intense (probably because they're transferring more energy). I think that aspect gets worse the higher you go, I'll quite often decide to increase the top end of the range to maybe 140-150Hz, but I don't really use 200Hz as that's more towards getting slightly painful. It's possible that could be for a different reason like the Coyote not being capable of accurately producing the pulses at that rate though (the DG Labs app only goes up to 100Hz, so everything beyond that is sort of "unofficial").

I don't know that it necessarily translates to stereostim though, since I've only tried the Coyote. The difference in feeling might somehow be a product of the different way it generates pulses.

Since your experience is different, I'll have to retest and double check I'm not just imagining it. Moving the high end of the range up in Howl has a very obvious effect, but it's because it rescales the whole pattern, so lower frequencies also move up. So will need to specifically do a test just comparing the high frequencies we're talking about.

[Amethyst-Sysadmin]

Forgot to update the thread, but I did eventually implement experimental audio output in the 0.6 release. I went with a choice between two modes, so users can have either wavelet output or a more basic continuous sound wave (that might help with compatibility for some older devices or those that add their own processing). The available options are described here.

One slight change from the Restim implementation you mentioned was that I thought the fading in and out of wavelets might be better specified as a proportion of a wavelet (0.0 to 1.0). For example when set to 0.5 we'd fade in over the first 25% and fade out over the last 25%. I think that might be a little more intuitive, since then there are no invalid settings, and a similar shape is maintained when leaving the fade fixed and changing other parameters.

I did re-test whether I could actually tell the difference with frequencies beyond 100Hz, and felt that I could, even when trying to adjust for the difference in power as best as I could manage. However I do think there might also be something going on related to nerve conditioning or something along those lines. In one session I found that I could not tell the difference initially from cold, but tried the higher frequencies again later in the session and then could easily tell the difference.

I also theorised that because the Coyote uses very short pulses, it's probably possible to still feel a difference at slightly higher frequencies than with a stereostim setup. As the Coyote at 100Hz would have longer gaps between pulses than the stereostim device at 100Hz, just because its pulses are shorter.