Difference between revisions of "S15: Wireless Power Transfer System"

Revision as of 06:16, 23 May 2015

Grading Criteria

Wireless Power Transfer System

Abstract

                                                      File:Trans rec wrel.jpg

Wireless power transfer or wireless energy transmission is the transmission of electrical power from a power source to a consuming device without using solid wires or conductors. The technology dates back when Tesla first created his coil and the project is based on that idea. As the world is gaining momentum on wireless communication technology, there is a niche market for wireless power transfer for low power devices. This project explores one such idea and implementation for wireless power transfer from source to destination. The project is limited to near field application of such technology. The project does not explore the EMI/EMC aspects of the design.

Objectives & Introduction

Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.

Team Members & Responsibilities

• Team Member 1
  • Haroldo Filho - Lead Software Engineer
• Team Member 2
  • Hemant Raman - Lead Hardware Engineer
• Team Member 3
  • Hassan Naveed - Software Implementation
• Team Member 4
  • Guangyu Chen - Software Implementation

Schedule

 -Light an LED wirelessly
 -Test ADC: read 0~3.3V range
 -Test Nordic wireless: send/receive ADC value

 -Find channel frequency: 7.7MHz
 -Define wireless package structure: status and commands
 -Spec/order motor

 -Implement wireless communication
 -Define software architecture layers
 -Define error code and handler
 -Implement motor control

 -Evaluate ADC reading dynamics and design LPF
 -Implement software architecture layers

 -SW/HW Integration and testing.

Parts List & Cost

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation. The sections below provide a descriptive overview of the hardware block and flow diagram.

Hardware Design

The Hardware design consists of major blocks an shown below. For the transmitter section, there are two methods of turning the system ON/OFF. One is a physical switch which maybe used as an override and the other is a software way of turning it ON/OFF. This switches the 60 Watts power supply module which is transmitted to the Copper loop (ref Pictures). The system runs at about 1.7MHz which is clear of the wireless signal transfer frequency of the Nordic wireless system (2.4GHz). For the Receiver, the loop which is tuned to the resonant frequency of the transmitter has very little losses and picks up about 24V 1.7MHz signal. The Power section has diodes which outputs RMS voltage of 1.41 x 24V AC= 33.9Vrms. Since all logics that the SJSU one board uses 3.3V a zener diode voltage regulator topology is implemented. A 1 ohm power resistor is used to sense the voltage on High Side and a current amplifier is used to set the gain of the system. The amplifier has common mode rejection ration of Bandwidth 500KHz and the signal is very noisy. A low pass filter was implemented in hardware so that the ADC could read stable values. Furthermore the software has a digital filter implemented to further stabilize the readings.

The hardware block diagram for the transmitter is:

File:Tx.PNG‎

The hardware block diagram for the receiver circuit:

File:Rx.PNG‎

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

Software Design

File:Sw1.jpg

For the software design, we define a layered architecture where each layer takes its services from the layer directly below it. The integrity of layered system was important as to ensure that no race conditions are generated where two tasks wait indefinitely for each other. The layers are:

• WIFI : Receive wireless packet from mesh network and pass the packet to communication layer for decoding.

• Communication : Decode the packet and execute corresponding actions.

• Motion Control : Control the motor to move to the desired position.

Package structures between three layers:

Wireless Data Package Structure
|| 1 byte   | length - 1 ||
|| commands |    Data    ||

Status Package Structure
||   1 byte   |      1 byte      |      1 byte      |     x byte     ||
|| Error byte | ADC upper 4 bits | ADC lower 8 bits | Motor position ||

Error byte Structure
|| 8th bit  | 7th bit  | 6th bit  | 5th bit  | 4th bit  | 3rd bit  | 2nd bit  | 1st bit  ||
|| reserved | reserved | reserved | reserved | reserved | reserved | reserved | Busy bit ||

Motion Control Package Structure
|| 1 byte  |   1 byte    |   1 byte    |   1 byte    ||
|| Command | Parameter 1 | Parameter 2 | Parameter 3 ||

Implementation

This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.

Testing & Technical Challenges

Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.

Include sub-sections that list out a problem and solution, such as:

My Issue #1

ISSUE
The current sensing on the receiver through the 1 ohm resistor has a lot of noise riding on the signal. Using a software digital filter was not possible since it would put the software in a blocking mode for the duration of the capture. This would change the topology of the software architecture and deviate from being a good RTOS implementation. A quick alternative option needed to be implemented.

RESOLUTION
The resolution was:
1) to find a component with good common mode rejection ratio. LT1362 device was used, CMMR 500KHz.
2) to implement a Hardware filter before the ADC readings were taken. Even with hardware filter the signal was still noisy. Along with Hardware filter implementation, there was still noise on the signal and showed in terminal window of software. This variability in signal would cause "Hunting" on the transmitter platform where the platform would jitter. A software digital filter was implemented so the signal was smooth and some hysteresis was added to the PID control system of the tuning table.

My Issue #2

ISSUE
The voltage output from the receiving antenna was ~33Vrms and all the electronics for the SJSU board were running at 3.3V logic. Even with voltage dividers it still presented a danger to damage the SJSU board ADC channel in case a large spike lasting long period was generated.

RESOLUTION
A very cheap and simple foldback voltage regulator was implemented which produced 3.3V DC. This ensured that the absolute maximum voltage that the ADC would see was 3.3V. To further protect the SJSU board peripherals, a Instrumentation amplifier block was placed between the 3.3V supply and the ADC. This gave us some confidence that in the worst condition the damage will first be sustained by the Instrumentation amplifier and not the ADC channel.

My Issue #3

When we first implemented the software layers, we handled and decoded all the wireless packages in the top level while the lower two layers also required data feedback to the top level. In this case, the top level needed to listen two queues or to fill feedback to the wireless quese which are both impossible. So we changed the whole architecture and moved the decoding and wireless feedback to the middle layers that made the whole software simpler without any layer violation.

Conclusion

It can be concluded from this project that a lot of real world problems like noise, signal integrity and signal conditioning cannot be solved by software or hardware alone. It takes a combination of the 2 to solve it.
Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

Project Video

• Youtube video of hardware prototype

Project Source Code

• Sourceforge Source Code Link

References

Acknowledgement

We would like to thank our instructor Preet for always inspiring and encouraging us to learn and and explore new projects related to embedded systems. We really appreciate his patience and his guidance.

References Used

List any references used in project.

Appendix

You can list the references you used.