PSAS/ CapstoneLV2bProjectReport

logo.jpg

PSAS Avionics Node Front End for LV2b Rocket

To:

Capstone Team Members:

(16-June-2006)

Table of Contents

  1. Introduction
  2. (Final) Requirements
  3. System Level Design
    1. Communications Bus
      1. Bus Requirements
      2. CAN and USB Comparison
    2. Microcontroller
      1. Requirements
      2. 32-bit Microcontrollers considered
      3. ARM Comparison
      4. Final Choice
    3. RTOS
      1. eCos
    4. System Block Diagram
      1. Block Diagram of Node
      2. Switching Power Supply (SPS) Block Diagram
      3. ARM and Glue Circuitry Block Diagram
  4. Detailed Design
    1. Schematics
      1. Eagle CAD Schematic of node
    2. Board Layout
  5. Component Specification
    1. SPS
      1. Front end Passive Block
      2. Circuit Breaker Block
      3. Overvoltage Protection
      4. Switcher
      5. Secondary Voltage Supply
      6. Power LED
      7. Bill of Materials (BOM)
    2. ARM and Glue Circuitry
      1. ARM 7 microcontroller (U280)
      2. Power decoupling (C285, 286, 287, 288, 291, 292, 293, 294)
      3. USB filtering block
      4. Power-on reset
      5. Oscillator and divider
      6. RTC crystal oscillator
      7. Debug port
      8. Power Good and Shutdown
      9. Breakout of signals to application specific area
      10. Status LEDs
      11. Test points
      12. Configuration trace-cuts or solder jumpers
      13. Bill of materials (BOM)
  6. Software
    1. Introduction
    2. Tools used
      1. Serial Terminal
      2. ISP Software
      3. Cross-Compiler
    3. Serial Port Test
    4. "Hello Blinky World!" Example
      1. Introduction
      2. License Issue
      3. Modifications From Original
      4. Source Code Review
      5. Compiling and Downloading Instructions
      6. Results
    5. eCos Port
      1. Introduction
      2. LPC2148 Port
      3. Source Code Review
      4. Compiling the eCos Demo
      5. Downloading Instructions
    6. Future Work
  7. Construction and Test Plan
    1. SPS
      1. Front end
      2. Circuit breaker (CB)
      3. Switcher
      4. Overvoltage (OV)
      5. Secondary supply
      6. Final System block testing
    2. ARM and Glue Circuitry
      1. Reset Circuitry
      2. Crystal Oscillator
      3. USB interface
      4. ARM + Glue "power up"
      5. ARM + Glue final block testing
    3. Software
      1. Node Testing
      2. Initial USB Testing
      3. USB Performance Testing
    4. Final System Testing
  8. References
    1. USB
    2. Switching Buck Regulator
  9. Appendix
    1. User Manuals

2006 Capstone Project Final Report

Introduction

Our Capstone project was sponsored by the Portland State Aerospace Society. PSAS is a Portland State University student club that focuses on amateur rocketry projects. Students and industry professionals design and build motors, airframes, avionics hardware, and write software, all with the end goal of launching an "open source" rocket. All the designs and software are freely available on the PSAS website, so any amateur group could duplicate our results.

Since the successful but finally disastrous launch of Launch Vehicle No. 2 (LV2), the PSAS Avionics Team has been redesigning the avionics system. This new system, called the "LV2b" avionics system, should avoid the limitations of the old system:

The goal of the PSAS Capstone team is to design the generic front-end that interfaces between all the nodes of the system (GPS, IMU, recovery system, etc) and the communication bus.

(Final) Requirements

There are three requirements for completion of our capstone project:

These engineering notebooks should cover the three major areas of design: the Switching Power Supply (SPS), the microcontroller and glue circuitry, and the software. The notebooks should contain a detailed discussion of how the design works and an explanation of all component choices and values. A smart, experienced engineer should be able to use this document to understand why the design is the way it is.

System Level Design

Communications Bus

Part of our capstone project was to decide what communications bus the next generation rocket should use. Numerous suggestions were thrown out (from FireWire to MIL-STD-1553) but only two communication buses were considered in depth: the Universal Serial Bus (USB) and the Controller Area Network (CAN) bus.

Bus Requirements

Avionics Team Requirements

Reliability

The bus must be capable of handling EMI, along with short and open conditions on the PHY layer. The bus must tolerate the acceleration and vibration associated with a launch. The bus should also have been used in real-time systems where a failure in the bus might result in lives being lost (such as medical equipment or automobiles). The bus must provide a way for the software to prioritize messages so that system critical messages will be sent, even at the expense of non-critical messages.

Performance

The bandwidth of the bus must be large enough to keep data flowing and nodes operational. Some nodes will require access to the bus on regular intervals, while others will be sending non-periodic data packets. The previous rocket's CAN bus provided 1Mbps, and at most 40% of that bandwidth was used. The bandwidth requirement may change, so more bandwidth would be better.

Software Team Requirements

High level software control

The Software team would like the high-level software to deal with retransmission of corrupted packets and packets that were not received by the intended recipient. System critical messages like commands for parachute deployment and manual overrides from ground support are important to retransmit if a failure occurs. Retransmission of time-based data like IMU readings is not useful and may eat up the bandwidth of the bus.

Connectivity

The bus should be able to interface to laptops during testing with minimal difficulty. The communications connectors should be easy to remove during development and testing, but must lock down during flight. It would also be ideal if the node controllers could be flashed over the bus.

Firmware and Device Drivers

The firmware for the node controllers should be maintainable. If there already exists tested bus protocol drivers, it would be advantageous to use them to minimize the development time and design complexity. Firmware and device driver development should not require proprietary software or a propriety environment (i.e. Windows).

CAN and USB Comparison

Avionics Team Requirements

Reliability

Both USB and CAN are differential buses, and are more immune to EMI than single-ended buses. CAN is used in some automobile systems, but not in any systems where failure of the bus alone would result in an accident. USB is used in some medical devices, but not in life-critical devices.

CAN and USB differ in how they prioritize messages. CAN provides a message-by-message prioritization: when the bus is idle and two nodes attempt to transmit, the node with a higher prioritization continues to transmit and the other node waits for the bus to become idle. USB allows the software to reserve bandwidth for each USB endpoint.

USB relies on a host (in our case, the flight computer) to initiate all transactions, even interrupts. This means that if the flight computer powers off, no messages will flow on the bus. With the CAN peer-to-peer model, the bus would still operate if the flight computer were offline.

Performance

CAN provides 1Mbps, and full-speed USB provides 12Mbps.

Software Team Requirements

High Level Software Control

The CAN controller handles packet retransmission automatically. The Software team is concerned about the automatic retransmission of all corrupted packets. Often we don't want an older time-dependent message (such as an IMU message) to be retransmitted if it means that we don't receive the newest message. If a high priority node starts sending lots of corrupted packets, it may flood the bus with automatic retransmissions. This is a remote possibility, but it demonstrates the inflexibility of the CAN transmission protocol.

USB provides some flexibility when it comes to message retransmission. If the transmitter uses isochronous transfers, there is no ACK of the message, and corrupted packets are not retransmitted. Isochronous transfers provide guaranteed bandwidth, and would be ideal for messages from the IMU. Control transfers provide a limited amount of guaranteed bandwidth (10% of the frame, or more if the isochronous transfers take less than 90% of the bandwidth). They are acknowledged by the receiver, and automatically retransmitted if the message was not acknowledged or if it was corrupted. Control transfers would be ideal for system critical messages, such as data from the DTMF receiver board or commands to the recovery node. Each USB endpoint could be set to a different transfer type.

Connectivity

A USB communications bus could be directly plugged into a software developer's laptop. CAN requires special conversion hardware (such as USB to CAN adapters) to interface with a laptop. USB will require a special connector, since the standard connector does not lock into place. However, CAN has no standard connector, so we will be creating our own custom connectors anyway.

Firmware and Device Drivers

The most likely candidate for an open source RTOS is eCos, and the flight computer will run Linux. PSAS members have experience writing CAN drivers, but they also have local contacts with people who write Linux USB device drivers. There are many Linux and eCos USB drivers available that could be modified, but few CAN drivers. Linux and eCos both have a hardware-independent driver framework for USB, but not for CAN.

PSAS members have written CAN drivers, and PSAS has contacts with programmers who have written USB drivers for Linux. Even if we find a device driver that meets most of our needs, there will probably be some custom "hacking" on it.

Summary

Hardware Requirements

Requirement

CAN

USB

"best" bus

EMI immunity

Differential bus

Differential bus

-

tolerance to over-voltage

built-in

none

CAN

safety critical systems usage

automobiles

some medical devices

CAN

message priority

individual node priority

bandwidth priority

?

bus topology

peer-to-peer

host initiated

?

speed

1Mbps

12Mbps (full speed)

USB

Software Requirements

Requirement

CAN

USB

"best" bus

packet retransmission

automatic

depends on message type

USB

packet size

up to 8 bytes

up to 1023 bytes

USB

connectivity

special connection disrupts debugging

plugs in directly to a laptop

USB

previous open source drivers

very few

good Linux support

USB

As the chart shows, the Avionics team wanted the CAN bus because it provided better hardware reliability and was widely used in safety critical systems. However, USB was an overall win for the Software team. In the end, the promise of higher bandwidth and better open source support won over the Avionics team.

Microcontroller

Requirements

The microcontroller for the node front-end must meet the following requirements:

Architecture

Development Tools

Packaging

Peripherals

Computational Horsepower

Power Consumption

Cost

32-bit Microcontrollers considered

There were two microcontroller architectures considered initially: ARM (Advanced RISC Machine) and PPC (Power PC). ARMs are popular microcontrollers with good open source support. On the other hand, PSAS has a grant from IBM to use Power PC microcontrollers on the rocket. A quick look at PPC manufactures revealed the microcontrollers did not meet our package size requirements; the smallest package size available was a 168 pin BGA.

ARM Comparison

The capstone team searched the websites of over 34 companies that license the ARM core. Of those companies, only five had microcontrollers with CAN or USB: Atmel, Freescale, Philips, STMicroelectronics, and Texas Instruments.

There were roughly 30 chips that met our requirements. We compared the 30 chips, looking at various characteristics, such as package size, speed, memory, and peripherals. For the full comparison chart, see the file ARMs.xls

There were 11 microcontrollers that best met our requirements: 5 had both CAN and USB, 3 had CAN only, and 3 had USB only. The microcontrollers that had both CAN and USB were all 100 pin packages from Atmel. Once we looked at drawings of pin package sizes compared to our required board size, we realized that we simply couldn't fit a 100 pin package on the board. That only left the 64-pin CAN only or USB only microcontrollers.

When the decision was made to use USB in the next generation rocket, we took a look at the USB only ARM chips. There were three top choices: an Atmel AT91SAM7S256, the Philips LPC2148, and the STM STR711FR2T6.

Comparison Chart

Characteristic

Atmel

Philips

STM

production status

production

sampling

active

SRAM (KB)

64

40

64

flash (KB)

256

512

256

frequency (MHz)

55

60

66

JTAG

Y

Y

Y

serial boot

N

Y

?

A/D bits

10

10

12

number of ADCs

8

14

4

max number of GPIO pins

32

45

30

UARTs

3

2

4

SPIs

1

2

2

I2C

1

2

2

16 bit timers

3

4

4

PWM channels

4

3

4

Watch dog reset

Y

Y

Y

brown out reset

Y

Y

?

power on reset

Y

Y

?

RTC

Y

Y

N

Miscellaneous "Warts" Found

Atmel

To use USB, the system designer is forced to under clock the microcontroller at 48MHz. It also doesn't have a real-time clock (only a real-time timer). The Atmel chip was discarded early in the selection process because of USB issues (see below).

Philips

Philips was lacking in memory, and the quoted SRAM size of 40KB is deceptive. There is 32KB of SRAM for general use, but 8KB of that is reserved for USB. That puts it on the lower limits of our memory requirements.

The Philips part exclusively uses an internal 1.8V voltage regulator, which means we can't hook up our switching power supply. This increases the power consumption of the system.

Also, the pin multiplexing may prove troublesome. When PSAS designs a self-correcting rocket, all three PWMs will be used on a node to control motor servos. The PWMs on the LPC2148 conflict with other devices we want to use, such as SPI and UART0. However, this need is far in the future and we may switch to a new microcontroller before then.

STM

The STM part also requires the microcontroller to be run at 48MHz to use USB.

Another wart was that the ADC conversion time is listed as 1ms. This was unacceptable, considering that the other two microcontrollers listed 2us conversion times. The PLL lock time also seemed to be a bit long; it was listed as 600us, while Philips listed a 100us lock time. Further, the internal oscillator takes 2.5 seconds to start up. If the microcontroller has to do a hard restart in flight, we would lose half of the apogee window to oscillator initialization.

Also, the data sheet was vague about whether the internal voltage regulator could be bypassed in Standby mode.

USB Considerations

The STM documentation for USB was severely lacking. Their datasheet did not indicate how many of each type of USB endpoint were available. The lack of documentation made this an unacceptable choice.

The Atmel part only had four USB endpoints; two endpoints could be configured to be isochronous endpoints. They also listed endpoint 0 as being able to send control, bulk, or interrupt transfers. This seemed to be an indication they were doing something out of spec with their USB controller, since the USB specification clearly states that endpoint 0 must be reserved for control transfers from the host.

The Philips chip had the best documentation of the three chips, and it had the most endpoints. The LPC2148 had 16 USB endpoints and 4 endpoints could be configured to be isochronous endpoints.

Final Choice

In the end, we decided to choose the Philips LPC2148 chip because of its great documentation and USB support.

RTOS

A program with real-time requirements will need a real-time operating system. With a standard operating system, there is no guarantee that time constraints of a program will be met. This is disastrous in an avionics system, when a delay in sensor data or recovery node commands may mean the parachute is not deployed in the 5 second apogee window.

RTOS Requirements:

There were two RTOS that fit all requirements: eCos (http://ecos.sourceware.org/) and FreeRTOS (http://www.freertos.org/). PSAS members have more experience with eCos, so eCos was chosen.

eCos

eCos stands for "embedded Configurable operating system". eCos is configurable because you can choose which features you want to compile into your embedded operating system. This allows you to tweak your options if you don't have a lot of memory in your embedded system. For example, a programmer can choose to compile GDB stubs into their program and eCos. This is great for debugging, but can inflate the code size. After the person is done coding and wants to run the program out in the field, they can recompile eCos without GDB stubs to save memory.

System Block Diagram

Here is the new avionics system design:

lv2 avionics diagram 2006-06-01 sized.png

Block Diagram of Node

The scope of this project is within the dashed line.

sys block.png

Each generic node front-end contains a switching power supply (SPS), some "glue circuitry", and an ARM microcontroller running a real-time operating system (RTOS).

Switching Power Supply (SPS) Block Diagram

SPS Block Diagram.png

Power Bus

Front end Passive Block

Circuit Breaker Block

Overvoltage Protection Block

Switcher

+3.3 V SPS

Power LED

Secondary Voltage Supply

ARM and Glue Circuitry Block Diagram

The underlying goal of the Glue subsystem is to satisfy the interconnection needs of the microcontroller, and to provide any forseen resources to the application specific area for future users.

glue block.png

System Block Diagram - Glue

ARM7 microcontroller (CPU)

Power decoupling

USB filtering block

Power-on reset

Oscillator and divider

RTC crystal oscillator

Debug port

Power Good and Shutdown

Breakout of signals to application specific area

Status LEDs

Test points

Configuration trace-cuts or solder jumpers

Detailed Design

Schematics

Eagle CAD Schematic of node

The schematics used in the design of this project appear in two forms; one for the Spice circuit simulator, and another for the Eagle CAD PCB board layout tool. This section only shows the Eagle CAD schematic. The Spice schematic was used for verification of the SPS design, and can be found in that section.

Naming convention

The name of this project according to PSAS convention is:

So the name of this board is: lv2-node4-frontend

Getting the Eagle CAD board layout tool

Go to the Eagle CAD site (http://www.eagle.de) and follow the instructions under downloads for your specific platform. For this project we used the Debian Linux distribution, and thereby were able to use Debian's package management tool called Aptitude. The following command on a Debian Linux system installs the Eagle CAD software package.

sudo apt-get install eagle

Getting the Eagle schematic files for this project

The schematic files for this project are kept in the PSAS Subversion source repository. The following Linux command checks out the CAD sub-tree from the repository which includes the node-4 files, and needed libraries. To find out more about Subversion see: <http://subversion.tigris.org/>

svn co http://svn.psas.pdx.edu/svn/psas/trunk/cad

The above command will check out the entire PSAS cad directory. The files you will actually need for this project are:

It is intended that eventually the <node4.lbr> library be merged into the <psas-eagle-library.lbr> library at a future time.

Maintaining the files

To maintain the schematics, be sure you have latest copies before starting by doing an update command. Once your changes are made, check them into the repository using the check-in command.

svn up    # get latest update
svn ci    # check-in your latest work

Board Layout

This is the preliminary board layout; it is not complete. The board dimensions are 2 in. x 3 in. with traces on only two sides. Components are also on top and bottom. The decision to use only two trace layers was driven by the desire to use the free version of Eagle CAD, which is a PSAS standard.

On the left top side of the board is the USB/Power connector. The Debug port will be placed on the left bottom side.

gnl board.png

Both top and bottom of board shown with component placemets

gnl board top.png

Top side only of board

gnl board bot.png

Bottom side only of board

Component Specification

SPS

SPS Design Schematic rev2 2.png

SPS Design Schematic rev2 2.pdf

Note: It is easier to refer to the schematic above when reading section 1.5.1 instead of the detailed Eagle schematic in section 1.4.1.1. This is because this section exclusively covers all SPS components. The part numbers are consistent with those in the Eagle schematic.

Front end Passive Block

Power Bus Input Choke (L201a, L201b)

Part Description:

Purpose:

Specifications/ Calculations:

Power Bus Fast-Acting Fuse (F200)

Part Description:

Purpose:

Specifications/ Calculations:

DC Path From SPS Node GND to Chassis GND Resistor (R215)

Part Description:

Purpose:

Specifications/ Calculations:

Power Bus Input Caps (C203, C204)

C203

Part Description:

Purpose:

Specifications/ Calculations:

C204

Part Description:

Purpose:

Specifications/ Calculations:

Power Bus Input Voltage Suppressor (TVS200)

Part Description:

Purpose:

Specifications/ Calculations:

Circuit Breaker Block

MAX5902 Circuit-Breaker Resistor Network (R250, R251)

R250

Part Description:

Purpose:

Specifications/ Calculations:

R251

Part Description:

Purpose:

Specifications/ Calculations:

Overcurrent/Circuit-Breaker Protection (U250)

Part Description:

Purpose:

Specifications/ Calculations:

MAX5902 External P-MOSFET (Q250)

Part Description:

Purpose:

Specifications/ Calculations:

MAX5902AAETT Circuit-Breaker External P-MOSFET RDS(on) Additional Series Resistor (R252)

Part Description:

Purpose:

Specifications/ Calculations:

Overvoltage Protection

Undervoltage/Overvoltage Protection (U251)

Part Description:

Purpose:

Specifications/ Calculations:

TLV3012AIDBVT Overvoltage Detection External N-MOSFET Current Limiting Resistor (R253)

Part Description:

Purpose:

Specifications/ Calculations:

TLV3012AIDBVT External Logic-Level N-MOSFET (Q251)

Part Description:

Purpose:

Specifications/ Calculations:

TLV3012AIDBVT UVLO Lockout Resistor Network (R254, R255)

R254

Part Description:

Purpose:

Specifications/ Calculations:

R255

Part Description:

Purpose:

Specifications/ Calculations:

TLV3012AIDBVT "Secondary Power Supply" Schottky Diode (CR250)

Part Description:

Purpose:

Specifications/ Calculations:

TLV3012AIDBVT "Secondary Power Supply" Cap (C250)

Part Description:

Purpose:

Specifications/ Calculations:

TLV3012AIDBVT Overvoltage Detection Cap (C251)

Part Description:

Purpose:

Specifications/ Calculations:

Switcher

Step-Down Switching Voltage Regulator (Buck Topology) (U200)

Part Description:

Purpose:

Specifications/ Calculations:

LT1767EMS8 UVLO Lockout Resistor Network: (R209, R210)

R209

Part Description:

Purpose:

Specifications/ Calculations:

R210

Part Description:

Purpose:

Specifications/ Calculations:

LT1767 UVLO Resistor Network Shunt Cap (C210)

Part Description:

Purpose:

Specifications/ Calculations:

Buck Input Cap (C201)

Part Description:

Purpose:

Specifications/ Calculations:

LT1767 Frequency Compensation Caps (C205, C206)

C205

Part Description:

Purpose:

Specifications/ Calculations:

C205 may not be needed given that the frequency compensation of R206/C206 is satisfactory.

C206

Part Description:

Purpose:

Specifications/ Calculations:

Boost Cap (C202)

Part Description:

Purpose:

Specifications/ Calculations:

Boost Rectifier Diode (CR201)

Part Description:

Purpose:

Specifications/ Calculations:

Buck (Catch) Schottky Diode (CR200)

Part Description:

Purpose:

Specifications/ Calculations:

Split Buck Inductor (L200a, L200b)

Part Description:

Purpose:

Specifications/ Calculations:

Buck Output Cap (C200)

Part Description:

Purpose:

Specifications/ Calculations:

LT1767 FB Resistor Network: (R200, R201)

R200

Part Description:

Purpose:

Specifications/ Calculations:

R201

Part Description:

Purpose:

Specifications/ Calculations:

LT1767 FB Resistor Network Shunt Caps (C208, C209)

C208

Part Description:

Purpose:

Specifications/ Calculations:

C209

Part Description:

Purpose:

Specifications/ Calculations:

SPS Output Power On LED Current Limiter Resistor (R214)

Part Description:

Purpose:

Specifications/ Calculations:

Secondary Voltage Supply

SPS Secondary Buck (Catch) Schottky Diode (CR251)

Part Description:

Purpose:

Specifications/ Calculations:

SPS Secondary Buck Output Cap (C252, C252a)

Part Description:

Purpose:

Specifications/ Calculations:

Power LED

SPS Output Power On LED (D201)

Part Description:

Purpose:

Specifications/ Calculations:

Bill of Materials (BOM)

NOTE: Component fields with a "-" mean they are TBD.

Digi-Key BOM

Qty

Digi Key SKU

Cust ID

Part

Mfgr

Description

Mfg Num

Price

Stock

Package

Order Size

5

LT1767EMS8-ND

PSAS-SPS

U200

Linear Tech

Switching Step-Down Voltage Buck Regulator

LT1767EMS8

6.00

2716

8-MSOP

1

5

PCC2401CT-ND

PSAS-SPS

C200

Pansonic-ECG

22 uF Ceramic Cap

ECJ-2FB0J226M

8.31

4740

0805

10

5

PCC2414CT-ND

PSAS-SPS

C201

Pansonic-ECG

10 uF Ceramic Cap

ECJ-3YB1E106K

5.45

7640

1206

10

5

PCC1840CT-ND

PSAS-SPS

C202

Pansonic-ECG

0.1 uF Ceramic Cap

ECJ-2YB1H104K

1.61

21520

0805

10

5

399-3782-1-ND

PSAS-SPS

C203

Kemet

22 uF Tantalum Cap

T491D226K025AT

0.65

863

7434-31

1

5

490-3327-1-ND

PSAS-SPS

C204

Murata Electronics North America

0.33 uF Ceramic Cap

GRM219R71H334KA88D

3.09

3090

0805

10

5

-

PSAS-SPS

C205

-

-

-

-

-

-

-

5

-

PSAS-SPS

C206

-

-

-

-

-

-

-

5

-

PSAS-SPS

C208

-

-

-

-

-

-

-

5

BC1256CT-ND

PSAS-SPS

C209

BC Components

10 pF Ceramic Cap

VJ0805A100JXACW1BC

0.52

80

0805

10

5

BC1298CT-ND

PSAS-SPS

C210

BC Components

0.1 uF Ceramic Cap

VJ0805Y104KXATW1BC

0.72

60

0805

10

5

399-3127-1-ND

PSAS-SPS

C250

Kemet

2.7 uF Ceramic Cap

C0805C275K8PACTU

7.02

3860

0805

10

5

478-1359-1-ND

PSAS-SPS

C251

AVX Corp

0.015 uF Ceramic Cap

08051C153KAT2A

2.64

5300

0805

10

5

-

PSAS-SPS

C252, C252a

-

-

-

-

-

-

-

15

MA2Q70500LCT-ND

PSAS-SPS

CR200,CR250,CR251

Panasonic-SSG

30V Schottky Diode

MA2Q70500L

6.24

4192

MiniPower 2P

10

5

MMBD1501TPMSCT-ND

PSAS-SPS

CR201

Micro Commercial Co.

180V Rectifier Diode

MMBD1501-TP

2.00

3000

SOT-23

10

5

L71515CT-ND

PSAS-SPS

D201

CML Innovative Technologies Inc

1.9V Orange LED

CMDA5BA7D1S

0.35

3048

0805

1

5

WK6213CT-ND

PSAS-SPS

F200

Wickman USA Inc/Littlefuse Inc

500 mA Fast Acting Fuse

FCD120500TP

0.56

4521

1206

1

5

ZXMP6A17E6CT-ND

PSAS-SPS

Q250

Zetex Inc

P-Channel MOSFET

ZXMP6A17E6TA

1.04

2755

SOT-23-6

1

5

BSS123INCT-ND

PSAS-SPS

Q251

Infineon Technologies

N-Channel Logic-Level MOSFET

BSS123E6327

0.36

4177

SOT-23

1

5

SMBJ18ADICT-ND

PSAS-SPS

TVS200

Diodes Inc

Unidirectional Voltage Suppressor

SMBJ18A-13

0.89

896

SMB

1

20

RHM10.0KCCT-ND

PSAS-SPS

R200,R210,R251,R255

Rohm

10 kohm Resistor

MCR10EZHF1002

0.38

34,300

0805

10

5

RHM17.4KCCT-ND

PSAS-SPS

R201

Rohm

17.4 kohm Resistor

MCR10EZHF1742

0.38

3370

0805

10

5

-

PSAS-SPS

R206

-

-

-

-

-

-

-

5

RHM60.4KCCT-ND

PSAS-SPS

R209

Rohm

60.4 kohm Resistor

MCR10EZHF6042

0.38

960

0805

10

5

RHM649CCT-ND

PSAS-SPS

R214

Rohm

649 ohm Resistor

MCR10EZHF6490

0.38

760

0805

10

5

RHM100KCCT-ND

PSAS-SPS

R215

Rohm

100 kohm Resistor

MCR10EZHF1003

0.38

15560

0805

10

5

RHM61.9KCCT-ND

PSAS-SPS

R250

Rohm

61.9 kohm Resistor

MCR10EZHF6192

0.38

3160

0805

10

5

P.82DCT-ND

PSAS-SPS

R252

Panasonic-ECG

0.82 ohm Resistor

ERJ-6RQFR82V

2.10

4440

0805

10

5

RHM47.0KCCT-ND

PSAS-SPS

R253

Rohm

47.0 kohm Resistor

MCR10EZHF4702

0.38

6840

0805

10

5

RHM18.2KCCT-ND

PSAS-SPS

R254

Rohm

18.2 kohm Resistor

MCR10EZHF1822

0.38

3650

0805

10

Coiltronics BOM

Qty

Coiltronics SKU

Cust ID

Part

Mfgr

Description

Mfg Num

Price

Stock

Package

Order Size

5

SD3118-470-R

PSAS-SPS

L200a,L200b

Coiltronics

47 uH Inductor

SD3118-470-R

-

-

Shielded Drum "Bobbin" (SMT)

-

5

CMS1-11-R

PSAS-SPS

L201,L202

Coiltronics

100 uH Inductor

CMS1-11-R

-

-

Torodial (SMT)

-

ARM and Glue Circuitry

ARM 7 microcontroller (U280)

Part Description:

Purpose:

Specifications/ Calculations:


Power decoupling (C285, 286, 287, 288, 291, 292, 293, 294)

C285, C286, C287, C288, C291, C292, C293, C294

Part Description: