Safety of Arduino self-bondage timer?

[Riddle]

How safe are Arduino timers for self-bondage?

I believe that the standard setup is battery powered and uses an electromagnet for the release.

Is there anything else that should be done to improve the safety of the timer?

[Shannon SteelSlave]

A thermal fail safe switch and also break power if it receives no light. This can protect the user from being stuck in case of fire or power failures that create freezing or no lights conditions. A fire or power failure should be a "game over" situation.
Maybe a covered release numbered code that can be emailed to a willing person, that can be offered in an emergency, or if they are willing to beg for it and satisfy a certain condition. Otherwise, see you in 4 hours.
We should get these into the hands of members to test them.

[Riddle]

A thermal fail safe switch and also break power if it receives no light. This can protect the user from being stuck in case of fire or power failures that create freezing or no lights conditions. A fire or power failure should be a "game over" situation.
Maybe a covered release numbered code that can be emailed to a willing person, that can be offered in an emergency, or if they are willing to beg for it and satisfy a certain condition. Otherwise, see you in 4 hours.
We should get these into the hands of members to test them.

I will look into thermal fuses for the electromagnets.

A light sensor is a good idea for an extra option. Also, a temperature sensor would be nice to offer.

Internet connection requires more processing capacity than the Arduino has available. For that application, a Raspberry Pi would be a better choice.

[Shannon SteelSlave]

I was thinking about a number code that can over ride the lock command. I guess I didn't fully think that through, as it is the burden of combination code based bondage users to set the code, somehow not see it, and make it only accessible under certain conditions.
I would prefer to keep this thing from relying on internet capability.
Congratulations on your 4th star. (500 posts)

[kinbaku]

Congratulations on your 4th star, Riddle.
An emergency stop on a separate battery that disconnects everything and frees the bound can also be helpful.

[Riddle]

I was thinking about a number code that can over ride the lock command. I guess I didn't fully think that through, as it is the burden of combination code based bondage users to set the code, somehow not see it, and make it only accessible under certain conditions.
I would prefer to keep this thing from relying on internet capability.
Congratulations on your 4th star. (500 posts)

There are a number of ways to override the lock command. In my design, there are 4 buttons: start, stop, hours, and minutes. The stop button can be pushed at anytime to release assuming the user has access to the button. Another option is an emergency stop button that kills all power to the release mechanism.

Thank you for noticing and congratulating me on my 4th star.

[Shannon SteelSlave]

The emergency could be a key operated switch that opens the power to the entire unit, thus fail safing all connected devices. Next to that, smash it with a hammer until it gives up the ghost.
Are we having a formal meeting? I am currently in 4.5 inch heels, open toed backless boots. I don't want to be under dressed. (Inside joke that only a few members here will get)
We should get all members' input on how to predictably make this thing safer. Try to think of all devices it can work with, as we are planning to have 4 ports, 2 five volt ports, and 2 twelve volt ports. Why don't you explain what it is? (so I can understand it) It is connected by wires, or blue tooth? Is it stationary, or does one has to keep it nearby like in a fanny pack if using "mobile bondage"? Maybe quote from some of the spin off Developer Board posts.

[Riddle]

We should get all members' input on how to predictably make this thing safer. Try to think of all devices it can work with, as we are planning to have 4 ports, 2 five volt ports, and 2 twelve volt ports. Why don't you explain what it is? (so I can understand it) It is connected by wires, or blue tooth? Is it stationary, or does one has to keep it nearby like in a fanny pack if using "mobile bondage"? Maybe quote from some of the spin off Developer Board posts.

This thread is for everyone on the forum to comment on the safety of a generic Arduino Self-Bondage Timer.

I will create a new thread in the DIY section for information specific to my design work with Arduino timers.

[kinbaku]

I've learned in my magic to never rely on electrical or electronic circuitry. Something can always go wrong: electricity goes out, short circuit because a part breaks, battery is weakened too much, Bluetooth or Wifi does not work in a certain place, ... (Have seen all this happen to my fellow magicians).
Just like I put 2 padlocks in series or using a totally different release (ice lock,...) I wouldn't want to risk my life on the operation of just 1 Arduino.
Of course everything depends on the circumstances: if the timer only blocks the key to my handcuffs and I can still walk out of the house in the event of a fire, there is nothing wrong except the shame.

For my vibrator program I use 2 arduinos: one for the program and one for the power supply of the vibrator. So if one of the two breaks, everything stops.

[KinkInSpace]

Also, keep in mind that it is very possible to have an error in your code that make the operation of your arduino device do the wrong thing, so before fully committing either have a good backup or do a full dryrun as if you were to do the real session.

And very important: if you make a last minute change, or fix a bug, don't think: It really should work now, I don't need to test. It are these moments where your code breaks in unexpected ways. I often have run a script that was nothing bondage related that I knew would work, to fail on my miserably because my fixing broke something else or I used a debug flag to quickly test something, then forgetting to remove the debug flag.

[lj]

I'm not an Arduino user, still a steam-driven Assembly Language coder, but in the early days of microprocessors, we always used a watchdog timer - these were originally totally separate chips that received a regular pulse (at some time period) from the main programme, and if the pulse failed to appear, the watchdog would reset the processor. I know the PIC microprocessors (what I use) have an internal watchdog which is an unrelated bit of silicon within the chip, so your main code loop includes a watchdog pulse.

As a suggestion, I would concentrate on the term "pulse", so include a bit of hardware that is capacitively coupled to a pulse output. Then if the pulse fails to appear, the external watchdog triggers, perhaps it holds in the overall power supply to whatever "lock" is being controlled. If the source of the pulse fails, either to permanent ON or OFF, the watchdog will trigger. The hardware need only be a diode feeding the pulse to a suitable capacitor in parallel with a suitable resistor, feeding a transistor or FET - the values determine how long the pulse train will maintain a voltage sufficient to hold the transistor/FET into the ON state, thereby maintaining the relay etc supplying the lock power.

This pulse link provides an emergency release option. Anything that breaks the pulse-to-watchdog causes release - could be a wire that gets broken by pulling a cord, a switch, use a light beam/opto-receiver and throw a towel over the transmitter (!), a pin pulled from a simple switch.

And finally, always use a battery to power the lock, and only use a lock that requires power to maintain, NOT to operate a release.

It is far too easy to rely on microprocessors to take care of all processes, they are NEVER 100% reliable, whether by electronics failure or coding errors, so a simple mechanical or low-level electronics release should always be used. Like slave-L, I have, in my career, come across unexpected failures when using electronics, and particularly microprocessors, despite detailed testing, and I would never rely on a microprocessor alone to control my fate!

[Riddle]

I'm not an Arduino user, still a steam-driven Assembly Language coder, but in the early days of microprocessors, we always used a watchdog timer…

And finally, always use a battery to power the lock, and only use a lock that requires power to maintain, NOT to operate a release.

It is far too easy to rely on microprocessors to take care of all processes, they are NEVER 100% reliable, whether by electronics failure or coding errors, so a simple mechanical or low-level electronics release should always be used. Like slave-L, I have, in my career, come across unexpected failures when using electronics, and particularly microprocessors, despite detailed testing, and I would never rely on a microprocessor alone to control my fate!

Thank you for sharing your thoughts. The Atmel microcontrollers have a watchdog timer option which is now available to Arduino users. A stand-alone watchdog ic is available also. I will look into them more. What do you think about a stand-alone watchdog feeding an and gate on the release output? This way, the microcontroller needs to keep the release output high and feed the watchdog to keep the release energized.

I agree with battery powering the lock and with a lock that requires power to maintain.

I also agree that a microcontroller alone should not be relied upon for release. The question is how do we incorporate a microcontroller into a relatively safe release mechanism.

[lj]

The general set-up that I would propose is to have the microprocessor doing the complex stuff, whether it is a simple timer through to a detailed procedure/set of exercises/video recognition/language/text/application of stimulus, coupled with a simple watch-dog style circuit, battery powered, that provides the final lock in the bondage - whether it is a simple key-release/magnet release or the first in a set of releases, but ensures the victim can achieve release from the one action by the watchdog.

Whilst adding to the complexity (yet more to go wrong so you need to think through the failure modes) I would only use a microprocessor with an internal/external watchdog, resetting the processor to the main code loop, so there is a very good chance that unintended code bugs will be caught, rather than cause an unexpected random inescapable loop.

The output watchdog (the one controlling the release) would be "kicked" regularly from the main processor code loop, and would drop out if the "kick" failed to appear within the watchdog time period. I think the capacitive connection for the pulse/kick is essential, as an output can fail to high as well as low, but cannot fail by giving pulses. This "watchdog", as I suggested, could be a simple as a FET (easier to get longer time periods than a transistor, though not essential) biased on (holding in a relay) by the charging of a capacitor via a diode, and capacitor fed by a port on the main processor, with a resistor in parallel with FET gate/ground to give a time constant before the FET becomes unbiased and drops the current through the relay.

The external "watchdog" must be battery powered - I would use rechargeable cells, and calculate (and test!) the maximum acceptable time to remain restrained. This way, pretty much any failure of the main processor will result in an absence of pulses, so the simple "watchdog" will release the relay, and thereby release the securing key/maglock, and as long as the lock/maglock and "watchdog" are battery powered, the final lock will release as the battery discharges.

Please note my earlier comment about my coding experience - I run Assembly Language code, my programmes nearly always use a main loop based on primary functions and a simple interrupt structure to require time interval updates, together with an internal watchdog that will bring the code back to the main loop by a total reset if something goes wrong. This may not be the case with higher level languages. If you use such systems, my simple "watchdog" provides considerable safety.

However, an additional mechanical emergency release is essential - you may be happy with a two-hour wait if all fails except the battery discharge release, but that won't be much use if you are choking on a gag! A simple emergency release such as the "pull the cord to get the key, which also tips engine oil over the carpet" should also be included.

[Riddle]

… Whilst adding to the complexity (yet more to go wrong so you need to think through the failure modes) I would only use a microprocessor with an internal/external watchdog, resetting the processor to the main code loop, so there is a very good chance that unintended code bugs will be caught, rather than cause an unexpected random inescapable loop.

The output watchdog (the one controlling the release) would be "kicked" regularly from the main processor code loop, and would drop out if the "kick" failed to appear within the watchdog time period. I think the capacitive connection for the pulse/kick is essential, as an output can fail to high as well as low, but cannot fail by giving pulses. This "watchdog", as I suggested, could be a simple as a FET (easier to get longer time periods than a transistor, though not essential) biased on (holding in a relay) by the charging of a capacitor via a diode, and capacitor fed by a port on the main processor, with a resistor in parallel with FET gate/ground to give a time constant before the FET becomes unbiased and drops the current through the relay.

The external "watchdog" must be battery powered - I would use rechargeable cells, and calculate (and test!) the maximum acceptable time to remain restrained. This way, pretty much any failure of the main processor will result in an absence of pulses, so the simple "watchdog" will release the relay, and thereby release the securing key/maglock, and as long as the lock/maglock and "watchdog" are battery powered, the final lock will release as the battery discharges.

…

However, an additional mechanical emergency release is essential - you may be happy with a two-hour wait if all fails except the battery discharge release, but that won't be much use if you are choking on a gag! A simple emergency release such as the "pull the cord to get the key, which also tips engine oil over the carpet" should also be included.

Thank you for going into more detail. Are you recommending both internal and external watchdog timers? Can you provide us with a diagram for your external watchdog?

[kinbaku]

I saw yesterday this. It is best to also provide this for your timer program to avoid unforeseen power problems and unexpected loops that would occur in the program.