Patent Grant
8441947
The present patent relates generally to wireless communications and, more particularly, to a device for capturing and analyzing data transmitted via multiple wireless communication channels.
The WirelessHART communication protocol establishes a wireless communication standard for process applications. More particularly, WirelessHART is a secure, wireless mesh networking communication technology operating in the 2.4 GHz ISM radio band. WirelessHART utilizes IEEE STD 802.15.4-2006 2.4 GHz DSSS transceivers with channel hopping on a transaction by transaction basis. WirelessHART communication is arbitrated using time division multiple access (TDMA) to schedule link activity. All communications are performed within a designated slot and one or more sources and one or more destination devices may be scheduled to communicate in a given slot. Thus, a slot may be dedicated to communication from a single source device or a slot may support shared communication access between multiple devices. The message being propagated by the source device on a slot may be addressed to a specific device or may be broadcast to each of the destination devices assigned to the slot.
To be successful, WirelessHART must support interoperability and allow compliant devices from different manufactures to be mixed in the same network to create an integrated system. The HART Communication Foundation (HCF) has always had a strict definition of interoperability. In particular, HCF defines “interoperability” as the ability for like devices from different manufacturers to work together in a system and be substituted one for another without loss of functionality at the host system level.
To attain compliance, the HCF has developed a quality assurance program to ensure the compliance of WirelessHART products. The objective of the WirelessHART quality assurance program is to ensure product adherence to the high standards of interoperability and compatibility defined by the HCF.
Using the network analyzer or radio capture tools available today, an operator may monitor an individual communication channel by tuning a network analyzer to the radio frequency associated with the channel and attempting to capture data packets transmitted via this communication channel. To monitor another communication channel, the operator needs to either adjust the frequency setting of the network analyzer being used, or use another network analyzer. Thus, to monitor multiple channels at the same time, the operator needs to set up and operate several network analyzers. In addition to the inconvenience, high cost, and stringent calibration requirements associated with using multiple network analyzers at the same time, the operator may also generate undesirable interference in the respective antennas of the network analyzers when placing these devices close to each other.
A wireless communication network analyzer for use in, for example, an IEEE 802.11 or 802.15-compliant communication network, includes an acquisition engine to capture and process data packets or other data units transmitted on multiple wireless communication channels, and a user interface to display information related to the data packets and to support channel configuration and selection commands. In some embodiments, the wireless communication network is a WirelessHART network that operates in a process control environment and communicates on IEEE STD 802.15.4-2006 2.4 GHz channels. The acquisition engine includes a radio frequency (RF) interface that can capture communications on multiple radio channels simultaneously and a packet server to receive data packets and related statistics (e.g., Received Signal Level (RSL_, Link Quality Indicator (LQI), Cyclic Redundancy Check (CRC) status) from the RF interface, provide the data packets and the statistics to the local user interface and/or one or more client applications, and control data capture at the RF interface.
The packet server and the user interface may run on a computer host that supports a standard operating system such as, for example, Linux, QNX, or Microsoft® Windows 2000, XP, or Vista. The RF interface may be implemented as a hardware component powered by the computer host via a USB connection interface such as USB 2.0. The same USB connection interface may also support communications between the packet server and the RF interface. In this manner, the acquisition engine may be manufactured using commercial, off-the-shelf hardware.
In some embodiments, the communication network in which the network analyzer operates is compliant with the 2.4 GHz IEEE Standard 802.15.4-2006 (“the Standard”), and the acquisition engine can capture communications on all 16 channels specified by the Standard. The acquisition engine may capture information related to all layers of the protocol stack, i.e., from the preamble and header associated with the lowest physical (“PHY”) layer up to the complete payload of the application layer. In an embodiment, the communication network is a secure mesh WirelessHART network operating in a process control environment. In this embodiment, the network analyzer may perform conformance testing of WirelessHART products in addition to sniffing data packets for the purposes of supervising communications between devices.
In some embodiments, the RF interface includes a single antenna receives a wireless signal that includes all communication channels on which the network analyzer operates, at least one splitter to generate multiple copies of the received signal, and several radio transceivers to process communications on the respective communication channels using the copies of the received signal. Thus, in one operational mode, each radio transceiver is tuned to the frequency of the corresponding communication channel. In another operational mode, all radio transceivers of the RF interface are tuned to the same communication channel to perform reliable diagnostics of communications on the communication channel. In these embodiments, the radio transceivers are tunable. In an embodiment, a user can tune the radio transceivers by entering appropriate commands via the user interface of the network analyzer.
To allow the use of a single antenna with a relative large number of radio transceivers, the RF interface may also include a low noise amplifier (LNA) disposed upstream of the splitter to compensate for the loss of power that occurs when the splitter slits the received signal. In some embodiments, the LNA provides sufficient power compensation to enable first-stage splitting using a first-stage splitter, and second-stage splitting using several second-stage splitters, each coupled to a respective output of the first-stage splitter.
In another embodiment, the RF interface includes a bandpass filter that receives a signal from a single antenna, a first-stage amplifier coupled to the output of the bandpass filter, a first-stage splitter coupled to the output of the first-stage amplifier, several second-stage amplifier coupled to the respective outputs of the first-stage splitter, and several second-stage splitters each coupled to the respective second-stage amplifier. In one such embodiment, the first-stage splitter and each of the second-stage splitter is a four-way splitter to accordingly provide a 16-way split of the received radio signal for use by 16 radio transceivers.
In some embodiments, the RF interface further includes a central processing unit (CPU) such as a microcontroller, and a packet controller with at least a transceiver interface, a CPU interface, and a packet processing module. The CPU provides data packets captured by the radio transceivers to the packet server, receives configuration commands from user interface to be forwarded to the appropriate radio transceiver, etc. The CPU may receive configuration or control data, and transmit data packets and related statistics, via the USB interface connecting the RF interface to the computer host. In some embodiments, the CPU also provides a clock signal for use by other components of the RF interface, including the packet controller. Accordingly, the CPU interface of the packet controller may include a set of pins to transmit packets from the output queue of the packet controller, a pin to output a signal indicative of a presence of one or more data packets in the output queue of the packet controller, and a set of pins to receive a selection of a radio transceiver for control or configuration. In at least some of the embodiments, the CPU interface of the packet controller also includes a pin to receive a clock signal, a set of pins defining the known serial parallel interface.
The transceiver interface of the packet controller to the radio transceivers provides a separate connection to each transceiver. In some embodiments, the transceiver interface includes a group of sets of pins, each set in the group defining the SPI interface to the respective transceiver. For each transceiver, the transceiver interface may also include a pin to receive a signal indicative of the beginning of reception of a data packet at the transceiver, a pin to receive a signal indicative of the end of reception of a data packet at the transceiver, and a pin to receive a signal indicative of the end of transfer of data packets from the transceiver to the packet controller. In those embodiments where the packet controller has a SPI interface with the CPU and with each transceiver, the packet controller may be considered a serial packet controller (SPC) that operates as a slave device relative to the CPU and as a master device relative to each transceiver.
The packet controller may further provide independent first-in-first-out (FIFO) buffering for each communication channel, i.e., for data packets received from a particular transceiver. In some embodiments, the packet controller implements a separate state machine for each communication channel, and drives each state machine in parallel using a common clock signal. The clock signal may also drive a counter which the packet controller may use for time stamping data packets. In this manner, the packet controller can generate a highly accurate time stamp for each packet, so that two packets, A and B, detected simultaneously (i.e., within the same clock cycle) by two transceivers on the respective communication channels, acquire an identical time stamp. Thus, when the packet controller forwards the packets A and B to the CPU and, ultimately, to the packet server, the packet A may be forwarded prior to the packet B or, conversely, the packet B may be forwarded prior to the packet A. In either case, the packets A and B can be properly processed because the packet controller always generates a time stamp that reflects the time the data packet was received at the respective transceiver.
In an embodiment, the packet controller may be implemented as a field-programmable field array (FPGA). The FPGA may be commercially available off-the-shelf hardware, and the packet controller may be implemented as firmware. In other embodiments, the packet controller may be implemented using standard components such as AND and OR gates, for example, or another type of an application-specific integrated circuit (ASIC). The clock may be a low-drift crystal clock with a resolution and accuracy selected in view of the duration of a transmission period in the communication network in which the network analyzer operates. When the communication network is a WirelessHART network, the resolution and accuracy of the clock is preferably one microsecond to provide reliable analysis of communications within TDMA timeslots used by WirelessHART networks.
The packet server of the network analyzer may receive a stream of time stamped data packets from the acquisition engine via the USB port. The packet server may then provide the stream of data packets to the user interface as well as to one or multiple clients via a standard network protocol such as TCP/IP or UDP/IP, for example. The data stream may be formatted as ASCII text, hex data, or according to any other format. By supporting multiple clients, the packet server allows multiple users to remotely connect to the network analyzer disposed in a convenient location relative to the corresponding communication network, for example.
A packet client may be a text-only or a graphical application that displays data packets captured from multiple communication channels in a convenient and intuitive format. At least some packet client applications may include filtering functions. In some embodiments, a packet client is adapted to apply a device-specific filter to display only those data packets that travel toward or from the specified network device. Further, a packet client may communicate with multiple packet servers so that a user may, for example, view network communications in several places within the communication network. In some embodiments, a packet client supports automated or scripted testing and/or filtering.
In some embodiments, a wireless communication network analyzer adapted to simultaneously capture and process communications on multiple communication channels may include a software component executable on a conventional computer system, and a dedicated external hardware component that implements the RF interface and communicates with the software component via a standard interface such as USB, for example. In an embodiment, the software component includes both a packet server and a user interface. In other embodiments, the software component includes a packet server, and the user interface is provided as a separate component executable locally or remotely from the packet server. In yet other embodiments, the packet server alone or in combination with the user interface may be provided as a dedicated hardware component. In one such embodiment, the RF interface along with the packet server and the user interface are implemented in an embedded system.
In an embodiment, a packet controller for simultaneous processing of data packets transmitted via a plurality of communication channels includes a plurality of inputs, each to receive a respective data packet signal indicative of a presence of a data packet on a respective one of the plurality of communication channels; a clock source to continuously supply a periodic clock signal associated with a certain clock cycle; a counter communicatively coupled to the clock source to generate a clock cycle count defined as a number of instances of the clock cycle that have occurred since a reference time; and plurality of independent time stamp generators, each coupled to the counter and to a respective one of the plurality of inputs to generate a time stamp in response to receiving the respective data packet signal, such that the time stamp includes a value of the clock cycle count. Optionally, the plurality of inputs of the packet controller is a first plurality of inputs, and the packet controller further includes a second plurality of inputs, each to receive data packers from a respective one of the plurality of communication channels; and an output to output data associated with the plurality of communication channels in a first-in, first-out (FIFO) order.
In another embodiment, a serial data controller for parallel processing of a plurality of communication channels includes a master interface to exchange data with a master device, the master interface having a master output, slave input (MOSI) to receive data from the master device, a first master input, slave output (MISO) to transmit data to the master device, and a serial clock input (SCLK) to receive a master clock signal from the master device; and the serial data controller further includes a plurality of slave interfaces, each to exchange data with a respective one of a plurality of slave devices, such that each of the plurality of slave devices services a respective one of the plurality of communication channels and each of the plurality of slave interfaces having a MOSI to transmit data to the respective one of the plurality of slave devices, a MISO to receive data from the respective one of the plurality of slave devices, and an SCLK output to forward the master clock signal to the respective one of the plurality of slave devices; each of the plurality of slave interfaces further including a multiplexer having a plurality of inputs coupled to the plurality of slave interfaces, and an output coupled to the master interface, and a processing module to simultaneously process data received from each of the plurality of slave interfaces, and coupled to the multiplexer to provide the data to the master device as a single stream via the master interface. Optionally, the serial data controller further includes a mode selection input to select between at least a first mode and a second mode of operation of the serial data controller, such that the first mode is associated with transferring data from the plurality of slave interfaces to the master interface, and the second mode is associated with transferring data from the master interface to the plurality of slave interfaces. Optionally, the serial data controller receives data packets via the plurality of slave serial interfaces, and the processing module includes a clock source to supply a periodic clock signal, a counter coupled to the clock source to count a number of clock cycles of the periodic clock signal, and a plurality of first-in-first-out (FIFO) buffers, each corresponding to a respective one of the plurality of slave serial interfaces; so that the processing module generates a time stamp for each data packet received via one of the plurality of slave serial interfaces, and places each data packet and the corresponding time stamp into one of the plurality of FIFO buffers, where the one of the plurality of FIFO buffers corresponds to the one of the plurality of slave serial interfaces, and where the time stamp includes the number of clock cycles of the periodic clock signal Optionally, the master interface of the serial data controller further includes a slave device selector to select between the plurality of slave devices. Optionally, a wireless communication network analyzer includes the serial packet controller and is adapted to simultaneously capture data packets on a plurality of radio channels; the network analyzer further including a processor defining the master device, a plurality of radio transceivers defining the plurality of slave devices, each of the plurality of radio transceivers associated with a respective one of the plurality of radio channels, and a packet server stored in a computer-readable memory as a set of instructions and executing on the processor to transmit the data packets captured on the plurality of radio channels to one or more clients.
For ease of explanation,
With continued reference to
In addition to the packets P1 and P3 that travel “upstream” relative to the device D7, some of the devices D1-D8 may similarly propagate data packets P2 and P4 “downstream” from the device D7 to the destination devices D5 and D4, respectively. As illustrated in
During operation of the wireless network 1, the network analyzer 2 continuously and simultaneously captures communications on all channels F1-F5 used by the devices D1-D8. Further, the network analyzer 2 captures and maintains timing information to ensure correct TDMA operation. To this end, the network analyzer 2 may use a common clock source to time stamp communications occurring on any channel. Still further, the network analyzer 2 may record all communications to allow the network traffic to be analyzed for the purpose of assessing compliance with the network protocol used by the wireless network 1.
Users such as engineers, technicians, etc. may operate the network analyzer 2 locally or remotely via the network interface of the network analyzer 2. If desired, several instances of the network analyzer 2 may placed in several locations in the process control plant, and a user at a remote location may run a single client application that communicates with the two or more network analyzers 2. Conversely, each network analyzer 2 may support multiple client applications by assigning separate TCP or UDP ports to each instance of a packet client, for example.
The RF interface 14 includes one or more receive antennas 18 (preferably only one) and simultaneously acquires data packets on all communication channels used by the wireless network 1, e.g., on all 16 channels of a 802.15.4-compliant 2.4 GHz network protocol. The RF interface 14 time stamps the data packets upon reception, and provides the data packets to the packet server 16 for conveyance to a user interface (UI) 20 of the network analyzer 2 and/or one or multiple client applications 24 via a network interface 26 and a network 28. Preferably, the time stamps are synchronized across all communication channels with less than ±8 μS (micro-seconds) error. The time stamps also preferably have a resolution of at least 8 μS and preferably have a resolution of 1 μS. In an embodiment, the time stamp corresponds to the reception of the delimiter byte in the IEEE 802.15.4 PHY PDU. Alternatively, the time stamp may correspond to another event such as the reception of the last octet of the data packet, for example.
The connection between the RF interface 14 and the packet server 16, which is executed in the host computer 12, may be implemented using a USB connection port 22, which may be a USB 2.0 full speed (12 Mbits/sec) or a high speed (480 Mbits/sec) connection, and may comply with the appropriate USB device type profile. The RF interface 14 is preferably appropriately packaged for laboratory and non-hazardous plant floor use. The packaging should also be appropriate for accompaniment by a laptop host computer. Further, packaging should ensure that all 16 channels can be received equally well. Thus, for example, there should not be more variance than ±3 dBm in received signal sensitivity between any of the 16 channels.
The packet server 16 may be a simple console application that connects to and supports the RF interface 14. The basic control of the packet server 16 may be implemented via command-line options. Once launched, the packet server 16 connects to the specified RF interface 14 via the USB port 22 and waits for the user interface 20 to connect to the packet server 16 via a predefined control port, for example. The packet server 16 may also support one or several data ports to which the user interface 20 and/or the client applications 24 may connect to retrieve data captured at the RF interface 14. Alternatively, the interaction between the packet server 16 and the UI may be implemented remote procedure calls (RPCs) or other inter-task communication techniques supported by the operating system executing on the host 12. Preferably, both the packet server 16 and the user interface 20 are compatible with Microsoft® Windows 2000, XP, or Vista, as well as with Linux, QNX, and other operating systems.
As discussed in greater detail below, the packet server 16 may support a set of commands which the user may enter directly via the command-line interface or via the user interface 20. Once the user interface 20 successfully connects to the packet server 16, the user may transmit the “START” to the packet server 16 to initiate transfer of data from the RF interface 14 to the user interface 20. The data transfer may continue until the packet server 16 receives the “STOP” command, or until the UI application 20 disconnects.
Still referring to
In an embodiment, the packet analyzer 24 may run on the same compute host 12, and connect to the packet server 16 locally. Alternatively, the packet analyzer 24 may run on another host and connect to the packet server 16 remotely, as illustrated in
As indicated above, the packet analyzer 24 can also connect to multiple packet servers 16 simultaneously (see
Next,
Referring to
The CPU 42 may be connected to the host computer 12 (see
As illustrated in
In general, the SPC 40 may perform several functions in the radio interface 14. On the one hand, the purpose of the SPC 40 is to provide separate SPI interfaces to each of the 16 802.15.4 radio transceivers 38, as well as to the transceiver 50. The SPC 40 may operate as an SPI master device relative to the transceivers 38 and 50, and as a slave device relative to the CPU 42. On the other hand, the FPGA of the SPC 40 also provides first-in-first-out (FIFO) buffering, channel selection, start of packet time stamping and a parallel interface to the CPU 42 for capturing packet data. In addition, the FPGA of the SPC 40 includes an interface from the CPU 40 for reading and writing all radio and internal FPGA registers as needed.
Referring to
On the transceiver interface, signals MOSI_n, MISO_n, and SCLK_n may define a synchronous serial data link consistent with the SPI architecture for each transceiver 38.
Signals SFD_n, FIFO_n and FIFOP_n may be used to drive independent state machines responsible for time stamping data packets, as well for initiating and stopping packet data transfer from the transceivers 38 (state machine implementation is discussed in detail with reference to
Regarding the CPU interface of the SPC 40, eight RXDATA pins are used to transfer a byte to the CPU 42 from a FIFO memory or buffer associated with a certain communication channel within the SPC 40, the READ_DATA signal is used to advance the readout to the next byte, and the /RX_INT signal is used to generate an interrupt that notifies the CPU 42 that data is available in one of the FIFO buffers in the SPC 40. The five pins ADDR[5:0] are used to select one of the transceivers 38 or one of the internal registers of the SPC 40, as discussed in more detail below. Further with respect to the CPU interface, signals MOSI, MISO, and SCLK define an SPI interface in which the CPU 42 operates as a master device and the SPC 40 operates as a slave device. Still further, the /CS_SPC signal provides the CPU 42 with access to any register within the SPC 40; the /LED1 and /LED2 signals are used to control respective light-emitting diodes to indicate network activity or errors, and may be connected to the CPU 42 so that the CPU 42 can read the LED states directly; the /CLK—16 MHZ signal is used to supply a clock signal from the CPU 42 and the SPC_CLK is used for monitoring the internal clock of the SPC 40; and the /RESET_SPC signal from the CPU 42 may reset all or some of the data and/or internal states of the SPC 40.
In general, the SPC 40 may operate in one of two fundamental modes, a setup mode and a receive mode, selectable via the RX_MODE pin. The setup mode is used to initialize the radio transceivers 38, 50 and to transmit packet data for testing, while the receive mode is used to capture data packets on all 16 channels simultaneously with a separate SPI bus for each radio transceiver 38. To enter the setup mode, the RX_MODE pin may be set to 0, for example.
More particularly, the network analyzer 2 may initially program each radio transceiver 38 using the setup mode. First, one of the 16 channels is selected using a set of ADDR[3:0] pins and setting an ADDR4 pin low. These five pins are some of the inputs to the SPC 40 when the SPC 40 is in the setup mode. Next, a normal SPI cycle is performed using the SPI engine run on the CPU 42. A set of /CS_SPC, MOSI, MISO and SCLK signals are automatically routed through the SPC 40 to the radio transceiver 38 associated with the addressed channel. Thus, in the setup mode, the SPC 40 can forward signals associated with standard SPI communications between the CPU 42 and the selected one of the transceivers 38. For maximum flexibility, the /CS_SPC signal timing is generated by software via a GPIO port in output mode.
In the setup mode, all of the registers of the selected radio transceiver 38 are programmed, and each transceiver 38 is set to a different one of the 16 frequency channels defined by the 802.15.4 specification. As the last step performed in the setup mode, the network analyzer 2 may write the 16-bit channel enable register within the SPC 40 to indicate which ones of the 16 channels are actually enabled in the receive mode. Once this step is completed, the RX_MODE pin is set to 1 to enter the receive mode.
In addition to selecting one of the radio transceivers 38 via the ADDR[3:0] pins and transmitting control or configuration data to the selected transceiver 38, the CPU 42 may directly access the internal registers of the SPC 40 via the /CS_SPC signal by setting ADDR4 signal high, for example. In this scenario, the ADDR[3:0] pins may be used to select one of the 16 internal registers of the SPC 40. In some embodiments, the internal registers are all 16-bits wide. The exact functions of the registers of the SPC 40 in one embodiment are defined in the table below.
In an embodiment, the register data is clocked in on the positive-edge of the SCLK signal and is saved in the appropriate register when /CS_SPC goes high.
In the receive mode, an independent state machine within the SPC 40 processes data packets from a respective transceiver 38, and generates time stamps for each received data packet. The transceiver 38 may forward all layers of the captured data packet to the SPC 40, including the PHY header and possibly the preamble. When the RX_MODE pin is set to 1, the SPC 40 automatically sends a command (SRX-ON) to each enabled radio transceiver 38 (identifiable using the channel enable register 0 as described in the table above) to start reception. The operation of the SPC 40 in the receive mode, as well as the components used in the receive mode, are discussed next with reference to
Normally, each radio transceiver 38 is set to a different one of the set of communication channels used to transmit data packets in the network 1. As indicated above, the network analyzer 2 may thus capture communications occurring on all communication channels of the network 1. However, the network analyzer 2 preferably permits the user to program any of the radio transceivers 38 via the user interface 20 to operate on any 802.15.4 channel. As one example, the user may configure all radio transceivers 38 of the RF interface 14 to receive communications on the same channel in order to determine the RSSI signal strength variance between communication channels. This mode of operation is referred to below as the calibration mode.
As indicated above, the CPU 42 and the SPC 40 use the signals RXDATA[7:0], READ_DATA and /RX-INT to transfer data packets to the CPU 42 and, in particular, the RXDATA pins are used to read a byte from a corresponding FIFO buffer. When transitioning from the receive mode back to the setup mode (i.e., RX-MODE pin goes low), the SPC 40 may automatically clear all of the internal states related to the receive mode, and flushes all FIFO buffers.
Still referring to
Each of the state machines 70 may operate according to a state transition diagram 90 illustrated in
In the notation used in
Prior to retrieving a data packet in the state 96, the SPC 40 may generate a header identifying the channel on which the data packet was received and a 5-byte long time stamp. The SPC 40 may insert the generated header into the corresponding FIFO buffer ahead of the data packet to be retrieved from the transceiver 38 in state 96. In some embodiments, the packet header data format may be defined as follows:
According to this example format, the lower nibble of the channel byte is in the range 0 to 15 to indicate the physical channel of the packet. The software of the network analyzer 2 may map this physical channel to the 802.15.4 channel in the setup mode. The upper nibble of the channel byte carries a copy of the status bits from SPC Register #1 defined above. The time stamp is preferably a 40-bit value with a resolution of 1 microsecond per bit. This resolution allows a packet capture period of more than 12.7 days without wrapping. The time stamp counter is set to 0 when the SPC 40 is reset at power-up.
In state 96, the state machine 70 may retrieve the data packet available at the transceiver 38. In other embodiments, the state machine 70 may read multiple data packets in state 96 without transitioning back to state 92 after each reception. However, time stamp generation and insertion may need to be adjusted accordingly. In general, the transfer in state 96 may occur via the corresponding SPI interface (i.e., MISO_n, MOSI_n, and SCLK_n pins).
In the example network 1 that implements WirelessHART, the packet data is up to 128 bytes in length. The first byte indicates the length in bytes of the rest of the packet. The SPC state machine first reads the length byte and uses it to read the remaining bytes of the packet. Alternatively, the SPC 40 can just read the bytes from the radio transceiver 38 until the FIFO_n pin goes low indicating that there are no more bytes to read.
If desired, the SPC 40 may also append a length check byte at the end of a data packet stored in the corresponding FIFO. This additional byte is used for synchronization purposes and validation of packet boundaries. Any packets with a length byte greater than 127 may be considered invalid and can be discarded. When a discard occurs, a packet discard counter may be incremented. Packets with valid lengths but with cyclical redundancy check (CRC) errors also may be captured. The last byte of the packet may include a bit that indicates whether the packet had a CRC error.
Once the packet has been received, time stamped and stored in the appropriate channel-specific FIFO memory, the SPC 40 may proceed to notify the CPU 42 that new data is available for retrieval and subsequent processing by packet server 16 and, ultimately by one of the packet clients 24 (see
In some embodiments, to ensure that the CPU 42 can detect the de-asserted /RX-INT pin before the next interrupt comes in, the SPC 40 waits to issue any pending interrupts until after the READ_DATA signal is toggled one additional time by the CPU 42.
Further, the SPC 40 may be adapted to efficiently and safely handle overflows. Although the SPC 40 is preferably fast enough to avoid an overflow under normal conditions, an overflow may still occur if, for example, one of the transceivers 38 receives a data packet longer than the maximum length of 128 bytes. In this case, an overflow may be indicated by the FIFO_n signal going low after FIFOP_n goes high at the end of the data packet. In an embodiment, the SPC 40 detects this condition and issues a command to the corresponding transceiver 38 to flush the associated FIFO memory and to resume operation. In this case, some data in the FIFO buffer is lost and the corresponding time stamp is not used. This condition could be reported using, for example, one of the LEDs 48 on a pin from the SPC 40, if desired.
Further with respect to clock signals used to drive the state machines 70, the clock source 72 (see FIG. 6A0) may be the CLK-16 MHz input pin. This signal may be highly accurate clock (+−1.5 ppm), and may be also used to drive the time stamp counter 74 and the XCVR_CLK—[16:0] signals. In this case, the SPC 40 may be simply used as a distribution buffer for the XCVR_CLK_n outputs. The extra XCVR_CLK_16 signal may go to the radio transceiver 50, if desired.
Further, the SPC_CLK output pin may be the internal clock used by the state machines 70. This signal is preferably a 40 MHz clock generated by an internal phase locked loop (PLL) of the SPC 40, and this clock signal may be output at pin for SPC_CLK testing purposes.
As indicated above, the CPU 42 may also completely reset the SPC 40 by issuing a low pulse on the /RESET_SPC input. In this case, the SPC 40 may set the one or more counters 70, the internal registers, and all of the internal FIFO buffers to zero. The SPC 40 may also reset all of the state machines to the idle state. The SPC 40 may also send a single /NRESET signal to all of the transceivers 38. Preferably, this signal is pulsed low when the SPC 40 is reset via the /RESET_SPC signal.
When operating in the calibration mode, the network analyzer 2 may tune all transceivers 38 to the same carrier frequency. The RF interface 14 may then receive the same control signal on every communication channel, measure the RSL on each communication channel, and use the obtained RSL measurements to compensate for variations in channel-specific signal attenuation in subsequent processing. In other words, the network analyzer 2 may operate the transceivers 38 on the same frequency in order to reduce or completely cancel out channel-to-channel variations in receiver sensitivity, and thus efficiently and accurately calibrate the RF interface 14. The control signal may include actual data packets transmitted by the devices D1-D7 in the network 1, or a signal from a control transmitter. In one embodiment, the network analyzer 2 may use the transceiver 50 to generate the control signal having a controlled strength and/or other parameters. It will be appreciated that accurate calibration of the RF interface 14 across multiple communication channels allows the network analyzer 2 to estimate the strength of the signal emitted by a device under test (e.g., one of the devices D1-D7 illustrated in
Next,
From the foregoing, it will be appreciated that the radio interface 14 in general, and the SPC 40 in particular, permit the client applications 24 (see
To better illustrate some of the advantages associated with this approach,
In general, the time stamp accuracy may be limited to the resolution of the CLK signal. The data packet detected on communication channel N at the time T4 may accordingly acquire a time stamp associated with the time T5 different from the time T3, while the data packets detected on communication channels 1 and 2 acquire the same time stamp at the time T3 despite the difference between the times T1 and T2.
Further, it will be noted that the SPC 40 need not trigger time stamping at the beginning of the delimiter field. If, for example, all packets are known to use the same format of the PHY preamble and/or header, the SPC 40 may trigger using other signals, or different transitions of the same signals, received from the transceivers 38. For example, the relative accuracy of time stamps can be the same if the SPC 40 were to trigger on the transition of SFD_n from high to low at the times T6, T7, or T9.
Next,
In an embodiment, the SPC 40 may include a Xilinx XC3S1000-FT256 FPGA in which the serial slave mode configuration is implemented. In this mode, the CPU 42 controls loading the FPGA code via the CCLK, DIN, DONE, INIT_B & PROG_B pins on the FPGA. The code itself is stored in the serial flash 44 connected to the CPU 42. The CPU 42 is required to download the FPCA code at power-up time. More details may be found in the Xilinx Application Note (XAPP502) on using a microprocessor to configure a Xilinx FPGA. Further, the radio transceivers 38 may be TI/Chipcon CC2420 chips and the FPCA may be customized to use the signal interface of this transceiver.
From the foregoing, it will be appreciated that the radio interface 14 discussed with reference to
Referring back to
p port
Server port used to establish a bi-directional configuration and control connection to a packet client 24 and/or the user interface 20 (default: 1024)
l descriptor
ISO 639 specified language descriptor string (default: “en”).
d
Run in debug mode taking input from stdin and sending the capture packets to stdout. The capture is stopped by sending a ^C via stdin. If this option is not specified, the message server will wait for control commands on the control port before starting the capture
O stdout
G stdlog
file name with optional path (default: “analysaelog.txt”)
E stderr
file name with optional path (default: “analysaeerr.txt”)
The user interface 20 and the packet server 16 may use a TCP data port and a TCP control port to communicate with each other. In operation, the user interface 20 may first assess the connection port for the application configuration and control. In one embodiment, the control port at “localhost” is the TCP port “ANALYS_WH_UI_CONNECT” (localhost refers to the host computer 12 on which the acquisition engine 10 is executing, and ANALYS_WH_UI_CONNECT is a compile-time constant for the default port number).
After the user interface 20 connects to the packet server 16 of the acquisition engine 10 via the ANALYS_WH_UI_CONNECT port, the other uni-directional data port number may be provided as a decimal number in ASCII text form. A negative number may indicate a stream allocation error or some other error condition. The user interface 20 may also display a list of USB devices attached to the packet server 16.
The user interface 20 can send configuration and control commands to the packet server 16 using the configuration and control ports. If the message server 16 accepts the command, it preferably responds with an acknowledgement. If the command contains an error or if the packet server 16 is unable to complete the command for some reason, the packet server 16 preferably responds with a negative acknowledgement along with a string of text specifying the reason. The table below provides an example set of control port commands the packet server 16 may recognize:
During operation of the network analyzer 2, the acquisition engine 10 may provide a data stream to the user interface 20 and/or the packet clients 24 that includes data packets captured on several wireless channels as well as additional information useful in device and network diagnostics. For example, the data stream may include some or all of the fields Description (e.g., “802.15.4-DATA”), Packet Number (e.g., a continuously increasing 32-bit number to keep track of each captured packet), Date and Time, Timestamp, RSL, Packet Status, Channel, Byte Stream, USB Device Number. Additionally, the data stream may include a field USB Device Number to specify the USB device on which the packet was captured.
In some embodiments, the Date and Time field includes the ISO 8601 date string, a space character, and the ISO 8601 time string. The second field is immediately followed by a decimal point and the number of milliseconds. This configuration is similar to the output of the standard ANSI C library function strftime invoked with the format string of “% Y-% m-% d % H: % M: % S” with the addition of the milliseconds. Meanwhile, the field Elapsed Time may contain the number of milliseconds since the acquisition system was last reset. The elapsed time is reported every 8 μS and may have an accuracy of at least 8 μS. The time is preferably represented as a floating point number with three digits to the right of the decimal point. The value should not overflow for at least 48 hours.
The RSL field may indicate the receive signal level for each packet, included to provide an estimate of a power level (in dB) of the signal for the received packet. This value may be represented and stored as a signed integer between −128 and +127.
Further, the Packet Status may be an unsigned, 16-bit enumerated status of the packet. The status may indicate the following values, for example: bit 0—Packet FCS Error; Bit 1—Bad receive byte count; Bit 2—Receiver overflow. Bits 3-15 are reserved.
Still further, the field Channel contains the decimal channel number as per the IEEE 802.15.4-2006 specifications. The field byte Stream preferably contains all of the bytes received in the data packet. Each byte may be separated by a space character and includes 2 hexadecimal characters.
In general, all fields may be ASCII text separated by a comma, and the packet is preferably terminated by a line feed. An example of the resulting stream is:
1, 802.15.4-DATA, 10523, 2007-07-16 14:04:31.261, 6581973.929, −14, 0x0000, 23, 5B 41 88 2C 11 00 . . . equivalent).
Because the packet client 24 illustrated in
It is also contemplated that the network analyzer 2 may be used for automated test execution as well as test annotation. In particular, the packet server 16 may be provisioned to execute predefined test scenarios in response to corresponding commands from a packet client 24. In other words, the network analyzer 2 can process data packets addressed to the network analyzer 2 itself. For example, packets can be used to instruct the network analyzer 2 to start and stop recording data; to specify the name of the file to record the data; to provide cryptographic keys in use during the test may be used, etc. The network analyzer 2 may create a specific directory (e.g., on a memory disk of the host 12) to which the packet server 16 may direct data packets collected in the course of executing the particular test scenario. In this manner, the amount of information which a human operator has to analyze manually may be significantly reduced.
Although the forgoing text sets forth a detailed description of numerous different embodiments, it should be understood that the scope of the patent is defined by the words of the claims set forth at the end of this patent. The detailed description is to be construed as exemplary only and does not describe every possible embodiment because describing every possible embodiment would be impractical, if not impossible. Numerous alternative embodiments could be implemented, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims.
This application is based on and claims the benefit of priority to U.S. Provisional Application No. 61/074,954, entitled “Wireless Communication Network Analyzer” filed Jun. 23, 2008, the entire disclosure of which is hereby expressly incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4792944 | Takahashi et al. | Dec 1988 | A |
| 5159592 | Perkins | Oct 1992 | A |
| 5459855 | Lelm | Oct 1995 | A |
| 5535193 | Zhang et al. | Jul 1996 | A |
| 5719859 | Kobayashi et al. | Feb 1998 | A |
| 5781549 | Dai | Jul 1998 | A |
| 5926531 | Petite | Jul 1999 | A |
| 6028522 | Petite | Feb 2000 | A |
| 6198751 | Dorsey et al. | Mar 2001 | B1 |
| 6218953 | Petite | Apr 2001 | B1 |
| 6233327 | Petite | May 2001 | B1 |
| 6236334 | Tapperson et al. | May 2001 | B1 |
| 6298377 | Hartikainen et al. | Oct 2001 | B1 |
| 6430268 | Petite | Aug 2002 | B1 |
| 6437692 | Petite et al. | Aug 2002 | B1 |
| 6522974 | Sitton | Feb 2003 | B2 |
| 6532507 | Falik et al. | Mar 2003 | B1 |
| 6556335 | Lee et al. | Apr 2003 | B2 |
| 6578047 | Deguchi | Jun 2003 | B1 |
| 6594530 | Glanzer et al. | Jul 2003 | B1 |
| 6618578 | Petite | Sep 2003 | B1 |
| 6628764 | Petite | Sep 2003 | B1 |
| 6747557 | Petite et al. | Jun 2004 | B1 |
| 6801777 | Rusch | Oct 2004 | B2 |
| 6836737 | Petite et al. | Dec 2004 | B2 |
| 6891838 | Petite et al. | May 2005 | B1 |
| 6914533 | Petite | Jul 2005 | B2 |
| 6914893 | Petite | Jul 2005 | B2 |
| 6920171 | Souissi et al. | Jul 2005 | B2 |
| 6959356 | Packwood et al. | Oct 2005 | B2 |
| 6970909 | Schulzrinne | Nov 2005 | B2 |
| 6996100 | Haartsen | Feb 2006 | B1 |
| 7002958 | Basturk et al. | Feb 2006 | B1 |
| 7053767 | Petite et al. | May 2006 | B2 |
| 7079810 | Petite et al. | Jul 2006 | B2 |
| 7103511 | Petite | Sep 2006 | B2 |
| 7110380 | Shvodian | Sep 2006 | B2 |
| 7137550 | Petite | Nov 2006 | B1 |
| 7209840 | Petite et al. | Apr 2007 | B2 |
| 7292246 | Goldschmidt | Nov 2007 | B2 |
| 7295128 | Petite | Nov 2007 | B2 |
| 7346463 | Petite et al. | Mar 2008 | B2 |
| 7375594 | Lemkin et al. | May 2008 | B1 |
| 7397907 | Petite | Jul 2008 | B2 |
| 7420980 | Pister et al. | Sep 2008 | B1 |
| 7468661 | Petite et al. | Dec 2008 | B2 |
| 7529217 | Pister et al. | May 2009 | B2 |
| 7602741 | Tapperson et al. | Oct 2009 | B2 |
| 7650425 | Davis et al. | Jan 2010 | B2 |
| 7675935 | Samudrala et al. | Mar 2010 | B2 |
| 7680033 | Khan et al. | Mar 2010 | B1 |
| 7697492 | Petite | Apr 2010 | B2 |
| 7848827 | Chen | Dec 2010 | B2 |
| 7853221 | Rodriguez et al. | Dec 2010 | B2 |
| 7978059 | Petite et al. | Jul 2011 | B2 |
| 8013732 | Petite et al. | Sep 2011 | B2 |
| 8064412 | Petite | Nov 2011 | B2 |
| 8098676 | Connor | Jan 2012 | B2 |
| 20010030957 | McCann et al. | Oct 2001 | A1 |
| 20010041591 | Carroll | Nov 2001 | A1 |
| 20020007414 | Inoue et al. | Jan 2002 | A1 |
| 20020013679 | Petite | Jan 2002 | A1 |
| 20020031101 | Petite et al. | Mar 2002 | A1 |
| 20020067693 | Kodialam et al. | Jun 2002 | A1 |
| 20020111169 | Vanghi | Aug 2002 | A1 |
| 20020120671 | Daffner et al. | Aug 2002 | A1 |
| 20030014535 | Mora | Jan 2003 | A1 |
| 20030026268 | Navas | Feb 2003 | A1 |
| 20030040897 | Murphy et al. | Feb 2003 | A1 |
| 20030074489 | Steger et al. | Apr 2003 | A1 |
| 20030169722 | Petrus et al. | Sep 2003 | A1 |
| 20030198220 | Gross et al. | Oct 2003 | A1 |
| 20030236579 | Hauhia et al. | Dec 2003 | A1 |
| 20040011716 | Sandt et al. | Jan 2004 | A1 |
| 20040028023 | Mandhyan et al. | Feb 2004 | A1 |
| 20040053600 | Chow et al. | Mar 2004 | A1 |
| 20040095951 | Park | May 2004 | A1 |
| 20040117497 | Park | Jun 2004 | A1 |
| 20040148135 | Balakrishnan et al. | Jul 2004 | A1 |
| 20040174904 | Kim et al. | Sep 2004 | A1 |
| 20040183687 | Petite et al. | Sep 2004 | A1 |
| 20040203973 | Khan | Oct 2004 | A1 |
| 20040257995 | Sandy et al. | Dec 2004 | A1 |
| 20040259533 | Nixon et al. | Dec 2004 | A1 |
| 20050013253 | Lindskog et al. | Jan 2005 | A1 |
| 20050018643 | Neilson et al. | Jan 2005 | A1 |
| 20050025129 | Meier | Feb 2005 | A1 |
| 20050030968 | Rich et al. | Feb 2005 | A1 |
| 20050049727 | Tapperson et al. | Mar 2005 | A1 |
| 20050078672 | Caliskan et al. | Apr 2005 | A1 |
| 20050085928 | Shani | Apr 2005 | A1 |
| 20050114517 | Maffeis | May 2005 | A1 |
| 20050125085 | Prasad et al. | Jun 2005 | A1 |
| 20050160138 | Ishidoshiro | Jul 2005 | A1 |
| 20050164684 | Chen et al. | Jul 2005 | A1 |
| 20050190712 | Lee et al. | Sep 2005 | A1 |
| 20050192037 | Nanda et al. | Sep 2005 | A1 |
| 20050213612 | Pister et al. | Sep 2005 | A1 |
| 20050228509 | James | Oct 2005 | A1 |
| 20050239413 | Wiberg et al. | Oct 2005 | A1 |
| 20050249137 | Todd et al. | Nov 2005 | A1 |
| 20050276233 | Shepard et al. | Dec 2005 | A1 |
| 20050282494 | Kossi et al. | Dec 2005 | A1 |
| 20060007927 | Lee et al. | Jan 2006 | A1 |
| 20060029060 | Pister | Feb 2006 | A1 |
| 20060029061 | Pister et al. | Feb 2006 | A1 |
| 20060045016 | Dawdy et al. | Mar 2006 | A1 |
| 20060062192 | Payne | Mar 2006 | A1 |
| 20060067280 | Howard et al. | Mar 2006 | A1 |
| 20060077917 | Brahmajosyula et al. | Apr 2006 | A1 |
| 20060120384 | Boutboul et al. | Jun 2006 | A1 |
| 20060174017 | Robertson | Aug 2006 | A1 |
| 20060182076 | Wang | Aug 2006 | A1 |
| 20060192671 | Isenmann et al. | Aug 2006 | A1 |
| 20060213612 | Perron et al. | Sep 2006 | A1 |
| 20060215582 | Castagnoli et al. | Sep 2006 | A1 |
| 20060245440 | Mizukoshi | Nov 2006 | A1 |
| 20060253584 | Dixon et al. | Nov 2006 | A1 |
| 20070016724 | Gaither et al. | Jan 2007 | A1 |
| 20070070943 | Livet et al. | Mar 2007 | A1 |
| 20070074489 | Erhardt et al. | Apr 2007 | A1 |
| 20070076600 | Ekl et al. | Apr 2007 | A1 |
| 20070078995 | Benard et al. | Apr 2007 | A1 |
| 20070109592 | Parvathaneni et al. | May 2007 | A1 |
| 20070118604 | Costa Requena | May 2007 | A1 |
| 20070121531 | Lee et al. | May 2007 | A1 |
| 20070121615 | Weill et al. | May 2007 | A1 |
| 20070124654 | Smolinske et al. | May 2007 | A1 |
| 20070140245 | Anjum et al. | Jun 2007 | A1 |
| 20070143392 | Choe et al. | Jun 2007 | A1 |
| 20070153010 | Uhlik | Jul 2007 | A1 |
| 20070161371 | Dobrowski et al. | Jul 2007 | A1 |
| 20070237094 | Bi et al. | Oct 2007 | A1 |
| 20070243879 | Park et al. | Oct 2007 | A1 |
| 20070280144 | Hodson et al. | Dec 2007 | A1 |
| 20070280286 | Hodson et al. | Dec 2007 | A1 |
| 20070282463 | Hodson et al. | Dec 2007 | A1 |
| 20070283030 | Deininger et al. | Dec 2007 | A1 |
| 20080075007 | Mehta et al. | Mar 2008 | A1 |
| 20080082636 | Hofmann et al. | Apr 2008 | A1 |
| 20080084852 | Karschnia | Apr 2008 | A1 |
| 20080098226 | Zokumasui | Apr 2008 | A1 |
| 20080117836 | Savoor et al. | May 2008 | A1 |
| 20080120676 | Morad et al. | May 2008 | A1 |
| 20080148296 | Chen et al. | Jun 2008 | A1 |
| 20080192812 | Naeve et al. | Aug 2008 | A1 |
| 20080198860 | Jain et al. | Aug 2008 | A1 |
| 20080215773 | Christison et al. | Sep 2008 | A1 |
| 20080285582 | Pister et al. | Nov 2008 | A1 |
| 20090059855 | Nanda et al. | Mar 2009 | A1 |
| 20090068947 | Petite | Mar 2009 | A1 |
| 20090097502 | Yamamoto | Apr 2009 | A1 |
| 20090154481 | Han et al. | Jun 2009 | A1 |
| 20090323594 | Mishra et al. | Dec 2009 | A1 |
| 20100194582 | Petite | Aug 2010 | A1 |
| 20100312881 | Davis et al. | Dec 2010 | A1 |
| 20110264324 | Petite et al. | Oct 2011 | A1 |
| 20110309953 | Petite et al. | Dec 2011 | A1 |
| 20110320050 | Petite et al. | Dec 2011 | A1 |
| Number | Date | Country |
|---|---|---|
| 2324563 | Sep 1999 | CA |
| 1170464 | Jan 1998 | CN |
| 1804744 | Jul 2006 | CN |
| 1169690 | Jan 2002 | EP |
| 1236075 | Sep 2002 | EP |
| 1293853 | Mar 2003 | EP |
| 1370958 | Dec 2003 | EP |
| 1376939 | Jan 2004 | EP |
| 2388708 | Nov 2011 | EP |
| 2 403 043 | Dec 2004 | GB |
| 2005143001 | Jun 2005 | JP |
| 1020010076781 | Aug 2001 | KR |
| 1020040048245 | Jun 2004 | KR |
| 1020050028737 | Mar 2005 | KR |
| 1020060066580 | Jun 2006 | KR |
| 1020050016891 | Sep 2006 | KR |
| 1020060111318 | Oct 2006 | KR |
| 1020070026600 | Mar 2007 | KR |
| WO-0055825 | Sep 2000 | WO |
| WO-0135190 | May 2001 | WO |
| WO-0205199 | Jan 2002 | WO |
| WO-0213036 | Feb 2002 | WO |
| WO-0213412 | Feb 2002 | WO |
| WO-0213413 | Feb 2002 | WO |
| WO-0213414 | Feb 2002 | WO |
| WO-02075565 | Sep 2002 | WO |
| WO-2005079026 | Aug 2005 | WO |
| WO-2005096722 | Oct 2005 | WO |
| WO-2006121114 | Nov 2006 | WO |
| Entry |
|---|
| International Search Report and Written Opinion for corresponding International Application No. PCT/US2009/048342, mailing date Feb. 24, 2010. |
| Deering et al., “Internet Protocol, Version 6 (IPv6) Specification; rfc1883.txt”, IETF Standard, Internet Engineering Task Force, IETF, CH, Dec. 1, 1995, XP015007667. |
| Wong, “A Fuzzy-Decision-Based Routing Protocol for Mobile Ad Hoc Networks,” Networks, 2002. ICON 2002. 10th IEEE International Conference on Aug. 27-30, 2002, Piscataway, NJ, USA, IEEE, Aug. 27, 2002, pp. 317-322. |
| Alandjani et al., “Fuzzy Routing in Ad Hoc Networks,” Conference Proceedings fo the 2003 IEEE International Performance, Computing, and Communications Conference. Phoenix, AZ, Apr. 9-11, 2003, IEEE, vol. Conf. 22, Apr. 9, 2003, pp. 525-530. |
| Thomas et al., “Anthoc—QoS: Quality of 1-7 Service Routing in Mobile Ad Hoc Networks Using Swarm Intelligence” Mobile Technology, Applications and Systems, 2005 2nd International Conference on Guangzhou, China Nov. 15-17, 2005, Piscathaway, NJ, USA, IEEE, Piscathaway, NJ, USA Nov. 15, 2005, pp. 1-8. |
| Kastner et al., “Communication Systems for Building Automation and Control,” Proceedings of the IEEE, vol. 93, No. 6, Jun. 1, 2005, pp. 1178-1203. |
| Thomesse, J., “Fieldbus Technology in Industrial Automation,” Proceedings of the IEEE, vol. 93, No. 6, Jun. 1, 2005, pp. 1073-1101. |
| Cleveland, F., “IEC TC57 Security Standards for the Power System's Information Infrastructure—Beyond Simple Encryption,” May 21, 2006, pp. 1079-1087. |
| Matkurbanov et al., “A Survey and Analysis of Wireless Fieldbus for Industrial Environments,” SICE-ICCAS 2006 International Joint Conference, 5555-5561 (2006). |
| Lopez et al., “Wireless communications deployment in industry: a review of issues, options and technologies,” Computers in Industry, Elsevier Science, 56:29-53 (2005). |
| Shen et al., “Wireless Sensor Networks for Industrial Applications,” WCICA, 15-19 (2004). |
| “A Survey and Analysis of Wireless Field bus for Industrial Environments”, Pulat Matkurbanov, SeungKi Lee, Dong-Sung Kim; Dept. of Electron. Eng., Kumoh Nat. Inst. of Technol., Gumi. This paper appears in: SICE-ICASE, 2006. International Joint Conference: Issue Date: Oct. 18-21, 2006, on pp. 55555-55561; Print ISBN: 89-950038-4-7. |
| “D1100 SmartMesh Network Release 1.0 Engineering Software Specifications,” Dust Networks, Dec. 17, 2011, 36 pages. |
| “D1100 SmartMesh Network Release 1.0 Engineering Software Specifications,” Dust Networks, 36 pages. |
| “Multiple Interpenetrating MultiDiGraphs,” Dust Incorporated, 12 pages. (Powerpoint). |
| “SmartMesh-XT CLI Commands Guide,” Dust Networks, Inc., Jun. 27, 2007, 36 pages. |
| SmartMesh-XT KT1030/KT2135/KT2030 Evaluation Kit Guide, Dust Networks, Inc., Nov. 2, 2007, 58 pages. |
| “SmartMesh-XT M2135-2, M2030-2 2.4 GHz Wireless Analog/Digital/Serial Motes,” Dust Networks, Inc., Mar. 28, 2007, 33 pages. |
| SmartMesh-XT Manager XML API Guide, Dust Networks, Inc., Apr. 4, 2007, 148 pages. |
| “System Description for Security Review SmartMesh Alba,” Dust Networks, 32 pages. |
| Berlemann, Software Defined Protocols Based on Generic Protocol Functions for Wired and Wireless Networks, Nov, 2033, RWTH Aachen University. |
| Qu et al., “A web-enabled distributed control application platform for industrial automation”, Emerging Technologies and Factory Automation, Proceedings, 2:129-32 (Sep. 16, 2003). |
| Willig (ed.), “An architecture for wireless extension of PROFIBUS”, IECON 2003—Proceedings of the 29th Annual Conference of the IEEE Industrial Electronics Society, New York, vol. 3, pp. 2369-2375 (Nov. 2-6, 2003). |
| Zheng, “ZigBee wireless sensor network in industrial applications”, SICE-ICCAS 2006 International Joint Conference, IEEE, New Jersey, pp. 1067-1070 (Oct. 1, 2006). |
| Number | Date | Country | |
|---|---|---|---|
| 20100110916 A1 | May 2010 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61074954 | Jun 2008 | US |
