SexBeacon

The SexBeacon is a variant of the OpenBeacon Tag with the purpose of RF-enabling sex toys.

Revision 1: remote-controlled vibrating toys
The idea of SexBeacon Rev. 1 is to allow remote control of any vibrating device that uses 3V DC motors for generating vibrations.

Such 3V DC motors are commonly found in vibrators, butterflies, vibrating love balls and the like. You can identify such toys mostly on the kind of batteries used: Typically two AA or B cells in series, creating the 3V voltage.

3V is the ideal match, since the OpenBeacon Tag is usually powered by a 3V Lithium battery and thus the whole system can be powered by a single power supply.

In order to control the DC motor, the integrated PWM controller of the PIC16F684 is used. Strictly by coincidence this PWM output is currently used for the LED, and therefore using a FET in parallel to (or instead of) the LED gives us the desired behaviour of a software-controlled, variable intensity vibrating device.

Receiver
The receiver is a stock OpenBeacon Tag that was originally developed for the Sputnik project.

PC-based Sender
The PC-based sender is yet another OpenBeacon Tag interconnected with a host computer (via USB [most likely usb serial emulation]), forming a small base station.

This interconnection can then be used by PC host software to
 * directly control the PWM of a receiver
 * (de-)activate patterns in receivers
 * create, read, edit and store vibration patterns in a given receiver

Keyring Sender
The keyring sender is a small device that can possibly be attached to a keyring, allowing the user to select and (de-)activate pre-programmed vibration patterns in the Receiver.

The very first edition will only have a single-button user interface, since then the OpenBeacon Tag of the  Sputnik tag can be re-used.

Receiver Software
The main functional blocks of the receiver software are:


 * Receiving radio protocol frames
 * Storage and management of vibration patterns
 * PWM generation according to selected pattern
 * Authentication of received data (who wants his or her sex toy to be controlled by unauthorized personnel?)

Storage of vibration patterns
The data format has to be flexible and efficient to allow storage of as many patterns as possible. Patterns are in variable length, since they range from the most simple (100% duty cycle, stay like this until further notice) to the most complex.

In order to represent an arbitrary vibration pattern, a sequence of tuples with the following members is required:
 * intensity (PWM level)
 * the number of required levels is quite low (16 would be way enough). however, the problem is calibration of that range. a linear distribution doesn't always result in a linear distribution of vibrator levels, since this is highly device specific.
 * duration (time)
 * problem: range and granularity at the same time. If we'd go for milliseconds resolution, then a 16bit value was required in order to cover at least up to one minute.
 * solution: use a fixed-point (easy) or floating point (difficult) encoding. As of now, an 8bit fixed-point format (4bit mantisse and 4bit exponent) seems to be the format of choice.

However, in some cases (like a fine-grained linear increase of intensity) this sequence would grow quite long. Therefore, a more optimum [alternative] form must be found. In an ideal world, we would be able to specify linear and even quadratic functions (or even polynomia), which the SexBeacon then would execute.

A more realistic approach, considering the limits in processing power (and possible ranges of parameters) is required.

Controller to Receiver
The protocol needs to convey the following message types:


 * directly configuring currentPWM frequency and duty cycle
 * this means that the last successfully received setting will stay enabled until power loss
 * (De-)Activation of a given pattern
 * activate or deactivate an already stored pattern
 * Storing a vibration pattern in non-volatile storage (EEPROM)
 * downloading a pattern into the device, over the air, for later use

Receiver to Controller

 * Acknowledging messages received from the controller
 * indicating low-battery condition
 * indicating power failure or other reset conditions
 * indicating a user request (button)

Revision 2: remote controlled EMS/TENS
we have some existing ideas for remote controlling EMS/TENS devices. However, SexBeacon has to be completed first.