Program visualization / sync signal

The most versatile and user friendly E-Stim control unit available today. If you want More Power, More Control, and more fun, then the 2B is the one you want.
Post Reply
againgo
Active
Posts: 7
Joined: Tue Jun 02, 2020 9:59 am
Location: Berlin

Program visualization / sync signal

Post by againgo »

When playing with people remotely with the 2B I've often wished there would be some decent visualization on the Connect website or any of the tools available, especially when the person controlling the device doesn't have much estim experience or maybe owns a device that is quite different from the 2B and its routines.

The manual with its descriptions and drawing of the programs does a very poor job explaining those tbh, and I'm imagining something more along the lines of a real time chart showing the rising and falling of the channels etc with proper timescale and so forth... kind of very simplified, visual versions of the actual output functions.

Thought a couple of times about creating something myself, but there are a few speedbumps on the road...
* one would have to tediously collect timing values of the different programs at different settings to even get anywhere in the neighborhood of the actual behavior
* it would be pretty much impossible to keep the visualization in sync with the actual unit and even if initially achieved they'd drift away over time quite quickly

Does anybody know if there's a good compilation of descriptions and possibly runtime data of the 2B routines somewhere available? Anything that goes beyond the manual?

Is there any kind of timing signal the 2B emits if connected to a computer for something like every cycle of a program or similar? Anything that could be used to keep a visualization in sync with the actual device? If not, is that something that could be part of a future firmware version?


User avatar
admin
Site Admin
Posts: 2100
Joined: Tue Feb 19, 2008 8:14 pm
Location: Watford,UK
Contact:

Re: Program visualization / sync signal

Post by admin »

againgo wrote: Tue Jun 02, 2020 3:27 pm When playing with people remotely with the 2B I've often wished there would be some decent visualization on the Connect website or any of the tools available, especially when the person controlling the device doesn't have much estim experience or maybe owns a device that is quite different from the 2B and its routines.
Interesting idea...... I remember Winamp visualisation!!
The manual with its descriptions and drawing of the programs does a very poor job explaining those tbh, and I'm imagining something more along the lines of a real time chart showing the rising and falling of the channels etc with proper timescale and so forth... kind of very simplified, visual versions of the actual output functions.
We are working on better descriptions with the online version of the Beta firmware manual, but we are always interested in how we can improve the manual.
Thought a couple of times about creating something myself, but there are a few speedbumps on the road...
* one would have to tediously collect timing values of the different programs at different settings to even get anywhere in the neighborhood of the actual behavior
* it would be pretty much impossible to keep the visualization in sync with the actual unit and even if initially achieved they'd drift away over time quite quickly
Yup.
Does anybody know if there's a good compilation of descriptions and possibly runtime data of the 2B routines somewhere available? Anything that goes beyond the manual?
Not that I know of, and for several modes the variations possible run into many 1000s of data points, and that is before you get into how things actually feel.
Is there any kind of timing signal the 2B emits if connected to a computer for something like every cycle of a program or similar? Anything that could be used to keep a visualisation in sync with the actual device? If not, is that something that could be part of a future firmware version?
Not at the moment, as at the moment a sync pulse would flood the serial port with data, as some modes the cycle time is considerably higher than you would expect, especially if you are looking to visualise the feel side of the waveforms.

Si
E-Stim Systems Ltd
rubberstim
Active
Posts: 17
Joined: Sun Apr 10, 2016 12:41 pm

Re: Program visualization / sync signal

Post by rubberstim »

My take is that I'm not sure a waveform or equaliser would add much more than a simple indicator that showed a representation of the rhythm/pulse speed maybe with a percent of relative power levels that dips up and down. Sort of a slightly enhanced digital version of the lights on the 2B channels. At a guess the timing does not vary widely between 2B boxes so it could be potentially computed from the commands sent to the box.

Won't be hugely accurate to what the person is feeling but a represenation providing feedback on pace and channel behaviour such a constant waveform would be useful. I often use a 2B controlled with commander on myself then transcribed it into connect when driving another person to get an idea of pace.

Displaying accurate, complex but meaningless (to the inexperienced) data has even less value than an interpreted approximation.
againgo
Active
Posts: 7
Joined: Tue Jun 02, 2020 9:59 am
Location: Berlin

Re: Program visualization / sync signal

Post by againgo »

we are always interested in how we can improve the manual.
Just a couple of smaller things:
- Small, simple but possibly slightly more precise visualizations for all programs (where it's possible)
- More concise but also complete tabular overview (sometimes lower value mean faster, sometimes slower, what is the approximate "duration of a program" (ramp up, up/down cycle etc.) at the lowest, default and highest speed setting etc. (it's hard for somebody who doesn't know the programs already to get a feel for what "fast" and "slow" means for a certain program... sometimes we're talking about a second or two and fractions of seconds (pulse, bounce), sometimes we're talking about 5-30 seconds (waterfall etc.), sometimes we're talking about many seconds, a minute or two so (training, step)
for several modes the variations possible run into many 1000s of data points
True. Then again, it seems to me, most programs are somewhat straight forward and getting a few samples of the slowest, fastest and some inbetween settings could possibly allow to estimate the rest.
In any case, the goal would merely be to visualize the gist of a program... definitely something simplified and not a scientifically accurate graph of some sort and that would definitely exclude minute details like pulse feel (though I can think of a few purely visual tricks that could give a certain hit at different pulse feel settings in some sort of graph).
as at the moment a sync pulse would flood the serial port with data, as some modes the cycle time is considerably higher than you would expect, especially if you are looking to visualise the feel side of the waveforms
- As said above, the feel side would not be the goal and I'd try to cover that with mere visual hints/tricks.
- At least for my pure visualization goal, the sync signal would become less important the faster a certain program is. It could just come once a second (give or take). If the value of the signal would be the number of cycles passed since the last signal, that could actually work even for faster signals, as any tool interpreting the signal could just estimate the actual speed/frequency of a fast running program based on that info, even if a sync signal only comes every second or two.
Than again, I obviously don't have any knowledge of how the programs actually work on a technical level, so maybe I'm missing things here and reality is a bit more complex than that :)
againgo
Active
Posts: 7
Joined: Tue Jun 02, 2020 9:59 am
Location: Berlin

Re: Program visualization / sync signal

Post by againgo »

rubberstim wrote: Wed Jun 03, 2020 10:08 am At a guess the timing does not vary widely between 2B boxes so it could be potentially computed from the commands sent to the box.
For slower runs with waterfall, or even more so training or step, this would probably be really off after a few minutes and vis might show e.g. a low while the actual unit is almost at its peak. And that's not even considering the two channels and the possible but not always same shift between those. To me it seems quite hard to get even in the neighbourhood of reality, merely based on the commands sent.
rubberstim wrote: Wed Jun 03, 2020 10:08 am Displaying accurate, complex but meaningless (to the inexperienced) data has even less value than an interpreted approximation.
Fully agree there. That's why I literally said "very simplified". Definitely not thinking about complex waveforms here, more like a simple scrolling chart showing how the signal rises and falls, goes on and off, along those lines. This is purely about giving somebody an idea of what is happening on the other end of the line, not at all about showing some scientifically correct signal or so.
User avatar
admin
Site Admin
Posts: 2100
Joined: Tue Feb 19, 2008 8:14 pm
Location: Watford,UK
Contact:

Re: Program visualization / sync signal

Post by admin »

The problem with any form of simplification is people will take it at face value. The current printed manual shows a number of tiny almost cartoon like waveform giving some indication as to the output, and we have had one or two customers complain quite voraciously that these did not match what unit is doing. So over simplification can cause just as much issues as making things too complex.

I like the Winamp idea as the graphics gave you some visual understanding of intensity and feeling for the music without dropping down to the technical aspects of a display of a graphic equaliser.

Si
E-Stim Systems Ltd
rubberstim
Active
Posts: 17
Joined: Sun Apr 10, 2016 12:41 pm

Re: Program visualization / sync signal

Post by rubberstim »

againgo wrote: Wed Jun 03, 2020 10:19 am
rubberstim wrote: Wed Jun 03, 2020 10:08 am At a guess the timing does not vary widely between 2B boxes so it could be potentially computed from the commands sent to the box.
For slower runs with waterfall, or even more so training or step, this would probably be really off after a few minutes and vis might show e.g. a low while the actual unit is almost at its peak. And that's not even considering the two channels and the possible but not always same shift between those. To me it seems quite hard to get even in the neighbourhood of reality, merely based on the commands sent.
rubberstim wrote: Wed Jun 03, 2020 10:08 am Displaying accurate, complex but meaningless (to the inexperienced) data has even less value than an interpreted approximation.
Fully agree there. That's why I literally said "very simplified". Definitely not thinking about complex waveforms here, more like a simple scrolling chart showing how the signal rises and falls, goes on and off, along those lines. This is purely about giving somebody an idea of what is happening on the other end of the line, not at all about showing some scientifically correct signal or so.
I think we may be saying a similar sort of thing but with different representations. A rolling chart could work as well as numeric value but alas getting realtime telemetry from the 2B seems to be impractical as is deriving the values. Is there is mid point that is good enough?
againgo
Active
Posts: 7
Joined: Tue Jun 02, 2020 9:59 am
Location: Berlin

Re: Program visualization / sync signal

Post by againgo »

I kind of dropped this project, since I never really found the time, but as it turns out now somebody else has done exactly what I was hoping to do:
viewtopic.php?f=22&t=10500

Really nice work, and exactly what I envisioned, just to give the remote side some idea of what's going on in stim play, or as they put it:
One of the things that annoys me is remote drivers rarely touch settings other than power levels and a few modes. I think this is because they have no idea what the other options do so I made this visualizer.
They also mentioned the sync issue between the visualization and the actual device:
I've tried to get the timings roughly correct but unless someone knows the exact formulas I think it's futile to waste time on getting them closer.
I don't think the exact formulas are necessary. I guess they would be considered proprietary information anyways.
But any sort for a cycle signal from the device over the serial port on a regular basis would do the trick just as well as I've previously mentioned.
User avatar
Megrez
Active
Posts: 6
Joined: Sun Jun 20, 2021 5:30 am
Location: Korea

Re: Program visualization / sync signal

Post by Megrez »

even if it is not synchronized,
at least,
I think visualization of signal type, intensity and speed is interesting idea !!
Post Reply