搜档网
当前位置:搜档网 › Atheros AP System User's Manual_01112010

Atheros AP System User's Manual_01112010

Atheros AP System User's Manual_01112010
Atheros AP System User's Manual_01112010

Atheros AP System User’s Manual

PRELIMINARY

11 January 2010

? 2000–2008 by Atheros Communications, Inc. All rights reserved.

Atheros?, Atheros Driven?, Atheros XR?, Driving the Wireless Future?, ROCm?, Super AG?, Super G?, Total 802.11n?, and Wake on Wireless? are registered by Atheros Communications, Inc. Atheros SST?, Signal-Sustain Technology?, the Air is Cleaner at 5-GHz?, XSPAN?, Wireless Future. Unleashed Now.?, and 5-UP? are trademarks of Atheros Communications, Inc. The Atheros logo is a registered trademark of Atheros Communications, Inc. All other trademarks are the property of their respective holders.

Subject to change without notice.

Notice

The information in this document has been carefully reviewed and is believed to be accurate. Nonetheless, this document is subject to change without notice, and Atheros Communications, Inc. (Atheros) assumes no responsibility for any inaccuracies that may be contained in this document, and makes no commitment to update or to keep current the contained information, or to notify a person or organization of any updates. Atheros reserves the right to make changes, at any time, in order to improve reliability, function or design and to attempt to supply the best product possible. Atheros does not represent that products described herein are free from patent infringement or from any other third party right.

No part of this document may be reproduced, adapted or transmitted in any form or by any means, electronic or mechanical, for any purpose, except as expressly set forth in a written agreement signed by Atheros. Atheros or its affiliates may have patents or pending patent applications, trademarks, copyrights, maskwork rights or other intellectual property rights that apply to the ideas, material and information expressed herein. No license to such rights is provided except as expressly set forth in a written agreement signed by Atheros.

ATHEROS MAKES NO WARRANTIES OF ANY KIND WITH REGARD TO THE CONTENT OF THIS DOCUMENT. IN NO EVENT SHALL ATHEROS BE LIABLE FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL SPECULATORY OR CONSEQUENTIAL DAMAGES ARISING FROM THE USE OR INABILITY TO USE THIS PRODUCT OR DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBLITY OF SUCH DAMAGES. IN PARTICULAR, ATHEROS SHALL NOT HAVE LIABILITY FOR ANY HARDWARE, SOFTWARE, OR DATA TRANSMITTED OR OTHERWISE USED WITH THE PRODUCT, INCLUDING THE COSTS OF REPAIRING, REPLACING, INTEGRATING, INSTALLING OR RECOVERING SUCH HARDWARE, SOFTWARE OR DATA. ATHEROS SPECIFICALLY DISCLAIMS THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE AS THEY MIGHT OTHERWISE APPLY TO THIS DOCUMENT AND TO THE IDEAS, MATERIAL AND INFORMATION EXPRESSED HEREIN.

Document Number: 984‐00065‐001 MKG‐0922 Rev. 1

Revision History

Revision Date Description

Original Release

0.5 November

2008

Updated to include Web interface and configuration methods.

0.6 November

2008

0.7 Jan 2010 Updated for UMAC baseline

Table of Contents

1Introduction (6)

1.1Top Level architecture (6)

1.2Fusion Overview (6)

1.3Lower MAC (7)

1.3.1HAL (7)

1.3.2ATH (7)

1.3.3Rate Control (7)

1.3.4Packet Logging (8)

1.3.5DFS (8)

1.4Upper MAC (8)

1.4.1802.11 Layer (8)

1.4.2Shim Layer (8)

1.5WLAN Driver Interface and OS Abstraction Layer (9)

1.6WBUF Abstraction (9)

2User Interface (10)

2.1Configuration File (10)

2.2Environmental Variables (10)

2.3Shell Scripts (19)

2.3.1Initialization Scripts (26)

2.3.1.1rcS (27)

https://www.sodocs.net/doc/c912307820.html,work (27)

2.3.1.3rc.bridge (27)

2.3.1.4rc.wlan (27)

2.3.2Driver Operation Scripts (27)

2.3.2.1makeVAP (28)

2.3.2.2activateVAP (29)

2.3.2.3killVAP (29)

2.3.3Compatibility Scripts (29)

2.3.3.1apup (29)

2.3.3.2apdown (29)

2.4Wireless Tools (30)

2.4.1iwconfig (30)

2.4.2iwpriv (32)

2.4.2.1Radio Layer (33)

2.4.2.2Protocol Layer (41)

2.4.2.3WMM related (42)

2.4.2.4Security Related (44)

2.4.2.5802.11n related (48)

2.4.2.6Regulatory commands (52)

2.4.2.6.1General commands (54)

2.4.3Changing parameters using iwconfig and iwpriv (63)

2.5wlanconfig utility (63)

2.5.1Creating a VAP (63)

2.5.2Listing VAP Parameters (63)

2.5.2.1Station (sta) (64)

2.5.2.2AP List (ap) (65)

2.5.2.3Channel (chan) (65)

2.5.2.4Capabilities (caps) (66)

2.5.2.5WMM Configuration (wme) (66)

2.5.3Deleting a VAP (66)

3AP Configuration Guide (67)

3.1AP Modes of Operation (67)

3.1.1Network Configuration (67)

3.1.1.1Bridged Mode (67)

3.1.1.2Static IP address Mode (67)

3.1.1.3DHCP Client (67)

3.1.1.4DHCP Server (67)

3.1.2Radio Configuration (68)

3.1.3Operating Mode (68)

3.2Security (69)

3.2.1WEP Configuration (69)

3.2.2WPA (69)

3.2.2.1Enabling WPA Preauthorization (AP only) (69)

3.2.2.2WPA PSK (70)

3.2.2.3WPA Enterprise (70)

3.2.3WSC Configuration (70)

3.2.3.1Including WSC in the build (70)

3.2.3.2Activating WSC support on the AP (70)

3.3VLAN Configuration (71)

3.3.1Bridge configuration in mBSSID and VLAN mode (72)

3.4Multiple BSS (72)

3.4.1Multiple Open APs (72)

3.4.2Multiple AP’s with different security modes (73)

3.4.3Changing Parameters in mBSSID Modes (73)

3.5Wi-Fi Distribution System (WDS) (73)

3.5.1AP With Single WDS Repeater (73)

3.5.1.1Limitations (73)

3.5.1.2Setup Instructions (74)

3.5.2AP with Multiple Repeaters (74)

3.5.2.1Limitations (75)

3.5.2.2Setup Instructions (75)

3.5.3WDS Bridge with single span (75)

3.5.3.1Limitations (75)

3.5.3.2Setup Instructions (76)

3.5.4WDS Bridge with multiple span (76)

3.5.4.1Limitations (76)

3.5.4.2Setup Instructions (77)

3.6Dual Concurrent Operations (77)

Appendix A Country Code Definition (78)

1 Introduction

This manual provides information on the design and use of the Atheros AP system. This system consists of the OS kernel, utility functions, and the Atheros AP Driver.

1.1 Top Level architecture

This driver is based on the Atheros Universal Driver Architecture. This architecture abstracts the WLAN driver into

various common sections that can be used for a variety of operating systems. OS specific components are well isolated,

and the Atheros Driver Framework (ADF) provides abstractions of OS services such that the common code does not

have to have ANY OS specific coding. The data packet abstraction, called WBUF, allows the driver to handle different

OS specific frame formats in a common way. This abstraction has been used with both SKB and MBUF frame

architectures successfully, and also works with Windows frame architectures.

The software design is moved to a further modularized architecture that allows for better isolation of data items and

object oriented design. . Global variables are eliminated, and all layer functions are contained within a call structure.

Overview

1.2 Fusion

The main driver for the Fusion architecture was the use of a common code base to support multiple operating systems.

This allows for more efficient development processes, as well as the synergy of getting bug fixes for all major platforms

at the same time.

The Fusion architecture consists of 4 major components. The first is the WLAN driver interface, which is the operating

system unique interface adaptor that translates OS specific calls to Fusion “generic” calls. The second is the Upper

MAC layer, which contains the bulk of the 802.11 protocol processing for both station and AP applications. In earlier

versions of Fusion, this layer was implemented specifically for each operating system. In later versions, a common

version of the Upper MAC is used to provide the protocol processing layer.

The third component is the Lower MAC, which contains the ATH and HAL layers. This layer is much more hardware

centric, and is designed to support the needs of the Atheros chipset architecture. The fourth component is the OS

Abstraction layer. This is a set of macros that is used to redefine “generic’ OS primitives into specific system calls that

perform the required function. Functions such as register read/write, translation of OS packets into WBUF abstractions,

and tasking control are all included in this section. A block diagram of the components and their relationship are shown

in Figure 1.

Figure 1 Fusion Top Level Block Diagram

1.3 Lower MAC

The Lower MAC portion consists of two main components: The Hardware Abstraction Layer (HAL), and the

Atheros Device Object (ATH). The HAL contains all chip-specific settings and procedures that are performed to initialize and operate the device. The ATH layer is responsible for managing the data flow into the input queues of the hardware, as well as managing lower layer protocols, such as Block ACK processing.

1.3.1 HAL

HAL provides low-level primitives to program Atheros chipsets. HAL abstraction will allow runtime support of multiple chipset families and defines a common body of functions between chipsets with chipset differences being handled in specific components. Only low-level driver components can interface directly with HAL.

1.3.2 ATH

ATH_DEV module implements the low level MAC functionalities including:

? Unified transmit and receive path for both legacy and 11n chipsets.

? Advanced 11n MAC features: aggregation, RIFS, MIMO power save, etc. ? 802.11 network power save and device power state (D0-D3) management. ? Beacon generation and TSF management. ? Wake-On-Wireless support. ? Key cache management.

? RfKill, Customized LED and GPIO algorithms

ATH_DEV can be accessed through Atheros device object interface (section 1.2) by protocol shim layer.

1.3.3 Rate Control

The rate control algorithm attempts to transmit unicast packets at the optimum data rate. If there are changes in the propagation channel, the rate control algorithm will automatically step up or down to a data rate that allows reliable transmission at the fastest possible rate. The rate control can only be accessed by ath_dev, and should OS Abstraction Layer

Atheros Device Object (ath dev)

Packet Logging

ATH DEV

Rate Control

DFS

Hardware Abstraction Layer IEEE 802.11 Protocol Stack

AR5416

WLAN Driver Interface LMAC Interface

Base Objects (channel, ic, node, VAP)

MLME

PM

STA/AP SME

Scanning/Roaming

Mgmt Frm

Config

AR5212

1.3.4 Packet Logging

Packet logging provides a low level mechanism to capture driver activities. It can log activities like transmit,

receive, rate find and update, aggregation, ANI, and etc. Different operating system shall have its own tool to

enable packet log and retrieve the log buffer.

1.3.5 DFS

This module implements the DFS or Dynamic Frequency Selection algorithm, which enables wireless devices

operating in the 5GHz band to detect the presence of radar systems. If a radar system is detected, the wireless

device must avoid interfering with it and must automatically switch to another frequency.

MAC

1.4 Upper

The Upper MAC is the portion of the MAC that performs most of the 802.11 protocol processing, and

provides the interface to the OS networking stack. In the Fusion implementation, the Upper MAC consists of

the 802.11 layer, and the so-called “shim” layer.

1.4.1 80

2.11 Layer

Most wireless LAN device driver today consists of two major components: a protocol stack and a low-level

driver. Usually the protocol stack contains IEEE802.11 state machine, scanning/roaming, IE processing, and

other device independent support needed by an 802.11 device. Although the functionalities of a protocol stack

are largely platform independent, the actual implementation is often platform specific.

Many protocol stacks are available. The protocol stacks with the most support in the Fusion driver are the

net80211 derivatives. They have been ported to NetBSD, Linux, Darwin, and Windows Vista. Another popular

stack is Devicescape’s 802.11 stack in Linux kernel. Microsoft also has a separate stack for SoftAP on Vista.

1.4.2 Shim Layer

The Shim layer is provided in order to minimize changes to upper layers that have been implemented for non-

fusion architectures. Since the HAL/ATH layers try to encapsulate internal data and only provide interfaces

through the operations interface, the upper layer no longer have direct access to variables within the lower

layers. The Shim layer is provided to expose various state and configuration variables to the upper layers in

order to minimize changes to the upper layers.

The Shim layer uses the standard interfaces to the ATH/HAL layers to obtain state information. Since

everything is written in the “C” language, this is enforced more through coding convention than through

language restrictions. Because of the protocol stack is largely device independent, while a low level driver is

protocol independent, a protocol shim layer is required to connect different components of the wireless LAN

driver. Most importantly, it has the following operations:

?Register with IEEE802.11 protocol stack.

?Register with operating system’s network stack.

?Manage low level driver object (ath_dev, see section 1.4).

?Forward packets between protocol stack and low level driver.

?Translate control request and event indication between protocol stack and low

level driver.

Figure 2 illustrates the operations of protocol shim layer.

Figure 2 UMAC Shim Layer

1.5 WLAN Driver Interface and OS Abstraction Layer

Each operating system has its own networking and wireless driver interface, such as NDIS 6.0 with Revised Native WiFi in Windows Vista. The WLAN driver interface allows the driver to register with kernel, and defines data path and configuration path from/to network stack, such as OID for Windows Vista, iwconfig/iwpriv tools for Linux, and etc. OS abstraction layer is a set of kernel services used by wireless LAN driver. A separate implementation is required for each platform. By having a consistent API across all platforms, driver developers can focus on the core wireless LAN logic. Currently supported operating systems are: NetBSD, Linux and Windows Vista.

1.6 WBUF Abstraction

A wbuf (wireless buffer) is a platform independent object to represent a network buffer. In WLAN world, it also

represents an MSDU passed down by the protocol stack. The low level driver components treat wbuf as an opaque object defined by type wbuf_t , and access it only through a well defined interface. The wbuf APIs can be found in include/wbuf.h . Each platform should implement the same set of APIs in their OS abstraction layer. Usually the wbuf is associated with or mapped to native network buffer structures.

net80211

2 User

Interface

The user interface on the Linux AP baseline provides a rich set of capabilities via command line tools, and also provides a simplified web interface that can be used for quick AP configuration. The user interface is based on shell scripts and a configuration utility that will store configuration information in flash. The web interface also uses this utility to store information through boot cycles.

Default

File

2.1 Factory

The file /etc/ath/apcfg contains the “factory default” information for the AP. This is the data that is used to configure

the device in the absence of other configuration information. If the configuration information is erased, this data will

repopulate the configuration information files. The default values included in this file can be changed if the user so

desires.

Tool

2.2 Configuration

The purpose of the cgiMain utility is to provide a small program size mechanism for managing environmental configuration information in as efficient manner as possible. Major consideration has been applied to small footprint

environments, where JFFS2 filesystem space is at a premium. Further, if no configuration information needs to be

changed in the JFFS2 filesystem, the cramfs can be used to further reduce the flash footprint of the overall system.

2.2.1 Design

The main design intent was to provide a busybox like environment that can be used as a CGI program for getting

environmental information, and further providing output formatting that will make the web pages easily configurable,

but dynamic. This was done in lieu of other larger implementations, such as PHP or Python, simply for the smaller size

requirement, and the customization required to use flash resources effectively.

The main engine will receive an input file and “translate” it, changing specially tagged parameters into their equivalent

values. For example, let’s say that we have an environmental variable called AP_SSID, whose value is AP24. Further,

let’s say we have a configuration file that has a line in the file of the form

ssid=.

We can put a tagged reference to the environmental variable in the configuration file, and then “translate” it to a scratch

file:

Original file: ssid=~~AP_SSID~

Translated file: ssid=AP24

The translated file can be written to /tmp (ram disk), thus not requiring any more flash space to support the translation.

A typical command line to implement this would be

# cgiMain –t2 /etc/ath/PSK.ap_bss > /tmp/vap2sec.bss

Where /etc/ath/PSK.ap_bss is the file containing the tags, and /tmp/vap0sec.bss is the file containing the translated

version with tags replaced with values.

2.2.1.1 Variable

Names

All tags work with the names of environmental variables. These are passed either through the CGI interface when doing HTML pages, and/or read from the stored environmental data. There are two types of variable names used by the program:

Fixed Names:The standard name with no additions, like AP_SSID

Indexed Names:When variables are indexed by instance, they will typically have an extension, such as

AP_SSID_2. The indexed names are expressed as AP_SSID#, where the # is replaced by the

index as specified in the –t (translate) option

All variable names fall within these two categories. Indexed names can be used in any tag value

2.2.1.2 File

Tags

The used tag types are designed to support two main efforts. First, they will allow an HTML page to be created with tagged information that will be translated through the CGI interface. Secondly, in a command line format, it can be used to manage the values stored in the flash/cache areas, allowing the user to have either temporary or permanent parameter storage. Table 1 defines the available tags.

Table 1 Available File Tags

Tag Usage Example

~~VAR_NAME~ ~~VAR_NAME#~ Direct replacement of the environmental

variable with its value. Variable must

exist to produce a value. If the value does

not exist, the tag is erased and no

characters are substituted.

~~AP_SSID~

~~AP_SSID#~

~~VAR_NAME:default~ ~~VAR_NAME#:default~ Direct Replacement with Default. If the

variable exists, then its value is inserted.

If it does not exist, then the “default”

string will be substituted.

~~AP_STARTMODE:dual~

~~AP_CHMODE#:11NAHT20~

~`exec str`~ Execute the program or script enclosed in

` ` markers. The output of these programs

will be processed to be displayable in

HTML format (non breaking spaces will

be added, and tabs translated). Note that

any stderr output is not caught, and

should be piped to /dev/null if to be used

in a web page.

~`athstats 2>/dev/null`~

~cVAR_NAME:VAL~

~cVAR_NAME#:VAL

Used for checkboxes in HTML files

~sVAR_NAME:VAL~

~sVAR_NAME:VAL~

~?VAR_NAME:VAL`exec str`~

~?VAR_NAME#:VAL`exec str`~

Usage

2.2.1.3 Flash

This program seeks to eliminate extra usage of flash resources by using an existing sector for storing date (the calibration sector). Note that the board and radio calibration data only take up the first 32 KB of flash storage, leaving the second

32 KB available. The permanent storage area for parameter data is put into this area without using a filesystem – the

data is simply written to flash as a linear string of data. Parameters are stored in the “NAME=VALUE” format. The first 4 bytes of the data are flagged with a know value (0xfaf30020) as a synchronization value to verify the data is valid (as opposed to an “erased” flash). The data is assumed terminated if a value of 0x0 is found (note that all data is stored as ASCII, and can be read/edited in flash using u-boot).

A limit of 32 characters for variable names, and 64 characters for values are imposed. Adding the “=” and the

terminators, each value has a maximum of 98 characters used. This means that a total number of (32768-4)/98 = 334 parameters can be stored in this area. Since many parameter names and values are much shorter, an estimate of 450-500 parameters is not unreasonable. Note that parameters will only take up the space required, not the full 32/64 byte area.

The following is an example “dump” of the parameter data in flash:

ar7100> md 0xbf668000

bf668000: faf30020 49504144 44523d31 39322e31 ... IPADDR=192.1

bf668010: 36382e31 2e320a49 504d4153 4b3d3235 68.1.2.IPMASK=25

bf668020: 352e3235 352e3235 352e300a 57414e49 5.255.255.0.WANI

bf668030: 503d3139 322e3136 382e322e 310a5741 P=192.168.2.1.WA

bf668040: 4e4d4153 4b3d3235 352e3235 352e3235 NMASK=255.255.25

bf668050: 352e300a 41505f53 5349443d 41503234 5.0.AP_SSID=AP24

bf668060: 5f486f6c 64656e0a 41505f53 5349445f _Holden.AP_SSID_

bf668070: 323d4150 35305f48 6f6c6465 6e0a4150 2=AP50_Holden.AP

bf668080: 5f504153 53504852 4153453d 6672617a _PASSPHRASE=fraz

bf668090: 65310a41 505f5041 53535048 52415345 e1.AP_PASSPHRASE

bf6680a0: 5f323d66 726f7a65 0a5a4849 46454e47 _2=froze.ZHIFENG

bf6680b0: 3d686572 650a0000 0000fbb7 ffc1f6f7 =here...........

File

2.2.1.4 Cache

For temporary changes, a cache file is located in /tmp/.apcfg. This file contains the same type of information that is in the flash, but is not permanent. This is used to perform updates to parameters during a run, but it is not desired to commit these changes to flash. Note that a specific commit operation is required to update the flash area.

2.2.2 Tool Usage

The intended use for this is for both a web server interface, and for script access to permanent variables. Having a single program to perform this function will save on flash space.

2.2.2.1 Web Server Usage

HTML files that define web pages usually contain static content, unless they have embedded java code. In order to get dynamic content (without using something like PHP or java) something is required to modify the pages such that they display the dynamic data as required. This is accomplished by linking the page name to the cgiMain program.

A web server will execute programs/scripts as part of the Computer Gateway Interface (CGI). This allows a program to

be run to generate the web page content as required. This interface is exploited for this function. The Busybox httpd daemon will execute as a CGI program any page that is located in the /usr/www/cgi-bin directory. In order to have separate pages that reference the same program, the same method that Busybox uses is used here. Page names are soft linked to /usr/www/cgi-bin/cgiMain. The cgiMain program uses the argv[0] (the name of the program) to determine which html page to process to produce the web content. This works in the exact same way as the file translation mode of the cgiMain program, changing tagged values into their value strings, or in special cases indicating which parameters have been “set” to specific values.

An example of a tagged HTML page:

  

  

Basic AP Configuration

Bridged 

Routed 

DHCP 

Local IP settings

Local IP Addr

size="20" maxlength="16" value="~~IPADDR~">

Local Netmask

size="20" maxlength="16" value="~~IPMASK~">

Gateway IP

size="20" maxlength="16" value="~~IPGW~">

WAN IP settings

WAN IP Addr

size="20" maxlength="16" value="~~WANIP~">

Local Netmask

size="20" maxlength="16" value="~WANMASK~">

Primary DNS

size="20" maxlength="16" value="~~PRIDNS~">

Secondary DNS

size="20" maxlength="16" value="~~SECDNS~">

Note the embedded tags for the text boxes and the check boxes. This produces the web page:

2.2.2.2 Command Line Usage

The cgiMain program also has command line switches available for use in scripts. This provides convenient access to stored parameter data, and data updated via web pages. In fact, a web page can start a script as part of a CGI interface, where the script executes command line versions of cgiMain within the script to perform various functions.

Note that the cache file takes precedence over the flash contents when executing scripts. This is to allow changes to be made and executed on a temporary basis, and only kept if the desired configuration operates satisfactorily. If you want to discard cache change, they either ALL have to be discarded, or specific parameters removed. See adding, deleting, committing, and invalidating cache.

In order to avoid putting /usr/www/cgi-bin into the execution path, a soft link from /bin/cfg to /usr/www/cgi-bin/cgiMain can be made. All following examples assume the system is configured in this manner. The basic command line format is as follows:

#cfg [option] [option parameter]

2.2.2.2.1 Adding/modifying a variable in the cache file

To add a variable/value pair to the cache, use the following form:

#cfg –a VAR=VALUE

The variable name must not include spaces, and if the value includes spaces they must be “escaped” (\) or the value enclosed in quotes (“val”).

2.2.2.2.2 Deleting (removing) a value from the cache file

To delete a variable/value pair from the cache, use the following form:

#cfg –r VAR

The variable name must not include spaces. If the variable does not exist, no error is generated, but no action is preformed on the cache file. If you remove a variable from the cache file, but do not commit the cache, it will remain in the permanent flash storage and will be defined upon next bootup.

2.2.2.2.3 Committing the cache file to flash

To commit the contents of the cache file to flash, use the following form:

#cfg –c

This copies the entire contents of the cache file to flash. These values will be preserved through boot and power cycles.

2.2.2.2.4 Invalidating the cache file

In order to invalidate the cache file (re-read it from flash), use the following form:

#cfg –i

This re-reads the contents of the flash and overwrites the cache file with the flash values. This effectively eliminates any changes made to the cache file without saving them to flash. Use with caution.

2.2.2.2.5 Translating a file

In order to translate a tagged file into a file with values inserted, use the following form:

#cfg –t

This performs the translation as defined above. Note that the output is put to stdout, so it must be redirected to the desired destination. The index argument on the option indicates the index value to use for variables with the “#” tag. An example of usage:

#cfg –t2 /etc/wpa2/open_bss.ap > /tmp/sec2.cfg

This will translate the file /etc/wpa2/openbss.ap, inserting tags and using the value of “_2” as the substation for “#” tags, and output the file to /tmp/sec2.cfg. The original file is not affected.

variables

2.2.2.2.6 Exporting

In order to use the variables in scripts, they need to be exported. The form for doing this is:

#cfg –e

This will output all variables in the form “export VAR=VALUE” for all variables in the cache. To use this in a script file, you can put the following line in the script:

`cfg –e`

and all variable/value pairs will be in the environment for use.

2.2.2.2.7 Resetting to factory defaults

Resetting to factory defaults is a two step process. First, all current variables must be deleted. This is done by using the –x option as in the following form:

#cfg -x

This deletes everything in cache and in flash. To reset the default values, execute the apcfg script to re-populate the defaults. Note that this will be done by the apup script automatically:

#/etc/ath/apcfg

Variables

2.3 Environmental

All configuration information is stored in the form of environmental variables that can be displayed by the “cfg –e”

command. Error! Reference source not found. outlines the various environmental variables, their default values (if applicable), and their effects.

Table 2 AP Environmental Variable

Variable Default Description

ATH_countrycode Identifies the specific regulatory table to use for the country of

interest. Used for testing regulatory compliance.

address of the LAN interface; typically assigned to the bridge AP_IPADDR 192.168.1.2

IP

The

interface, because the LAN is always included in the br0 bridge

interface with the ath interfaces.

AP_NETMASK 255.255.255.0 Provides the netmask for the LAN/bridge interface; defines the

number of IP address that can be addressed on the local LAN

interface.

Indicates the mode for the WAN.

WAN_MODE bridged

bridged Indicates that the WAN interface is included on br0

static Indicates that the WAN interface is to be given the IP

address specified by WAN_IPADDR

dhcp Indicates that the WAN interface should get its IP

address from the network it is connected to WAN_IPADDR 192.168.2.1 IP address for the WAN

WAN_NETMASK 255.255.255.0 Netmask

PRIDNS Primary DNS server IP address

SECDNS Secondary DNS server IP address

WLAN_ON_BOOT N Indicates that the WLAN should be activated as part of the rcS script

on bootup. Only valid with the default parameters specified in the

apcfg file. This will be more useful with future enhancements.

Mode for apup execution. standard Creates a single AP

rootap Creates a single WDS mode AP client Creates a single WDS station instance.

repeater Creates a WDS repeater containing an AP and client multi Creates a multiple VAP configuration multivlan Puts each VAP on a desired VLAN interface

AP_STARTMODE standard

dual

On platforms capable of dual concurrent operations set

VAP0 to 2.4 GHz on radio 0, and VAP1 to 5.0 GHz band on radio 1

AP_RADIO_ID# 0 1 For dual concurrent devices, the radio ID (0 for the “lower” slot, and

1 for the “upper” slot) must be identified for each VAP. When dual

concurrent mode (as opposed to multi mode) is selected, the radio ID of the first VAP (ath0) is set to 0 and the second VAP (ath1) is set to 1. In the following entries the radio parameters with the _2 suffix refer to settings for Radio 1 (the “second” radio). For each VAP, the “mode” of the AP is required. The mode is used

to initialize the VAP. The following are the available modes:

ap Infrastructure access point

sta Simple station VAP (not normally used alone) ap-wds WDS (4 address frame) format interface that WDS stations can connect to. See ROOTAP_MAC. AP_MODE# ap sta-wds

Client WDS interface that connects to an Infrastructure WDS interface, creating a WDS bridge between the two devices. Also see ROOTAP_MAC.

AP_PRIMARY_CH AP_PRIMARH_CH_2 6 40

Indicates the specific channel to set the AP to. Setting to a value of “11ng” will cause the AP to scan for a free 11g (2.4 GHz) channel. A value of “11na” will cause the AP to scan for a free 11a (5 GHz) channel, and a value of “11ng” will scan for a free 11g (2.4 GHz) channel. Note that the selected channel should match the extension channel (PLUS or MINUS) mode appropriate for the selected channel/regulatory mode.

AP_CHMODE AP_CHMODE_2 11NGHT20 11NAHT40PLUS

Specifies the channel operating mode. See Table 7 Channel Operating Modes

and section 3.1.3 for details.

ROOTAP_MAC

This is used for clients, and will set the preferred MAC address for the repeater client to associate to. In WDS mode, this is provided to the client device, and is the MAC address of the WDS VAP on the root AP device.

AP_VLAN#

For each VAP that is associated to a VLAN, this parameter identifies the VLAN ID for the VAP.

AP_BRNAME When assigning a VLAN to a VAP, a bridge instance is created for the VLAN. This identifies the “name” of the bridge.

TXQUEUELEN 1000 Provides the number of transmit descriptors to be allocated for the ath object. These are shared for all VAPs SHORTGI SHORTGI_2 1 Enables the short gating interval.

AMPDUENABLE AMPDUENABLE_2 1 Enables AMPDU aggregation; applies to all VAPs attached to the radio.

AMPDUFRAMES AMPDUFRAMES_2 32 Maximum number of frames to include in the aggregated frame. Applies to all VAPs attached to the radio.

AMPDULIMIT AMPDULIMIT_2 50000 Number of bytes for the maximum size of the AMPDU packet. AMPDUMIN AMPDUMIN_2 32768 Minimum number of bytes to include in an AMPDU frame. Setting for channel width management.

0 HT20 only 1 HT20/40 CWMMODE CWMMODE_2

1

2 HT40 only

Specifies if rate control is to be controlled automatically through the rate control module.

auto Automatic rate control

RATECTL auto manual

Manually set the rates and retry limits

MANRATE 0x8c8c8c8c This 32 bit hex number encodes the 4 rate table entries that are tried on the link. This if manual rate control is enabled.

MANRETRIES 0x04040404

Number of retries on each rate interval to attempt before changing. Only applicable if manual rate control

RX_CHAINMASK RX_CHAINMASK_2

5 for 3 chain device 3 for 2 chain device Selects the chain mask to apply to the Receive path. The lowest 3 bits indicate the three antenna chains. This is for a “by 2”

configuration. This setting will override the setting in the EEPROM of the device. TX_CHAINMASK TX_CHAINMASK_2

5 for 3 chain device 3 for 2 chain device Selects the chain mask to apply to the Transmit path. The lowest 3 bits indicate the transmit chains to include. This is for a “2 by”

configuration. . This setting will override the setting in the EEPROM of the device.

AP_SSID# Atheros_Xspan_2G Atheros_Xspan_5G For the single VAP configurations, or the repeater case, only

AP_SSID is used. Default setting is as indicated.

For multiple VAP configurations, specifies the SSID for each VAP instance (AP_SSID is VAP 1). If any of the variables are not defined, the associated VAP will not be created. The AP_SSID_x variables should be defined in order. If AP_SSID_2 is not defined, AP_SSID_3 should not be defined. For example, if you are creating 3 VAPs, do not define AP_SSID_4. If you are only creating two VAPs, do not define AP_SSID_3 and AP_SSID_4. AP_SECMODE#

NONE

Selects the security mode for the indicated VAP. One of “WEP”, “WPA”, “WSC”, or “NONE”

AP_SECFILE# Indicates which security configuration file to use for the VAP. See

section 2.1for a description of the configuration files.

AP_VLAN# Used to configure VLAN tags for SSIDs AP_SSID, AP_SSID_2,

AP_SSID_3 and AP_SSID_4 respectively. To configure VLANs.

AP_STARTMODE should be set to multivlan. No default values

are assumed for these configuration items.

WEPKEY_1 WEPKEY_2 WEPKEY_3 WEPKEY_4 These are the 4 WEP keys that are defined in the first 4 slots. Note that they are the same for ALL VAPs. The length of the key indicates the strength of the cipher (10 hex digits or 4 characters for 64 bit, 26 hex digits or 13 characters for 128 bit). To indicate ASCII entry, prepend “s:” to the string

AP_PRIKEY Primary WEP key to use.

AP_WPA# WPA mode. This indicates if WPA-1 or WPA-2 (or both) are to be

used in WPA operations.

AP_CYPHER# Which pairwise ciphers to use for WPA operations. CCMP is AES

encryption where TKIP is WEP. Specifying both indicates auto

selection based on the client.

PSK_KEY# A 9 to 64 bit value used for the PSK generation. This is an ASCII

value.

PSK_KEY_HEX# A 9 to 64 bit value used for the PSK generation. This is an ASCII

value.

AP_AUTH_SVR# IP address of the Radius server used for EAP authentication

methods.

AP_AUTH_PORT# Port number on the Radius server used for EAP authentication login AP_AUTH_SECRET# Password for logging onto the EAP server for authentication.

WSC_PIN In WSC mode, the PIN number used by the client to authenticate

with the WSC server.

WSC_NAME Simple network name for the AP in WSC mode.

Interface

2.4 Web

The Atheros AP reference design includes a simplified web interface that can be used to configure the AP in various modes. These pages provide both configuration and status information. All pages are processed using the cgiMain program described in section 2.2. Each of these pages contains related information that can be used to configure the AP.

Note that default values are automatically provided to the web interface. These defaults are encoded in the /etc/ath/apcfg file, and can be modified as required for a particular implementation

Each web page has the buttons:

Update This button accepts the changes on the current page. If the current page is switched, the

updates are NOT saved, so click update if you want to save what you changed on the page.

Reboot This button will reboot the AP. This performs a quick reboot, without closing any open files.

Use with care.

Commit This

commits the parameters in the parameter cache (/tmp/.apcfg) to the flash area.

button

This saves the parameters through reboot cycles.

Start This starts the AP using the /etc/ath/apup script. This script reads configuration information

from flash/cache, and applies the parameters using the sub-scripts described in the following

sections.

Stop This brings the AP driver and hostapd software down using the /etc/ath/apdown script. This

performs a graceful shutdown of the AP.

In addition, the main network page includes a “factory reset” button that reapplies the parameters encoded in the /etc/ath/apcfg file.

2.4.1 Network Page

The network page is the default initial page, and provides for general network settings. The network page is shown in Figure 3.

Figure 3 Network Configuration Page

The parameters on this page allow the user to set specific environmental variables with a “point and click” interface:

Table 3 Network Configuration: Page Parameters

Parameter Env Var Description

Bridge Mode WAN_MODE Selects the bridge mode. Bridged means that the WLAN, WAN, and LAN interfaces are all

bridged together, and use the Local IP Addr as the IP address of the device. DHCP means

that the WAN IP address will be set via DHCP. Static means that the WAN interface will use

the IP address and mask specified under WAN IP Settings

Startup Mode AP_STARTMODE Sets the startup mode that the scripts use to initialize the AP. The modes are described in the

parameter description for AP_STARTMODE

LocalIP addr AP_IPADDR This is the IP address used for bridged mode, or it’s the IP address on the LAN interface in

DHCP mode

Local Netmask AP_NETMASK Network mask for the LAN network.

Gateway IP IPGW IP address for the network gateway for Bridged mode, or the gateway on the WAN link for

DHCP mode.

WAN IP Addr WAN_IPADDR IP address for the WAN interface when static mode is used

WAN Netmask WAN_NETMASK Netmask of the WAN interface when static mode is used

Primary DNS PRIDNS Primary DNS server on the WAN interface

Secondary DNS SECDNS Secondary DNS server on the WAN interface

常用无线射频芯片

常用无线射频芯片 TYYGROUP system office room 【TYYUA16H-TYY-TYYYUA8Q8-

常用无线射频芯片目录 CC1000PWR 超低功率射频收发器 CC1010PAGR 射频收发器和微控制器 CC1020RSSR 射频收发器 CC1021RSSR 射频收发器 CC1050PWR 超低功率射频发送器 CC1070RSQR 射频发送器 CC1100RTKR 多通道射频收发器 CC1101RTKR 低于1GHz射频收发器 CC1110F16RSPR 射频收发片上系统 CC1110F32RSPR 射频收发片上系统 CC1110F8RSPR 射频收发片上系统 CC1111F16RSPR 射频收发片上系统 CC1111F32RSPR 射频收发片上系统 CC1111F8RSPR 射频收发片上系统 CC1150RSTR 多通道射频发送器 CC2400RSUR 多通道射频发送器 CC2420RTCR 射频收发器 CC2420ZRTCR 射频收发器 CC2430F128RTCR ZigBee?芯片 CC2430ZF128RTCR ZigBee?芯片 CC2431RTCR 无线传感器网络芯片 CC2431ZRTCR 无线传感器网络芯片 CC2480A1RTCR 处理器 CC2500RTKR 射频收发器 CC2510F16RSPR 无线电收发器 CC2510F32RSPR 无线电收发器 CC2510F8RSPR 无线电收发器 CC2511F16RSPR 无线电收发器 CC2511F32RSPR 无线电收发器 CC2511F8RSPR 无线电收发器 CC2520RHDR 射频收发器 CC2530F128RHAR 射频收发器 CC2530F256RHAR 射频收发器 CC2530F64RHAR 射频收发器 CC2550RSTR 发送器 CC2590RGVR 射频前端芯片 CC2591RGVR 射频前端芯片 CCZACC06A1RTCR ZigBee芯片 TRF7900APWR 27MHz双路接收器 TRF6900APT 射频收发器 TRF6901PTG4 射频收发器

驱动桥的工作原理

驱动桥的工作原理 驱动桥处于动力传动系的末端,其基本功能有如下三个方面: 1、增大由传动轴或变速器传来的转矩,并将动力传到驱动轮,产生牵引力。 2、通过差速器将动力合理的分配给左、右驱动轮,使左右驱动轮有合理的转速 差,使汽车在不同路况下行驶。 3、承受作用于路面和车架或车身之间的垂直力、纵向力和横向力。 驱动桥的组成: 驱动桥一般由主减速器、差速器、车轮传动装置和驱动桥壳等组成。 1-后桥壳;2-差速器壳;3-差速器行星齿轮;4-差速器半轴齿轮;5-半轴;6-主减速器从动齿轮;7-主减速器主动锥齿轮 对一些载重较大的载重汽车,要求较大的减速比,用单级主减速器传动,则从动齿轮的直径就必须增大,会影响驱动桥的离地间隙,所以采用两次减速。通常称为双级减速器。双级减速器有两组减速齿轮,实现两次减速增扭。 A、在主减速器内完成双级减速 为提高锥形齿轮副的啮合平稳性和强度,第一级减速齿轮副是螺旋锥齿轮。二级齿轮副是斜齿圆柱齿轮。 主动圆锥齿轮旋转,带动从动圆银齿轮旋转,从而完成一级减速。第二级减速的主动圆柱齿轮与从动圆锥齿轮同轴而一起旋转,并带动从动圆柱齿轮旋转,进行第二级减速。因从动圆柱齿轮安装于差速器外壳上,所以,当从动圆柱齿轮转动时,通过差速器和半轴即驱动车轮转动 B、轮边减速: 将二级减速器设计在轮毂中,其结构是半轴的末端是小直径的外齿轮,周围有一组行星齿轮(一般5个),轮毂内有齿包围这组行星齿轮,以达到减速驱动的目的。 优点: a、由于半轴在轮边减速器之前,所承受扭矩减小,减速性能更好(驱动力加大); b、半轴、差速器等尺寸减小,车辆通过性能大大提高。 缺点: a、结构复杂,成本增加。 b、载质量大、平顺性小(故只用于重型车)。

最详细解读射频芯片

最详细解读射频芯片 传统来说,一部可支持打电话、发短信、网络服务、APP应用的手机,一般包含五个部分部分:射频部分、基带部分、电源管理、外设、软件。 射频部分:一般是信息发送和接收的部分; 基带部分:一般是信息处理的部分; 电源管理:一般是节电的部分,由于手机是能源有限的设备,所以电源管理十分重要; 外设:一般包括LCD,键盘,机壳等; 软件:一般包括系统、驱动、中间件、应用。 在手机终端中,最重要的核心就是射频芯片和基带芯片。射频芯片负责射频收发、频率合成、功率放大;基带芯片负责信号处理和协议处理。那么射频芯片和基带芯片是什么关系? 1. 射频芯片和基带芯片的关系 先讲一下历史,射频(Radio Frenquency)和基带(Base Band)皆来自英文直译。其中射频最早的应用就是Radio——无线广播(FM/AM),迄今为止这仍是射频技术乃至无线电领域最经典的应用。 基带则是band中心点在0Hz的信号,所以基带就是最基础的信号。有人也把基带叫做“未调制信号”,曾经这个概念是对的,例如AM为调制信号(无需调制,接收后即可通过发声元器件读取内容)。 但对于现代通信领域而言,基带信号通常都是指经过数字调制的,频谱中心点在0Hz的信号。而且没有明确的概念表明基带必须是模拟或者数字的,这完全看具体的实现机制。 言归正传,基带芯片可以认为是包括调制解调器,但不止于调制解调器,还包括信道编解码、信源编解码,以及一些信令处理。而射频芯片,则可看做是最简单的基带调制信号的上变频和下变频。 所谓调制,就是把需要传输的信号,通过一定的规则调制到载波上面让后通过无线收发器(RF Transceiver)发送出去的工程,解调就是相反的过程。 2.工作原理与电路分析 射频简称RF射频就是射频电流,是一种高频交流变化电磁波,为是Radio Frequency的缩写,表示可以辐射到空间的电磁频率,频率范围在300KHz~300GHz之间。每秒变化小于1000次的交流电称为低频电流,大于10000次的称为高频电流,而射频就是这样一种高频电流。高频(大于10K);射频(300K-300G)是高频的较高频段;微波频段(300M-300G)又是射频的较高频段。射频技术在无线通信领域中被广泛使用,有线电视系统就是采用射频传输方式。

各种无线网卡测评

各种无线网卡测评作者:石小田 组合:1、瑞银+网件WG111V2(100元),瑞银上网,网件研究学习,绝配啊 2、瑞银+760N(100元),瑞银专门蹭网 760专门破解 3、萨基姆WLS5061S+ 760N,上网用WLS5061S,研究学习用760N, 关键是这个组合价格低 研究学习首选卡王,噌网首选瑞银,网上洋垃圾WG111V2体质差异很大,不建议购买 1、卡皇(180元) 如果对价钱不大在意,又要破解又追求最高性能那选择卡皇。 2、卡王(380元) 你如果想研究学习顺利,而且金钱充足,那么卡王是首先,卡王的灵敏度也比较高,在BT3下可以搜索到较多的AP信号。此卡最适合研究学习,相比其他网卡对信号要求低,此可以说是天生就是为研究学习而存在的。抛开研究学习强的优点,卡王只能在神卡一类。 3、瑞银UR054G(芯片GW3887 R01)V1.1 (42元) 瑞银毋庸置疑,是块“噌网”首选卡,信号灵敏、稳定!无法研究学习是软肋,不然价格肯定卖150+,只比380的卡王性能低了一点点 瑞银的灵敏度可以说是目前usb卡里面最好的,同样地方比其他无线网卡和路由多搜索不少信号,并且连接稳定,虽说其他卡搜索不到的信号,瑞银不一定能连接,总归多搜索信号心里踏实点,不加天线的瑞银偶尔会出现虚信号情况,加了SMA接头外接一个定向天线的话,基本能看到的信号1格左右都能连接。瑞银如果用3321版本的驱动,则可以在win下面用winaircrack抓包研究学习。此卡可谓价廉物美,价格42元左右。 在XP下比瑞银的信号显示低,但链接很稳定,发热量低,网件信号也不错。 瑞银使用感觉一斑斑,信号比760N好很多,连接质量没760N好。要-85样才能稳定连接。2格信号,才能有好的表现。

无线网卡芯片性能分析与比较

无线网卡芯片性能分析与比较 无线终端的进入门槛越来越低,市场上公版方案外加一个壳就能DIY。除了做工对产品有影响外,成品性能很大程度上依赖于所采用的方案。因此,只要了解产品所采用的芯片,整机性能就能掌握个大概。 目前市场上主流无线芯片厂商有Intel(英特尔)、Ralink(雷凌)、Realtek(瑞昱)、Atheros(创锐讯通)、Broadcom(博通)等,其中外置无线网卡市场采用Ralink、Realtek 的芯片比较多;Atheros、Broadcom、Intel三家主要耕耘于笔记本电脑内置无线网卡市场。 Ralink最出名的芯片当属RaLink 3070系列,其中有3070L和3070两个版本,都支持

802.11b/g/n。3070可支持300Mb/s的最大速度,3070L可以看作是3070的降速版,最大速度150Mb/s。Ralink的芯片通常来说品质都比较不错,信号强度好,连接要求低。由于RaLink 3070系列只能做成单功放方案,所以功耗相对较小,辐射强度相对于其他采用多功放方案的芯片要小。而RaLink 5370芯片的特点在于体型小,许多厂商的mini USB无线网卡都是采用这颗芯片。 Realtek作为业界老牌IC芯片厂商在业界享有很高的声誉,其产品分布可谓雅俗共赏,特别在中低端领域口碑颇佳。比较出名的芯片当属Realtek 8187L,其成熟度相当高,虽然Realtek 8187L芯片规格相对落后,但可以做成多功放方案,网络覆盖能力出色,这是RaLink 3070芯片无法比拟的。Realtek 8187L目前最大支持三功放方案,缺点是功率和辐射相对于单功放芯片就要大得多。 Realtek的另一枚芯片Realtek 8188也比较常见,特点在于支持惠普很多机型。众所周知,惠普和联想ThinkPad系列的笔记本是电脑很挑网卡的,而Realtek 8188则能提供很好的支持。另外Realtek8188也经常用于miniUSB无线网卡上。 因为瑞昱的IC芯片涉及各个领域,比如高清播放、板载声卡等,因此很多只要采用瑞昱芯片的高清播放设备都可以兼容瑞昱无线网卡芯片,兼容性十分出色。 笔记本电脑领域Atheros、Broadcom、Intel三家的无线网卡比较普遍,其中属Intel 的无线网卡兼容性最好。笔记本电脑从迅驰一路走来,Intel的无线网卡一直都是迅驰的标配。要兼容Intel的CPU和芯片组自然选择Intel的无线网卡最好。Intel无线网卡型号从

芯片组介绍

Intel 855PM 芯片组 概述: 英特尔? 855芯片组家族是英特尔? 迅驰? 移动计算技术的组成部分,专门设计用于以较低的功耗提供突破性的性能。英特尔? 855PM 芯片组内存控制器中枢(MCH-M )是一款经过优化的移动式芯片组解决方案,可支持英特尔? 奔腾? M 处理器、高速DDR 内存和到ICH4-M 的中枢接口。该芯片组拥有一个AGP 4X 接口,能够为高性能独立显卡解决方案提供灵活的支持。 系统图表: 英特尔? 855PM 芯片组特性: 特性 优势 400 MHz 低功耗处理器系统总线 支持用于单处理器配置的400 MHz 系统总线 支持高达 2 GB 的 DDR 333/266/200 内存技术 更高的性能和灵活性 集成高速 USB 2.0 支持USB 2.0 外设,可将数据传输速率提高40倍,而且 具有后向兼容能力,支持USB 1.0设备 AGP4X 接口 高带宽接口,可为高性能移动式独立显卡解决方案提供 灵活的支持 英特尔? 稳定映像技术(英特尔? SIPP ) 支持芯片组硬件变化,最大限度降低对IT 软件映像稳定性的影响 支持处理器系统总线与内存的动态输入/输出缓冲禁用 通过智能地激活或关闭处理器系统总线或内存来降低芯片组功耗

相关产品: 处理器英特尔? 奔腾? M 处理器、英特尔? 赛扬? M 处理器芯片组英特尔? 855GM 芯片组、英特尔? 855GME 芯片组 其它产品英特尔? PRO/无线网卡、英特尔? 迅驰? 移动计算技术 封装信息: 产品封装 82855GM (MCH)593针Micro-FCBGA 82801DBM (ICH4-M)421针Micro-FCBGA Intel 855PM参数:

无线收发芯片的比较与选择

无线收发芯片比较与选择 原文日期:2003-10-1原文作者:清华大学摩托罗拉MCU与DSP应用开发研究中心蒋俊峰 收录日期:2005-7-1来源:今日电子 网页快照:https://www.sodocs.net/doc/c912307820.html,/2003/0009/js5.htm 阅读次数:1196次 摘要:本文比较了nRF401、nRF903和CC1000三款无线收发芯片的特性,详细介绍了它们的结构原理、特性及应用电路。 关键词:无线收发芯片;nRF401;nRF903;CC1000 1.前言 目前许多应用领域都采用无线的方式进行数据传输,这些领域涉及小型无线网络、无线抄表、门禁系统、小区传呼、工业数据采集系统、无线遥控系统、无线标签身份识别、非接触RF智能卡等。 由于无线收发芯片的种类和数量比较多,无线收发芯片的选择在设计中是至关重要的,正确的选择可以减小开发难度,缩短开发周期,降低成本,更快地将产品推向市场。选择无线收发芯片时应考虑需要以下几点因素:功耗、发射功率、接收灵敏度、收发芯片所需的外围元件数量、芯片成本、数据传输是否需要进行曼彻斯特编码等。 在本文中笔者就所了解的NRF短距数据通信芯片nRF401、nRF903和CC1000作一个对比描述,给出了它们的结构原理、特性及应用电路。 2. nRF401无线收发芯片 nRF401是Nordic公司研制的单片UHF无线收发芯片,工作在433MHz IS M(Industrial, Scientific and Medical)频段。它采用FSK调制解调技术,抗干扰能力强,并采用PLL频率合成技术,频率稳定性好,发射功率最大可达10dBm,接收灵敏度最大为-105dBm,数据传输速率可达20Kbps,工作电压在+3~5V之间。nRF401无线收发芯片所需外围元件较少,并可直接单片机串口。 nRF401芯片内包含有发射功率放大器(PA)、低噪声接收放大器(LNA)、晶体振荡器(OSC)、锁相环(PLL)、压控振荡器(VCO)、混频器(MIXFR)、解调器(DEM)等电路。在接收模式中,nRF401被配置成传统的外差式接收机,所接收的射频调制的数字信号被低噪声较大器放大,经混频器变换成中频,放大、滤波后进入解调器,解调后变换成数字信号输出(DOUT端)。在发射模式中,数字信号经DIN端输入,经锁相环和压控振荡器处理后进入到发射功率放大器射频输出。由于采用了晶体振荡和PLL合成技木,频率稳定性极好;采用FSK调制和解调,抗干扰能力强。 nRF401的ANT1和ANT2引脚是接收时低噪声接收放大器LNA的输入,以及发送时发射功率放大器P A的输出。连接nRF401的天线可以以差分方式连接到nRF401,一个50Ω的单端天线也可以通过一个差分转换匹配网络连接到nRF401。

PL1167中文资料-2.4GHz无线射频收发芯片资料

PL1167 单片低功耗高性能 2.4GHz 无线射频收发芯片 芯片概述: 主要特点: PL1167是一款工作在 2.4~2.5GHz 世界通用 ISM频 段的单片低功耗高性能 2.4GHz无线射频收发芯片。 ψ 低功耗高性能2.4GHz无线射频收 发芯片 ψ 无线速率:1Mbps 该单芯片无线收发器集成包括:频率综合器、功率放 大器、晶体振荡器、调制解调器等模块。ψ 内置硬件链路层 ψ 内置接收强度检测电路输出功率、信道选择与协议等可以通过 SPI或 I2C接 ψ 支持自动应答及自动重发功能 ψ 内置地址及FEC、CRC校验功能 ψ 极短的信道切换时间,可用于跳频 ψ 使用微带线电感和双层PCB板 ψ 低工作电压:1.9~3.6V 口进行灵活配置。 支持跳频以及接收强度检测等功能,抗干扰性能强, 可以适应各种复杂的环境并达到优异的性能。 内置地址及 FEC、CRC校验功能。 ψ 封装形式:QFN16/TSSOP16 内置自动应答及自动重发功能。 ψ ψ QFN16仅支持SPI接口芯片发射功率最大可以达到 5.5dBm,接收灵敏度可 以达到-88dBm。TSSOP16可支持SPI与I2C接口内置电源管理功能,掉电模式和待机模式下待机电流 可以减小到接近 1uA。 应用: ψ 无线鼠标,键盘,游戏机操纵杆 ψ 无线数据通讯 ψ 无线门禁 管脚分布图: ψ 无线组网 ψ 安防系统 ψ 遥控装置 ψ 遥感勘测 ψ 智能运动设备 ψ 智能家居 ψ 工业传感器 ψ 工业和商用近距离通信 ψ IP电话,无绳电话 ψ 玩具

1概要 性能强,可以适应各种复杂的环境并达到优异的 性能。 PL1167 是一款工作在 2.4~2.5GHz 世界通 用 ISM 频段的单片低功耗高性能 2.4GHz 无线射 频收发芯片。 内置地址及 FEC 、CRC 校验功能。 该单芯片无线收发器集成包括:频率综合器、 功率放大器、晶体振荡器、调制解调器等模块。 内置自动应答及自动重发功能。 芯片发射功率最大可以达到 5.5dBm ,接收 灵敏度可以达到-88dBm 。 输出功率、信道选择与协议等可以通过 SPI 或 I2C 接口进行灵活配置。 内置电源管理功能,掉电模式和待机模式下 待机电流可以减小到接近 1uA 。 支持跳频以及接收强度检测等功能,抗干扰 2特性 ζ 低功耗高性能2.4GHz 无线射频收发芯片 ζ 无线速率:1Mbps ζ 极短的信道切换时间,可用于跳频 ζ 使用微带线电感和双层PCB 板 ζ 低工作电压:1.9~3.6V ζ 内置硬件链路层 ζ 内置接收强度检测电路 ζ 封装形式:QFN16/TSSOP16 ζ 支持自动应答及自动重发功能 ζ 内置地址及FEC 、CRC 校验功能 ζ ζ QFN16仅支持SPI 接口 TSSOP16可支持SPI 与I2C 接口 3快速参考数据 参数 数值 单位 最低工作电压 最大发射功率 数据传输速率 发射模式功耗@0dBm 接收模式功耗 工作温度范围 接收灵敏度 1.9 V dBm Mbps mA 5.5 1 16 17 -40 to +85 -88 mA ℃ dBm uA 掉电模式功耗 1

短距离无线通讯(芯片)技术概述

短距离无线通讯(芯片)技术概述 一、各种短距离无线通信使用范围与特性比较 无线化是控制领域发展的趋势,尤其是工作于ISM频段的短距离无线通信得到了广泛的应用,各种短距离无线通信都有各自合适的使用范围,本文简介几种常见的无线通讯技术。 关键字:短距离无线通信,红外技术,蓝牙技术,802.11b,无线收发 工业应用中,现阶段基本上都是以有线的方式进行连接,实现各种控制功能。各种总线技术,局域网技术等有线网络的使用的确给人们的生产和生活带来了便利,改变了我们的生活,对社会的发展起到了极大的推动作用。有线网络速度快,数据流量大,可靠性强,对于基本固定的设备来说无疑是比较理想的选择,的确在实际应用中也达到了比较满意的效果。但随着射频技术、集成电路技术的发展,无线通信功能的实现越来越容易,数据传输速度也越来越快,并且逐渐达到可以和有线网络相媲美的水平。而同时有线网络布线麻烦,线路故障难以检查,设备重新布局就要重新布线,且不能随意移动等缺点越发突出。在向往自由和希望随时随地进行通信的今天,人们把目光转向了无线通信方式,尤其是一些机动性要求较强的设备,或人们不方便随时到达现场的条件下。因此出现一些典型的无线应用,如:无线智能家居,无线抄表,无线点菜,无线数据

采集,无线设备管理和监控,汽车仪表数据的无线读取等等。1.几种无线通信方式的简介 生产和生活中的控制应用往往是限定到一定地域范围内,比如:主机设备和周边设备的互联互通,智能家居房间内的电器控制,餐厅或饭店内的无线点菜系统,厂房内生产设备的管理和监控等0~200米的范围内,本文着重探讨短距离无线通信实用技术,主要有:红外技术,蓝牙技术,802.11b无线局域网标准技术,微功率短距离无线通信技术,现简介如下: 1.1 红外技术 红外通信技术采用人眼看不到的红外光传输信息,是使用最广泛的无线技术,它利用红外光的通断表示计算机中的0-1逻辑,通常有效作用半径2米,发射角一般不超过20度,传统速度可达4 Mbit/s,1995年IrDA(InfraRed Data Association)将通信速率扩展到的高达16Mbit/s ,红外技术采用点到点的连接方式,具有方向性,数据传输干扰少,速度快,保密性强,价格便宜,因此广泛应用于各种遥控器,笔记本电脑,PDA,移动电话等移动设备,但红外技术只限于两台设备通讯,无法灵活构成网络,而且红外技术只是一种视距传输技术,传输数据时两个设备之间不能有阻挡物,有效距离小,且无法用于边移动边使用的设备。 1.2 蓝牙技术 蓝牙技术是一种短距离无线通信技术,它采用无线电射频技术实现设备之间的无线互连,有穿透能力,能够全方位传送,主要面对

Zigbee技术主流芯片比较 2概况

Zigbee技术主流芯片调研 1、Zigbee芯片调研 当今市场已有大量集成Zigbee协议和射频电路的芯片。以下是市场上主流的生成Zigbee的公司及其生产的典型Zigbee芯片。 公司TI FREESCALE ATMEL Nordic 芯片CC2530 MC1321 AT86RF230 nRF24E1/nRF9E5 MCU内核8051 HCS08 无(通过SPI接口由外 接MCU连接) 8051 通过在淘宝上的调查,TI公司的CC2530和FREESCALE的MC1321用户量比较大,有大量的公司提供基于这两款芯片的Zigbee模块,使用这些模块可以减少大量的硬件调试工作,而较容易的实现我们所需的传输功能。以下就这两类主流芯片进行详细介绍。 1.1 CC2530调研 CC2530是市场最主流的Zigbee芯片,TI公司推出的ZIGBEE网络处理器,将复杂的ZIGBEE网络协议栈,处理成了简单的用户接口命令,用户只要使用任何简单的单片机(微控制器),就可以容易的实现对ZIGBEE网络的控制;TI推出这个芯片的目的,就是希望ZIGBEE容易被使用。CC2530是TI公司推出的最新一代ZigBee标准芯片,适用于2.4GHz、IEEE802.15.4、ZigBee和 RF4CE应用。 CC2530包括了极好性能的一流RF收发器,工业标准增强性8051MCU,系统中可编程的闪存,8KB RAM以及许多其它功能强大的特性,可广泛应用在2.4-GHzIEEE802.15.4系统,RF4CE遥控制系统,ZigBee系统,家庭/建筑物自动化,照明系统,工业控制和监视,低功耗无线传感器网络,消费类电子和卫生保健。主要参数如下:

驱动桥的拆装实验报告

驱动桥的拆装 一、实训目的 1、掌握主减速器与差速器的功用、构造和工作原理 2、熟悉主减速器与差速器的拆装顺序,以及一些相关的检测与维修知识 二、实验原理 根据驱动桥的种类、结构特点、工作原理和组成部分,以及主减速器与差速器的结构特点、工作原理和组成部分,进行驱动桥总成的分拆装实训。 三、设备和实训用具 1、驱动桥总成1个(非断开式驱动桥) 2、工作台架1个 3、常用、专用工具全套 4、各式量具全套 四、实验步骤 1、用专用工具从驱动桥壳中拉下左、右两边 半轴主减速器 2、松下主减速器紧固螺栓,卸下主减速器总成 3、松开差速器支撑轴承的轴承盖紧固螺栓,卸下轴承盖,并做好记号 4、卸下支撑轴承,并做好标记,以及分解出差速器总成 5、从主减速器壳中,拉出主减速器双曲面主动齿轮(可视需要进行分拆装) 6、分解差速器总成,直接卸下一边半轴锥齿轮,接着卸下行星齿轮,以及另一边半轴锥齿轮 7、观察各零部件之间的结合关系,以及其工作原理

8、装配顺序与上述顺序相反

五、注意事项 1、拆卸差速器轴承盖时,应做好左、右两边轴承盖的相应标记 2、驱动桥为质量大部件,需小心操作,必要时用吊装,切忌勿站在吊装底下 3、严格按照技术要求及装配标记进行装合,防止破坏装配精度,如差速器及盖、调整垫片、传动轴等部位。行星齿轮止推垫片不得随意更换 4、差速器轴承的预紧度要按标准调整 5、差速器侧盖与变速器壳体的接合面装复时要涂密封 6、侧盖固定螺栓要按规定的扭矩拧紧 7、从动锥齿轮的固定螺栓应按规定的扭矩拧紧 &差速器轴承装配时可用压床压入 六、实验结果与分析 1、驱动桥的动力传递路线: 从万向传动轴到主减速器小齿轮,到从动锥齿轮,差速器壳T十字轴T行星齿轮T半轴齿轮T左右半轴。 2、主减速器、差速器等的支撑方式,及轴承预紧度调整: (1)主动锥齿轮与轴制成一体,主动轴前端支承在相互贴近而小端相向的两个圆锥滚子轴承上,后端支承在圆柱滚子轴承上,形成跨置式支承。其轴承预紧度可通过相对两个锥齿轮中加减垫片进行调整。 (2)从动锥齿轮连接在差速器壳上,而差速器壳则用两个圆锥滚子轴承支承在主减速器壳的座孔中。 (3)在从动锥齿轮背面,装有支承螺栓,以限制从动锥齿轮过度变形而影响齿轮的正常工作。装配时,一般支承螺栓与从动锥齿轮端面之间的间隙为0.3~0.5mm。 3、齿轮啮合间隙调整方法:

常用无线射频芯片

常用无线射频芯片集团档案编码:[YTTR-YTPT28-YTNTL98-UYTYNN08]

常用无线射频芯片目录 CC1000PWR 超低功率射频收发器 CC1010PAGR 射频收发器和微控制器 CC1020RSSR 射频收发器 CC1021RSSR 射频收发器 CC1050PWR 超低功率射频发送器 CC1070RSQR 射频发送器 CC1100RTKR 多通道射频收发器 CC1101RTKR 低于1GHz射频收发器 CC1110F16RSPR 射频收发片上系统 CC1110F32RSPR 射频收发片上系统 CC1110F8RSPR 射频收发片上系统 CC1111F16RSPR 射频收发片上系统 CC1111F32RSPR 射频收发片上系统 CC1111F8RSPR 射频收发片上系统 CC1150RSTR 多通道射频发送器 CC2400RSUR 多通道射频发送器 CC2420RTCR 射频收发器 CC2420ZRTCR 射频收发器 CC2430F128RTCR ZigBee芯片 CC2430ZF128RTCR ZigBee芯片 CC2431RTCR 无线传感器网络芯片 CC2431ZRTCR 无线传感器网络芯片 CC2480A1RTCR 处理器 CC2500RTKR 射频收发器 CC2510F16RSPR 无线电收发器 CC2510F32RSPR 无线电收发器 CC2510F8RSPR 无线电收发器 CC2511F16RSPR 无线电收发器 CC2511F32RSPR 无线电收发器 CC2511F8RSPR 无线电收发器 CC2520RHDR 射频收发器 CC2530F128RHAR 射频收发器 CC2530F256RHAR 射频收发器 CC2530F64RHAR 射频收发器 CC2550RSTR 发送器 CC2590RGVR 射频前端芯片 CC2591RGVR 射频前端芯片 CCZACC06A1RTCR ZigBee芯片 TRF7900APWR 27MHz双路接收器 TRF6900APT 射频收发器 TRF6901PTG4 射频收发器 TRF6901PTRG4 射频收发器

市场上的主流WiFi芯片组或模块调研报告

市场上的主流WiFi芯片组或模块调研报告

2014年3月 By Cym 目录 TI新型WIFI芯片 (1) MARVELL WIFI 芯片组 (10) 博通 (15) 高通 (17) MTK 单芯片WIFI SOC MT7688/MT7681 为智能家居而设 (18) 嵌入式WIFI模块TLN13UA06 (21) HF-A11嵌入式WIFI 模组(利尔达科技) (22) 嵌入式微控芯片RT5350 (23)

物联网应用的蓬勃发展也带来了新一轮的无线通信技术商机,越来越多的芯片(如处理器和微控制器MCU)厂商开始厉兵秣马,加快了WiFi/BT/ZigBee等技术的研发,以卡位物联网市场。从2013年至今,整合无线的单芯片MCU、集成MCU和无线功能的模块、整合嵌入式处理器和无线的单芯SOC等产品和方案全线开花。本报告重点针对WIFI无线芯片或模块,对市场上各主流芯片商所推出的主打的或最新的芯片进行比较。 TI新型WiFi芯片 日前,仪器(TI)宣布推出其面向物联网(IoT)应用的新型SimpleLink WiFi CC3100和CC3200平台。这一新型片上互联网系列使得客户能够轻松地为众多的家用、工业和消费类电子产品增添嵌入式WiFi和互联网功能。 该产品系列的特性包括:拥有业界最低的功耗(适用于电池供电式设备),以及低功耗射频和高级低功耗模式;高度的灵活性,可将任何微控制器(MCU)与CC3100解决方案配合使用,或者利用CC3200的集成型可编程ARM Cortex-M4 MCU,从而允许客户添加其特有的代码;可利用快速连接、云支持和片上WiFi、互联网和稳健的安全协议实现针对IoT 的简易型开发,无需具备开发连接型产品的先前经验;能够采用某种手机或平板电脑应用程序或者一种具有多种配置选项简单且安全地将其设备连接至WiFi。 CC3100和CC3200采用QFN封装并具有全集成型射频(RF)及模拟功能电路,因而允许开发人员通过将器件直接布设在PCB上来创建一种低成本、

安装指南_LAFALINK无线网卡

(3)连接完成后会出现连接的无线信号的信息,被连接上的无线信号的前面会打上对勾,如下图所示。电脑上的驱动图标 也会变成绿色的。到这里无线网卡的连接设置就完成了,连接上以后就可以无线上网了。 (1)驱动安装完成后电脑桌面右下角会出现一个 图标,插上网卡后会变成 ,此时,双击该图标,会出现下面的界面。点击左边图片上的“放大镜”图标 搜索无线信号,如右图所示。 1 2.选择“我接受许可证协议中的条款”并点击“下一步” 3.选择“安装驱动程序与ralink无线网络设定程序” 并点击“下一步” 4.选择“Ralink无线网络设定程序”并点击“下一步” 5.点击“安装”开始安装网卡驱动程序 6.点击“完成”结束安装,网卡驱动程序安装就完成了。 简介 系统需求 笔记本或者台式电脑拥有奔腾1GHz以上的处理器 Windows 2000/XP/Vista/win7,MAC OS,Linux 带有高速USB 2.0接口 非常感谢您购买LAFALINK无线网卡,LAFALINK无线网卡,采用优秀的Ralink芯片,是一款高性能,高速率,稳定性好, 接受距离远的无线网卡,让您的笔记本或者台式机电脑连接到家里或者办公室的无线局域网,使您在任何角落都能轻松畅享高速 稳定的无线网络。 1.注意: 为了正确操作,请不要在安装软件之前把无线网卡连接到您的电脑。如果您已这样操作,请等到找到新硬件的画面出现后,点击“取消”,否则安装过程可能受到影响。插入附带的安装CD到光驱里,打开光盘如下图所示,请选择和您电脑相符的操作系统,然后点击 Setup.exe安装 1.软件以及驱动安装 2.网卡无线连接设置(连接可用的无线信号) (2)选择你需要连接的无线信号,双击该信号进行连接,如果该信号有 密码,会出现下图中左下角的部分,连续点击图中的 图标进行连接, 当出现下图中输入密码的部分,请输 入密码并点击 进行连接。

几种常用无线收发芯片性能比较

几种常用无线收发芯片性能比较表 CC400nRF401 Brand Nordic 工作电压2.7—5.25VRF2915BC418XC1201 RFMD 2.4—5.0VBluechip 2.5--- 3.4V 不能直接接单Xemics 2.4—5.5VChipCon 2.7--- 3.3V不能直接接单可以直接接单片不能直接接单片片机串口使 数据可否机串口使用,数机串口使用,数 用,数据需要 直接接单据无需曼彻斯特据需要进行曼彻 进行曼彻斯特 片机串口编码,可直接传斯特编码,效率 编码,效率低 使用输串口数据,效低(实际速率为 (实际速率为

率高标称的1/3)不能直接接单片 片机串口使用,机串口使用,数 数据需要进行据需要进行曼彻 曼彻斯特编码,斯特编码,效率 效率低(实际速低(实际速率为 率为标称的标称的1/3) 标称的1/3)1/3)发射电流 @5dBm9mA17mA45mA10mA91mAoutput 6.8mA+ 接收电流 11mA 433MHz ext.filters 最大输出 +10dBm 功率 <128Kbps(外 部调制) 速率20Kbps9.6Kbps 2.4Kbps(内部 调制)

需要外接112*2*1 64Kbps9.6Kbps+5dBm+12dBm-5dBm+14dBmext.PLL&3 8mA maximum 7.5mA40mA天线的数 量(分别为 收发用) 封装SSOP20LQFP32TQFP44TQFP32 两根天线时约 外围元件 约10个 数量约50个>50个 一根天线时约 35个SSOP2820个 >25个由于无线收发芯片的种类和数量比较多,如何在你的设计中选择你所需要的芯片是非常关键的,正确的选择可以使你少走弯路,降低成本,更快地将你的产品推向市场。下面几点有助于你选择你所需要的产品: 1、收发芯片的数据传输是否需要进行曼彻斯特编码? 采用曼彻斯特编码的芯片,在编程上会需要较高的技巧和经验,需要更多的内存和程序容量,并且曼彻斯特编码大大降低数据传输的效率,一般仅能达到标称速率的1/3。

常用无线射频芯片[优质文档]

常用无线射频芯片目录 CC1000PWR 超低功率射频收发器 CC1010PAGR 射频收发器和微控制器 CC1020RSSR 射频收发器 CC1021RSSR 射频收发器 CC1050PWR 超低功率射频发送器 CC1070RSQR 射频发送器 CC1100RTKR 多通道射频收发器 CC1101RTKR 低于1GHz射频收发器 CC1110F16RSPR 射频收发片上系统 CC1110F32RSPR 射频收发片上系统 CC1110F8RSPR 射频收发片上系统 CC1111F16RSPR 射频收发片上系统 CC1111F32RSPR 射频收发片上系统 CC1111F8RSPR 射频收发片上系统 CC1150RSTR 多通道射频发送器 CC2400RSUR 多通道射频发送器 CC2420RTCR 2.4GHz射频收发器 CC2420ZRTCR 2.4GHz射频收发器 CC2430F128RTCR ZigBee?芯片 CC2430ZF128RTCR ZigBee?芯片 CC2431RTCR 无线传感器网络芯片 CC2431ZRTCR 无线传感器网络芯片 CC2480A1RTCR 2.4GHzZigBee处理器 CC2500RTKR 2.4GHz射频收发器? CC2510F16RSPR 2.4GHz无线电收发器 CC2510F32RSPR 2.4GHz无线电收发器 CC2510F8RSPR 2.4GHz无线电收发器 CC2511F16RSPR 2.4GHz无线电收发器 CC2511F32RSPR 2.4GHz无线电收发器 CC2511F8RSPR 2.4GHz无线电收发器 CC2520RHDR 射频收发器 CC2530F128RHAR 射频收发器 CC2530F256RHAR 射频收发器 CC2530F64RHAR 射频收发器 CC2550RSTR 2.4GHz发送器 CC2590RGVR 2.4GHz射频前端芯片 CC2591RGVR 2.4GHz射频前端芯片 CCZACC06A1RTCR 2.4GHZ ZigBee芯片 TRF7900APWR 27MHz双路接收器 TRF6900APT 射频收发器 TRF6901PTG4 射频收发器 TRF6901PTRG4 射频收发器

wifi模块开发 芯片选型对比

Wifi模块开发调研 本文对几款主流的wifi芯片进行对比,包括TI公司的cc3200,乐鑫的esp8266,联发科的mt7681。通过了解它们的特点和开发环境等方面的需求,选取适用于自己使用的芯片来进行物联网wifi模块的开发。 1CC3200 1.1芯片简介 CC3200是TI无线连接SimpleLink Wi-Fi和物联网(IoT)解决方案最新推出的一款Wi-Fi MCU,是业界第一个具有内置Wi-Fi的MCU,是针对物联网应用、集成高性能ARM Cortex-M4的无线MCU。客户能够使用单个集成电路开发整个应用,借助片上Wi-Fi、互联网和强大的安全协议,无需Wi-Fi经验即可实现快速的开发。CC3200是一个完整平台解决方案,其中包括软件、示例应用、工具、用户和编程指南、参考设计以及TI E2E支持社区。CC3200采用易于布局的四方扁平无引线(QFN)封装。 有人科技的USR-C322模块采用的是TI的CC3200方案,基于ARM Cortex-M4内核,运行频率高达80MHz;超低功耗:低功耗,在网待机低至3.5mA,深度休眠最低25uA;Simplelink 功能:实现一键联入Wi-Fi网络;另外支持自定义网页、websocket、httpd client等功能。 1.2特点 Wi-Fi网络处理器(CC3200)包含一个Wi-Fi片上互联网和一个可完全免除应用MCU处理负担的专用ARM MCU。Wi-Fi片上互联网包含802.11b/g/n射频、基带和具有强大加密引擎的MAC,可以实现支持256位加密的快速安全的互联网连接。Wi-Fi片上互联网还包括嵌入式TCP/IP和TLS/SSL协议栈、HTTP服务器和多种互联网协议。CC3200支持站点、接入点和Wi-Fi直连3种模式,支持WPA2个人和企业安全性以及WPS2。 1.3开发支持 官方提供的SDK包含用于CC3200可编程MCU的驱动程序、40个以上的示例应用以及使用该解决方案所需的文档。它还包含闪存编程器,这是一款命令行工具,用于闪存软件并配置网络和软件参数(SSID、接入点通道、网络配置文件等)、系统文件和用户文件(证书、网页等)。 SDK中所有的应用例程均支持CCS开发环境、并且都是不带操作系统的。当然,也有一些例程基于实时操作系统FreeRTOS和TI RTOS,也有一部分支持IAR、GCC开发环境。因此,此款芯片可以在TI的CCS集成开发环境下开发,可以不涉及操作系统,使开发更简单。

无线、射频收发模块大全

无线收发模块大全 本文中着重通过几种实用的无线收发模块的剖析为你逐步揭开无线收发的原理,应用和结构,希望对你有所裨益! 无线数据传输广泛地运用在车辆监控、遥控、遥测、小型无线网络、无线抄表、门禁系统、小区传呼、工业数据采集系统、无线标签、身份识别、非接触RF智能卡、小型无线数据终端、安全防火系统、无线遥控系统、生物信号采集、水文气象监控、机器人控制、无线232 数据通信、无线485/422数据通信、数字音频、数字图像传输等领域中。

这是DF发射模块,体积:19x19x8毫米,右边是等效的电路原理图 主要技术指标: 1。通讯方式:调幅AM 2。工作频率:315MHZ (可以提供433MHZ,购货时请特别注明) 3。频率稳定度:±75KHZ 4。发射功率:≤500MW 5。静态电流:≤0.1UA 6。发射电流:3~50MA 7。工作电压:DC 3~12V DF数据发射模块的工作频率为315M,采用声表谐振器SAW稳频,频率稳定度极高,当环境温度在-25~+85度之间变化时,频飘仅为3ppm/度。特别适合多发一收无线遥控及数据传输系统。声表谐振器的频率稳定度仅次于晶体,而一般的LC振荡器频率稳定度及一致性较差,即使采用高品质微调电容,温差变化及振动也很难保证已调好的频

点不会发生偏移。 DF发射模块未设编码集成电路,而增加了一只数据调制三极管Q1,这种结构使得它可以方便地和其它固定编码电路、滚动码电路及单片机接口,而不必考虑编码电路的工作电压和输出幅度信号值的大小。比如用PT2262等编码集成电路配接时,直接将它们的数据输出端第17脚接至DF数据模块的输入端即可。 DF数据模块具有较宽的工作电压范围3~12V,当电压变化时发射频率基本不变,和发射模块配套的接收模块无需任何调整就能稳定地接收。当发射电压为3V时,空旷地传输距离约20~50米,发射功率较小,当电压5V时约100~200米,当电压9V时约300~500米,当发射电压为12V时,为最佳工作电压,具有较好的发射效果,发射电流约60毫安,空旷地传输距离700~800米,发射功率约500毫瓦。当电压大于l2V时功耗增大,有效发射功率不再明显提高。这套模块的特点是发射功率比较大,传输距离比较远,比较适合恶劣条件下进行通讯。天线最好选用25厘米长的导线,远距离传输时最好能够竖立起来,因为无线电信号传输时收很多因素的影响,所以一般实用距离只有标称距离的20%甚至更少,这点需要在开发时注意考虑。 DF数据模块采用ASK方式调制,以降低功耗,当数据信号停止时发射电流降为零,数据信号与DF发射模块输入端可以用电阻或者直接连接而不能用电容耦合,否则DF发射模块将不能正常工作。数据电平

主流无线芯片汇总及特点解析

主流无线芯片汇总及特点解析时代需要速度更快、互操作更方便以及更安全可靠的无线网络,Nordic VLSIASA、Freascale、Atmel等具有国际影响力的IC生厂商都相继推出了新一代短距离无线数据通信收发芯片,以nRF905、CC1100 为主流的无线芯片性能得到了很大提高,最新的无线收发芯片将全部无线通信需要的调制/解调芯片、高/低频放大器等全部集成在芯片中,使外围器件大幅度减少,很容易与各种型号微控制器连接实现高可靠性无线通信,使开发无线产品成本大大降低,开发难度更简单,应用更广泛,嵌入式无线通信和无线网络将逐步取代现有的有线通信和有线网络,无线技术将展示其巨大的影响力,必将掀起一场的新的技术浪潮。系列A: 433/868/915MHZ频段 1. NRF905基本特性工作电压:1.9-3.6V 调制方式: GFSK 接收灵敏度:-100dBm 最大发射功率: 10mW (+10dBm) 最大传输数率:50kbps 瞬间最大工作电流: <30mA 工作频率:(422.4-473.5MHZ)1) 接收发送功能合一,收发完成中断标志2) 433/868/915 工作频段,433MHZ 开放ISM 频段免许可使用3) 发射速率50Kbps,选用外置433 天线,空旷通讯距离可达300 米左右,加功放可到3000 米左右;室内通信仍有良好通信效果,3-6层可实现可靠通信,抗干扰性能强,很强的扰障碍穿透性能;4) 每次最多可发送接收32 字节,并可软件设置发送/ 接收缓冲区大小1/2/4/8/16/32 5) 100 多个频道,可满足多点通讯和跳频通讯需求6) 内置硬件 8/16 位CRC 校验,开发更简单,数据传输可靠稳定。 7) 1.9-3.6V 工作,低功耗,待机模式仅2.5uA. 8) 内置SPI 接口,也可通过I/O 口模拟SPI 实现。最高SPI 时钟可达10M。 2. SI4432基本特性1) 完整的FSK 收发器,2) 工作频率范围430.24~439.75MHz;发射功率最大17dBm,接收灵敏度-115 dBm(波特率9.6Kbps);空旷通讯距离800 米左右(波特率9.6Kbps) 3) 工作频率范围900.72~929.27MHz;发射功率最大17dBm;接收灵敏度-115 dBm(波特率9.6Kbp);空旷通讯距离800 米左右(波特率9.6Kbps) 4) 传输速率最大128Kbps 5) FSK 频偏可编程(15~240KHz) 6) 接收带宽可编程(67~400KHz) 7) SPI 兼容的控制接口,低功耗任务周期模式,自带唤醒定时器 8) +20dB,低的接收电流(18.5mA),最大发射功率的电流(73mA) 3. CC1100芯片特性工作电压:1.8-3.6V 接收灵敏度:在1200 波特率下-110dBm 最大发射功率: 10mW (+10dBm) 最大传输数率:500kbps 瞬间最大工作电流: <30mA 工作频率:(387-464MHZ)1)315、433、868、915Mh 的ISM 和SRD 频段2)最高工作速率500kbps,支持2-FSK、GFSK 和MSK 调制方式选用外置433 天线,直线通讯距离可达300 米左右,降低通信波特率距离更远,我公司也提供高精度参数RF1100SE 模块,性能更佳,室内通信仍有良好通信效果,3 层左右可实现可靠通信,抗干扰性能强,很强的扰障碍穿透性能; 3)高灵敏度(1.2kbps 下-110dDm,1%数据包误码率) 4)内置硬件CRC 检错和点对多点通信地址控制5)较低的电流消耗(RX 中,15.6mA,2.4kbps,433MHz) 6)可编程控制的输出功率,对所有的支持频率可达+10dBm 7)支持低功率电磁波激活功能,支持载波侦听系统 8)模块可软件设地址,软件编程非常方便 9)单独的64 字节RX 和TX 数据FIFO 4. CC1020芯片特性1) 频率范围为402 MHz -470MHz 工作2) 高灵敏度(对12.5kHz 信道可达-118dBm) 3) 可编程输出功率,最大10dB m 4) 低电流消耗(RX:19.9mA) 5) 低压供电(2.3V 到3.6V)6) 数据率最高可以达到153.6Kbaud 7) SPI 接口配置内部寄存器8) 比相同功率下,NRF905- CC1100 远1/3 5. A7102基本特性1) 433Mhz 开放ISM 频段免许可证使用2) 最高工作速率50kbps,高效GFSK 调制,抗干扰能力强,适合工业控制场合 3) 125 频道,满足多点通信和跳频通信需要 4) 内置硬件CRC 检错和点对多点通信地址控制 5) 低功耗3-3.6V 工作,待机模式下状态仅为2.5uA 6) 收发模式切换时间 < 650us 7) 模块可软件设地址,只有收到本机地址时才会输出数据(提供中断指示),可直接与各种单片机使用,软件编程非常方便 8)TX Mode: 在+10dBm 情况下,电流为40mA; RX Mode: 14mA 9)增加了电源切断模式,可以实现硬件冷启动功能!10)SPI 接口、功能强大、编程简单,与RF905SE 编程接口类似。11)增加了RSSI 功能,通过SPI 接口可以获取当前接收到的信

相关主题