Milovana.com

I have all my parts, and now I feel dumb asking: how do I know I've got the transformers oriented correctly? When I built the stereostim box, this was pretty important, so I want to make sure I'm not about to vaporize my soft fleshy parts.

Thanks.

diglet wrote: ↑Thu Jan 16, 2025 4:07 pm I want to improve this, but I have trouble imagining what the ideal user interface would look like.

I guess a slider would make it or, if I can get it to work, restim-controller

lorada wrote: ↑Fri Jan 17, 2025 4:39 am I have all my parts, and now I feel dumb asking: how do I know I've got the transformers oriented correctly? When I built the stereostim box, this was pretty important, so I want to make sure I'm not about to vaporize my soft fleshy parts.

Thanks.

The primary, marked with 'P' is the output side. The secondary is marked with black paint from the top, and should be connected to the board.

If you have it oriented the wrong way around, the output will be very weak.

edit: added this information to github.

Pinco wrote: ↑Fri Jan 17, 2025 7:47 am

diglet wrote: ↑Thu Jan 16, 2025 4:07 pm I want to improve this, but I have trouble imagining what the ideal user interface would look like.

I guess a slider would make it or, if I can get it to work, restim-controller

The problem with a slider is that there is no fast/obvious way to focus the control without clicking it, potentially making a large adjustment in the process. So I will have to add lots of custom UI code to make this control safe to use for this purpose.

diglet wrote: ↑Fri Jan 17, 2025 8:30 am The problem with a slider is that there is no fast/obvious way to focus the control without clicking it, potentially making a large adjustment in the process. So I will have to add lots of custom UI code to make this control safe to use for this purpose.

Yeah same line of reasoning I had for restim controller, there is progress bar as visual display but for changing volume I added buttons for +/- 10%, 5% and 1% so that there are faster and finer adjustments available

diglet wrote: ↑Sun Jan 12, 2025 6:02 pm Yes. I used -5 to -6 with my stereostim rig, and -1.3 with FOC-Stim. I believe this is mostly caused by the 3-transformer configuration.

And also with FOC-stim, the 3 outputs are are calibrated to similar values, right? I've been sick for a week so I still haven't had a chance to test it, but I hope I'll get some alone time next week so I can :)

My motivation for trying to perform a safety analysis of the device is that if the hardware at it's max capacity could deliver a signal comparable with the strength of a taser, then it has the potential to be dangerous. Luckily I've never been tasered myself, but there are clips on youtube where the effects of it can be studied. It seems to me that the victim gets paralyzed with pain, which renders them unable to just pull out the taser electrodes - and these people aren't even being hit in the genitals :D So it would seem to me that if a FOC-stim device for some reason went to full signal strength, a solo stimmer might not be able to neither turn it off nor pull off the electrodes to escape, even if they aren't using self-bondage.

The different failure scenarios I've looked at:

FOC-stim code/firmware. I haven't been able to verify every single line, but so far I haven't found any serious bugs. It has multiple safety mechanisms such as a watchdog timer, input voltage protection and a current limiter, and I have seen the first two in action so at least they seem to work. I think any bug which interrupts program execution would in worst case lead to a constant current being emitted, which would not be transferred to the user thanks to the transformers. I think it's extremely unlikely that the signal generation algorithms would suddenly fail while given normal inputs, so I tried to focus on what would happen during different failure scenarios, and with the current code I was unable to trigger any bug using "normal" input or cause any buffer overflow.
Risk mitigation:
A1. Document each function (e.g. doxygen) to describe what it does, valid input parameters, preconditions etc. to make it easier for reviewers to verify that the code works as intended.
A2. Add unit tests. Would make it easy to test a lot of edge cases that might not show up during manual testing, and most importantly it would reduce the risk of accidentally breaking things that have been manually verified previously. If you add the basic framework for tests, so you get it the way you like, then I could help writing test cases.

Communication errors. FOC-stim communicates with the computer using plain serial, and while I can't say for sure, I don't think it uses any parity bits. However, while a single bit flip could change A0999 to C0999, I think the risk of that happening is quite low. Lost packages, for example initial calibration, could also cause the device to emit stronger signals than intended, but since Restim periodically re-sends all settings, and because of the watchdog timer, any error ought to be corrected after a second.
Risk mitigation:
B1. Use a more robust protocol which has checksums, sequence numbers and acks. Would take a bit of work to implement, and could make communication monitoring require more effort, but I don't think it would be too difficult to do. Personally I would use a binary protocol to make deserialization as simple as possible.
B2. Initialize calibration parameters to -10 in firmware (minimum) instead of 0.
B3. If keeping the serial text based protocol, I think it's better to not continue parsing commands in case of errors (unexpected characters or line buffer full). IMO any parse error should ignore data until the next newline.

Restim code. Larger code base but did not find anything severe in the parts that I reviewed. Any bug here has the potential to be dangerous, since sending a high calibration value and/or high volume would not be detected as a malfunction. Especially if the user sets the FOC-stim pot to max, and relies on software for intensity control. I think it's a risk that users can "calibrate" the signal intensity in multiple different ways, i.e. using the potentiometer, the calibration fields, and the global volume in Restim. This makes testing all use cases more convoluted, and if the behaviour of certain features are changed in the future, it might lead to different end results for different users.
Risk mitigation:
C1. Standardize the calibration/usage of FOC-stim/restim. IMO using global volume for calibration should not be an option, and it should be "safe" to use the full range of Vx000 to Vx999.
C2. Limit calibration (C command) range to a "safe" range. If you use -1.3 yourself, allowing up to 10 sounds a bit excessive. If you set the max value to something which ought to be enough for most users, anyone wishing to exceed it could still modify their own firmware to do so.
C3. Unit tests are always good to have :) But I think it's difficult to get good behaviour coverage in a GUI application.

Malicious funscript. Since Restim only transmits translated t-codes I think it's not easy to create a malicious funscript file, which in some way causes Restim/firmware to generate non-safe signals outside of its calibrated range.
Risk mitigation:
D1: Unit tests to really cover all kinds of weird input, and to prevent regression.

Using FOC-stim with some other software. The usage of t-code suggests that the device is intended to be usable with other software too. Not sure if other software written to control t-code based devices will send DPING at regular intervals, which could prevent interoperation. But if possible, a third party program could have all sorts of bugs and/or implementation errors (e.g. not verifying FOC-stim compatible version)
Risk mitigation:
E1. (same as B1) Use proprietary protocol, so that any software controlling the FOC-stim is explicitly designed to do so.
E2. (same as C1/C2) Set firmware limits so that no combination of C and V generate potentially dangerous signals.

User mistake/error. I think this currently poses the biggest risk. For example if the user is calibrating their device, they likely have a signal playing while entering values. Accidentally writing a positive number instead of a negative could lead to a big jump in intensity. I think it's also easy to quickly get to large numbers if holding the mouse button and moving around on the graphic calibration widget. User might not realize the device isn't at max volume, and calibrate it too high to compensate.
Risk mitigation:
F1. (same as C1/C2) Set firmware limits so that no combination of C and V generate potentially dangerous signals.
F2. Add GUI switch to unlock/lock calibration widgets.
F3. Visual warning if enabling calibration while volume is low.
F4. Keep separate calibrations/settings for different devices.
F5. Always ramp changes in calibration values instead of immediately applying them. Probably a good idea to block further change meanwhile, to prevent the user from keep increasing the number if they don't realize it takes a few seconds to reach the number the entered.

Thanks for the code review

Perhaps I should explain a bit how the calibration works. The software is configured with some maximum signal amplitude (let's take 1A). When the calibration parameters are all zero, the signal amplitude is 1A everywhere in the circle. When using the calibration parameters the software keeps the maximum amplitude the same but it reduces the volume in some parts of the circle. When using neutral -1.3, the amplitude at neutral drops by about 25% but the amplitude at the opposite position stays at 1A. When using +1.3 calibration, it's swapped. Moving the calibration parameters away from 0 never increases the signal intensity.

I also think most users are playing pretty close attention when calibrating since the whole calibration process is somewhat non-arousing, making the probability of them fat-fingering during calibration quite low.



For the taser, the mechanism of action isn't pain, but that the electricity forces the muscles to contract rendering the target inoperable. In that sense, a one-time software failure is not that dangerous. A single shock may cause you to jump 2 meters into the air, but afterwards the safety mechanism trigger or the transformer saturates, allowing the user to turn off the device. The real horror scenario is a software bug that delivers a series of pulses rendering the operator unable to turn off the device. This can maybe happen if the current sense hardware stops working, or when the device enters a boot loop of some kind.

The first problem can probably be solved by adding some detection for disconnected electrodes, I planned for this feature but I have yet to come up with a good method for detection.

I might add some logic in Restim to not automatically resume playback if a boot is detected, to avoid any possibility of boot loops. FOC-Stim takes 1000ms to boot and stack overflows / nullpointers lock the device up instead of rebooting, so the chance of entering a boot loop seems extremely low.


A1: noted
A2: I think it'd be very difficult to add tests for the safety critical stuff without some sort of testing fixture that records the output. That sounds like a lot of work to test maybe 500 lines of safety critical code. The remaining code is not really safety critical, and it doesn't sound like it's worth creating a tests harness for.


Communication errors: This is definitely the weakest part of the code, although I'm glad you weren't able to trigger any serious bugs in the parsing code. The main reason for using T-Code was that I already had the C and Python code written for another project. I spent around 2 days researching binary protocols but in the end couldn't find anything with the features I wanted. My plan was to wait for the NeoDK API to drop (which has checksums and sequence numbers, not sure about acks) and then copy that messaging scheme for the FOC-Stim. So I'm just going to wait for that to happen (likely this month).


Restim code: Not sure about the suggestions here. In principle all values between Vx000 and Vx999 are safe. Some users already climax around 30%, which suggests there is some scope for reducing the maximum volume for some users (this will definitely be needed for the NeoDK). I tried to be extra defensive programming the volume stuff in Restim, as the values are clamped to 0...1 in many different calculation steps. I don't really see how I can improve anything meaningful here.

Malicious funscript: Don't think this is a concern. The worst thing you can do is ramp up the volume very fast to 100%, but this is perfectly safe if the user has configured the volume in Restim and/or the pot correctly.

Using FOC-stim with some other software.. I use some proprietary extensions to T-Code and existing programs will not produce any output FOC-Stim. This is intended. Programs are expected to interface with Restim or be specifically built to interface with FOC-Stim.

User mistake/error. I don't see any problem with the calibration controls. Even if you fat-finger the inputs the maximum volume increase is limited, most users probably don't calibrate at max volume (nor do they need to).

The biggest problem is people fat-fingering the volume control. I have not received any reports of this happening, but I suspect most users just use the pot on their (stereo)box and not really interact with the volume control in Restim. On a few occasions people told me they clicked the start button not realizing the volume and pot were at a quite high level. It is difficult to create counter-measures for this without annoying them and/or conditioning them to just click OK on any dialog box. I guess I could ramp the volume on start, but I'm sure this will annoy and confuse users, too.

diglet wrote: ↑Fri Jan 17, 2025 8:43 pm{snip}The biggest problem is people fat-fingering the volume control. I have not received any reports of this happening, but I suspect most users just use the pot on their (stereo)box and not really interact with the volume control in Restim. On a few occasions people told me they clicked the start button not realizing the volume and pot were at a quite high level. It is difficult to create counter-measures for this without annoying them and/or conditioning them to just click OK on any dialog box. I guess I could ramp the volume on start, but I'm sure this will annoy and confuse users, too.

With a stereo box and Restim, I'll set my computer volume setting(sound settings) to where I expect it will be at the max for a specific file I'll be playing if it has volume funscripts, pulse frequency, etc. that I've played it before with the amplifier volume at max and let Restim do the rest. This way I get a consistent experience every time as long as the specific electrodes I'm using and their contact is consistent.

If I'm playing a standard funscript file, I'll usually use the Restim volume set to 70% and a .5% to .7% rise depending on how long the file is and if I want it to raise aggressively. Sometimes it feels a little weak as I run the file and I might use Restim to push it up a % or 2.
I'd rather Restim not do the ramp, I'd prefer to control it. With FOC-Stim I imagine I'll configure the pot volume so that way I'll know it will always be able to reach the max volume I'd want it to ever go and then take notes on where things should be for other specific files and change the 70% starting point to perhaps 50% or whatever feels comfy at the start.

It would be great if there was some kind of log message telling the position of pot on board on startup or when changed (just to be able to reproduce settings we prefer)

edger477 wrote: ↑Sat Jan 18, 2025 12:34 pm It would be great if there was some kind of log message telling the position of pot on board on startup or when changed (just to be able to reproduce settings we prefer)

The pot value is logged to teleplot (scale 0...1).

The xicon 42TU200-RC is about to run out of stock on mouser. Replacement is the 42TU400-RC, it has a slightly higher winding ratio making it about 20% stronger. This does not meaningfully affect the safety analysis.

Greetings!
Great project!

According to ChatGPT

L2=K^2*L1
L2=10^2⋅4=100⋅4= 400ohms

So, using 400 omhs we have K = 10, with 200omhs K=7.2
Why dont you use 400 omhs in the first place?
What K will be still safe to use?

​ It is recommended to keep the secondary winding impedance as low as possible. But what numbers would still be ok? 1, 2, 10 ohms?

Regards.

I just finished soldering the protoboard components. Caps inductors and Transformers.
Mounting the board is a little hurdle. I think little plastic offsets, along with the usb port on the box wall.
I have several 12V 1.67A power supplies can I use one of these or is it too much current? I also have a 12V 0.8Ah SLA battery that could be used. but the battery is heavy and I'm trying to keep the build small.
I'm getting close to a trial run! what is a good script for testing to use with restim? And a good script for my first real session?

Afapp wrote: ↑Sun Jan 26, 2025 3:22 am I have several 12V 1.67A power supplies can I use one of these or is it too much current?

The 1.67A is just maximum current, FOC will draw close to like 0.3A or less and this supply should be fine.

For some scripts to try it with, check the index in my sig.

dr_bearcat wrote: ↑Sat Jan 25, 2025 9:50 pm Greetings!
Great project!

According to ChatGPT

L2=K^2*L1
L2=10^2⋅4=100⋅4= 400ohms

So, using 400 omhs we have K = 10, with 200omhs K=7.2
Why dont you use 400 omhs in the first place?
What K will be still safe to use?

​ It is recommended to keep the secondary winding impedance as low as possible. But what numbers would still be ok? 1, 2, 10 ohms?

Regards.

I'm not sure where you got the value 4 from. I think you have the impedance calculation backwards. The impedance printed on the transformer has little value for this application.

A winding ratio of 10 was selected as this was available on a popular transformer that I already had on hand. A higher winding ratio is possible (15, 20...) if you need more power or can't find anything with a winding ratio of 10. I choose not to go with a higher winding ratio because it's overkill. Lower winding ratio's are not recommended as the current sense accuracy will become an issue.

The transformer has a secondary DC resistance of 0.25 ohm. Higher values will work, but will reduce the maximum output power of the device. You may start to notice this around 1ohm and will definitely notice it around 5ohm, depending on your electrode quality. You can always increase the power by using a higher voltage power supply.

According to the datasheet the secondary winding is listed as 8 ohms, the schematic uses half of the winding. Since this is an audio transformer, I assume it is 4 ohms.
If I have calculated the transformer coefficient wrong, please correct me. But if correct, at 200 ohms primary K=7 and at 400 = 10 . Why not use the 400 ohm version initially?