Power characterization of a bluetooth-equipped sensor node
- 格式:pdf
- 大小:894.98 KB
- 文档页数:5
Bluetooth ® SDK 2.12.1.0 GA19Q2 Gecko SDK Suite July 19, 2019Silicon Labs is a leading vendor in Bluetooth hardware and software technologies, used in products such as sports and fitness, consumer electronics, beacons, and smart home applications. The core SDK is an advanced Bluetooth 5-compliant stack that provides all of the core functionality along with multiple API to simplify development. The core func-tionality offers both standalone mode allowing a developer to create and run their appli-cation directly on the SoC, or in NCP mode allowing for the use of an external host MCU. Extensions to the SDK include Bluetooth Mesh and Apple ® HomeKit ® for customers seek-ing the additional capabilities.These release notes cover SDK version(s): 2.12.1.0 released on July 19, 2019 2.12.0.0 released on June 7, 2019Compatibility and Use NoticesIf you are new to the Silicon Labs Bluetooth SDK, see Using This Release . Compatible Compilers:IAR Embedded Workbench for ARM (IAR-EWARM) version 8.30.1• Using w ine to build with the IarBuild.exe command line utility or IAR Embedded Workbench GUI on macOS or Linux could result inincorrect files being used due to collisions in wine’s hashing algorithm for generating short file names. • Customers on macOS or Linux are advised not to build with IAR outside of Simplicity Studio. Customers who do should carefullyverify that the correct files are being used. GCC (The GNU Compiler Collection) version 7.2.1, provided with Simplicity Studio.KEY FEATURESAdded support for new parts [B|M]GM210PContents Contents1New Items (3)1.1New Features (3)1.2New APIs (3)2Improvements (4)2.1Changed APIs (4)3Fixed Issues (5)4Known Issues in the Current Release (6)5Deprecated Items (7)6Removed Items (8)7Using This Release (9)7.1Installation and Use (9)7.2Support (9)8Legal (10)8.1Disclaimer (10)8.2Trademark Information (10)New Items 1 New ItemsGecko Platform release notes are now available through Simplicity Studio’s Launcher Perspective, under SDK Documentation > Blue-tooth SDK 2.12.n.n > Release Notes. The Gecko Platform code provides functionality that supports protocol plugins and APIs in the form of drivers and other lower layer features that interact directly with Silicon Labs chips and modules. Gecko Platform components include EMLIB, EMDRV, RAIL Library, NVM3, and mbedTLS.1.1 New FeaturesAdded in release 2.12.0.0Advertising packet chainingWith this feature, the total amount of advertising data in an advertising packet can be up to 1650 bytes in extended advertising.1.2 New APIsFor additional documentation and command descriptions please refer to the Bluetooth Software API Reference Manual.Added in release 2.12.0.0cmd_gatt_server_set_max_mtucmd_le_connection_set_timing_parameterscmd_le_gap_set_conn_timing_parameterscmd_le_gap_set_long_advertising_datacmd_sm_set_minimum_key_sizecmd_system_data_buffer_writecmd_system_data_buffer_clearImprovements 2 Improvements2.1 Changed APIsChanged in release 2.12.0.0cmd_le_gap_bt5_set_adv_dataRemoved the 191 bytes advertising data limitation for extended advertising.cmd_le_gap_set_adv_dataRemoved the 191 bytes advertising data limitation for extended advertising.evt_le_gap_extended_scan_responseAdded new value in packet_type parameter for data incomplete status.evt_le_gap_scan_responseAdded new value in packet_type parameter for data incomplete status.evt_sync_dataAdded new value in data_status parameter for data incomplete status.Fixed Issues 3 Fixed IssuesFixed in release 2.12.1.05942Fix unstable connection issue while the master device has multiple simultaneous connections and is performing scanning. 5943 Fix an issue that the stack may return the link layer procedure response timeout error when closing a Bluetooth connec-tion.6136 After advertising is started the stack will send the first advertisement straight away. Previously it might send it after the first advertisement interval has elapsed.6349 Fix disconnection issue when performing connection update with slave latency and specific interval parameters.6375 Apploader can now write images right up to the NVM start address.6458 Fix missing ADI field in chained advertisement packets.6465 The stack can now handle 255 bytes data in cmd_system_data_buffer_write command.6475 Periodic advertising data can now be set in stack when the periodic advertising has not been started. Previously this command returns an error.6501 The stack now blocks the example LTK in Bluetooth specification if sent by the other device. This security improvement addresses vulnerability CVE-2019-2102.6502 Fix default RF antenna pin selection for EFR32xG21 parts, radio boards and xGM210 modules.6520 If advertising single event at a time, the stack does not check anymore if packet length would exceed advertising interval.Previously packet_too_long error would have been returned.6532 The stack ensures that the GATT database hash value is calculated when it is first read by commandgecko_cmd_gatt_server_read_attribute_value. Previously an incorrect value might be returned in this case. Additionallythe fix also prevents from overwriting the hash value with gecko_cmd_gatt_server_write_attribute_value.6542 A change was introduced in version 2.12.0 which caused compatibility issues with TB Sense mobile app. This change was reversed to fix those issues and it will be reintroduced when board detection gets improved on the TB Sense mobile appside.Fixed in release 2.12.0.03414 In Bluetooth SDK 2.11.4 and 2.11.5, occasionally the stack is unable to receive all GATT write without response or charac-teristic value notification PDUs.4559 Deleting the bonding of a device while the device is still connected causes the stack using outdated bonding data on the connection. This has been fixed so that the connection is also closed after the bonding has been deleted.5940 The application cannot configure the maximum ATT MTU if GATT client is excluded. This has been fixed by adding a new equivalent API in GATT server class.6051 When Bluetooth runs in RTOS, the stack initialization may cause assertions.6135 Advertising could not be restarted if a timeout has been set previously.6189 Increasing security on a connection with previously bonded devices may fail.6279 The stack does not correctly inform the application about ATT MTU size change if the remote device first denies the stack’s ATT MTU exchange request and then initiates another ATT MTU exchange request.Known Issues in the Current Release 4 Known Issues in the Current ReleaseIssues in bold were added since the previous release.1835 With certain events, GCC breakpoints cannot be set. Change optimization level to none in projectsettings4521 Command gecko_cmd_gatt_discover_primary_services_by_uuidNonereturns success in case of incomplete parameters.5390 The sync_data event does not report TX power. NoneDeprecated Items 5 Deprecated ItemsDeprecated in release 2.12.1.0Deprecated item: EFR32BG14 Part SupportReason: The EFR32BG14 is EOL.End-of-Service (EoS) Date: June 30, 2020. As of this EoS date, EFR32BG14 part support will no longer be available in the then current and future GSDK releases, and EFR32BG14 parts will no longer be supported in any GSDK releases.Maintenance Period: From now until the EoS date, only critical bug fixes and security patches may be made available on currently supported GSDK releases.Replacement: EFR32BG13.Deprecated in release 2.12.0.0As of June 2019 Simplicity Studio 3.0 is being deprecated. All access will be removed from Silicon Labs' website at the end of 2019. Deprecated APIscmd_le_gap_set_conn_parametersThe replacement is cmd_le_gap_set_conn_timing_parameters.cmd_le_connection_set_parametersThe replacement is cmd_le_connection_set_timing_parameters.Removed Items 6 Removed ItemsNoneUsing This Release 7 Using This ReleaseThis release contains the following•Silicon Labs Bluetooth stack library•Bluetooth sample applicationsFor more information about the Bluetooth SDK see QSG139: Getting Started with Bluetooth® Software Development. If you are new to Bluetooth see UG103.14: Bluetooth LE Fundamentals.7.1 Installation and UseA registered account at Silicon Labs is required in order to download the Silicon Labs Bluetooth SDK. You can register at https:///apex/SL_CommunitiesSelfReg?form=short.Stack installation instruction are covered in QSG139: Getting Started with Bluetooth® Software Development.Use the Bluetooth SDK with the Silicon Labs Simplicity Studio V4 development platform. Simplicity Studio ensures that most software and tool compatibilities are managed correctly. Install software and board firmware updates promptly when you are notified. Documentation specific to the SDK version is installed with the SDK. Additional information can often be found in the knowledge base articles (KBAs). API references and other information about this and earlier releases is available on https:///.7.2 SupportDevelopment Kit customers are eligible for training and technical support. You can use the Silicon Labs Bluetooth LE web page to obtain information about all Silicon Labs Bluetooth products and services, and to sign up for product support.You can contact Silicon Laboratories support at /support.Legal 8 Legal8.1 DisclaimerSilicon Labs intends to provide customers with the latest, accurate, and in-depth documentation of all peripherals and modules available for system and software implementers using or intending to use the Silicon Labs products. Characterization data, available modules and peripherals, memory sizes and memory addresses refer to each specific device, and "Typical" parameters provided can and do vary in different applications.Application examples described herein are for illustrative purposes only.Silicon Labs reserves the right to make changes without further notice and limitation to product information, specifications, and descrip-tions herein, and does not give warranties as to the accuracy or completeness of the included information. Silicon Labs shall have no liability for the consequences of use of the information supplied herein. This document does not imply or express copyright licenses granted hereunder to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any Life Support System. A "Life Support System" is any product or system intended to support or sustain life and/or health, which, if it fails, can be reasonably expected to result in significant personal injury or death. Silicon Labs products are not designed or authorized for military applications. Silicon Labs products shall under no circumstances be used in weapons of mass destruction including (but not limited to) nuclear, biological or chemical weapons, or missiles capable of delivering such weapons.8.2 Trademark InformationSilicon Laboratories Inc.® , Silicon Laboratories®, Silicon Labs®, SiLabs® and the Silicon Labs logo®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Energy Micro logo and combinations thereof, "the world’s most energy friendly microcontrollers", Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, ISOmodem®, Micrium, Preci-sion32®, ProSLIC®, Simplicity Studio®, SiPHY®, Telegesis, the Telegesis Logo®, USBXpress®, Zentri, Z-Wave and others are trade-marks or registered trademarks of Silicon Labs.ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks of ARM Holdings.Keil is a registered trademark of ARM Limited.Apple and HomeKit are registered trademarks of Apple Inc. All other products or brand names mentioned herein are trademarks of their respective holders.。
混频器的设计与仿真设计题目:混频器的设计与仿真学生姓名: ____________________________学院: _______________________________专业: _______________________________指导老师: ____________________________学号: _______________________________ 期:2011年12月20 日•、射频电路与ADS既述 (3)1、............................................................... 射频电路概述32、................................................................... ADS既述3 1、混频器的设计. (7)1. 混频器的基本原理 (7)2、混频器的技术指标 (9)三、混频器的设计 (9)1、3 D B定向耦合器的设计.................................................. .9...…1.1、建立工程............................................................ 9.......1.2、搭建电路原理图 (10)1.3、设置微带线参数 (11)1.4、耦合器的S参数仿真 (12)2、............................................................. 完整混频器电路设计173、低通滤波器的设计 ................................................................... 2.错误!未定义书签四、混频器性能仿真 (23)1、....................................................... 混频器功能仿真231.1、仿真原理图的建立 (23)1.2功能仿真 (25)2、....................................................... 本振功率的选择273、混频器的三阶交调点分析 (28)3.1、三阶交调点的测量 (28)3.2、三阶交调点与本振功率的关系 (31)4、混频器的输入驻波比仿真 (31)五、设计总结 (33)一、射频电路与ADS既述1、射频电路概述射频是指超高频率的无线电波,对于工作频率较高的电路,人们经常称为“高频电路”或“射频(RF电路”或“微波电路”等等。
Configuring the Bluetooth Interface with MS Windows XP Background: The Bluetooth Interface is typically easy to configure, as is the FTP-628 Driver. The mechanics are simple: the FTP-628 Serial Driver is assigned to a virtual Serial (COM) Port, and the Bluetooth driver links to the same virtual Serial (COM) Port.This example was developed using a Fujitsu Lifebook Notebook PC with built-in Toshiba Bluetooth hardware support.Bluetooth Interface Configuration:1.Make sure the FTP-628 printer battery has been fully charged; if your printer has never beenused, allow 3 hours for the initial charge.2.Turn on the printer (hold down the Power button until the Green LED starts blinking, then re-lease); place the printer in close proximity to the Bluetooth PC; it is best to ensure there are noother active Bluetooth devices within range (about 30 feet).3.Start the Bluetooth Manager on the PC and select the ‘Add New Connection’ function. [Image ][Image ]FTP-628WSL-110 Bluetooth® Configuration Guide4.The Add New Connection Wizard will pop up; select Custom Mode and click Next. [Image 2]5. The Wizard will search for any Bluetooth device within range, and should display the[Image 2][Image 3][Image 4]highlighted FTP-628WSL100 icon after a few moments; [Image 3] click Next. [Image 4][Image 5][Image 6][Image 7][Image 9]7.Once the Pin is successfully entered, the Bluetooth Manager will display ‘Serial Device’; [Image 5] click Next. [Image 6]8.Now the Bluetooth Manager will display the COM Port selection dialog; De-Select the “usedefault COM port” box, and change the COM port to COM5; [Images 7, 9, 10] ignore thewarning regarding default COM port recommendation, [Image 8] and DO NOT de-select the Auto Connect box; click Next. [Image 11][Image 10][Image 8][Image ][Image 12][Image 13][Image 4][Image 5]9.Now you can select a different icon for the printer if you wish, then click Next and Finish; your Bluetooth Manager should show the FTP-628WSL-110 as an active device. [Images 12 to 15]10. Bluetooth configuration is now finished; proceed to FTP-628WSL-110 Serial Driver Installation.[Images 16 and 17][Image 16][Image 7]Serial Driver Installation:1.Download the latest driver Zip file from the website at: [Images 18 to 22] /us/services/edevices/components/printers/drivers.html[Image 9][Image 18][Image 21][Image 20]2. Extract all of the files to a folder on your desktop. [Images 23 to 25][Image 23][Image 24][Image 25]3. From the Start menu select Printers and Faxes, and double-click on the Add Printericon. [Images 26][Image 26]4. The Add Printer wizard will pop up on the display; click Next; select ‘Local Printer’ andDE-SELECT ‘Automatically detect and install my Plug and Play printer’; click Next. [Images 27 and 28][Image 27][Image 28]5. Select ‘Use the following port’, then use the pull-down menu to select COM5; click Next.[Images 29 and 30][Image 29][Image 30]6. Select FCL, click ‘Have Disk’; when the ‘Install from Disk’ dialog box pops up, Browse to yourDesktop and select the FTP-628WSL and open it; you should see ‘FTP’ in the next dialog box;select ‘FTP’ and click Next. [Images 31 and 32][Image 31][Image 32]7. Assign a name for the printer, or use the default provided, click No for default printer and clickNext. [Image 33]8. Click ‘Do not Share this printer’ and clickNext. [Image 34][Image 33]9. Click Yes or No for the Test Page printing as desired; click Next. [Image 35][Image 35]10. The Successful Installation page should appear next; click Finish; a warning box will pop upregarding Unsigned Drivers, click ‘Continue Anyway’, and wait while the driver is installed.Once the ‘Copying Files’ dialog box closes, you are ready to use the printer. [Images 36 to 38] [Image 36][Image 37][Image 37]1211.Go to the Start Menu and select Printers and Faxes; when this window opens makes sure yousee FTP-628WSL in the list of printers. [Image 39]12. Remember to select and observe the proper settings for the paper size and length (1.9-inch wide 1/2 letter) in the Printer Setup. You can access the settings from the Printers and Faxes window by right-clicking on the FTP-628WSL printer name, and selecting Properties.To change printer behavior, select the General tab, click on Printing Preferences, then click on Advanced; the variable printing controls will be displayed and may be changed.[Image 40 to 42][Image 39][Image 40][Image 4 ][Image 42]13. To test the printer you can either create your own text file, or download and use any ofthe test files provided on the web site. If you use the Windows Test Page, the Windows logographic icon should print correctly, but some of the text will be truncated due to the defaultmargin settings – this is normal operation.To download the Test Print files go to:Graphic Demo:/downloads/MICRO/fcai/printers/drivers/ftp-628wsl110-graphic-demo.zipReceipt Demo:/downloads/MICRO/fcai/printers/drivers/ftp-628wsl110-receipt-demo.zipGraphic and Text Demo:/downloads/MICRO/fcai/printers/drivers/ftp-628wsl110-graphic-text-demo.zipJapanFujitsu Component LimitedGotanda-Chuo Building3-5, Higashigotanda 2-chome, Shinagawa-kuTokyo 141, JapanTel: (81-3) 5449-7010Fax: (81-3) 5449-2626Email:**************Web: North and South AmericaFujitsu Components America, Inc.250 E. Caribbean DriveSunnyvale, CA 94089 U.S.A.Tel: (1-408) 745-4900Fax: (1-408) 745-4970Email:*********************.comWeb: /us/services/edevices/components/EuropeFujitsu Components Europe B.V.Diamantlaan 252132 WV HoofddorpNetherlandsTel: (31-23) 5560910Fax: (31-23) 5560950Email:*****************.comWeb: /emea/services/components/ Asia PacificFujitsu Components Asia Ltd.102E Pasir Panjang Road#04-01 Citilink Warehouse ComplexSingapore 118529Tel: (65) 6375-8560Fax: (65) 6273-3021Email:*****************.comWeb: /sg/services/micro/components/Fujitsu Components International Headquarter Offices©2006 Fujitsu Components America, Inc. All rights reserved. All trademarks or registered trademarks are the property off their respectiveowners.Fujitsu Components America does not warrant that the content of datasheet is error free. In a continuing effort to improve our products Fujitsu Components America, Inc. reserves the right to change specifications/datasheets without prior notice. Rev. 04/07/2006.13。
Bluetooth Low EnergyProduct Brief v2.0OverviewBluetooth version 4.0 introduced Bluetooth with low energy functionality. Bluetooth low energy technology allows for short bursts of long-range radio connections, making it ideal for applications that depend on long battery life and don’t need high throughput streaming data. Developers are now able to create sensors that can run on coin-cell batteries for months and even years. Bluetooth low energy technology is built on an entirely new development framework using GATT (Generic Attributes). Silicon Labs supports the latest version of the Bluetooth ® Core Specification, Bluetooth™ LE 5.4. This enables customers to claim compliance with the latest Bluetooth spec.Bluetooth Low Energy ArchitectureThe Bluetooth Low Energy architecture components are as follows: Physical Layer: Controls radio transmission/receiving.Link Layer: Defines packet structure, includes the state machine and radio control, and provides link layer-level encryption.HCI: A Host-to-Controller interface (HCI) standardizes communication between the controller and the host.L2CAP: Logical Link Control and Adaptation Protocol acts as a protocol multiplexer and handles segmentation and reassembly of packets. ATT: Attribute protocol provides means to transmit data between Bluetooth low energy devices.SM: Security Manager provides means for bonding devices, encrypting and decrypting data, and enabling device privacyGAP: Generic Access Profile layer provides means for Bluetooth low energy devices to advertise themselves or other devices, make device discovery, open and manage connections, and broadcast data.GATT: GATT is used to group individual attributes into logical services GATT also provides information about the attributes, that is, how they can be accessed and what security level is needed.Key Features of Silicon Labs Bluetooth Low Energy StackFeature BenefitCore FeaturesDirection finding, Periodic Advertising with Responses (PAwR), Encrypted Advertising Data (EAD),Advertisement Extensions, Periodic Advertising, LE secure connections, 2M PHY , Long Range, AFH, LE Privacy 1.2 (peripheral), LE packet length extensions, Accept List (central side), GATT, & GATT Caching Scalable AoA Scale to AoA to few hundred devices simultaneouslyCertificate Based Authentication and Pairing (CBAP) Use certificates to authenticate devices before provisioning, thus saving cost and time. Also, prevents counterfeit devices from being provisioned into the networkSilicon Labs Bluetooth stack supports three modes:Standalone mode: Bluetooth stack and the application run in an EFR32SoC or moduleNetwork Co-Processor mode: Bluetooth stack runs on the EFR32, and the application runs on a separate host MCU. API is exposed over a serial interface such as UART.Radio Co-Processor mode: Link layer of the Bluetooth stack runs on the EFR32, and the Host Layer of the stack, as well as the application runs on a separate host MCU or PC. Link Layer and Host Layer communicate via HCI.Technical ResourcesBluetooth Low Energy xG24 Technical Library Data Sheets, App Notes, and moreBluetooth Low Energy xG21 Technical Library Data Sheets, App Notes, and moreBluetooth Low Energy xG22 Technical Library Data Sheets, App Notes, and moreBluetooth Low Energy xG27 Data ShortBluetooth Low Energy API Documentation Bluetooth Low Energy API documentationSilicon Labs’ Bluetooth Low Energy HW supportHigh Performance device for Bluetooth LE and Bluetooth mesh applications thatrequire advance features and more Flash and RAMIndustry-leading, energyefficient device for Bluetooth LE applicationsOptimized for line-powered devices including LED bulbs, and gateways for Bluetooth LE and Bluetooth meshMost Battery Versatile SoC for Connected Health, Smart Home, Portable Products1536kB Flash 256kB RAM TX power 19.5dBm -105.7dBm @ 125kbps -97.6dBm @ 1Mbit/s -94.8dBm @ 2Mbit/s RX current 4.4mA @ 1MbpsTX current 5.0mA @ 0dBm1.3 µA Sleep current (16kB )Robust peripheral set AI/ML hardware accelerator Secure Vault High QFN40 5x5 (26) QFN48 6x6 (32)512kB Flash 32kB RAM TX power 6dBm -106.7dBm @ 125kbps -98.9dBm @ 1Mbit/s -96.2dBm @ 2Mbit/s RX current 3.6mA @ 1MbpsTX current 4.1mA @ 0dBm1.26µA Sleep current (16kB )Lowest Power Bluetooth LESecure Vault Mid QFN40 5x5 (26) QFN32 4x4 (18) TQFN32 4x4 (18)1024kB Flash 96kB RAM TX power 20dBm -104.9dBm @ 125kbps -97.5dBm @ 1Mbit/s -94.4dBm @ 2Mbit/s RX current 8.8mA @ 1MbpsTX current 9.3mA @ 0dBm+135 Junc. Temperature Secure Vault High Line-Powered Bluetooth LE QFN32 4x4 (20)768kB Flash 64kB RAM TX power 8dBm -106.9dBm @ 125kbps -99.2dBm @ 1Mbit/s -96.3dBm @ 2Mbit/s RX current 3.6mA @ 1Mbps TX current 4.1mA @ 0dBm 1.26µA Sleep current (16kB ) Secure Vault Mid QFN40 5x5 (26) QFN32 4x4 (18) TQFN32 4x4 (18)Bluetooth LE Target Applications• ESL • Medical• Direction Finding • Smart Home • Smart Tags • Sensors • Switches• Building Automation • HVACBluetooth LE Software / ToolsSilicon Labs Bluetooth Low Energy SDK helps you build smooth, reliable, and secure wireless connectivity for your IoT applications. Software and Tools features • Supports Bluetooth™ LE 5.4 • Wi-Fi Coexistence • Simplicity Studio IDE • GATT Configurator • Network Analyzer • Direction Finding Tool Suite • Bluetooth NCP Commander • Proprietary Radio Configurator • Energy Profiler • Tool Chain – GCC and IARLinks: Bluetooth Low Energy SDKLearning CenterReady for Bluetooth 5.4?Learn more about the latest specification Bluetooth Direction FindingBluetooth Location Services: AoA/AoD Why EFR?Silicon Labs EFR32 FeaturesSilicon Labs Secure Vault accreditations Product security certificationsBluetooth SoC and Module Selector Guide Bluetooth Low Energy Selector Guide Case Study: Rethinking Epilepsy Management EFR32 Portable Medical DeviceBluetooth BeaconsBluetooth Beacons and AdvertisingSilicon Labs’ Bluetooth LE Development KitsSilicon Labs’ Bluetooth development kits are divided into three categories based on your development need:• Rapid Prototyping • Proof of Concept• Advanced RF DevelopmentFor more information on the portfolio, check the link: https:///bluetooth-kitsBG22 BG21 BG24 BG27Disclaimer: Silicon Labs intends to provide customers with the latest, accurate, and in-depth documentation of all peripherals and modules available forsystem and software implementers using or intending to use the Silicon Labs products. Characterization data, available modules and peripherals, memory sizes and memory addresses refer to each specific device, and “Ty pical ” parameters provided can and do vary in different applications. Application examples described herein are for illustrative purposes only. Silicon Labs reserves the right to make changes without further notice to the product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the included information. Without prior notification, Silicon Labs may update product firmware during the manufacturing process for security or reliability reasons. Such changes will not alter the specifications or the performance of the product. Silicon Labs shall have no liability for the consequences of use of the information supplied in this document. This document does not imply or expressly grant any license to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any FDA Class III devices, applications for which FDA premarket approval is required or Life Support Systems without the specific written consent of Silicon Labs. A “L ife Support System ” is any product or system intended to support or sustain life and/or health, which, if it fails, can be reasonably expected to result in significant personal injury or death. Silicon Labs products are not designed or authorized for military applications. Silicon Labs products shall under no circumstances be used in weapons of mass destruction including (but not limited to) nuclear, biological or chemical weapons, or missiles capable of delivering such weapons. Silicon Labs disclaims all express and implied warranties and shall not be responsible or liable for any injuries or damages related to use of a Silicon Labs product in such unauthorized applications. Note: This content may contain offensive terminology that is now obsolete. Silicon Labs is replacing these terms with inclusive language wherever possible. For more information, visit /about-us/inclusive-lexicon-projectTrademark InformationSilicon Laboratories Inc.®, Silicon Laboratories ®, Silicon Labs ®, SiLabs ® and the Silicon Labs logo ®, Bluegiga ®, Bluegiga Logo ®, EFM ®, EFM32®, EFR, Ember ®, Energy Micro, Energy Micro logo and combinations thereof, “the world ’s most energy friendly microcontroller s”, Redpine Signals ®, WiSeConnect , n-Link, ThreadArch ®, EZLink ®, EZRadio ®, EZRadioPRO ®, Gecko ®, Gecko OS, Gecko OS Studio, Precision32®, Simplicity Studio ®, Telegesis, the Telegesis Logo ®,USBXpress ®, Zentri, the Zentri logo and Zentri DMS, Z-Wave ®, and others are trademarks or registered trademarks of Silicon Labs. ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks of ARM Holdings. Keil is a registered trademark of ARM Limited. Wi-Fi is a registered trademark of the Wi-Fi Alliance. All other products or brand names mentioned herein are trademarks of their respective holders.Silicon Laboratories Inc. 400 West Cesar Chavez Austin, TX 78701IoT PortfolioQualitySupport & Community/products/quality/community。
26080111240012608011024001Bluetooth® Smart Module∙Embedded 2.4 GHz Bluetooth 4.2 module∙ 1.7 to 3.6 V operation∙Up to +2 dBm output power∙-96 dBm sensitivity∙UART∙Event driven API∙Automated power management system withautomatic power management of each peripheral∙AES HW encryption∙Compact dimensions: 11 x 8 x 1.8 mm∙Antenna options: integrated or RF padThe AMB2621 is an ultra-low power 2.4 GHz wireless module integrating the nRF52832 System on Chip including a 2.4 GHz transceiver and an ARM Cortex TM-M4F CPU with flash memory. The module is optimized for applications where costs and low-power optimization really matter. Several pins with alternate functions are available to e.g. connect LEDs, or realize an SPI, I2C, ADC or handshake for the UART as well as NFC.By default the AMB2621 contains the AMBER firmware according to option 1. Upon request the customer’s own firmware (option 2) may be flashed during production.Option 1: AMBER firmwareBy default, the module provides the industry proven, fully qualified Bluetooth® Smart (previously called Bluetooth low energy) stack from Nordic, plus the AMBER firmware. The latter contains an SPP-like profile, which offers a fast secured data transmission of packets with up to 128 bytes payload. Furthermore the AMB2621 includes an easy-to-use command interface allowing a convenient configuration and operation. The module can perform both, an advertising mode in order to be found, or a scan for finding other devices, which are advertising. Data transmission can be executed as soon as a (secured) connection has been set up. In addition data can be broadcasted quickly using so called Beacons. The module enables distance estimation (localization) using RSSI and output power in just one advertise packet for optimized power consumption.As a second option the module can be switched into peripheral only mode with transparent UART and static passkey pairing.As interface to the host system a 2-wire UART interface is provided with a default data rate of 115200 Baud. OTA firmware update via PC or Android / iOS App is supported. An Android App supporting the SPP-like operation is also available on request.Option 2: Custom developmentBased on the free Nordic Semiconductor SDK and demo examples various BLE-profiles and custom applications can be realized and flashed on the AMB2621 module. The versatile and well documented Nordic stack ensures quick and easy realization of various standard BLE-profiles, such as:∙HID services∙Medical services (BLS, HRS, HTP…)∙Alert services (ANS, IAS, PASS …)∙In formation services (CTS, DIS, TPS …)∙and othersFor full feature list see the nRF52832 documentation .SpecificationsTA = 25°C, VCC = 3 V if nothing else stated. Performance RF data rate 1 Mbit/sInterface data rate Typ. 115200 BaudOutput power Up to +2 dBm @ 50 OhmRF sensitivity Typ. -96 dBm @ 50 OhmRange AMB2621: 50m, AMB2621-1: 125mGeneral Power supply 1.7 - 3.6 VPower consumption TX: typ. 5.3 mA @ 0dB, 7.5 mA@ 4dBm / RX: 5.4 mA *Low Power: typ. 0.4 µA (System OFF mode)Dimensions 8 x 11 x 1.8 mmOperating temperature -40 to +85 °CWeight Approx. 3 gAntenna Integrated antenna or RF padRF Technology Bluetooth® Smart 4.2Frequency range 2.402 GHz to 2.48 GHzModulation DSSSCompliance Europe EN 60950, EN 301 489, EN 62311, EN 300 328US FCCBluetooth SIG SIG listing is mandatory* DC/DC converter in use, transceiver only. Complete currents with CPU active: TX 8mA @ 0 dBm, TX 11mA @ 4 dBm, RX 8mA Dimensions and Pin AssignmentNo. Pad Name No. Pad Name1 RF 1 9 P0.09/NFC1 22, 17 GND 10 P0.00/XL1 23 SWDCLK 11 P0.01/XL2 24 SWDIO 12 P0.02/AIN0 25 P0.21/Reset 13 P0.03/AIN1 26 P0.05/AIN3 214 P0.04/AIN2 27 VDD 15 P0.28/AIN4 28 P0.10/NFC2 216 P0.29/AIN5 212 can be used with customer specific firmware. Refer to AMB2621 manual for function in standard (SPP-like)firmwareOrdering InformationItem No. DescriptionAMB2621 Bluetooth Smart Module w/ integrated antennaAMB2621-1 Bluetooth Smart Module w/ RF padAMB2621-EV Bluetooth Smart Evaluation Board (Module AMB2621) Phone +49.651.993.550**************************** Internet 26080111240012608011024001。
AN1346: Running the BLE Interoperability (IOP) Test Application NoteInteroperability (IOP) is one of the key value propositions of Blue-tooth Low Energy and something that consumers have come to expect from Bluetooth enabled end products.This document describes Silicon Labs IOP test framework comprising of hardware kits, embedded software, and mobile app. It also explains the requirements for building the IOP test setup, running the test, and collecting data for further analysis.Note: This application note is valid for GSDK 3.2.x where interoperability is only availa-ble as a pre-compiled demo. For GSDK 4.0 and onward please refer to the readme file which is presented when opening the interoperability sample application.KEY FEATURES•Software and Hardware requirements to run the IOP test•Bringing up the test environment and running the test•Collecting test data from EFR32 and mobile phoneTable of Contents1. Introduction (3)1.1 Hardware Requirements (3)1.2 Software Requirements (3)1.3 Mobile App Requirements (3)1.3.1 Minimum Mobile Operating System Versions (3)2. Bringing up the Test Environment (4)3. Running the IOP Test (6)4. Logging and Sharing Data (8)4.1 Collecting Additional Data from the Embedded Device (10)5. Revision History (12)Introduction 1. IntroductionIOP is a cornerstone of Bluetooth and one of the key reasons why this wireless technology has become ubiquitous. It enables end users to mix and match devices between different vendors without fearing connectivity issues. For example, whether a heart rate moni-tor from a company A will connect to a smart watch from a company B to retrieve and display the heart rate information.It is therefore essential that when a customer is looking for a Bluetooth solution supplier for his design, the supplier can provide means to test IOP between his Bluetooth solution and 3rd party devices.One of the most common use cases for Bluetooth enabled devices is interaction with smartphones where a mobile app is used for com-mand and control of the Bluetooth device. This use case places IOP in the spotlight because of the large number of permutations be-tween smartphone hardware (namely Bluetooth chipset), low level firmware (typically BLE link layer), mobile OS (typically BLE host stack), and mobile OS version.Silicon Labs provides a framework to test IOP between the EFR32 family of SoCs and a large number of smartphones currently on the market. This framework is used to run IOP testing against a large list of devices periodically. AN1309 contains both IOP test results and the IOP test plan.Subsequent sections list the requirements for the IOP test framework. Subsequent chapters describe how to bring up the test environ-ment, run the IOP test, and collect data for further analysis.1.1 Hardware RequirementsThe IOP embedded software is available for the following radio boards:•BRD4104A (based on the xG13 SoC)•BRD4181A (based on xG21 SoC) – currently in obsolete state and may no longer be available for purchase. However, if you have already purchased this board, it can be used for IOP testing•BRD4181B (based on xG21 SoC – a new version of BRD4181A with a corrected pinout, more details in the PCN.•BRD4182A (based on the xG22 SoC)You can purchase the following boards stand-alone or as a part of a starter kit.•BRD4104A can be purchased stand-alone with OPN SLWRB4104A or as part of SLWSTK6020B starter kit•BRD4181B can be purchased stand-alone with OPN SLWRB4181B or as part of SLWSTK6006A starter kit•BRD4182A can be purchased stand-alone with OPN SLWRB4182A or as part of SLWSTK6021A starter kit1.2 Software RequirementsThe IOP embedded software is available in the Silicon Labs GSDK starting with version 3.2.0 and later. Users should install Simplicity Studio 5 and Bluetooth SDK 3.2.0 or newer, which is part of GSDK 3.2.0. For more information about installing Simplicity Studio 5, see QSG169: Bluetooth® SDK v3.x Quick-Start Guide.1.3 Mobile App RequirementsTo enable IOP testing framework on mobile, install EFR Connect mobile app, version 2.3 or newer. The app is available for both An-droid and iOS and the source is available on GitHub.1.3.1 Minimum Mobile Operating System VersionsThe minimum OS versions supported by EFR Connect mobile app are Android™ 9 and iOS®12.2. Bringing up the Test EnvironmentThe IOP test consists of a sequence of BLE operations executed between a mobile device and an EFR32 SoC running the interopera-bility test embedded software.To flash the embedded software into one of the supported kits, plug the kit into the PC and open Simplicity Studio 5. In the Simplicity Studio launcher, select the “Example Projects & Demos” tab then filter by “Bluetooth” technology type and disable the “Example Projects” toggle switch. This will narrow down the results to a few ready-to-flash demos, which include the IOP test, as shown belowFigure 2.1. IOP Test Demo in Simplicity Studio 5The embedded software can be flashed to the kit by clicking the “Run” button. After the flashing is complete, you should see the follow-ing information on the kit display, as shown below.Figure 2.2. BRD4182A Running the IOP Embedded SoftwareFor mobile, open EFR Connect mobile app which will automatically open in Develop view. Tap on the Interoperability Test Tile, which brings up the initial information pop-up with a summary of the feature and a link to this document. It is also pre-populated with the de-fault device name. After tapping OK, it will switch to the IOP screen where the you can tap on “Run Tests” option to get started.Figure 2.3. Launching the IOP Test on EFR Connect Mobile App3. Running the IOP TestAfter the IOP test sequence starts running, the mobile app will scroll through the test cases and indicate Pass/Fail when the test is completed, as shown below.Figure 3.1. Ongoing IOP TestMost tests do not require user intervention, the exception being the security tests. Both perform bonding where the user is prompted several times to bond with the device on the mobile app side. Some of those prompts require simple confirmation, such as Just Works pairing, while other prompts require inputting a pin code for authenticated pairing, which can be read from the kit LCD or from the UART logs.Figure 3.2. Just Works PairingFigure 3.3. Authenticated PairingEnsure that there is no existing bond with the embedded device before initiating the IOP test sequence, which you can check from thephone Bluetooth settings. If the device is already bonded, the bond must be removed before proceeding with IOP testing.4. Logging and Sharing DataAfter the test is finalized on the mobile app, the user is given the option to rerun the test or share the results.Figure 4.1. Run and Share Test OptionsTo rerun the tests, first reset the embedded device through the reset push button on the bottom right side of the kit mainboard. Addition-ally, remove the bond from the phone’s Bluetooth settings.The Share option allows sharing the test log through OS-standard mediums, such as cloud storage (e.g., Dropbox, Google Drive, iCloud, and so on), email, or saving it locally. The log is in xml format and contains information about the phone model, OS version, Bluetooth connection parameters, and the result of each test. Below is an example of a test log from running IOP test on a Pixel 2 with Android 11.Figure 4.2. IOP Test Log Example4.1 Collecting Additional Data from the Embedded DeviceThe IOP embedded software also sends logging data over UART, which can be captured by a terminal emulator on the PC. Further-more, the Packet Trace Interface (PTI) is enabled which means that the radio traffic can be captured using the Network Analyzer.For a more comprehensive data set around an individual IOP test sequence, capture both UART logs and radio traces using Simplicity Studio. Radio trace capture must be initiated before starting the IOP test.To start the radio capture, right click on the debug adapter and select "Connect". Then, right click once again and select "Start Cap-ture".Figure 4.3. Initiate Radio Traffic Capture Using Network AnalyzerThis will automatically bring up the Network Analyzer view where the traffic is logged and every packet can be decoded for further anal-ysis if required. At the end of the IOP test, the trace can be saved through File -> Save as, as shown below.Figure 4.4. Simplicity Studio Network AnalyzerWhile UART logs have multiple COMPort emulators such as tera term, you can also capture within Simplicity Studio’s own terminal. Similarly to the packet trace capture, right click on the debug adapter and select "Launch Console". Then, select "Serial 1" tab and enter any character into the prompt at the bottom of the screen. You should see the connection symbol changing, which indicates that the connection is successful and the logging should start, depending at which phase of the IOP test this is initialized. Otherwise, reset the board to ensure that the log is being received.Logging and Sharing DataFigure 4.5. Simplicity Studio ConsoleRev. 0.2 | 11Revision History 5. Revision HistoryRevision 0.2January, 2022•Added note to front page.Revision 0.1May, 2021•Initial releaseIoT Portfolio /products Quality /quality Support & Community /communitySilicon Laboratories Inc.400 West Cesar Chavez Austin, TX 78701USA DisclaimerSilicon Labs intends to provide customers with the latest, accurate, and in-depth documentation of all peripherals and modules available for system and software imple-menters using or intending to use the Silicon Labs products. Characterization data, available modules and peripherals, memory sizes and memory addresses refer to each specific device, and “Typical” parameters provided can and do vary in different applications. Application examples described herein are for illustrative purposes only. Silicon Labs reserves the right to make changes without further notice to the product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the included information. Without prior notification, Silicon Labs may update product firmware during the manufacturing process for security or reliability reasons. Such changes will not alter the specifications or the performance of the product. Silicon Labs shall have no liability for the consequences of use of the infor -mation supplied in this document. This document does not imply or expressly grant any license to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any FDA Class III devices, applications for which FDA premarket approval is required or Life Support Systems without the specific written consent of Silicon Labs. A “Life Support System” is any product or system intended to support or sustain life and/or health, which, if it fails, can be reasonably expected to result in significant personal injury or death. Silicon Labs products are not designed or authorized for military applications. Silicon Labs products shall under no circumstances be used in weapons of mass destruction including (but not limited to) nuclear, biological or chemical weapons, or missiles capable of delivering such weapons. Silicon Labs disclaims all express and implied warranties and shall not be responsible or liable for any injuries or damages related to use of a Silicon Labs product in such unauthorized applications. Note: This content may contain offensive terminology that is now obsolete. Silicon Labs is replacing these terms with inclusive language wherever possible. For more information, visit /about-us/inclusive-lexicon-projectTrademark InformationSilicon Laboratories Inc.®, Silicon Laboratories ®, Silicon Labs ®, SiLabs ® and the Silicon Labs logo ®, Bluegiga ®, Bluegiga Logo ®, EFM ®, EFM32®, EFR, Ember ®, Energy Micro, Energy Micro logo and combinations thereof, “the world’s most energy friendly microcontrollers”, Redpine Signals ®, WiSeConnect , n-Link, ThreadArch ®, EZLink ®, EZRadio ®, EZRadioPRO ®, Gecko ®, Gecko OS, Gecko OS Studio, Precision32®, Simplicity Studio ®, Telegesis, the Telegesis Logo ®, USBXpress ® , Zentri, the Zentri logo and Zentri DMS, Z-Wave ®, and others are trademarks or registered trademarks of Silicon Labs. ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks of ARM Holdings. Keil is a registered trademark of ARM Limited. Wi-Fi is a registered trademark of the Wi-Fi Alliance. All other products or brand names mentioned herein are trademarks of their respective holders.。
power as a replacement to yourApplication Specific DC Power Supplies tailored solutions for specific needsMore detailed specifications at /find/6630081Mobile Communications DC Sources 40-100 W198182battery, enabling them to emulate the operation of various batterytypes or batteries in different charge states. Plus, these DC sources can simulate negative resistance so that you can compensate for voltage drop due to wiring in a fixture.Feature SummaryAgilent has designed in the capability and flexibility that is required for accurately testing today’s communi-cations devices as well as your next generation designs for cell phones (formats include: 3G, cdma2000,WCDMA, CDMA, TDMA, GSM, PCS,DECT, TETRA, PHS, NADC), PDAs,Bluetooth TM enabled devices, and Wireless LAN access devices.More detailed specifications at /find/66300166332A also has RS-232 interface.2Applies with current detector set to DC.3Time for the output voltage to recover to within 20 mV of final value after 0.1 to 1.5 A load change in high capacitance compensation range.4Time for the output voltage to recover to within 20 mV or 0.1% of the voltage rating of the unit following a change in load current of up to 50% of the output current rating.DC Floating VoltageOutput terminals can be floated up to +/- 50 Vdc maximum from chassis ground (+/- 240 Vdc for 66332A)Remote Sensing Voltage DropFor 66332A: Up to 2 V can be dropped in each load lead. Add 2 mV to the load regulation specification for each 1 V drop in the positive output lead. For 66309B/D, 66311B: Up to 4 V can be dropped in each load lead. Add 2 mV to the load regulation specification for each 1 V drop in the positive output lead. For 66319B/D main output, 66321B/D mainoutput: Up to 3 V total can be dropped in both load leads. For 66319B/D auxiliary output, 66321B/D auxiliary output: Up to 4 V total can be dropped in both load leads.Command Processing TimeAverage time required for the output voltage to begin to change following receipt of GPIB data is 4 ms (with display disabled).83All models offer:•Fast output response technology •Programmable output response compensation•Advanced DSP-based dynamic measurements•Current sinking for testing and calibrating charger circuitry •Extensive protection features (including broken sense lead detection)•GPIB Interface, SCPI (Standard Commands for Programmable Instruments), VXI plug&play driversIn addition, the 66319B/D and 66321B/D high performance models offer:•Output resistance programming (positive and negative)•Superior output stability with up to 6 meters of load leads •Excellent transient voltage drop (typically < 30 mV)•Three current measurement ranges •NEW! Additional advanced battery drain measurements (CCDF, long term battery drain)The new and improved 66319B/D and 66321B/D high performance models are recommended for new automated test system platforms and for R&D applications. The 66309B/D and the 66311B are available for those customers who need to replicate existing test platforms and who do not want to re-engineer existing automated test system designs.More detailed specifications at /find/66300(Continued)Output Programming Response Time For 66332A: The rise and fall time (10/90% and 90/10%) of the output voltage is < 2 ms (400 µs in fast mode).The output voltage change settles within 1 LSB (0.025% x full scale voltage) of final value in < 6 ms (2 ms in fast mode).For 66311B, 66321B/D, 66309B/D output 1, 66319B/D output 1: The rise and fall time (10/90% and 90/10%) of the output voltage is < 200 µs.Measurement TimeAverage time to process query, calculate measurement parameter and return data is 50 ms (includes the default time of 30 ms for acquiring data and 20 ms data processing overhead).GPIB Interface CapabilitiesIEEE-488.2, SCPI command set, 6630A series programming capability (not supported in 66309B/D, 66319B/D,66321B/D)Software Driver:•VXI Plug&Play•IntuiLink Connectivity SoftwareInput power(at worst case conditions: full load, 100 Vac mains)For 66311B, 66321B/D: 1.7 A, 125 W.For 66309B/D, 66319B/D: 2 A, 170 W.For 66332A: 3.5 A, 250 W.Regulatory ComplianceComplies with EMC directive 89/336/EEC (ISM 1B). Warranty Period One yearSizeFor 66309B/D, 66311B, 66319B/D,66321B/D: 212.8 mm W x 88.1 mm H x 435 mm D (8.4 in x 3.5 in x 17.13 in).For 66332A: 425.5 mm W x 88.1 mm H x 364.4 mm D (16.8 in x 3.5 in x 14.3 in).WeightFor 66309B/D, 66311B, 66319B/D,66321B/D: 9.07 kg (20 lb) net, 11.1 kg (24.5 lb) shipping. For 66332A: 12.7 kg (28 lb) net, 15.0 kg (33 lb) shipping.Application Notes:Mobile Communications Device Testing (AN 1310)5968-2424ENEvaluating Battery Run-down Performance Using the Agilent 66319D or 66321D with Option #053 14565ADevice Characterization Software (AN 1427)5988-8157ENUsing Battery Drain Analysis to Improve Mobile-Device Operating Time 5988-7772ENCurrent Drain Analysis Enhances WLAN Network Card Design and Test (AN 1468)5989-0565EN84More detailed specifications at /find/66300Opt 100Opt 120Opt 220Opt 230Opt 004 Opt 007 Opt 020(66332A only)Opt UJ0(66332A only)Opt 521Opt AYK Opt 760Opt 8ZJ Opt 8ZLRearMore detailed specifications at /find/66300 85Simplify test and analysis in R&D or on the repair benchWith the Agilent 14565B Device Characterization Software, testing,analyzing, and troubleshooting wireless and battery powereddevices is made simple. The 14565B provides a graphical user interface that lets you easily control the Mobile Communications DC Sources. It gives you access to the Mobile Communications DC Source’s high-powered measurement system and provides an oscilloscope-like view of the voltage or current waveforms of the device under test. The 14565B provides reference waveform save/recall, and provides oscilloscope-like measurement and analysis including voltage and current waveform para-meter measurements, triggering,markers, zoom control, and more.By using the advanced capabilities built into the power supply, you can spend more time testing and analyzing instead of configuring and reconfiguring multiple pieces of test equipment, such as a current shunt, oscilloscope, current probe,DMM, and datalogger.(Continued)More detailed specifications at /find/14565B 86Mobile Communications DC Sources 14565B Device Characterization SoftwareZoom capabilityment setup controlOscilloscope-like view of battery current profiles •Peak current •Talk-mode •Standby-mode •Off-modeCalculated measurements fast analystsData Logging Mode387When coupled with the 66319B/D or the 66321B/D, the 14565B also provides Battery Drain Analysis capabilities. More than just measur-ing battery run time, Battery Drain Analysis allows you to characterize current out of the battery and make tradeoffs in design that impact the current drain and battery life. By providing CCDF measurements and long-term battery drain data logging, the 14565B and 66319/21provide a complete solution for analyzing current drain so that you can optimize your device designs to achieve maximum battery run time.Save time with test automationNew capability makes it easy to automate battery current drain analysis. The 14565B can becontrolled from various programs and programming languages such as the Agilent Wireless Test Manager, NI LabView TM , Agilent VEE, Micro-soft Visual Basic, Microsoft Excel and others. Save valuable resource and time by automating time con-suming, repetitive tasks associated with characterizing battery current drains during real world operation (like video streaming, music down-loads, text messaging). The 14565B Device Characterization Software with test automation reduces setup and test time, reduces manual intervention, and provides battery drain measurement and analysis.More detailed specifications at /find/14565B Key featuresFor R&D•Fast and easy test setup •Digitize current waveforms •Accurately log battery current drain measurements from 10 seconds to 1000 hours at64,000 measurements per second •New automation capability provides operational control from many test applications•Test designs simulating different battery conditions with program-mable output resistance•Zoom capability for analyzing waveform anomalies•Adjust markers for fast measure-ments on digitized waveforms •Easily document your test results •Record test data to files for archive or analysis by other software packagesFor Repair•Compact design with multiple instrument functionality •Fast and easy test setup •Graphical user software, no programming required•Dual DC outputs for replacing the main battery and the power adapter/charger power source •Electronic load for testing the battery charger circuitry •Programmable soft limits toprotect against incorrect voltage settingsOrdering Information14565B Device Characterization with Battery Drain Analysis & Test Automation14565U Device Characterization Software Upgrade (provides upgrade from 14565A to 14565B Software)Note:Battery Drain Analysis means Data Logging and CCDF measurements.These capabilities require models66319B, 66319D, 66321B or 66321D with version A.03.00 firmware or higher and 14565B or 14565A software version 3.01or higher.。
1300 Henley CourtPullman, WA 99163509.334.6306Unit 5: IrDA Communications ProtocolsRevised March 13, 2017This manual applies to Unit 5.1 IntroductionThis unit demonstrates how to use interrupts and the core timer to decode two IrDA protocols, in an effort to teach approaches for decoding different IrDA protocols used for remote device control. The IrDA is an implementation of wireless serial communications capable of simplex as well as half-duplex operation.I have encountered no fewer than 100 IrDA encoding protocols using pulse modulated infrared beams of light. Of the four IR remote control units I have found around my home, no two use the same encoding scheme. With so many existing IrDA protocols used for remote control devices, I present a method for decoding and encoding the NEC protocol that can be used on different schemes. I have verified this methodology for decoding the Pulse Length (also called Pulse Distance Modulated) protocol. Lab 5 will challenge you to follow the methodology presented to develop an interface for an IrDA remote control device of your own choosing.Some silicon devices will decode NED encoded IrDA to 9600 Baud UART outputs, such as the ST3679. Other silicon devices will alleviate the burden of pulse encoding and decoding, such as the Microchip MCP2122, which allows direct interface with the processor UART. The above two IrDA hardware devices are designed to implement wireless line-of-sight asynchronous communications and do not interface with NEC IR remote control devices.2 Objectives1.Identify the IrDA protocol by capturing the bit stream on the IR_RX pin using the Analog Discovery2.2.Develop a C function that executes an algorithm to decode the IrDA bit stream.3.Display the received codes on the LCD and send to the UART communications port.3 Basic Knowledge1.How to configure I/O pins on a Microchip® PIC32 PPS microprocessor.2.How to configure the Analog Discovery 2 to display logic traces.3.How to implement the design process for embedded processor based systems.4 Equipment List4.1 Hardware1.Basys MX3 trainer board2.Standard USB A to micro-B cable3.Workstation computer running Windows 10 or higher, MAC OS, or LinuxIn addition, we suggest the following instruments:4.Analog Discovery 2 Logic Analyzer4.2 SoftwareThe following programs must be installed on your development workstation:1.Microchip MPLAB X® v3.35 or higher2.PLIB Peripheral Library3.XC32 Cross Compiler4.WaveForms 20155.PuTTY Terminal Emulator5 Takeaways1.Understanding of the basics of IrDA protocols.ing instrumentation to characterize data streams.e processor external interrupts to decode signal timing patterns.4.Approaches to using state machines to process data.6 Fundamental Concepts6.1 IrDA ConceptsIt is reported that 99% of all consumer electronics use IrDA remote controllers.1 These remote control devices use low-cost, near infrared LEDs and photo-sensitive transistors to transmit and receive intensity modulated light beams. The fact that these semiconductor devices have a narrow, unobstructed field of view is seen either as a security advantage or a communications limitation, depending on your point of view. This is in comparison to RF communications, such as Bluetooth.IrDA communications has two major applications: high speed data and remote control. Remote control applications use small data packets at low data rates, whereas high speed data applications require a communications stack to manage the re-assemblage of data packets. Table 6.1 compares the key features of IrDA and Bluetooth.1“What is infrared?” /what.htmlTable 6.1. IrDA vs. Bluetooth features comparison.2IrDA-Data Bluetooth Physical Media Infrared RF (2.4 GHz) Communications Range Up to at least 1m 10cm to 100mConnection Type, Direction Point-to-Point, Narrow Angle (30degrees)Multipoint, Omni-directionalMaximum Data Rate 4Mbps (16Mbps on the way) 1Mbps (aggregate)Security Physical limitations offer some built-inprotectionAuthentication, encryption, spreadspectrumApproximate Cost under $2 under $57 Background Information7.1 IrDA Physical LayerThe Basys MX3 platform is equipped with a Rohm RPM973-H11 infrared communications module that provides the digital interface, as shown in Fig. 7.1. The three microprocessor control pins shown in Fig. 7.2 are the IR_TX, IR_RX, and the IR_PDOWN. The Rohm RPM973-H11 is in a low power mode whenever the IR_PDOWN control signal is in the high state. The IR_PDOWN must be in a low state to transmit or receive infrared signals. Both IR_TX and IR_RX are active low signals.Figure 7.1. RPM973-H11 block diagram.2/Embedded-Systems/How-To/Wireless-Bluetooth-IrDAFigure 7.2. Schematic diagram of PIC32 connection to the RPM841-H11 Infrared Module.Reference 3 lists 21 modulation protocols used for remote control devices. This reference also lists standard carrier frequencies used by these devices. In addition to different kinds of coding and different carrier frequencies, there are further variations in the data formats: with and without pre-burst, with different numbers of bits in a command, and with different bit lengths. As one soon realizes, one must match the IrDA protocol before two IrDA devices can communicate. The IrDA support reported in the PIC32MX370 data sheet (see Section 20 of Reference 6) requires an external IrDA Encoder/Decoder, such as the MC2120 suggested in the Microchip Analog Design Note ADN006. The Basys MX3 processor platform DOES NOT contain any hardware IrDA encoder/decoder. The Rohm RPM973-H11 simply asserts the IR_RX signal low whenever an IR signal of sufficient intensity is detected. Likewise, the IR LED is turned on whenever the IR_TX signal is asserted high. When using the Rohm RPM973-H11 on the Basys MX3 processor platform, all encoding and decoding of the IR pulses must be implemented by the PIC32 processor.7.2 Characterization of the NEC IrDA ProtocolThe NEC protocol will be characterized to illustrate the methodology of discovering the protocol used by an IrDA remote controller. The general procedure is to capture logic analyzer traces and match the data profile to an existing IrDA protocol. This is commonly referred to as reverse engineering.Figure 7.3 shows that the IR LED modulation for a 38 kHz carrier is determined as the inverse of the period between LED pulses. The LED is only on for about 2.4μs out of the 26.3 μs carrier frequency period. The duty cycle of the LED is less than 10% resulting in lower power consumption.Figure 7.3. IrDA 38 kHz carrier signal.Figure 7.4 shows a complete IrDA message using the NEC protocol. The signal is low whenever an infrared light is detected. The NEC protocol message contains 32 bits organized in eight bit bytes sent with LSB first. After a 9 ms leader and a 4.5 ms gap, a 560 μs bit marker signals the start of the LSB of the first data byte, as shown in Fig. 7.5.Figure 7.4. Screen capture of a NEC IrDA control message.Figures 7.5 and 7.6 show expanded views of portions of the NEC IrDA protocol, showing the sync followed by three of the 24 data bits. Note that the differentiation between a ONE bit and a ZERO bit is the length of the gap following each 560 μs period of 38 kHz modulated infrared pulses. The last byte contains 9 pulse bursts to allow the last bit to be framed correctly.Figure 7.5. Details of the message leader and first three data bits.Figure 7.6. 38 kHz pulse burst timing representing two ZERO bits and a ONE bit.Figures in Reference 4 are reproduced below to illustrate the timing of the NEC protocol. The encoding of an NEC protocol message in Fig. 7.7 shows that the entire packet consists of two bytes of data: the address byte and the command byte. Each byte is followed by its one’s com plement. The consequence of this encoding is that although the time to transmit a ONE bit is twice that of transmitting a ZERO bit, the time to send any NEC encoded message is constant regardless of the value of the address and control bytes.Figure 7.7. NEC encoded IrDA message.If the key on the remote control unit is held depressed for longer than 110 ms, a repeat code is continuously sent that contains no address or command data, as illustrated in Fig. 7.8.Figure 7.8. Timing diagram of a repeated NEC encoded IrDA message.7.3 Decoding the NEC IrDA Protocol with the PIC32MX370 ProcessorFrom the previous discussion, it is obvious that the PIC32 UART is not suitable for implementing the IrDA NEC remote control protocol. My investigation of internet documents has not produced any meaningful information as to how to implement this design. From my 30 years of microprocessor design experience, I have concluded that there are two possible approaches: application of digital signal processing concepts, namely Fast Fourier Transforms (FFT), or edge timing using PIC32 Input Compare capability or external interrupts. Interestingly, both methods involve frequency domain concepts.The modulation and demodulation of the IrDA signal involves binary coding of the 38 kHz carrier signal. As shown above, the bit value information for the NEC protocol is contained in the period length between the 38 kHz IR beam oscillations.My approach is to first map the PPS input of the IR_RX signal on Port B pin 6 to the external interrupt INT1 as shown in Table 7.1 below. The INT1 is configured to generate an interrupt on the falling (negative) edge of the IR_RX signal using the initialization code shown in Listing 7.1.Listing 7.1. Initialization of INT1// Set up IrDA RX interfaceINT1R = 0b00000101; // Mapping IrDA Rx to RPB6 --> INT1 // Set up INT1 for negative edge triggering IEC0bits.INT1IE = 0; // Disable INT1IPC1bits.INT1IP = 2; // Set Interrupt 1 for priority level 2 IPC1bits.INT1IS = 0; // Set Interrupt 1 for sub-priority level 0 INTCONbits.INT1EP = 0; // Set for falling edgeIFS0bits.INT1IF = 0; // Clear the INT1 interrupt flag IEC0bits.INT1IE = 1; // Enable INT1Table 7.1. Table 12-1 from the PIC32MX370 datasheet for the PPS Input Pin Selection for the PIC32MX370 Processor. Peripheral Pin [pin name ]R SFR [pin name ]R bits [pin name ]R Value to RPn Pin Selection INT1 INT1R INT1R<3:0> 0000 = RPD1 0001 = RPG9 0010 = RPB14 0011 = RPD0 0100 = RPD8 0101 = RPB6 0110 = RPD5 0111 = RPB2 1000 = RPF3(4) 1001 = RPF13(3) 1010 = Reserved 1011 = RPF2(1) 1100 = RPC2(3) 1101 = RPE8(3) 1110 = Reserved 1111 = ReservedT3CK T3CKR T3CKR<3:0> IC1 IC1R IC1R<3:0> U3CTS ̅̅̅̅̅̅̅̅̅ U3CTSR U3CTSR<3:0> U4RX U4RXR U4RXR<3:0> U5RX U5RXR U5RXR<3:0> SS2̅̅̅̅̅ SS2R SS2R<3:0> OCFAOCFAROCFAR<3:0>1. This selection is not available on 64-pin USB devices.2. This selection is only available on 100-pin General Purpose devices.3. This selection is not available on 64-pin USB and General Purpose devices.4.This selection is not available when USBID functionality is used.When the interrupt occurs, the value of the core timer operating at 40 MHz is captured. The previous core timer value is subtracted from the present core timer value to determine the period between interrupts. If this period is approximately 560 μs, a 38 kHz signal is present. The actual IR pulse length is of little concern provided it is sufficiently long to generate a processor interrupt. For our characterization case, the actual measured IR beam pulse width is 2.377 μs.Listing 7.2 shows the C code implementing the INT1 ISR. The time between interrupts contains the neededinformation, hence variable “t1_2” must be declared as static. The static variable, “start_timing” remembers thatthe variable “t1_2” has been initialized after a system reset. The only information needed by the NEC decodin g algorithm is the time since the last interrupt.Listing 7.2. INT1 ISRvoid __ISR(_EXTERNAL_1_VECTOR, IPL2SOFT) ext_int1_isr(void){unsigned long t1_1; // Current time of interruptstatic unsigned long t2_1; // Time of previous interruptunsigned long dt_1; // Time interval between edgesunsigned int bitCount = 0; // Number of decoded bitsstatic int start_timing = 0; // Time capture buffer has been initialized.t1_1 = ReadCoreTimer();if(!start_timing) // Check for first interrupt after reset{t2_1 = t1_1; // Initialize previous time on reset.start_timing = 1;}else{dt_1 = t1_1 - t2_1; // Compute time intervalbitCount = irda_nec(dt_1); // Call decoding functiont2_1 = t1_1; // Update time of last interrupt}IFS0bits.INT1IF = 0; // Clear the interrupt flag}The core timer increments at the rate of a count for each 1/40,000,000 seconds or 0.0025 μs per count. Referring back to the NEC characterization figures, we find that the sync period should be reported 0.0045 seconds multiplied by 40,000,000 counts per second, or approximately 180000 core timer counts. When a ONE bit is encoded, the number of core timer counts since the last interrupt is (0.0025 – 0.00056) seconds multiplied by 40,000,000 counts per second, or approximately 67000 core timer counts. When a ZERO bit is encoded, the number of core timer counts since the last interrupt is (0.00112 – 0.00056) seconds multiplied by 40,000,000 counts per second, or approximately 22400 core timer counts. Since the accuracy of the crystals used to generate the IR pulses is unknown, 2% accuracy can be assumed and still allow for adequate discrimination between symbols. Table 7.2 lists the core timer count range for the NEC protocol symbols.Table 7.2. Core Timer Count ranges.Symbol Minimum Core Timer Count Maximum Core Timer CountSync176400183600ONE bit6566068340Zero bit21952228487.4 Encoding the NEC IrDA Protocol with the PIC32MX370 ProcessorIn order to encode an IrDA for the NEC protocol, the 38 kHz modulated bit stream must be generated. I chose to generate the 38 kHz pulsed signal using the PWM output of the PIC32 processor. Table 7.3 is a copy from the PIC32MX370 data sheet showing the PPS mapping of OC5 to Port B bit 7, which is connected to the IR_TX signal line. Listing 7.3 is the code for the IrDA initialization.Table 7.3. PIC32MX370 PPS output mapping for bit 7 of Port B. RPn Port Pin RPnR SFR RPnR bits RPnR Value to Peripheral SelectionRPD9 RPD9R RPD9R<3:0> 0000 = No Connect0001 = U3RTS̅̅̅̅̅̅̅̅̅ 0010 = U4TX 0011 = REFCLKO 0100 = U5TX 0101 = Reserved 0110 = Reserved0111 = SS1̅̅̅̅̅ 1000 = SDO11001 = Reserved 1010 = Reserved 1011 = OC51100 = Reserved 1101 = C1OUT 1110 = Reserved 1111 = ReservedRPG6 RPG6R RPG6R<3:0> RPB8 RPB8R RPB8R<3:0> RPB15 RPB15R RPB15R<3:0> RPD4 RPD4R RPD4R<3:0> RPB0 RPB0R RPB0R<3:0> RPE3 RPE3R RPE3R<3:0> RPB7 RPB7R RPB7R<3:0> RPB2 RPB2R RPB2R<3:0> RPF12(4) RPF12R RPF12R<3:0> RPD12(4) RPD12R RPD12R<3:0> RPF8(4) RPF8R RPF8R<3:0> RPC3(4) RPC3R RPC3R<3:0> RPE9(4) RPE9RRPE9R<3:0>The 38 kHz carrier signal is generated by setting the Timer 2 counter register equal to the PBCLOCK divided by 38000. The PWM output is turned off by setting the OC5 reset time greater than the Timer 2 period. The 9% duty cycle 38 kHz signal is turned on by setting the OC5 reset time to the product of 0.09 times the Timer 2 period. Generating the NEC sync signal and encoding the one’s and zero’s is just a matter of turning the PWM on and off for the specific duration, as specified by Reference 3.Listing 7.3. IrDA initialization#define IRDA_38K_IDLE 264 #define IRDA_38K_ON 23 #define IRDA_38KHZ_PD 262 void irda_init(void) {int i;// IrDA Power Down ControlTRISGCLR = BIT_1; // Set IR_pdown as output(); LATGCLR = BIT_1; // Set IR_pdown(0);// Set up IrDA TX interfacePORTSetPinsDigitalOut(IOPORT_B, BIT_7); // IR_TX RPB7R = 0b00001011; // Mapping OC5 to RPB7// Enable OC5 for PWM operationOpenTimer2((T2_ON | T2_SOURCE_INT | T2_PS_1_1), IRDA_38KHZ_PD);OpenOC5((OC_ON|OC_TIMER_MODE16|OC_TIMER2_SRC|OC_PWM_FAULT_PIN_DISABLE),IRDA_38K_IDLE, IRDA_38K_IDLE);// Set up IrDA RX interfaceINT1R = 0b00000101; // Mapping IrDA Rx to RPB6 --> INT1PORTSetPinsDigitalIn(IOPORT_B, BIT_6); // IR_RX// Set up INT1 for negative edge triggeringIEC0bits.INT1IE = 0; // Disable INT1IPC1bits.INT1IP = 2; // Set Interrupt 1 for priority level 2IPC1bits.INT1IS = 0; // Set Interrupt 1 for sub-priority level 0INTCONbits.INT1EP = 0; // Set for falling edgeIFS0bits.INT1IF = 0; // Clear the INT1 interrupt flagIEC0bits.INT1IE = 1; // Enable INT1}8 References1.Remote Control, https:///wiki/Remote_control2.Consumer IR, https:///wiki/Consumer_IR3.Data Formats for IR Remote Control, /docs/80071/dataform.pdf4.AN #157 Implementation of IR NEC Protocol,/index.php?option=com_content&task=view&id=2235.Remote Control with IrDA® Transceivers, /TFBS4710-TT1-Vishay-datasheet-12514678.pdf6.SB –Projects NEC Protocol, /knowledge/ir/nec.php7.PIC32MX330/350/370/430/450/470 Data Sheet,/downloads/en/DeviceDoc/60001185E.pdf8.Understanding Sony IR remote codes, LIRC files, and the Arduino library,/2010/03/understanding-sony-ir-remote-codes-lirc.html。
Power Characterization of a Bluetooth-Equipped SensorNode.M.Lundberg,J.Eliasson,J.Allan,J.Johansson,P.Lindgren.EISLAB,Dept.of Computer Science and Electrical EngineeringLule˚a University of TechnologySE-97187Lule˚a,Swedenmaglun@csee.ltu.seABSTRACTWireless Sensor Networks(WSNs)consist of small,autonomous devices with wireless networking capabilities.In order to further increase the applicability of WSNs in real world ap-plications,minimizing energy consumption and size are im-portant research topics.A WSN node itself is a complex system consisting of numerous components,and the energy consumption of the node depends heavily on the interac-tion between its components and their respective operation modes.To develop a power consumption model,we have investigated the power characteristics of a Bluetooth(BT)-equipped node based on COTS(commercial off-the-shelf) components running standardized protocols for communica-tion.The characterization captures the transient behaviorof the individual components as well as the dynamic behav-ior of the system as a whole.Although the parameters of the model are derived for a specific node,the model and our conclusions can be applied to WSN nodes in general.Based on our model the estimated lifetime of a battery powered BT-equipped node can range from a couple of days to sev-eral months depending on battery and usage.This result indicates that COTS based sensor nodes can be used in a wide range of applications.1.INTRODUCTIONWireless Sensor Networks(WSNs)provide unique opportu-nities in environmental monitoring,industrial,health care, and military applications.WSNs are networks of several small,autonomous devices equipped with wireless commu-nication.Over the years,WSNs has evolved from tiny data gathering networks[12]to functionally rich distributed sys-tems[8].Comprehensive surveys on WSNs can be foundin[4,21]where different aspects of sensor networking are discussed.Minimizing energy consumption and size are important re-search topics in order to make WSNs deployable.As most WSN nodes are battery powered,their lifetime is highly de-pendant on their energy consumption[17].In cases with hundreds of nodes,changing batteries can be an almost un-achievable task due to the sheer number of nodes.Due to the low cost of an individual node,it is perhaps more costeffective to replace the entire node than to locate the node and replace or recharge its battery supply.In other scenar-ios the location of the node make battery changes infeasible; the node might be physically inaccessible(as embedded into the hosting equipment),the node may be located in an en-vironment where human intervention is undesirable(such as a bird nest[14]),the node is situated in a dangerous envi-ronment(such as a chemical plant),or the node resides in rugged unaccessible terrain.An effective solution to prolong the operational lifetime of a node is to apply energy scavenging methods such as solar technology[20],or vibrations[1][2].Another approach is to apply a local RFfield to temporarily power an individual node in order to retrieve data[10].The work presented in this paper is based on COTS com-ponents and standardized protocols for communication,in our case the microcontroller based platform MULLE[11] featuring Bluetooth and TCP/IP communication.COTS based solutions provides valuable insight of the underlying problems and serve as a basis for experimental work and development of real world applications.As wireless communication is one of the key issues for WSN nodes,the problem of energy-aware routing has been the focus of recent research[18,5].We however,investigate the power characteristics of an individual node in a single-hop network in order to develop a power consumption model. The node itself is a complex system consisting of numerous components.As the energy consumption of the node de-pends heavily on the interaction between its components and their respective context(operation mode),it is necessary to regard the transient behavior of the individual components as well as the dynamic behavior of the system as a whole. To formally analyze a WSN node would be intractable using today’s methodologies and ponent characteris-tics are often publicly unavailable due to proprietary issues. Even if we could obtain such information,there would still be a lack of formal methods for complex system analysis.So we ask ourselves,given the complexity of a node,is it at all possible to derive a model of its energy consumption.If so, will the model be robust,intuitive,and applicable?To address this problem,we undertake an applied approach, based on real life measurements conducted for representative contexts(operation modes for the node as a whole).In this paper we extend the general design methodology previously proposed in[13],by developing a model for the MULLE node.Although the parameters of the model are derived for this specific node,the model and our conclusions can be applied to WSN nodes in general.RTC / EEPROMBluetooth chipsetMain connectorInstr. amplifier Bluetooth antenna Figure 1:MULLE:front and back.The outline of the paper is as follows;chapter 1gives an introduction,chapter 2describes the system setup,chapter 3gives information on measurement setup,chapter 4is a description of the characterization,chapter 5explains the model,and the paper is concluded with discussion and re-sults.2.SYSTEM SETUP 2.1WSN ArchitectureA WSN node consists of a sensor,a microcontroller (MCU)and a communication device.The MCU acquires data from the sensor and transmits it using the communication device either raw or preprocessed.2.2HardwareThe MULLE,shown in Figure 1,is a wireless sensor node de-veloped at EISLAB [3],Lule ˚a University of Technology.The physical size of the sensor node is 25x23x5mm.The batter-ies used are a selection of lithium or lithium-ion with capac-ity ranging from 120mAh to 2200mAh.It holds a Renesas M16[15]microcontroller with 20kB of RAM,mounted as a bare die to save space on the PCB.The wireless communica-tion device chosen is a Bluetooth module [6].The MULLE has a 3.0V linear regulator controlling the power supply.A real-time clock (RTC)is also integrated and serves several purposes,it;provides the MCU with a sub clock,generates timer interrupts,and serves as non-volatile storage.A 26pin connector allows a multitude of sensors to be connected to the MULLE using both analog and digital I/O’s.2.3SoftwareTo give the node the possibility to use available communi-cation infrastructure,such as cellular networks and the In-ternet,all communication is performed using standardized protocols.Contained in the highest layer of the software hierarchy (Figure 2)are the applications;a generic sensor application which acquires and communicates data from the sensor,and a web server.The web server provides the user interface for the sensor application in the form of a Java ap-plet.TCP/IP communications are handled by a lightweight stack lwIP [9]and Bluetooth communications are handled by lwBT [16].No realtime operating system is used,all low level functionality is handled by an in-house hardwareFigure 2:The MULLE software stack.abstraction layer.In [19]several data delivery models are presented.The data delivery model used by the MULLE in this work is continuous,this means that data is sent at a pre-specified rate.Between transmissions,the MCU and the BT-module sleep and only wake up to send data or store data for later transmission.3.MEASUREMENT SETUPTo capture the power consumption,a digital oscilloscope Tektronics TDS7254was set up to measure the voltage over a series resistor.The oscilloscope has a vertical resolution of 8bits with a gain accuracy of 2%.During measurement the oscilloscope has been setup to use as much as possible of the available resolution.The resistor was chosen to 10Ohm to get a reasonably large signal to measure while keeping the voltage fluctuation over the MULLE low.The steady state current measurements were made with a digital Sourcemeter Keithley 2400.As the voltage provided to the MULLE is held constant we can calculate the power consumption.The Sourcemeter has a accuracy of 0.012%and a resolution of 51/2digits.In order to validate the derived model (presented in chapter 5)real world life time tests were made.To give the MULLE a lifetime in the range of minutes,convenient for conducting repeated experiments,a capacitor was used as power supply in a similar manner to [18].4.CHARACTERIZATIONTo make a complete characterization of the MULLE.The measurements were made on three representative operating modes;sleep mode,data acquisition,and data transmission.These modes should apply to WSN nodes in general.4.1Sleep modeIn order to reduce the power consumption,the MULLE uti-lizes the sleep mode whenever possible.To investigate how much power individual components consume,measurements began with only the MCU,and the basic components it re-quires to operate,such as the RTC and voltage regulator mounted.The next step was to measure with the voltage references mounted,the voltage references are used by the MCU internal AD converter.The last component mountedComponents Power MCU +Regulator 270µW Voltage References 470µW Instrumentation Amplifier450µW Bluetooth module270µW Total Sum 1460µWTable 1:Power consumption of different parts on MULLE in sleep mode.x 10−4time [s]P o w e r [W ]Figure 3:Ten overlayed measurements of the MULLE power consumption when acquiring one sample.At time a an interrupt is generated by the RTC and the MCU wakes up from sleep mode and starts initialization.At time b the MCU switches from 1.25MHz to 10MHz and acquires the sample.The MCU returns to sleep mode at time c .was the instrumentation amplifier.The instrumentation amplifier is used to give MULLE an analog differential in-put.The results of the measurements are shown in Table 1.This characterization shows that for the MULLE,the sleep mode power consumption could be reduced from 1460µW to 270µW by introducing switches to completely power down the BT-module,voltage references,and the instrumentation amplifier when they are not used.4.2Data AcquisitionTo characterize the MULLE during data acquisition,mea-surements were taken when the MULLE was reading analog values from a temperature sensor at a specific periodic rate controlled by interrupts generated by the RTC.Figure 3shows ten overlayed measured activations.Each activation consists of the RTC generating an interrupt,the MCU ini-tiating and acquiring one sample.During characterization tests where made with the MCU running at different clock frequencies.A comparison between 1.25MHz and 10MHz is shown in Figure 4.The tests showed that running the MCU at full speed (10MHz)was most energy efficient.To fully take advantage of the reduced frequency an accompanying reduction in supply voltage would be required.As the sup-ply voltage could not be adjusted the faster clock speed was preferred,allowing the MULLE to return to the low power sleep mode earlier.0123456x 10−40.0050.010.0150.020.0250.03time [s]P o w e r [W ]10 MHz1.25 MHzFigure 4:MULLE power consumption while run-ning at 10MHz vs 1.25MHz.The total energy consumption for these cases are 2.8and 3.4µJ re-spectively,obtained by integrating the above curves.4.3Data TransmissionTo be able to characterize the data transmission,measure-ments were made when the MULLE created a Bluetooth connection to a LAN-access point and sent 16bytes of sam-pled data.The by far most energy consuming component of the MULLE is the Bluetooth-module,where most of the energy is spent during the connection phase.Sending of the actual measurement data only corresponds to about 1%of the energy used by the Bluetooth-module during transmis-sion.In order to decrease the time required to make the Bluetooth connection,a fixed Bluetooth address was used.By using this approach,there is no need to make a time consuming Inquiry Scan before each connection.The recommended time for scans is set to 10.24s by the Generic Access Profile [7],so by reusing the previously used address,the connection setup time is reduced and made more predictable.In many cases,such as when using a mobile phone or LAN Access Point as the Internet provider,the Bluetooth address will in fact remain constant over time.The only occasion it is necessary to make an Inquiry scan is when the provider is no longer operational,in which case the MULLE must find a new Internet providing device within its vicinity.A Blue-tooth connection starts by synchronizing the Master and Client clocks.The next step is to set up an ACL radio link.When the ACL link is established,the power consumption initially fluctuates,leveling out at around 0.17W,as seen in Figure 5.The next steps involve setting up L2CAP,RFCOMM and PPP connections.All of these steps are considered to only be data traffic on the ACL link and do not cause any major variations on the power consumption.When a PPP connection is established between the Client and the Master,TCP traffic flows from the Master to a server on the Internet.Once all TCP data is sent,the Master shuts down the ACL link causing all other layers to abruptly disconnect.0123456789100.020.040.060.080.10.120.140.160.180.2time [s]P o w e r [W ]Figure 5:Ten overlayed measurements of the MULLE power consumption during a Bluetooth connection Variable DescriptionUnit P sleep Power Consumption while sleeping W E acq Energy Consumption while acquiring data J E con Energy Consumption for a connectionJ f acq Frequency of acquisition Hz f conFrequency of connection HzTable 2:Expression description5.ENERGY CONSUMPTION MODELDuring characterization,the energy consumption for MULLE was measured in three representative operating modes,based on these measurement the model was formulated.The ex-pression is given in Equation 1with a description of the variables given in Table 2.E =T ×(P sleep +f acq ×E acq +f con ×E con )(1)This model describes the total energy consumption for the MULLE platform given periodic data acquisition and trans-mission.It captures the complex interaction between the hardware and software components and incorporates oper-ation mode transitions.In this way,the model provides the system designer with a simple tool that conceals the com-plex system implementation when dealing with application development and system dimensioning,e.g.battery capac-ity,sampling frequency and data aggregation.Table 3shows the average power consumption for MULLE depending on time in between activations/connections.It is obvious from the results that the communication interval has by far the most influence on energy consumption.To validate the model real world life time tests were made.Pre-liminary results indicate a good agreement with the model.Time between Transmission interval Activations 10sec 1min 1h 24h 1ms 129mW 25mW 4.5mW 4.1mW 1s 127mW 22mW 1.8mW 1.5mW >1s127mW22mW 1.8mW 1.5mWTable 3:Average power consumption depending on time between activations and transmissions.6.CONCLUSIONSWireless Sensor Networks are gaining increasing interest,and can be useful for example in;environmental monitoring,industrial,health care,and military applications.As most of the nodes are battery operated the dominant constraint for WSNs is power consumption.Due to the complexity of a WSN node,it is a difficult task to make a formal analy-sis of the energy consumption.Instead,we derive a model of the energy consumption by characterizing measurements,and we show that the model is robust,intuitive and ap-plicable by comparison between expression and real lifetime experiments.The model is useful to target operational lifetime and modes of operations,and to make design decisions to minimize en-ergy consumption.The model can be used as a design tool e.g.to;•Estimate battery operating life,given activation and connection frequency.•Decide the number of activations or connections for a certain battery capacity.•Make decisions on battery capacity,given a requested lifetime.The derived model has been validated experimentally with promising results,but the internal resistance of the capaci-tance gives rise to voltage drops.This can cause the MULLE to reset,so further refinements to the measurements are needed.The characterization of the MULLE indicates pos-sible improvements,for example by switching offthe voltage references for AD conversion and power down the instrumen-tation amplifier and the BT-module.Such modifications are projected for the next revision of the MULLE.Future work also includes extending the model with support for routing costs in ad-hoc sensor networks.7.REFERENCES[1]Energy harvester by Ferro Solutions./,March2005.[2]Ipower energy harvesters by Continuum Control Corp./,March2005.[3]Lule˚a University of Technology,Embedded InternetSystem Laboratory,Jan2005.http://www.csee.ltu.se/eislabfo.[4]I.F.Akyildiz,W.Su,Y.Sankarasubramaniam,andE.Cayirci.Wireless sensor networks:A survey.Computer Networks,38:393–422,2002.[5]Juan Alonso,Adam Dunkels,and Thiemo Voigt.Bounds on the energy consumption of routings inwireless sensor networks.In Proceedings of the2ndWiOpt,Modeling and Optimization in Mobile,Ad Hoc and Wireless Networks,Cambridge,UK,March2004.[6]Bluetooth Module WML-C10Class2.MITSUMIELECTRIC CO.,LTD.,February2005.[7]Bluetooth Specification v1.2Core Specification,Version1.2.November2002.https:///,Mar2005.[8]A.Cerpa,J.Elson,D.Estrin,L.Girod,M.Hamilton,and J.Zhao.Habitat monitoring:Application driverfor wireless communications technology.In ACMSIGCOMM Workshop on Data Communications inLatin America and the Caribbean,April2001.[9]A.Dunkels.lwIP-A Lightweight TCP/IP Stack.http://www.sics.se/˜adam/lwip/,February2005. [10]D.Friedman,H.Heinrich,and D.-W.Duan.Alow-power cmos integrated circuit forfield-poweredradio frequency identification tags.In Digest ofTechnical Papers44th ISSCC Solid-State CircuitsConference,pages294–295.IEEE,Feb1997.[11]J.Johansson,M.V¨o lker,J.Eliasson,˚A.¨Ostmark,P.Lindgren,and J.Delsing.Mulle:A minimal sensor networking device-implementation andmanufacturing challenges.In IMAPS Nordic2004,pages265–271,2004.[12]J.M.Kahn,R.H.Katz,and K.S.J.Pister.Nextcentury challenges:mobile networking for’smartdust’.In Proceedings of the5th annual ACM/IEEEinternational conference on Mobile computing andnetworking,pages271–278.ACM Press,1999.[13]M.Lundberg,J.Eliasson,L.Svensson,andP.Lindgren.Context aware power optimizations ofwireless embedded internet systems.In Proceedings of the21st IEEE Instrumentation and MeasurementTechnology Conference,IMTC04,volume1,pages91–95,May2004.[14]Alan Mainwaring,Joseph Polastre,Robert Szewczyk,David Culler,and John Anderson.Wireless sensornetworks for habitat monitoring.In ACMInternational Workshop on Wireless Sensor Networks and Applications(WSNA’02),Atlanta,GA,September2002.[15]Microcontroller M16C/62M.Renesas TechnologyCorporation./eng/,June2004.[16]C.¨Ohult.lwBT-A Lightweight Bluetooth Stack.http://www.csee.ltu.se/˜conny/lwBT/,February2005.[17]V.Raghunathan,C.Schurgers,S.Park,andM.Srivastava.Energy aware wireless microsensornetworks.IEEE Signal Processing Magazine,vol.19,iss.2,pp.40–50,March2002.[18]Hartmut Ritter,Jochen Schiller,Thiemo Voigt,AdamDunkels,and Juan Alonso.Experimental Evaluationof Lifetime Bounds for Wireless Sensor Networks.InProceedings of the Second European Workshop onSensor Networks(EWSN2005),Istanbul,Turkey,January2005.[19]S.Tilak,N.Abu-Ghazaleh,and W.Heinzelman.Ataxonomy of wireless microsensor network models.InACM Mobile Computing and Communications Review (MC2R2002).[20]Thiemo Voigt,Hartmut Ritter,and Jochen Schiller.Utilizing solar power in wireless sensor networks.InThe28th Annual IEEE Conference on Local Computer Networks,October2003.[21]A.L.A.P.Zuquim,L.F.M.Vieira,M.A.Vieira,A.B.Vieira,H.S.Carvalho,J.A.Nacif,Jr.Coelho,C.N.,Jr.da Silva,D.C.,A.O.Fernandes,and A.A.F.Loureiro.Efficient power management in real-time embeddedsystems.In Emerging Technologies and FactoryAutomation,EFTA’03,volume1,pages496–505,Sept2003.。