bluetooth communication

Bluetooth communication is evolving, but currently handled by an HC-06 BT2S-slave module, from virtuabotix.com. It appears to be made by JY-MCU.

The default settings for a new BT2S are 9600 baud, and the name might be linvor or HC-06. Pincode is 1234.

The freebird configuration, handled by a separate script, initializes the default baud to 115200, the pincode to 0000, and the name to freebird.

Getting the BT2S module into AT mode is tricky. It appears that there are two tricks to using AT command mode. First is to avoid sending any non-AT traffic beforehand. Power up, set the baud rate on the teensy side, and send some AT commands. The other trick is that there are no line endings for the commands, so they are terminated by time. That means the entire command has to be sent in less than a second, and you have to wait a second to get the response.

The BT2S module is somewhat power hungry when not connected - oscillating between 5-25mA current draw. Once connected (i.e. both bluetooth is connected and an application on the host machine has opened the serial port), the current draw is a constant 5mA or so. When not connected, the red LED blinks, and goes solid when it is connected.

It appears that if the bluetooth goes out of range while connected, it will internally remain in the connected state (solid red light), and is not receptive to reconnection attempts.

For realistic usage, the Teensy needs to be able to power down the bluetooth. The current draw of the BT2S is too large to run off of a digital output.

Options:

• P-channel MOSFET - with MOSFETS the gate capacitance is significant so the digital pin needs resistor to limit the current. Generic MOSFETs tend to be targeted at power applications and expect more than 3.3V on the gate, but there are plenty of logic-level MOSFETs which turn on with 3.3V.
• Optomos - this is basically a MOSFET triggered by an LED rather than a voltage applied to the gate.
  When on there is an added current drain associated with keeping the LED on, nominally 0.6mA for the CPC1002N part.

In both cases, there is some effective resistance in the on state. For example, an IRF7342 has an on resistance around 0.15Ω, and the CPC1002N optomos has an on resistance around 0.4Ω. To avoid voltage drops on transient current spikes, a decoupling capacitor is necessary. To simplify assembly, it would be nice for the bluetooth power control circuit to also be sufficient for controlling power to the Squid. The optomos fits the bill here, since a 3.3V signal can switch an 18V load, and since the two sides are isolated it doesn't matter if it's a high side or low side switch (which means ground can be ground everywhere). With the MOSFET, when switching a higher voltage we'd have to introduce another component, maybe a BJT, so that the digital output at 3.3V could be isolated from the gate at 18V when the device is off.

Triggering Bluetooth Communication

For both power and disconnect/reconnect robustness, it's necessary to be able to power off then bluetooth radio. This is currently done by setting the output of digital pin 22 (aka A8), which is defined as BT2S_CONTROL_PIN in the firmware source code.

The two simple bluetooth modes are COMM_ON, and COMM_OFF. A third option ties the bluetooth state to the magnetometer. If an magnetic field is sensed with any component exceeding bluetooth_mag_threshold, the radio will be turned on. If it's idle (no received data) for more than bluetooth_idle_s, the radio is powered down. Since the magnetometer often has a bias, bluetooth_mag_threshold should be larger than the offset plus the magnitude of the local field. 800 counts seems sufficient, and is easily achievable by a small fridge magnet.