¡¡ | ||||
|
Schematics Below are the schematics in .pdf format: Schematic for the transmitter. Schematic for the receiver. And the OrCAD files in a .zip. Parts List BOM for the transmitter. BOM for the receiver. For the receiver, I used the AVRMini V3.1 development board for rapid prototyping. Hardware Design Choices An outline of design choices is given here with more details following: Accelerometer
Radio Link
Processing
Power
Note Positional input was not the ultimately implementation for this design. However, it is important to keep in mind that the processor speed and the accelerometer sampling rate were chosen with the open possibility of processing positional data in mind, which requires higher speed, lower noise, and more stringent timing constraints than actually needed currently for detecting static tilt. With some time, it is not difficult to add another accelerometer. Then a more successful attempt can be made to get the full positional data. The design choices made do provide for this possibility. Design Choices Details Accelerometer The accelerometer used is a 2-axis ¡À2g version (ADXL202JE) from Analog Devices. These types of MEMS devices typically sense an external force by counteracting the effects of that force on an internal mass-on-a-spring system using electrical feedback. The electrical signal that is output is proportional to the force sensed. Since there is no distinction between different types of forces, this device, by itself, is incapable of distinguishing the gravitational force from other forces. The accelerometer has an analog and a PWM output for each of its two axes. To use the PWM output, which is sampled internally from the analog output, a low-pass filter is required to cut out aliasing and cut down noise. This project uses the PWM outputs, because we want clean digital data right from the start. The filter cutoff used is around 15Hz, which is good enough to detect any reasonable human hand motion and which corresponds to on the order of 1-2mg of peak-to-peak noise, which is quite good for our purposes. We set the PWM to a period of about 2ms. This provides 500 samples a second, which is oversampling by a lot. The intention was to get so many samples that interpolation (in order to integrate to a velocity) would be unnecessary. It turns out, as will be explained later, that there is a serious drawback when implementing digital filters. To drive the PWM-decoding external interrupts with accurate timing, some glue logic is used to generate a pulse whenever there is an edge change on either axis. This is fed into the Interrupt Capture Pin of the AVR, which time-stamps each edge-change event with a 16-bit timer. Radio Link The modules used for the radio link are the transmitter-receiver pair TXM-433-LC-R and RXM-433-LC from Linx Technologies. They are pretty good at transmitting digital data, at up to 5000 bps and up to 300 feet. These use carrier-on carrier-off modulation, and the carrier is 433 MHz. See my presentation for information about implementing radio links with the LC series. I put digital data straight into the Linx transmitter module and receive it on the other end with, as it stands now, no encoding/decoding. The Linx modules seem to be very good at 1200 bps (serial mouse communication speed) and at a range that is useful for the project. Also, at 433 MHz, there doesn't seem to be a lot of interference. Finally, the data I send is, arguably, packaged already. The standard serial port mouse driver, which is where the data ultimately ends up, has its own decoding and error rejection mechanisms. Since we are collecting digital data at a rate of four 2-byte timestamps every 2ms, or 500*64 = 32000bps -- and if we process this into time duration data, then 16000bps -- this is too much data to be sent across the radio link. Therefore, we must process the data until there is relatively little information to send. This means most of the processing needs to be done on the handheld portion of the project. It turns out we have a reasonable power budget on the transmitter side for this, so we, in fact, do all of the processing on the handheld portion. Since I chose not to use encoding/decoding on the radio link, it was important to get a good link. A concern was the type of antennas to use. We chose the quarter-wave whip antenna on the receiver end for rather sensitive reception and a much shorter quarter-wave helical antenna on the transmitting portable portion to save space. As a bonus, the antenna provides a natural orientation for the handheld device! Processing For the processing of the accelerometer data, two choices were first made. It was decided to use C instead of assembly, and to implement digital filters, instead of analog ones. We wanted to be able to create and change algorithms quickly, which is the reason to use C (compiled with AVR-GCC). We used digital filters instead of filtering the analog output of the accelerometers for analogous reasons. The Mega232 processor on the transmitting side was chosen precisely because it can be clocked externally at 8MHz. This was important because we anticipated doing a good amount of DSP and because C carries its own overhead. In the current design, we have a Mega232 microprocessor on the receiver end also, but it does very little processing -- it echoes the data from the radio receiver to the serial port. It was put there in case any encoding/decoding was needed, as may be the case in a more hostile RF environment or when several such devices are operating. Nevertheless, if cost was an issue, this part can be removed or replaced with a much simpler microcontroller. Power The portable side is not tethered. Given the typical batteries, we can expect from 500mAh (Ni-Cd) to maybe 2000mAh (Li ion) of continuous energy. From a very rough calculation, it appears the microprocessor will take upwards of 25mA at 5V and 8MHz; the radio transmitter takes another 3mA when transmitting; the accelerometer takes 0.6mA; the glue logic takes some other small amount of current. This means we can use a low-end, low-cost battery solution, especially if we cut supply voltage down to 3.6V. We choose a 3.6V rechargeable Ni-Cd battery pack (very convenient, because I can recharge it in my cordless phone) and connect it directly to the supply line. On the receiver side, we considered "stealing" power from the serial port. Given the microprocessor there, it is apparent that the serial port cannot provide enough power for the receiver. Therefore, we operate at the standard 5V, as power consumption is not a big concern for the tethered receiver. We allow any DC input above 7V or so to be regulated down to 5V and also accept 5V directly from a USB port, which provides up to 500mA. |