Motion Control Sensor Interface

The task involved implementing and programming all hardware devices to make data accessible to the receiver program running on a PC. This included configuring all Prospeckz devices and establishing protocols for radio transmission communication back to the PC. Additionally, the setup of the accelerometer chips for data gathering was required. The problem was divided into several requirements: initially, the wireless communications supported a single transmitter, but this was later modified to accommodate multiple transmitters with minimal data loss. To define the data format transferred from the receiver to the PC, collaboration with a colleague was necessary to create a compact and efficient format that adhered to implementation standards and the PC processor specifications. The design involved creating circuit peripherals around the chips and mounting them on protoboards for testing, subsequently transitioning to small PCBs for compact integration with transmitters. Although there was an initial idea to include a gyroscope to enhance system capabilities, the decision was made to proceed solely with the accelerometer, which proved sufficient. Each task was addressed individually to ensure robustness before progressing. The radio communications between the transmitter and receiver were implemented first, utilizing test programs on the Prospeckz, such as the Cycling LED example in the Prospeckz Guide for verification. The ProSpeckz IIK (Programmable Speck using Zigbee Radio) served as the main microcontroller for all hardware functions. Its notable peripherals include an RGB LED, a Zigbee Radio Chip with a 2.4GHz antenna, a reset switch, a programmable switch, and two 8-bit ports for interfacing with other components. The PSoC CY8C29666-24LFXI acts as the primary programmable component and microcontroller. These models feature 3-axis measurements, support for I2C master-slave communication, good resolution range, and low-power operation. The MMA8451Q accelerometer was selected for its higher availability and ease of integration as a breakout board. After reviewing the accelerometer datasheet and consulting with the team, it was decided that an 8-byte packet size would be compact yet sufficient for wireless communication. The accelerometer provides 14-bit resolution data, requiring 2 bytes for each axis measurement, designated as MSB (most significant bits) and LSB (least significant bits). The total of 3 axes results in 6 bytes of raw data, which is combined in the packet with the device's ID for multi-device support. The packet format consists of colored boxes representing 1 byte (8 bits). It is important to note that the low-level code controlling the radio appends an additional byte at the end of each packet to indicate the packet's length; this is not depicted in the packet diagram. The 8th byte was left empty for potential future use. The realistic payload of the radio communication was determined to be 7 bytes per packet (excluding overhead bytes). Furthermore, error-checking was implemented for the radio communication to identify corrupted, incomplete, or invalid packets. It was concluded that the microcontroller should focus on controlling hardware, leading to the decision to incorporate error-checking in the backend processor executing on the PC.

The circuit design encompasses a modular architecture, allowing for the integration of various components while ensuring efficient data flow. The ProSpeckz IIK microcontroller serves as the central processing unit, managing the Zigbee radio communication and interfacing with the MMA8451Q accelerometer. The accelerometer's output is processed through an I2C interface, which simplifies communication and reduces pin count. The circuit layout includes power supply management to ensure stable operation of all components, with decoupling capacitors placed near power pins to filter out noise.

The PCB design follows best practices for signal integrity, with careful routing of high-frequency signals to minimize interference. Ground planes are utilized to provide a low-resistance return path, enhancing the overall performance of the system. The Zigbee radio module is positioned to optimize antenna performance, ensuring reliable wireless communication over the intended range.

In terms of software, the firmware running on the ProSpeckz IIK is optimized for real-time data acquisition and transmission. It handles the collection of accelerometer data, formats it into the defined packet structure, and manages the radio transmission process. Error-checking algorithms are integrated into the data transmission routine, allowing for the identification and retransmission of corrupted packets, thus enhancing the reliability of data communication.

Overall, this comprehensive design emphasizes robustness, efficiency, and scalability, enabling future enhancements and adaptations as requirements evolve.My task for the system was to implement and program all the hardware devices and make data available to the receiver program running on the PC. This includes the configuration of all Prospeckz devices and implementing protocols for radio transmissions communication back to PC.

I was also tasked with setting up the accelerometer chip(s) for data ga thering. To do this, I split the problem into several requirements: The wireless communications between hardware devices were initially required to support a single transmitter, however this requirement was amended in later stages of system development to support receiving data from multiple transmitters with minimal losses. To define the format of data transferred from receiver to PC, I worked closely with Li to create a compact and efficient format that conforms to the standards of my implementation and the PC processor that he worked on.

- Design the circuit peripherals around the chips and mount them on protoboards for testing, later switching to small PCBs to integrate with transmitters compactly Initially the group had an idea to also incorporate a gyroscope into the hardware implementation to increase the system`s capabilities, however no devices were available and in the end only an accelerometer proved to be sufficient. In response to the requirements above, I tackled each task individually, making sure the implementation is robust before moving on to the next stage.

I first implemented the radio communications between transmitter and receiver, using test programs on the Prospeckz such as the Cycling Led example in the Prospeckz Guide to verify by design. The ProSpeckz IIK (Programmable Speck using Zigbee Radio) was used extensively in this project, as it acted as the main microcontroller for all hardware behavior.

Some of its notable peripherals include an RGB LED, A Zigbee Radio Chip with 2. 4GHz antenna, one reset switch and one programmable switch, and two 8-bit ports for interfacing with other components. The PSoC CY8C29666-24LFXI is housed within the ProSpeckz as the main programmable component and microcontroller.

All these models incorporate the same basic features: 3-axis measurements, support for I2C master-slave communication, good resolution range and low-power operation. It was a draw as to which device to choose, so I ultimately settled for the MMA8451Q accelerometer due to higher availability in the university and because it was easier to integrate with the rest of the system as a breakout board.

After consulting the accelerometer datasheet and discussing with the group, it was decided that for the wireless communication, a packet size of 8 bytes is compact enough while being sufficient. This is due to the fact that the accelerometer provides data with 14 bit resolution, meaning it needs 2 bytes to store the acceleration measurement from each axis; these 2 bytes are denoted as MSB (most significant bits) and LSB (least significant bits).

A total of 3 axes amount to 6 bytes of raw data, to be added together in the packet along with the device`s ID (for multi-device support). The packet format is shown below, with each colored box denoting 1 byte (8 bits): Note that the low-level code controlling the radio appends an additional byte at the end of each packet which contains the packet`s length; this is not shown in the diagram above.

We left the 8th byte empty in case it was ever needed for additional transfers; Once the group was certain the data transferred is sufficient, the realistic payload of the radio communication was 7 bytes per packet (without overhead bytes). Additionally, some error-checking had to be performed on the radio communication in order to determine corrupted/incomplete/invalid packets.

Deciding that the microcontroller is better suited dedicating itself to the control aspects of the hardware, we build the error-checking into the backend processor executing on the PC. Once packet 🔗 External reference