Electronic devices supply with as low capacity as possible a battery with capacitor supporting

Application Note: JN-AN-1055
Using Coin Cells in Wireless PANs

This Application Note provides guidance on the system issues to be considered when

using a coin cell to power a device based on the Jennic JN513x wireless microcontroller. These include:

• Selecting the most appropriate cell

• Network operation

• Reduction of current consumption through hardware design

• Software techniques to reduce energy use

• Sample demonstration application

• Battery life calculation

Overview

Whilst initially appearing to offer an attractive and compact power source, the coin cell has a number of drawbacks that complicate its use in devices requiring short bursts of relatively high current. Depending on the target application, it may be possible to design the system to work around some of these limitations.

The advantages and disadvantages of coin cells are presented below.

Advantages

• Compact and lightweight

• Convenient 3V nominal single-cell voltage

• Relatively flat voltage over discharge

• Excellent self-discharge characteristics

Disadavantages

• Very low capacity

• High internal resistance

• Low maximum current source capability

• Long recovery time after supplying a high-current pulse

• Cell capacity decreases as load increases

Selecting a Coin Cell for Your Application

When choosing a cell for a system, there are a num ber of key factors that determine which cells are suitable. These are described below.

Average Current Consumption

The most significant factor that affects the choice of cell is the device’s average current consumption. Since the current drawn will vary considerably depending on the state of the system, in order to find the average current it is necessary to determine the current consumption for each of the different system states and the amount of time spent in each state.

To calculate the average current consumption, the average consumption for each state must be determined using the following equation:

offon on average tt t II + ×=

where I is the instantaneous current in the given state, t

on

is the time spent drawing current and t

off

is the time spent not drawing current in a cycle of the state.

For example, consider a device with three states, as listed below:

• Sleep state - drawing a steady current of 4 µA

• Beacon reception and processing state - waking up once every 10 seconds for a period of 2 ms to draw a current of 40 mA

• Data transmission state - transmitting a message back five times per day, each time drawing a current of 40 mA for a period of 100 ms

Thus,

Average sleep state current = 4 µA

Average beacon reception state current

=×= 10 2 40 ms mA

8 µA

Average data transmission state current

= × ×

×

×= seconds)60minutes60hours24( )1005( 40 ms mA

232 nA

Therefore, the average current consumption of the device is 4 µA + 8 µA + 232 nA = 12.232 µA

Obviously, this is a simplified example. In real applications, there are likely to be a larger number of states that draw varying amounts of current.

Desired Battery Life

Once the average current consumption has been calculated, it is possible to derive the capacity required to power the device over the desired ba ttery run-time using the following formula:

runtime average TI Capacity ×=

where I

average

is the average current consumption in amps and T

runtime

is the desired run-time of the battery in hours.

Taking the above example and a desired battery life of 1 year:

=

× × = )24 365(232.12 hours days µA Capacity

107.2 mAh

So in this case, the smallest suitable cell would have a capacity of at least 107.2 mAh.

Maximum Current Consumption

The maximum current that the device will draw at any time also affects the choice of cells since the available capacity of a coin cell varies depending upon the current drawn from it. Coin cells also have a very high internal series resistance and a low maximum current sourcing ability.

Continuing with the above example, a suitable cell would appear to be a CR2032 cell with a nominal capacity of around 220 mAh. The specifications for a Sanyo CR2032 cell are shown below:

Nominal Capacity *1	220mAh
Nominal Voltage	3V
Standard Discharge Current	0.3mA
Continuous *2	4mA
Max Disch	arge
Current Pulse *3 2	0mA Temper a tu
re Rang	e -20

°

C – 70°C Weight 3.0g *1 Nominal capacity is determined fo r an end voltage of 2.0V when the cell is allowed to di scharge at a standard current level a

t 23 degrees Celsius. *2 Current value is determined to be t he level at which 50% of the nominal capacity is obtained w ith an end voltage of 2.0V a

t 23 degrees Celsius. *3 Current value for obtaining 2.0V cell voltage when pulse is applied for 15 seconds at 50% discharge depth a

t 23 degrees Celsius. From the above data, it can be seen that the specified cut-off voltage is 2.0V . Since this is lower than the 2.2V minimum operating voltage of the Jennic wireless microcontr oller ICs, it will be necessary to compensate for this difference in any subsequent c alculations. If other components in the system require a higher minimum voltage, it will be necessary to co

nsider these as well. It can also be seen that with a continuous discharge current of 4 mA, the CR2032 cell would only provide 50% of its nominal capacity. Fortunately, in our example , the average current consumption is only 12.232 µA, well below the quoted standard dischar

ge current of 0.3 mA. Since the Jennic wireless microcontroller IC will only operate down to 2 .2V, we must consider this when calculating the maximum pulse energy available. The cell is c apable of providing a 20 mA current pulse for 15 seconds with a start voltage of 3.0V and an end voltage of 2.0V, thus giving a 1V drop over a period of 15 seconds - that is 0.0666666 Volt

Since we have an end voltage of 2.2V, we are only allowed a 0.8V drop. With a voltage drop per second of 0.0666666, this gives a duration of 12 seconds (0.8/0.0666666) with an average voltage of 2.6V, assuming a linear drop. If we convert the energy in this pulse into Joules:

=××=×= smAVTPE 12)206.2(

0.624 J

We can also calculate the energy required for the 40-mA pulse of 100-ms duration in the example (assuming an average cell voltage of 2.6V during the pulse)

=××=×= ms mAVTPE 100)406.2(

10.4 mJ

Since this is considerably less energy than the maxi mum pulse capacity of the cell, it is likely that the CR2032 cell would be a suitable candidate for the example application. However, it would still be prudent to contact the battery manufacturer to confirm suitability, since the cell’s internal resistance (which is not given in the battery data) may limit the maximum current that can be drawn.

Boosting the Maximum Cu rrent Pulse Capability

If the chosen cell is not capable of supplying the energy required for the pulse, it may be possible to supplement the energy from the cell wi th energy stored in a capacitor connected in parallel.

The required capacitance of the capacitor can be calculated using the steps below:

1. Find the voltage drop V that the system can tolerate during its maximum energy pulse delivery (0.8V here, since the start voltage would be 3.0V and the end voltage 2.2V).

2. Find the maximum energy that the cell can deliver in a single pulse (for the above cell, this is 0.624 Joules) – call this E

del

.

3. Find the maximum energy required in a single pulse by the system – call this E

sys

.

4. Calculate the energy shortfall E

diff

= E

sys

- E

del

In this example, if we have a system with a maximum pulse requirement of 40 mA for 6.5 seconds:

=

××=×= smAVTPE sys 5.6)406.2(

0.676 J

Therefore, the energy shortfall E

diff

is 0.676 – 0.624 = 0.052 J .

5. Use the following formula to find the size of capacitor required to make up the energy shortfall:

= × == 2 2 8.0 5222 mJ V E C

162.5 mF

In this case, the required capacitance is very large. Therefore, it may be more economical to choose a larger cell.

If a cell is chosen with very poor pulse capability but only very short periods of high current operation are required, it may be possible to supply all of the current pulse with a capacitor, the value of which can be calculated using the following formula:

= × = × == V msmA V TI V Q C 8.0 10040

5000 µF

Alternatively, to find how long a given capacitor can support a high current operation, the following steps can be followed:

1. Choose a capacitor - for this example, we will use 4700 µF.

2. Establish the voltage drop that the system can tolerate - in this case, it is 0.8V.

3. Establish the current that will be drawn - in this case, it is 40 mA.

The following formula can then be used to find the pulse duration that the capacitor can provide:

= × = × == mA VµF I VC I Q T 40 8.04700

94 ms

It can be seen from the above that capacitors of a realistic capacity can only provide for very short periods of high current consumption.

Cost

The table below provides a comparison of CR2032 coin cells from a number of manufacturers:

Manufacturer	Cell Capacity (mAh)
EEMB	210
GP Batteries	210
HB	210
Maxell	220
Panasonic	225
Renata	235
Sanyo	220
Varta	230
Energizer	240
FDK	220

As can be seen in the above table, there is some variation in the coin cell capacities from different manufacturers. When looking for a low-cost cell for a device, always check the specifications of the candidates, since the performance of a given cell type across manufacturers can vary greatly.

Size

If using the smallest possible coin cell is not a high priority, consider using a higher capacity cell that eliminates many of the problems associated with low-capacity parts.

For example, the CR2450 cell from Sanyo is only s lightly bigger but holds almost 3 times the capacity of the CR2032 cell, and has a much higher maximum pulse and continuous discharge rate. Since the CR2450 cell would provide a much longer run-time than the CR2032 used in the earlier examples, this would lead to lower maintenance costs of the end-product, since the battery would need replacing less often. The lower operating cost may well offset the increased cost of the larger cell.

Network Operation

Since the energy budget is very low when using such small capacity cells, every attempt must be made to keep the device in a sleeping state (consuming very little current) for as much time as possible. Coin cells are not suitable for networks that require devices to be awake and listening for unsolicited messages, since this requires the devices to be powered up with the radio switched on in receive mode. Suitable operati onal scenarios for coin cells are given below.

Data Flow from the Co-ordinator to End Devices

When the flow of data is from the Co-ordinator to End Devices, the End Devices must wake periodically to receive updates from the Co-ordinator. Since it is desirable for the End Device to be awake for the shortest possible time, the most appropriate configuration would be a beacon- enabled star network.

In a beacon-enabled star network, it is possible to synchronise End Devices with the beacons and sleep in-between the beacons. After synchronisation with the beacon, the End Device goes into sleep mode, waking up just in time to receive the next beacon and any pending messages. It then processes any data and returns as quickly as possible to the sleep state.

Care must be taken when deciding on the beacon period, since the initial beacon synchronisation phase at start-up requires the radio to be powered continuously until two consecutive beacons have been received. For long beacon periods, this may prove to be a current demand that the battery cannot supply.

Data Flow from End Devices to the Co-ordinator

When the flow of data is from the End Devices to the Co-ordinator, the End Devices can remain in a sleeping state until an event dictates that they must send data. Since the Co-ordinator in this scenario is always powered, it can remain in receive mode and listen for messages from End Devices.

Hardware Considerations

Correct choice of hardware can reduce the current consumption, as can be seen below.

External 32-kHz Crystal Oscillator

For systems that synchronise to a regular beacon, using a more accurate 32-kHz oscillator instead of the low-accuracy internal 32-kHz RC oscillator allows the End Device in a beacon- enabled network to wake up closer to the beacon to which it is synchronised. This, in turn, reduces the amount of time the End Device is awake in receive mode and results in energy savings. However, it is necessary to offset these energy savings against the extra energy used by an external oscillator.

Low Leakage Capacitors

When trying to minimise wasted energy in a system, care should be taken when choosing the capacitors used. For example, an NEC/Tokin 220µF 4V Tantalum capacitor has a leakage current of up to 8.8 µA. If this capacitor were to be connected across the power supply, it could be continuously wasting more energy than is required to power a JN513x-based system in sleep mode.

Software Considerations

The energy used by a device can be affected greatly by the design of the software controlling it. Some issues to consider are detailed below.

Calibrating the 32-kHz RC Oscillator

If the internal 32-kHz RC oscillator is being used to clock the wake timers in a beacon-enabled network, performing a calibration against the 16-MHz crystal will allow the inaccuracies in the RC oscillator to be compensated for.

Improving the timing accuracy with which the device can wake up, ready to receive a beacon, allows the device to wake up closer to the beacon transmission time and thus waste less time waiting for the beacon.

Passive Scans

When performing a passive scan, the device may spend a relatively long time in a mode with the receiver on. This uses a lot of energy. If t he system is only likely to be operating on a small subset of the available channels, performing the scan on this restricted set of channels will considerably reduce the amount of energy wasted.

Packet Lengths

Each byte transferred over the radio link consumes energy, either due to the transmitter being on during data transmission or the receiver being on during data reception. Minimising the amount of data transferred will therefore result in less energy being used by the system.

The transmission time is given by:

Data Frame Transmission Period (ms) = (HeaderSize + PayloadSize) x 8 / 250

PayloadSize = 1 to 112 bytes

HeaderSize = 15 to 31 bytes

For beacon-enabled systems, sending beacons with no payload will result in all End Devices spending less time in the receive state, thus saving a considerable amount of wasted energy.

The beacon overhead depends on the number of GTSs used and the number of pending address fields. The beacon payload can take up the remaining bytes and is available for the transmission of application-specific data.

PHYHeaderSize = 6 bytes

MACHeaderSize = 11 or 17 bytes

BeaconOverhead = 3 to 52 bytes

BeaconPayload = 0 to (127 – PHYHeaderSize – MACHeaderSize – BeaconOverhead) bytes

Beacon Frame Transmission Period (ms) =

(PHYHeaderSize + MACHeaderSize + BeaconOverhead + BeaconPayload ) x 8 / 250

Compatibility

The software provided with this Application Note has been tested with the following Jennic kits and SDK versions:

Product Types	Part Numbers	Version	Supported Networking Protocols
Evaluation Kit	JN5139-EK000 JN5139-EK010	-	IEEE 802.15.4
SDK Libraries	JN-SW-4030	V1.0.0	-
SDK Toolchain	JN-SW-4031	V1.0.0	-

Building and Downloading the Application

In order to build the software provided with this Application Note, the application’s folder must be placed directly under C:\Jennic\cygwin\jennic\SDK\Application\ . This directory is automatically created when you install the latest Jennic Software Developer’s Kit (SDK). You can obtain the latest versions of the SDK libraries and SDK toolchain from the Support area of the Jennic web site (www.jennic.com/support). The relevant part codes are JN-SW-4030 for the SDK libraries and JN-SW-4031 for the SDK toolchain.

Build the application as described in the appropriate section below, depending on whether you wish to use the Code::Blocks IDE or makefiles.

Using Code::Blocks

To build and download the application, follow the instructions below:

1. Ensure that the project directory is located in <JENNIC_SDK_ROOT>\cygwin\jennic\SDK\Application where <JENNIC_SDK_ROOT> is the path into which the Jennic SDK was installed (by default, this is C:\Jennic ).

2. Open the appropriate Code::Blocks project files ( .cbp files in the CodeBlocksProject directory) and build.

The binary files will be created in the 5139R1_Build or 5139_Build directory, the resulting filenames matching those of the project file used to create them.

3. Download the resulting binary files from the appropriate Build directory to the boards. You can do this using the Jennic JN51xx Flash Programmer application or directly from Code::Blocks (if you have installed the integrated Flash programmer).

! Caution: If problems occur when using your current Code::Blocks version,

download the latest version along with the latest version of this Application

Note from the Support area of the Jennic web site (www.jennic.com/support).

Using Makefiles

To build and download the application, follow the instructions below:

1. Ensure that the project directory is located in <JENNIC_SDK_ROOT>\cygwin\jennic\SDK\Application where <JENNIC_SDK_ROOT> is the path into which the Jennic SDK was installed (by default, this is C:\Jennic ).

2. In the Build directory, open the supplied makefile (with a text editor) and check the variables at the beginning of the file to ensure that the appropriate chip type is selected.

3. Still in the Build directory, enter make –f makefile at the command prompt to build the application.

The binary files will be created in the Build directory, the resulting filenames indicating the chip type ( 5139R1 or 5139 ) for which they were built.

4. Download the resulting binary files from the Build directory to the boards using the Jennic JN51xx Flash Programmer application.

Application Description

The application provides a simple non-beaconed IEEE 802.15.4 star network, consisting of a Co-ordinator and one or more End Devices. An End Device takes a temperature reading using its on-board sensor and transmits this reading to the Co-ordinator. The End Device then sleeps (with memory held) for a period, then wakes and sends a new reading. The Co-ordinator receives this data and sends it via its UART to a PC running a terminal emulator program. The communication parameters for the UART are: 19200 baud, 8 data bits, no parity, 1 stop bit.

The following traces were obtained by measuring the voltage drop across a 1- Ω resistor in series with the battery – thus, every 1 mA of current drawn results in a drop of 1 mV. In this way, the current drawn and the period during which it is drawn can both be measured.

Figure 1: Current Drawn Over Entire Awake Period without CPU Doze

Figure 2: Current Drawn Over Entire Awake Period with CPU Doze

Figure 3: Radio Initialisation Transmit and Receive after Doze

Figure 1

shows the current drawn over the whole awake period, if the CPU is not put into Doze mode during the time taken for the temperature sensor to complete its conversion. Calling the function vAHI_CpuDoze() can further reduce the current. This reduces the current from 8 mA to 2.4 mA, as can be seen in

Figure 2

. From the SHT1x sensor datasheet , the temperature sensor takes a nominal 55 ms ( ± 15%) to complete its conversion. So after the conversion has started, a timer is also started that will expire after 64 ms, causing an interrupt that will bring the CPU out

of Doze mode. The sensor reading can then be taken, the radio started and the data transmitted.

Examining

Figure 2

and

Figure 3

, it can be seen that there are five different phases of operation, each with a different current drawn:

1. The End Device wakes from sleep (in AppWarmStart() ) and starts the temperature conversion. A timer is set for 64 ms and the CPU is put into Doze mode. This draws 2.4 mA and lasts for 64 ms. Doze mode is used because there is no other processing to be done other than to wait for the temperature conversion to complete.

2. The CPU is brought out of Doze mode by the timer interrupt and the completed temperature reading is taken from the sensor. This draws 8 mA for 1.12 ms. The sensor is read before the radio is switched on to avoid drawing the higher current over an extended period.

3. Radio is enabled and MAC settings are restored (using vAppApiRestoreMacSettings() ), and the temperature result (2 bytes of data plus preamble and header) is transmitted to the controller. This period draws 31.2 mA for 2.64 ms.

4. The radio listens for the returned Ack from the Co-ordinator. This draws 44 mA for 1.72 ms.

5. The End Device then sleeps with memory held and will wake when the wake timer expires. This draws 6 μ A for 300 seconds. The wake period can be changed by editing the value of #define SLEEP_PERIOD_IN_SECS in the source code.

The average current for each period is calculated as:

offon on average tt t II + ×=

For each of the above five periods, this gives:

I

average

(1) = 0.5119 μ A

I

average

(2) = 0.0299 μ A

I

average

(3) = 0.2745 μ A

I

average

(4) = 0.2522 μ A

I

average

(5) = 5.9986 μ A

Adding together all the average currents gives a total average current of 7.0671 μ A .

Assuming we require a battery life of 3 years, the required battery capacity is given by:

mAhr A TI Capacity runtime average 72.185)243653(0671.7

=

×

×

×

=×=

μ

Therefore, to last 3 years, a battery capacity of greater than 186 mAhr is required.

To examine the effects of the sleep period on batte ry life, the above calculations were repeated for various sleep periods with the battery life normalised to 1 year. The only variable that changed was the sleep period, in seconds. The results are displayed graphically in

Figure 4

. It can be seen that as the sleep period is increased from a few seconds to hundreds or thousands of seconds, the required battery capacity reduces quickly.

Battery Capacity and Sleep 0.0 50.0 100.0 150.0 200.0 250.0 300.0 350.0 10 20 30 40 50 6 0 7 0 80 90 110 120 140 180 240 300 500 1000 2000 3000 5000 1 000 0 2 000 0 30 00 0 40 00 0 50 00 0 Sleep Period (S) Battery Capacity mAhr

Figure 4: Effects of Sleep Period on Battery Life, Normalised to 1 Year

Note: The above calculations ignore the current requirements of the networ

discovery and association phase. This will take a current of approxima

40 mA for a few seconds. The time taken depends on the number of

channels scanned and the radio environment at the time. Since this

application sleeps with memory held, the discovery and association phase

will only happen once, so the effects of 40 mA, for say, 4 seconds dur

period of a year or more can be ignored. However, the current puls

performance of the cell must be co

Network Discovery and Association

Network discovery and association can take several seconds to complete and while being performed, there will be about 40 mA of current drawn. As indicated in the Note above, although the effect of this on battery life

coin cell must be considered. During network discovery, the End Device sends a beacon on each channel requested in the scan, and listens for responses from any Co-ordinator on the channel and within range. The scan lasts for the period set by #define ACTIVE_SCAN_DURATION in the file config.h . In

application, this has been set to the minimum possible, so each channel is scanned for 32.72 ms. However, the actual time spent discovering networks will depend on how many networks are active and within range of the End Device. Each active scan will last until ei channels have been scanned or eight networks have

urned PAN IDs is then searched for our PAN ID:

• If our PAN ID is found, an attempt is made to associate with the corresponding netwo If our PAN ID is not found, the active scan is repeated on the previously u

channels - scanning starts on the lowest channel number and works up. From the above, it can be seen that if there are many networks within range and our network has started on a high channel, it could take several scans to find the right network. This time

could be reduced by not using all 16 channels, limiting the network to a subset of channels. Typical times for network discovery and association are given in the table below (actual

can Duration
N	er Channe	d Asso
0	30.72 ms	1.032 s
1	46.08 ms	1.28 s
2	76.8 ms	1.672 s

Working with the figures given previously for a C

this application, the current drawn was 44 mA mJ mAVTPE

118032.1)446.2( =××=×= This is within the maximum pulse capacity of the CR3032 cell.

Note : If in the discovery and association phase, the node fails to find and jo

a suitable network, the application should not continue to repeat endlessly,

as the pulse capacity of the cell will be exhausted. The

Caution : Do not go to sleep with memory held in this application, if a network

has not been joined

T

P

E

×= mSmAVmS mAVmS mAVE )644.26.2()64.22.316.2()72.1446.2(

×

×

+

×

×

+××=

Sleep without Memory Held The application can be modified so that it sleeps without memory held, which would draw a lower current during sleep. However, there are severa

eter the battery life can be extended in this way: The start-up period will be extended while the application is loaded back into RAM. T period will depend on the size of the application and can be estimated, in ms, to be

0.84 × Application Size (in Kbytes). The current drawn will be approximat The device will need to re-associate with the Co-ordinator. The function vAppApiRestoreMacSettings() only works after sleep with memory held. It will be too expensive in terms of current to do the netwo rk discovery and association each time the device wakes. Therefore, when the device first joins a network, it should save its channel number in Flash memory. Upon waking in AppColdStart() , the channel number should b retrieved from Flash memory and, if valid, used in the association request. If not valid

Deep Sleep Putting a device into Deep Sleep mode will reduce the current drawn during sleep even further, and the same considerations apply as for ‘Sleep without memory held’. However, the calculat of battery life is further complicated because the device is not woken at regular, predictable intervals. There is no wake timer running and the device is woken asynchronously, either by resets or changes on selected DIO pins. It is the responsibility of the application designer to determine

capacity. For Deep Sleep and ‘Sleep without memory held’, there will be a ‘tipping point’. This is where the extra time and current spent loading the application and restoring the association will be balanc

Note : All currents and ti

from a JN5139 evaluation kit, with the resistor R9 removed so that the

LED is not illuminated.

Note : The debugging Print statements in

Appendix

The following trace was obtained using the project code with the sensor reads removed to show the shorter initialisation period which can be obtained if, say, the application was returning switch data or reading a faster sensor. The application wakes, restores the MAC settings and sends two bytes of data.

Figure 5: Short Wake and Transmit Current Pulse

Analysing the results:

1. Initialisation: 8 mA for 1 ms, average current 0.0267 μ A

2. Transmit: 31.5 mA for 2.73 ms, average current 0.2866 μ A

3. Receive: 43.1 mA for 1.68 ms, average current 0.2414 μ A

4. Sleep: 6 μ A for 300 s, average current 5.9999 μ A

This gives a total average current of 6.5546 μ A .

Therefore, the required battery capacity for 3 years’ life is 172.25 mAhr .

Revision History

Version	Notes
1.0	Initial release
1.1	Software application added

Important Notice

Jennic reserves the right to make corre ctions, modifications, enhancements, improv ements and other changes to its products and services at any time, and to discontinue any product or service without notice. Cust omers should obtain the latest relevant information before placing orders, and should verify that such in formation is current and complete. All products are sold subje ct to Jennic’s terms and conditions of sale, supp lied at the time of order acknowledgment. Information relating to device application s, and the like, is intended as suggestion only and may be superseded by updates. It is the customer’s responsibility to ensure that t heir application meets their own specifications . Jennic makes no representation and gives no warranty relating to advice, support or customer product design.

Jennic assumes no responsibility or liability for the use of an y of its products, conveys no lic ense or title under any patent, copyright or mask work rights to these products, and makes no representations or warranties that these products are free from patent, copyright or mask work infringement, unless otherwise specified.

Jennic products are not intended for use in life support system s/appliances or any systems where product malfunction can reasonably be expected to result in personal injury, death, se vere property damage or environmental damage. Jennic customers using or selling Jennic products for use in such applications do so at their own risk and agree to fully indemnify Jennic for a ny damages resulting from such use.

All trademarks are the property of their respective owners.

	Corporate Headquarters Furnival Street Sheffield S1 4QT United Kingdom Tel +44 (0)114 281 2655 Fax +44 (0)114 281 2951 E-mail info@jennic.com	Japan Sales Office Osakaya building 4F 1-11-8 Higashigotanda Shinagawa-ku, Tokyo 141-0022, Japan Tel +81 3 5449 7501 Fax +81 3 5449 0741 E-mail info@jp.jennic.com	Taiwan Sales Office 19F-1, 182, Sec.2 Tun Hwa S. Road Taipei 106 Taiwan Tel +886 2 2735 7357 Fax +886 2 2739 5687 E-mail info@tw.jennic.com
	United States Sales Office 1060 First Avenue, Suite 400 King of Prussia PA 19406 USA	Tel +1 619 223 2215 Fax +1 619 223 2081 E-mail info@us.jennic.com Korean Sales Office 601, Bethel B/D, #324-1 Yangjae-dong Seocho-gu Seoul 137-897 Korea	Tel +82 2 552 5325 Fax +82 2 577 9130 E-mail info@kr.jennic.com