Design Document for the Solar Module Observation Device (SMOD)

(1)

Senior Design SD1107

Design Document for the

Solar Module Observation Device (SMOD)

4/26/2011 Collin Howe, Jacob Rasmuson, Arthur Fiester, Alex Rannow, Timothy Fox

(2)

SD1107 Design Document Solar Module Observation Device (SMOD) Page 2

List of terms

SMOD The device that we will be creating that will be a direct extension/attachment to PowerFilms Solar Module.

Solar Module The Solar Module built by PowerFilm.

Tethering Connecting and saving information about the Solar Module in the Application IMM Input Measurement module located in the SMOD device

App Android application that will communicate with the SMOD device

MC Microcontroller

List of figures

Figure 1: Concept Sketch ... 7

Figure 2: CSR BC4 MCU Block Diagram ... 10

Figure 3: MSP403 Block Diagram ... 11

Figure 4: User Interface Graph Sketch... 16

Figure 5: User Interface Home Screen Sketch ... 17

Figure 6: User Interface Setting Sketch ... 18

Figure 7: Schematic for MSP430/PAN1315 Implementation ... 22

Figure 8: Current Sense Schematic ... 23

Figure 9: Voltage Sense Schematic ... 23

(5)

1. Introduction

1.1. Executive summary

PowerFilm Solar Inc. is a local company in Ames, Iowa that develops and manufactures thin, flexible solar modules. The company's primary objective is to target the growing integrated solar power market and to supply products for selected portable and remote solar power applications, as well as custom and OEM solar module markets. PowerFilm manufactures solar modules that range from 1.5 Watts to 60 Watts in foldable packages and rollable sheets. We will be focusing on the foldable packages that operate under the 10 Watt range.

Currently, the module controlling the charging function of the solar module consists of a light- emitting diode that indicates the panel’s charge status. The diode only shows three states: off (no light), charged (steady light) and charging (blinking light). This primitive method of communication is very ambiguous and leaves users asking, “How charged is my device?”

PowerFilm wishes to have a remote measurement device that can communicate with a smartphone over USB and Bluetooth interfaces. This will allow users to observe an extensive amount of real-time data directly from the solar panel to a user-friendly Android application.

Benefits of this device include the following:

 Access to information about charging/discharging rates to give the user an in-depth look into the status of the device.

 Logging capabilities which will allow users to track the solar module’s efficiency.

 Estimated charging times which will allow the user to track the charge progress of the device.

 Real-time data which will help determine optimal placement angles to place the solar module.

1.2. Project Goal

The goal of this project is to create an accurate, reliable, and portable extension to PowerFilm’s foldable solar modules with minimal overhead. This extension will communicate effectively to an Android phone through a simple, fast, and easy-to-use program, and relay voltage and current information from three separate sources inside the device. One of our primary aims is to allow PowerFilm to create this extension economically; this translates to an upper bound for a production cost of $20. The device will consist of an array of measuring circuits, a microprocessor, and a Bluetooth radio. Our device will allow PowerFilm to expand their products into a new frontier of solar panel modules.

1.3. Operating environment

Our device will be an extension to the currently made foldable solar panels that PowerFilm produces so our device must be able to withstand the same operating environment. Operating temperature should range from −40°C to 105°C. Additionally, it should be able to withstand the same

punishment to which a solar module is subjected to.

(6)

SD1107 Design Document Solar Module Observation Device (SMOD) Page 6 1.4. Limitations

Among the developers of this project, our limitations are time and experience. We have only one year to develop a prototype. None of our group members have programmed with the chosen microprocessor or the Bluetooth device we plan to use. Mounting the device’s components onto a PCB is a new and exciting problem none of us have encountered. Limitations of the actual device include the following:

 The power supply available (Operation between 2V and 15V)

 Amount of power consumed (Less than 50mA in full operation)

 Physical size (Less than or equal to 1 square inch)

 Cost (< $20 for production version)

 Access to programming assistance (development community) 1.5. Deliverables

At the end of the project our client expects one working and fully integrated device and corresponding Android application. Along with the prototypes, it is important to provide

documentation on the device in the form of a user manual and a technical specifications document so that the device can be easily modified and is usable by an average person.

(7)

2. Concept sketch

Figure 1: Concept Sketch

(8)

3. Functional Decomposition 3.1. Microcontroller/Software

3.1.1. Variable sample rates

The user will be able to specify the desired sampling frequency of the 2 voltages and 2 currents which best suits his or her current needs. For example, if he or she is trying to find the optimum angle for power generation from the solar panel, the sampling frequency could be increased to provide better feedback. To obtain a general idea of how the device is doing, the sampling frequency could be decreased in order to reduce power consumption by the device.

3.1.2. Onboard Logging capability

The device must also be able to store, on onboard RAM, voltage and current readings for a certain period of time (Dependent on logging rate and memory available). This data will be used to provide a configurable graph of voltage/current vs. time on the user’s Android device.

3.1.3. Variable power states

In the interest of minimizing power usage by the microcontroller and its associated hardware that could otherwise be used to charge the user’s electronic devices, the microcontroller must be able to be remotely set to different power states. The three power states (active, standby, and sleeping) will allow our device to be much more efficient than if it was running full bore all the time. It must also have a physical power switch to allow the user to entirely disconnect the device. This will prevent it from leeching any power even when it is electrically off.

3.1.4. Power switch

The device must have a physical power switch that can allow the user to manually remove power from measurement device.

3.1.5. Communicate data to the Android phone VIA Bluetooth

The device will have an external Bluetooth radio provided by the PAN 1315 and a PCB-based antenna to communicate over 2.4 GHz Bluetooth to the Android phone. We will be

implementing the TI/Mindtree Bluetooth Stack for Bluetooth communication. The device will be tethered to the phone as an SPP device and will respond with the most recent data when the Android device requests it.

(9)

3.2. Measurement Module

3.2.1. Measure Voltage and Current via ADC

The microcontroller will use 12-bit ADCs to provide for the user voltage and current values with a precision of two decimal places.

3.2.2. Sampling Circuitry

The measurement module must be able to step down the inputs to ADC levels (Voltage: 0 -15.5 V, Current: 0 - 0.5 A) down to VCC. In order to fulfill our design goals we need to measure either voltage or current at four points. The measurements will occur at the voltage and current sources at the solar panel, the voltage at the low side of the battery, and the current flowing into the charging device.

3.3. Android App

3.3.1.Connects to multiple Bluetooth solar panels

The application needs to be able to store data and names for each solar panel that the user is monitoring. These should be able to be switched between quickly and with little processor power. The application must be able to differentiate between the multiple solar panels.

3.3.2. Log data from individual solar panels

The application needs to be able to store voltage and current data for each solar panel. It must be able to store an extended period of time’s worth of data. The measurement device can hold a limited amount of data while the Android phone has more data storage capacity.

3.3.3. Display data to user over time

The application needs to be able to display the data graphically over a period of time for each solar panel. The data must be able to be understood within a couple seconds of viewing the graph and it should be able to display different ranges and so it must have a zoom feature.

3.3.4. Control the power states of the measurement device

The application must be able to change the power states for each tethered device between active, sleeping, and off. The user should be able to figure out easily what state the device is currently in and change the state of the SMOD.

3.3.5.Control the data logging reception rate from the measurement device

The user must be able to choose between higher accuracy with a higher data logging rate or lower accuracy (with a longer period of data collection) with a lower data logging rate.

3.3.6. Estimate time to full charge and charge/discharge rate

The application should be able to monitor the power harvested from the solar panel over the entire data logging period and to estimate the current charge level of the battery. It must also estimate the time remaining before the battery becomes fully charged (if it is charging) or empty (if the battery is discharging).

(10)

4. System analysis (design tradeoffs)

Possible Platforms:

4.1. CSR BC4 PC-ROM

This is a 40pin microcontroller with an on-board Bluetooth2.1 + EDR radio.

Since we require a 12-bit ADC and the

microcontroller had an 8bit ADC, the ADS7866 will be attached to provide a 12-Bit ADC along with an input multiplexer. Since this chip was made for handset and USB dongle applications we would need work around to attach the multiplexer and ADC. It is very unclear if this would be possible.

Pros

 Inexpensive ($3.51 per chip)

 48 KB RAM

 On board Bluetooth radio Cons

 8-bit ADC

 Small developer community

 High voltage need

 Mounting difficulties

4.2. TI CC2540 Bluetooth Low Energy (BLE) onboard microcontroller.

Texas Instrument is prototyping the new CC2540 which was our first solution until we discovered it implemented Bluetooth Low Energy (BLE), which is not compatible with current consumer devices.

This is a 40-pin microcontroller with an onboard BLE radio. BLE is a new standard of the Bluetooth 7 gen and is not backwards compatible and will therefore not connect with modern Android

devices. An external Bluetooth radio will be necessary.

Pros

 Has a 12-bit ADC with 8 input channels

 Small physical size

 256KB RAM

 Lower Power need

 Once the 7^th Gen Bluetooth is implemented into Android phone this solution will be very marketable.

Cons

 Very Expensive

 Needs an external Bluetooth Radio

Figure 2: CSR BC4 MCU Block Diagram

(11)

SD1107 Design Document Solar Module Observation Device (SMOD) Page 11 4.3. TI MSP430F2013 + PAN1315 Bluetooth Radio

This TI MSP430 implementation is in a 64-pin package and will fulfill the requirements with few external components. It provides 4 KB of RAM. A similar processor is contained in an available evaluation kit (which is designed to

easily interface with the PAN1315).

The PAN1315 will be the external Bluetooth 2.1 +EDR radio.

Pros

 PAN1315 is easily made to interface with the MSP430

 Scalable

 Has a 12-bit ADC with eight input channels

 Large development community

 Very Lower Power needed Cons

 Somewhat expensive

 Excessive number of pins

4.4. Antenna size, efficiency, and directionality

The Bluetooth antenna is limited by our physical size constraint of one square inch. The design we intend to use will occupy about 20% of one side of the PCB. It is inlaid into the PCB itself, and with the PAN1315, no matching network is necessary.

Larger antennas would provide more gain, but most of the better antennas will not meet our design goals and limitations. We are limited to very few antenna choices due to these limitations.

4.5. Transmit power and current draw

With our limitation of current drawn, the maximum power consumption of our device is restricted.

Since RF transmit is a large part of that power consumption, out transmit power is effectively restricted by the current limit. We could find ways around this assuming a small duty cycle to even out the current drawn and maximizing power output, but such circuitry would add to our already crowded one-square-inch limitation.

Figure 3: MSP403 Block Diagram

(12)

5. Technology platforms/choices

5.1. TI MSP430F247 + PAN1315 Bluetooth Radio

This is a 60 pin Microcontroller and does not limit our project. Boast a large 32KB of RAM and is designed with the evaluation kit to easily interface with the PAN1315. The PAN1315 will be the external Bluetooth 2.1 +EDR radio. Has more than enough ADC input channels and has 12 bit ADC.

Pros

 PAN1315 is easy made to interface with the MSP430

 32KB Ram

 Allows for expansion

 Had a 12-bit ADC with 14 input channels

 Large Development community

 Very Lower Power need Cons

 Somewhat expensive

 Large physical size

5.2. Programming Android with Java and Eclipse IDE (Integrated Development Environment)

We chose Java because Android was created and maintained in Java. C# is another option, but it is not as well supported by Android and our group has had more experience with Java than with C#.

We choose the Eclipse IDE because it has a very good development environment and is well- supported and maintained and is made to interact well with Android. There are other options that do not use an IDE (instead, they use a text editor and command-line compiler). Our group has experience with Eclipse and we believe it to be sufficient for our needs.

(13)

6. Detailed design

6.1. System architecture (block diagram) 6.2. Microcontroller MSP430

6.2.1. Power Consumption

The amount of voltage needed to power to MSP430 is between 2.2 V and 3.6 V. This will be provided by the storage battery used by the solar module. This will more than enough voltage and will be stepped down to the microcontroller through power regulation. The power states will allow the MSP430 to either use 312 µA in the active mode, 2.6 µA in the sleeping mode, and 1.69 µA in the off mode with fast wakeup.

6.2.2. ADC/Data Sampling

The 12-bit SAR ADC has eight input/output channels. To sample four separate values we need four general input/output pins so this requirement will be fulfilled. Having a 12-bit ADC will give us a resolution of 0.005 from a voltage range of 0 - 15.5 V and an even better resolution for current. This gives us more than enough resolution for both current and voltage.

Data sampling rates will be directly tied to the clock and the MSP430 takes 1000 ns per sample which, once again, will be more than enough to fulfill our requirements of every 100ms.

6.2.3. Data Repository

We need a total of 10 bytes per sample. Below is a breakdown of these bytes

 22 bits for the 10 samples per second timestamp,

 48 bits for four 12 bit samples and

 8 bits for a unique identifier

The MSP430F5438 has 32 KB of Flash Memory so this will roughly give us 14,400 samples that we can save on board the device. At one-minute sampling intervals this will give us 52 hours of storage.

The MSP430F2013 has 2 KB of Flash Memory so this will roughly give us 400 samples that we can save on board. At 10-minute sampling intervals this will give us 33 hours of storage.

6.3. Bluetooth radio PAN1315

This radio will communicate over a UART interface with the MSP430. The Panasonic 1315 includes the radio and all needed antenna matching. It will require an external antenna and slow clock (provided by the MCU)

6.4. Bluetooth Antenna

The 2.4 GHz antenna will be a meandered-inverted F type antenna inlaid in the PCB.

(14)

SD1107 Design Document Solar Module Observation Device (SMOD) Page 14 6.5. Power Regulation/Supply

The system must not provide more than 2 mA into any measurement pin.

6.6. Current Measurement

In order to measure current we will insert a 20 mΩ sense resistor in series on the lines to be monitored. The maximum current (including a margin of safety) that will be seen at either of the points being measured is 0.5 A, resulting in a voltage drop of .01 V across the sense resistor. A differential amplifier will then step-up this voltage. The resistors were chosen such that the circuit would have a gain of 200 V/V. In this case the maximum current (0.5 A) corresponds to a voltage of 2 V at the ADC of our microcontroller. This allows us to derive a linear relationship between the current at the sensor and the voltage at the ADC.

 0.5 A at the sensor corresponds to 2 V at the ADC



6.7. Voltage Step-down ADC Module 6.7.1. Voltage Measurement

The method used to measure voltage is similar to the one used to measure current. The

maximum voltage possible at either of the measurement points (including a margin of safety) is 15.6 V. This voltage is scaled down using an inverting op-ampwith a gain of 1/7.77 followed by a unity-gain inverting op-amp. This results in the maximum voltage of 15.6 V corresponding to a voltage of 2.01 V at the ADC. This, like the current, is a simple linear relationship.

 15.6V at the sensor corresponds to 2.01 V at the ADC

 6.7.2. Circuit Protection

Also at the ADC is a Zener diode and small grounded capacitor in parallel with each

measurement circuit. The Zener diodes break down at 2.1V, protecting the microcontroller from any voltages or currents exceeding the expected maximum. The capacitor is intended to smooth any transients that may be present.

 The ADC is protected from voltages greater than 2.1V by a Zener diode

 A grounded capacitor in parallel minimizes any transient voltages

6.8. Android Application Design 6.8.1. General Design

The Android application will be made from a combination of a number of different modules.

Each will provide different information and will interact differently with the user.

(15)

SD1107 Design Document Solar Module Observation Device (SMOD) Page 15 6.8.2. Connectivity: Multiple SMODs

The application needs to be able to store data and names for each solar panel that the phone connects to. This will be referred to as tethering. These should be able to be switched between quickly and with little processor power. The application must be able to differentiate between the multiple (at least 3) SMODs. Only one SMOD will be able to be tethered to an Android phone but multiple SMODs can tether to an Android phone

6.8.3. Connectivity: Bluetooth interface:

Synchronizing a SMOD to the Android application needs to be fast and simple. Connecting a SMOD to an Android phone will take less than 10 seconds (not counting standing time for user input). The running application will prompt the user for connection when in range if an untethered SMOD and will independently connect to a SMOD if it is tethered to an Android device.

6.8.4. Battery life calculator

The module will estimate the battery’s current charge level and the time remaining before the battery becomes fully charged (if charging) or empty (if discharging). This will all be done while guaranteeing a maximum of 5% deviation from the actual charging rates and battery capacity.

6.8.5. Data Logging

Each SMOD, when connected to an Android phone, will freely update its sampling information at the user-specified rate at either 1 second, 1 minute, 5 minutes, 10 minutes, 30 minutes and every hour. When the SMOD is not actively connected with an application: it will log the information at its last set rate until it runs out of flash memory. When it runs out of memory it will either overwrite old data or notdepending on the user setting. Once connected again, the SMOD will upload its entire memory top the Android application if the user so desires.

6.8.6. Power State Control

The application must be able to change the state of a tethered and connected SMOD. There are three states:

 Active

 Standby

 Sleeping

Any state transition should execute within 2 seconds over either interface. The current state of the SMOD will be displayed in the SMOD home screen. The state status will be refreshed at a rate the can be set by the user in the range of once per second to once per hour.

(16)

SD1107 Design Document Solar Module Observation Device (SMOD) Page 16 6.9. Interface design

6.9.1. User interface.

Any window of the user interface may be accessed within 3 button clicks. Any setting can be changed in less than 4 clicks. Tethering a SMOD to the android phone will take less than 5 clicks. Our user interface will be a tabbed graphical user interface consisting on one home page tab and multiple SMOD tabs. The ordering of tabs will be moveable and the entire application will be

‘zoom-able.’

6.9.2. SMOD Tabs:

This will show the current status of the currently connected and tethered SMOD. There will be a graph that will show the output from the SMOD and a graph of currents and voltages. Upon clicking it will display a table of dates, currents, and voltages. The graph and tables will be ‘zoom-able.’

Figure 4: User Interface Graph Sketch

(17)

SD1107 Design Document Solar Module Observation Device (SMOD) Page 17 6.9.3. Home Screen:

This will be a tab that shows all tethered and currently connected SMODs. This will have a button to tether a SMOD and a button to untether a SMOD. Upon clicking, the SMOD will direct the user to the corresponding SMOD tab.

The user will be able to slide to the next tab.

6.9.4. Displaying Data/Graphing

It will provide to the user a quick evaluation of the charge progression of the battery, and it will report the changes over time that may not be visible from the averages sent by the battery life calculator module. Each graph, if double- tabbed, will display its contents in a table. It will also have the option to calculate the maximum and minimum power reached and what time each was reached.

Figure 5: User Interface Home Screen Sketch

(18)

SD1107 Design Document Solar Module Observation Device (SMOD) Page 18 6.9.5. Setting Screen:

Two types of setting screens will be available:

 The application settings screen which will be accessible one click from the home screen. This will include drop down menus for the following settings: user interface schemes (colors, size of text), graph types, current memory space for the application to allocate, and automatic Bluetooth connect rate.

 The SMOD setting screen which will be accessible one click from each SMOD tab. It will have the following settings: logging rate (and max logging time of that rate) and tethering configuration/info.

Figure 6: User Interface Setting Sketch

(19)

7. Testing and Evaluation plan

Test plan (unit, integration, and system testing, sample test cases)

Tests will be performed in three phases: Module, Integrated and System testing. Module testing will involve testing each module separately. Once it is determined that each module is working within respective parameters we will integrate all three modules in a lab environment. Finally the system test will involve system integration between our working device and a test bed solar panel in “real world” conditions.

7.1. Module testing:

7.1.1. Input measurement module (IMM)

Testing will be primarily based around accuracy and efficiency. Range, signal noise and accuracy through this module will be tested and verified in a lab environment. The power consumption from sampling will also be tested.

7.1.2. Microcontroller and Bluetooth radio (MC)

Power consumed from the different sleep modes of the microcontroller and Bluetooth radio will be tested to ensure they meet requirements. The Bluetooth radio will be powered off of the same supply as the microcontroller, soit must be included in the power consumption testing. Evaluation of the Bluetooth device will include connectivity to and from a Bluetooth host. Like the IMM the MC will need to be protected from power surges.

7.1.3. Android Application (App)

Since the application on the Android phone will be controlling the device, testing for this functionally will be essential. In order to ensure a proper and easy-to-use interface the application will be tested for usability and reaction time. Testing the application with decoy information will ensure that data received from both Bluetooth and USB interfaces will be accurate and displayed correctly. Numerous and unique Android platforms will be tested for comparability and bugs. We will also test the application on accepting and displaying output from multiple modules concurrently.

7.2. Integration testing

7.2.1. IMM to MC communication

The range of sampling rates from the three inputs to the microcontroller will be tested within the parameters set by the application. Additionally all samples should have a resolution of two decimal places. The battery charging time prediction process will also be tested for speed, consistency, and accuracy. Additionally, the sampling rate denoted by the application will be verified for consistency.

(20)

SD1107 Design Document Solar Module Observation Device (SMOD) Page 20 7.2.2. MC to Android App communication

The Bluetooth radio will be tested for data rate, range, and connectivity between the Android phone with the application and the microcontroller. The USB interface will also be tested for data rate and accuracy. Thorough testing will be implemented to ensure the device will quickly and consistently connect to the Android device, transfer data, and then disconnect in addition to switching power modes through the Android application. The device and Android must have proper tethering to allow for this transfer.

7.3. System testing

Testing will include if the unit will successfully power up, initialize, and connect properly given a medium along with the off switch will safely power down the device. We will test this using

numerous light conditions ranging from dim to intense. Temperature durability will ensure the end product will meet PowerFilm requirements.

(21)

8. Evaluation Plan

Test Module Preliminary Results

Accuracy of measuring voltages and currents. IMM 5% error from actual input Battery Capacity/ charging time prediction IMM

Range of voltages/currents IMM 1-15.4 volts and 0.01-0.5 amps

Input sampling rates(upper bound) via Android parameters

IMM, System 5 samples/sec with < 1 second propagation delay

ADC Input resolution IMM, System 2 decimal places

Current consumption of device IMM, MC Active mode: < 300 Microamp Standby mode: < 1 Microamp Hibernate mode: < 1 Microamp Data rate between application and MC MC, App

Perform properly and consistently under durability temperature range test

System Range : -40 to 105

Power mode state change via Android MC, Android <1 second propagation delay Compatible with multiple and different

android devices

App

Off switch safely powers down device System, MC

Power surge protection IMM, MC, System Operates within normal parameters Independent data updating to Android

functionality is consistently working

MC, App, System Works when connection denoted by the application

Consistent Connection/ Disconnection via Android

MC, App

Bluetooth range MC

(22)

9. Electronic circuit design

To power supply Positive (2V to 3.6V DC)

To Current &

Voltage Sensing Scalars

FEED

GND

1 9

1 2

3 4

5 6

7 8 9

1 0 1 1

1 2 2

1 7 1 8

1 3 1 4 1 5 1 6 2

0

2 3 2 4

GND TX_DBG HCI_CTS HCI_RTS HCI_RX HCI_TX AUD_FSYNCSLOW_CLK_IN IO2 MLDO_OUT CL1.5_LDO_IN

GND

RF

GND

MLDO_IN

nSHUTD

AUD_OUT

AUD_IN

AUD_CLK

GND I2C_SDA VDD_IO

I2C_SCL IO1

PAN1315

1 TDO 3 TDI 5 TMS 7 TCK 9 GND 11 RST/NMI 13 NC

VCC_IN 2 VCC_OUT 4 NC 6 TEST/VPP 8 NC 10 NC 12 NC 14

JTAG

MSP430F247

1 DVcc 2 P6.3/A3 3 P6.4/A4 4 P6.5/A5 5 P6.6/A6 6 P6.7/A7/SVSIN 7 Vref+

8 XIN 9 XOUT 10 Veref+

11 Vref-/Veref- 12 P1.0/TACLK/CAOUT 13 P1.1/TA0 14 P1.2/TA1 15 P1.3/TA2 16 P1.4/SMCLK

P5.4/MCLK 48 P5.3/UCB1CLK/UCA1STE 47 P5.2/UCB1SOMI/UCB1SCL 46 P5.1/UCB1SIMO/UCB1SDA 45 P5.0/UCBSTE/UCA1CLK 44 P4.7/TBCLK 43 P4.6/TB6 42 P4.5/TB5 41 P4.4/TB4 40 P4.3/TB3 39 P4.2/TB2 38 P4.1/TB1 37 P4.0/TB0 36 P3.7/UCARXD/UCA1SOMI 35 P3.6/UCA1TXD/UCASIMO 34 P3.5/UCA0RXD/UCA0SOMI 33 Avcc 64 DVss 63 Avss 62 P6.2/A2 61 P6.1/A1 60 P6.0/A0 59 RST/NMI 58 TCK 57 TMS 56 TDI/TCLK 55 TDO/TDI 54 XT2IN 53 XT2OUT 52 P5.7/TBOUTH/SVSOUT 51 P5.6/ACLK 50 P5.5/SMCLK 49

17 P1.5/TAO 18 P1.6/TA1 19 P1.7/TA2 20 P2.0/ACLK.CA2 21 P2.1/TAINCLK/CA3 22 P2.2/CAOUT/TAO/CA4 23 P2.3/CA0/TA1 24 P2.4/CA1/TA2 25 P2.3/Rosc/CA5 26 P2.6/ADC12CLK/CA6 27 P2.7/TA0/CA7 28 P3.0/UCB0STE/UCA0CLK 29 P3.1/UCB0SIMO/UCA0CLK 30 P3.2/UCB0SOMI/UCB0SCL 31 P3.3/UCB0CLKI/UCA0STE 32 P3.4/UCA0TXD/UCA0SIMO 270Ω 270Ω 270Ω

Figure 7: Schematic for MSP430/PAN1315 Implementation

(23)

Figure 8: Current Sense Schematic Figure 9: Voltage Sense Schematic

(24)

10. System design:

10.1. Microcontroller

The device will be controlled by a low power microcontroller. It will use analog-to-digital converters (ADCs) to measure voltages and currents, and a Bluetooth module (or other interfaces such as GSM or USB) to communicate with a user’s smartphone. The device will be configurable to report voltage and current data at user-definable intervals either to a local log and/or to the Android device it is in communication with. The device will be powered by the solar panel storage battery. We will measure the voltage and current from the solar panel, the voltage of the charging side of the battery, and the current out of the battery. The device has multiple power states including active, sleeping, and off.

10.2. Microcontroller power

The microcontroller needs to run at an operating voltage of about 3.0 V. The solar panel’s 3.7 V lithium ion battery should be able to provide the necessary voltage. To account for the 0.7 V

difference, a standard forward-biased diode can be placed in series with the positive terminal of the battery. A nanofarad-range capacitor shunted to ground in parallel with a reverse-biased 3.0 V Zener diode with a kΩ-range series resistor can be placed between the forward-biased diode and the power input to the microcontroller.

10.3. Android Application

The Android application must make use of Bluetooth on the Android hardware to interface with our device. Communication over GSM and USB are desirable possibilities as well, but might be

unfeasible. The application must be able to configure the states of the monitoring device.

Application should incorporate data from the device into a friendly user interface. The application should also allow the user to configure sampling rates and logging options.

(25)

11. References and Notes

Panasonic PAN1315 Datasheet:

http://www.panasonic.com/industrial/includes/pdf/PAN1315_Full-Spec_2010.pdf Texas Instruments MSP430F247 Datasheet:

http://focus.ti.com/lit/ds/symlink/msp430f247.pdf Inlaid PCB Antenna References and Design:

http://focus.ti.com/lit/an/swra117d/swra117d.pdf

Design Document for the Solar Module Observation Device (SMOD)

Senior Design SD1107