Rev. 0.2 7/13Copyright ? 2013 by Silicon Laboratories
AN626AN626
P ACKET H ANDLER O PERATION FOR Si446X RFIC S
1. Introduction
This application note discusses the operation of the Packet Handler (PH) on the Si446x family of RFICs. Details of operation in both TX mode and RX mode are provided. The purpose of this application note is to expand upon the information available in the data sheets for Si446x devices. This application note does not discuss direct mode or raw data mode (as may be required by legacy systems with non-standard packet structures). A thorough understanding of the topics discussed within this application note will be helpful in construction of a typical packet structure such as that shown in Figure 1.
Figure 1.General Packet Structure
In order to completely specify the structure of the packet, it is necessary to configure the Preamble, Sync Word,and Data fields. Configuration of these fields is provided by four groups of properties accessible through the API:
? Property Group 0x10xx=Preamble Configuration
? Property Group 0x11xx=Sync Word Configuration
? Property Group 0x12xx=Packet Field Configuration
? Property Group 0x30xx=Match (Header Check) Configuration
Although the PH itself is concerned only with configuration of the Packet Fields (property group 0x12xx), all four property groups are discussed within this document; a thorough understanding of configuration of these groups is required to construct a desired packet structure.
It is assumed that the user has a basic familiarity with the API for the Si446x family of RFICs. All configurations of the PH discussed within this application note are accomplished through the use of published API calls.
AN626
2
Rev. 0.2
2. Packet Handler Overview
The Si446x family of chips contains circuit functionality known as the automatic Packet Handler (PH). The purpose of the PH is to automatically perform basic packet structure construction (in TX mode) or deconstruction (in RX mode), without the need for MCU control or intervention. The usual fields needed for packet generation (such as Preamble and Sync Word) normally change infrequently and can therefore be stored in registers. Automatically adding these fields to the Payload data greatly reduces the required computational power of the MCU, allowing use of a less-complex (i.e., cheaper) MCU.
The PH has little benefit unless the chip is also operated in FIFO mode (as opposed to Direct mode where the bits of the transmit or receive data stream are processed in real-time on a physical input or output pin). Therefore,operation of the chip in FIFO mode is assumed throughout this document, unless noted otherwise.
The functionality of the PH may be enabled or disabled in RX mode. Enabling/disabling of the PH functionality is provided in Property 0x1206 PKT_CONFIG1 by the PH_RX_DISABLE bit D6. However, if the PH is disabled the receiver may only be operated in Direct mode; operation in FIFO mode is not possible. The PH remains enabled at all times in TX mode.
Figure 2.Property 0x1206 PKT_CONFIG1, General Packet Configuration Bits
The functionality of the PH includes the following:
? Detection/validation of Preamble quality in RX mode (PREAMBLE_VALID signal)
? Detection of Sync word in RX mode (SYNC_OK signal)
? Detection of valid packets in RX mode (PKT_VALID signal)
? Detection of CRC errors in RX mode (CRC_ERR signal)
? Data de-whitening and/or Manchester decoding (if enabled) in RX mode
? Match/Header checking in RX mode
? Storage of Data Field bytes into FIFO memory in RX mode
? Construction of Preamble field in TX mode
? Construction of Sync field in TX mode
? Construction of Data Field from FIFO memory in TX mode
? Construction of CRC field (if enabled) in TX mode
?
Data whitening and/or Manchester encoding (if enabled) in TX mode
AN626
Rev. 0.2
3
3. Packet Handler in TX Mode
In TX mode, operation of the PH has no meaning unless the chip is also operated in FIFO mode. This is self-evident; if the bits of the transmit data stream are provided by the host MCU in real-time on a physical input pin, the entire structure of the transmit packet is already determined and there is no additional functionality for the PH to provide. Thus the true benefit of the PH in TX mode is only realized when the Data Field bytes are programmed into FIFO memory, and the remainder of the packet structure is automatically constructed using the PH functionality. The PH functionality always remains enabled in TX mode; there is no enable/disable property for the PH in TX mode as there is in RX mode.
3.1. Preamble Field
The Preamble field is configured through the Preamble property group 0x1000-0x1008. These properties may be used to configure parameters such as selection of a standard or non-standard preamble pattern, preamble length,and preamble polarity (i.e., 1010 pattern or 0101 pattern).
3.1.1. Selection of Standard or Non-Standard Preamble
Selection of standard or non-standard Preamble pattern is specified by the STANDARD_PREAM[1:0] field in the PREAMBLE_CONFIG property 0x1004. A standard preamble pattern is one that consists of an alternating pattern of 1’s and 0’s, such as a 1010 pattern or a 0101 pattern. A 1010 pattern may be selected by setting STANDARD_PREAM = 2’b01, while a 0101 pattern may be selected by setting STANDARD_PREAM = 2’b10.
A non-standard preamble pattern is any regularly-repeating pattern that does not consist of alternating 1’s and 0’s.An example of a non-standard preamble pattern might be 11101110. Operation with a non-standard pattern may be selected by setting STANDARD_PREAM = 2’b00. It is necessary to additionally specify the actual structure of the non-standard repeating pattern, as discussed in “3.1.3. Configuration of Non-Standard Preamble Pattern” .Figure
3.Property 0x1004 PREAMBLE_CONFIG, Standard/Non-Standard Preamble Selection
3.1.2. TX Preamble Length
The length of the transmitted Preamble field is specified by the TX_LENGTH[7:0] field in the PREAMBLE_TX_LENGTH property 0x1000. Depending upon the setting of the LENGTH_CONFIG bit D4 in property PREAMBLE_CONFIG 0x1004 (refer to Figure 3), the meaning of this field is in units of nibbles (4 bits) or bytes. If the LENGTH_CONFIG bit is cleared, the TX_LENGTH field is specified in nibbles; if the LENGTH_CONFIG bit is set, the TX_LENGTH field is specified in bytes. For example, if LENGTH_CONFIG = 0 =nibbles and TX_LENGTH = 4, the transmitted Preamble length will be 4 nibbles = 16 bits. If LENGTH_CONFIG = 1= bytes and TX_LENGTH = 4, the transmitted Preamble length will be 4 bytes = 8 nibbles = 32 bits. The maximum Preamble length that may be specified is 255 bytes = 510 nibbles = 2040 bits.
It is possible to obtain a Preamble of length zero by simply setting the TX_LENGTH [7:0] field=0x00. In such a case, the transmission of the Preamble is skipped entirely and the next field (e.g., Sync Word) will be the first transmitted field. If the user desires a Preamble whose length exceeds 255 bytes, it is not possible to use the PH.In such a case, it will be necessary to disable the Preamble and Sync Word fields and to program the entire packet structure in the FIFO memory, or to construct the entire packet structure in the host MCU and to provide it to the RFIC in real-time over a physical input pin (i.e., TX Direct mode).
The TX_LENGTH [7:0] field is normally used only in TX mode. There is no purpose to specifying a Preamble length in RX mode during reception of a Standard Preamble (i.e., 1010 or 0101 pattern), as the chip does not use prior knowledge of the length of the Preamble field in determining when the Sync Word field begins. However, in RX mode during reception of a Non-Standard Preamble this property should be configured with the expected
AN626
4
Rev. 0.2
Preamble length; this provides an upper timeout limit on the Sync Word search algorithm.Figure
4.Property 0x1000 PREAMBLE_TX_LENGTH, Length of TX Preamble
3.1.3. Configuration of Non-Standard Preamble Pattern When operation with a non-standard Preamble pattern has been selected by setting STANDARD_PREAM=2’b00,it is additionally necessary to specify the desired non-standard pattern. There are two aspects to configuring the non-standard Preamble pattern:
? Setting the number of bits that will be repeated (PATTERN_LENGTH)
? Configuring the actual value of this repetitive pattern (PREAMBLE_PATTERN_31_0)
Figure 5.Property 0x1002 PREAMBLE_CONFIG_NSTD, Length of Non-Standard Pattern
The PATTERN_LENGTH[4:0] field in the PREAMBLE_CONFIG_NSTD property 0x1002 is used to specify the number of valid pattern bits to be repeated. The number of bits in the repeating pattern is the value of this field + 1bit. This field does not affect the total length of the transmitted Preamble; the length of the TX Preamble is specified by the TX_LENGTH[7:0] field as discussed above. Thus the non-standard pattern will repeat a number of times equal to (TX_LENGTH_in_bytes * 8) / (PATTERN_LENGTH + 1). As an example, if the TX_LENGTH field was set to 7 bytes = 56 bits and PATTERN_LENGTH[4:0] = 5’b00111 = 8 bits, the programmed non-standard preamble pattern will be repeatedly transmitted a total of 7 times.
The actual value of the repetitive pattern is specified in the PREAMBLE_PATTERN_31_0 properties 0x1005-0x1008. The pattern is always sent in order of bits 0-31, time-wise (i.e., little-endian). It is not necessary to specify the values of unused bits of the PREAMBLE_PATTERN field.
As an example, if the PATTERN_LENGTH field is set = 5’b00111 = 8 bits, and the PREAMBLE_PATTERN_7_0field is set = 0xA7, the pattern of bits transmitted over the air interface will be 11100101 11100101 (repeating).
It is self-evident from the length of the PREAMBLE_PATTERN field (as well as the maximum possible value of the PATTERN_LENGTH field) that the maximum length of the repetitive pattern is 32 bits.
If Manchester encoding/decoding is enabled, the values of the PREAMBLE_PATTERN_31_0 properties are expressed in chips (i.e., after Manchester encoding in TX mode, or before Manchester decoding in RX mode).
AN626
Rev. 0.2
5
Figure 6.Property 0x1005-08 PREAMBLE_PATTERN_31_0, Non-Standard Preamble Pattern
3.1.
4. Manchester Encoding Across the Preamble
Manchester Encoding of the Preamble is configured through the PREAMBLE_CONFIG property 0x1004.Manchester Encoding of the Preamble field is enabled by setting the MAN_ENABLE bit D2 of this property.
Figure 7.Property 0x1004 PREAMBLE_CONFIG, Manchester Encoding Options
Manchester encoding works by replacing each data bit by two data bits. The two replacement data bits are of opposite polarity (i.e., either a 10 or 01 pattern), thus ensuring a balanced number of 1’s and 0’s and regular edge transitions. The effective data rate is unchanged but the actual number of bits on the air interface is doubled. The normal encoding polarity is such that a 1 data bit is encoded to a 01 Manchester bit pattern, while a 0 data bit is encoded to a 10 Manchester bit pattern.
However, performing Manchester encoding across the Preamble field presents potential difficulties. As a normal Preamble already consists of a “1010…” pattern that contains regular bit transitions, there is little need for encoding to ensure dc-free transmission. Furthermore, if normal Manchester encoding is applied to a “1010…” pattern, the result would be a “011001100110…” pattern at twice the data rate, and thus not discernible from the original pattern anyway. As a result, the Preamble field is handled in a special fashion when Manchester encoding is enabled. If the MAN_CONST bit D3 is additionally set, the pre-encoded Preamble field is internally replaced by a constant “1111…” or “0000…” pattern. After encoding, these sequences become “010101…” and “101010…”, respectively,
AN626
6
Rev. 0.2
which are the desired Manchester-encoded results. In this fashion, the Preamble-like structure of alternating 1’s and 0’s is retained, but now occurs at the desired chip rate. The pre-encoded pattern (i.e., “1111…” or “0000…”) is selected by the STANDARD_PREAM[1:0] field in bits D1-D0. If STANDARD_PREAM = 2’b01, the pre-encoded pattern is “0000…” such that the post-Manchester encoded pattern will be “101010…”. If STANDARD_PREAM = 2’b10, the pre-encoded pattern is “1111…” such that the post-Manchester encoded pattern will be “010101…”. The MAN_CONST bit has no effect unless the MAN_ENABLE bit is also set.
When using Manchester encoding, the effective data rate is limited to 250 kbps as the over-the-air data rate of Si446x chips is limited to 500 kbps in 2(G)FSK mode. Manchester encoding is not currently supported in 4(G)FSK mode.
It is not possible to perform data whitening across the Preamble field.
3.2. Sync Word Field
The Sync Word field is configured through the Sync property group 0x1100-0x1104. These properties may be used to configure such parameters as the number of bytes in the Sync Word and the actual value of the Sync Word bytes.
3.2.1. Transmitting/Skipping the Sync Word
Transmission of the Sync Word may be skipped completely by setting the SKIP_TX bit D7 of the SYNC_CONFIG property 0x1100. If this bit is cleared, the Sync Word is transmitted with a length (in bytes) as specified by the LENGTH[1:0] field. The SKIP_TX bit affects operation only in TX mode, and does not affect reception of the Sync Word.
Figure8.Property 0x1100 SYNC_CONFIG, General Sync Word Configuration Bits
It should be understood that operation without some form of Sync Word is not usually recommended. Although it is possible to set the SKIP_TX bit to prevent the PH from automatically transmitting a Sync Word, it is assumed that the user still provides a Sync Word in the packet structure by including it in the bytes stored in the TX FIFO. The receiver must usually detect the Sync Word to determine the start of the Payload Data fields, and thus some form of Sync Word must nearly always be present in the packet.
3.2.2. Setting the Length of the Sync Word
When the SKIP_TX bit is cleared, the length of the Sync Word is specified by the value of the LENGTH[1:0] field in the SYNC_CONFIG property 0x1100. The length of the Sync Word is equal to LENGTH[1:0] + 1, in bytes. As the value of the LENGTH field can range from 0 to 3, the number of bytes in the Sync Word can range from 1 to 4 bytes. For example, a value of LENGTH[1:0] = 2’b00 corresponds to a length of 1 byte, while a value of LENGTH[1:0] = 2’b11 corresponds to a length of 4 bytes.
3.2.3. Setting the Values of the Sync Word Bytes
The actual values of the Sync Word bytes are specified in the SYNC_BITS_31_0 properties 0x1101-0x1104.
AN626
Rev. 0.2
7
Figure 9.Property 0x1101-04 SYNC_BITS_31_0, Sync Word Value(s)
The Sync Word bytes are transmitted in descending order. Thus if LENGTH[1:0] = 2’b00 (corresponding to a Sync Word of 1 byte length), then only Sync Word 3 (SYNC_BITS_31_24) is transmitted. If LENGTH[1:0] = 2’b01(corresponding to a Sync Word of 2 bytes length), then Sync Word 3 is transmitted first, followed by Sync Word 2(SYNC_BITS_23_16), and so on. Values programmed into Sync Word bit fields are ignored if the LENGTH[1:0]field is not configured for a Sync Word length that requires use of those SYNC_BIT fields. (e.g., SYNC_BITS_7_0are ignored if LENGTH[1:0] 2’b11.)
Each Sync Word byte is transmitted in little-endian fashion (bit 0 first, bit 7 last). Example: a 2-byte Sync Word defined with a value of 0x2DD4=16’b0010 1101 1101 0100 is transmitted over the air interface as 0xB42B=16’b1011 0100 0010 1011.
3.2.
4. Manchester Encoding Across the Sync Word
Manchester encoding of the Sync Word is enabled by setting the MANCH bit D2 of the SYNC_CONFIG property 0x1100. The polarity of the Manchester encoding is determined by the MANCH_POL bit D3 in the PKT_CONFIG1property 0x1206 (see “3.3.1. General Configuration Bits for TX Packet Data Fields” ). (The MANCH_POL configuration determines the polarity of Manchester encoding across all packet fields except the Preamble.)
Figure 10.
Property 0x1100 SYNC_CONFIG, Manchester Encoding Options
AN626
8
Rev. 0.2
3.2.5. 4(G)FSK Modulation Across the Sync Word
4(G)FSK modulation across the Sync Word is enabled by setting the 4FSK bit D3 of the SYNC_CONFIG property 0x1100. This enables the PH to encode the data bits of the Sync Word in the proper fashion to deliver to the Modem; it remains necessary to additionally configure the Modem to operate in 4(G)FSK mode (i.e., configure the MODEM_MOD_TYPE property 0x2000).
3.3. Data Field(s) in TX Mode
The Si446x family of chips provides for up to five independently configurable Data fields. The functionality of each Data field is configured through the Packet property group 0x1200-0x1234. These properties may be used to configure such parameters as the length of each Data field, enabling of Manchester encoding, enabling of data whitening, etc. The length of one (or more) of the Data fields may be re-configured on a packet-by-packet basis in order to accommodate variable-length packet structures.
There is no hard-coded mapping of functionality or content to a specific Data field; the content or “meaning” of a given Data field is exactly what the user intends, and no more. While it may be customary for the order of Data fields to occur in the sequence of Header-Packet_Length-Payload, there is no mandatory requirement for the field content to be defined in this fashion.
The total length of the Data Field is calculated as the sum of the lengths of each individual field. A sufficient number of bytes of data are retrieved from the TX FIFO as required to fill all specified fields. For example, if Field 1 length is set to 4 bytes, Field 2 length is set to 8 bytes, and Field 3 length is set to 5 bytes, then a total of 17 bytes will be retrieved from the TX FIFO for each transmitted packet. These 17 bytes of data will be allocated among the three fields as specified by the individual field lengths. It is the responsibility of the user to store the bytes into the TX FIFO in such an order as to have the intended meaning upon reception at the RX side of the link.
The primary purpose of providing multiple Data fields (instead of only one Data field) is to allow individual configuration of each field with respect to parameters such as Manchester encoding, data whitening, or CRC calculation. Thus it is possible (for example) to enable Manchester encoding on only Field 1, data whitening on only Field 2, and CRC calculation on only Field 3, and so on. This provides for compatibility with a wide range of data protocols and regulatory standards. If there is no need for custom processing of individual fields, then it is only necessary to configure the PH for one Data field and all transmit data bytes may be packed into that field.
Certain properties must be set that have a global effect across all Data fields in use. These properties include specifying bit order (MSB or LSB first), CRC bit inversion, and Manchester encoding/decoding polarity. Other types of properties must be set to individually configure each Data field in use. These properties include the length of each field, enabling of Manchester encoding across the field, enabling of data whitening across the field, and enabling of CRC calculation across the field. Certain additional unique properties must be configured for Field 1 that need not be configured for subsequent fields.
3.3.1. General Configuration Bits for TX Packet Data Fields
General configuration bits for the TX Data fields may be configured in the PKT_CONFIG1 property at 0x1206.
Figure11.Property 0x1206 PKT_CONFIG1, General Packet Configuration Bits
The PH_FIELD_SPLIT bit D7 may be used to specify sharing or splitting of the Data field-level properties between TX and RX mode. In many applications, it is desirable to transmit and receive identical packet structures; in such a case, the same configuration of Data field properties may be used in both TX and RX mode. This is specified by clearing the PH_FIELD_SPLIT bit and configuring the various PKT_FIELD properties discussed in the following sections. However, in other applications an asymmetric link is desirable, in which the length and configuration of the TX packet is different than that of the RX packet. (One common example would be that of a short TX ACK message in response to correctly receiving a packet.) This may be specified by setting the PH_FIELD_SPLIT bit, and subsequently specifying the TX Data field properties in 0x120D to 0x1220 and the RX Data field properties in
AN626
Rev. 0.2
9
0x1221 to 0x1234.
The MANCH_POL bit D3 may be used to specify the polarity of Manchester encoding used by all Data fields. If MANCH_POL = 0, a 0 data bit is encoded to a 10 Manchester bit pattern and a 1 data bit is encoded to a 01Manchester bit pattern. If MANCH_POL =1, a 0 data bit is encoded to a 01 Manchester bit pattern and a 1 data bit is encoded to a 10 Manchester bit pattern.
The CRC_INVERT bit D2 may be used to invert only the transmitted CRC bits. If CRC_INVERT = 0, the CRC bits are transmitted normally (without inversion). If CRC_INVERT = 1, only the CRC bits are inverted before transmission; all remaining bits of the Data fields are transmitted normally.
The CRC_ENDIAN bit D1 may be used to specify which bytes of the CRC checksum are transmitted first. If CRC_ENDIAN = 0, the low bytes of the CRC checksum(s) are transmitted first. If CRC_ENDIAN = 1, the high bytes of the CRC checksum(s) are transmitted first.
The BIT_ORDER bit D0 may be used to specify which bit of the bytes in the Data field(s) are transmitted first. If BIT_ORDER = 0, the MSB is transmitted first time-wise for all Data fields. If BIT_ORDER = 1, the LSB is transmitted first time-wise for all Data fields. This bit does not affect the Preamble or Sync fields; the LSB is always transmitted first for the Preamble and Sync fields.
3.3.2. Setting the Field Length
The length of each individual Data field is configured by the PKT_FIELD_X_LENGTH_12_0 properties starting at 0x120D-0E, where “X" ranges from 1 to 5. This property specifies the length of the corresponding field in bytes. A value of zero in this property means that this field is not used. Data bytes will be retrieved from the TX FIFO and populated into fields until the first field with LENGTH = 0 bytes is encountered, or until all five fields are populated (in the event that all fields have a non-zero length). Thus it is not possible to (e.g.) configure Field 1 and Field 3 for non-zero length and to set Field 2 length = 0 bytes; the TX FIFO will populate only Field 1 and will stop upon encountering unused Field 2.
Figure 12.Property 0x120D-0E PKT_FIELD_1_LENGTH_12_0, Field 1 Length
3.3.3. Configuring Field-Specific Processing
Processing functions such as Manchester encoding, data whitening, and 4(G)FSK modulation may be enabled or disabled on each individual Data field. These processing functions are configured by the PKT_FIELD_X_CONFIG properties starting at 0x120F, where “X" ranges from 1 to 5. The various bits that may be configured are as follows:
? MANCH bit D0: if set, enables Manchester encoding across the selected field
? WHITEN bit D1: if set, enables data whitening across the selected field
? PN_START bit D2: if set, loads the PN engine with the seed value at the start of the selected field. (This property is only available for Field 1; it is not possible to re-start the PN engine at the start of any other Data field.)
? 4FSK bit D4: if set, enables 4(G)FSK processing across the selected field. The Modem must be
additionally configured for 4(G)FSK modulation through appropriate setting of the MODEM_MOD_TYPE property; the 4FSK bit simply configures the PH to process the data stream from the TX FIFO as bit pairs
(instead of as single bits for 2(G)FSK mode). Simultaneous enabling of Manchester encoding while in
AN626
10
Rev. 0.2
4(G)FSK mode is currently not supported.
Figure 13.Property 0x120F PKT_FIELD_1_CONFIG, Field 1 Custom Processing 3.3.4. Configuring Field-Specific CRC Calculation
CRC checksum calculation may be enabled or disabled on each individual Data field. The CRC functions are configured by the PKT_FIELD_X_CRC_CONFIG properties starting at 0x1210, where “X" ranges from 1 to 5. The
various bits that are applicable to TX mode are as follows:? CRC_ENABLE bit D1: if set, calculation of the CRC checksum is enabled across the selected field.
? SEND_CRC bit D5: if set, the CRC checksum is appended to and transmitted at the end of the selected field.
? CRC_START bit D7: if set, loads the CRC engine with the seed value at the start of the selected field. (This property is only available for Field 1; it is not possible to re-start the CRC engine at the start of any other Data field.)
Figure 14.Property 0x1210 PKT_FIELD_1_CRC_CONFIG, Field 1 CRC Configuration
While it is usually customary to send only one CRC checksum at the very end of the packet structure, the PH may be configured to transmit a CRC checksum after any desired Data field (or after more than one Data field, if desired). The calculation of the CRC checksum may also span across non-contiguous Data fields. Thus it is possible (for example) to enable CRC across Field 1 and Field 3, but to disable it across Field 2.
3.3.5. Selection of the CRC Polynomial
Selection of the CRC polynomial is done by the PKT_CRC_CONFIG property at 0x1200. The selected polynomial is applied to each and every field for which CRC calculation has been enabled; it is currently not possible to use more than one CRC polynomial within the same packet. The seed value for the polynomial is determined by CRC_SEED bit D7. If CRC_SEED = 0, then all 0’s are used for the CRC seed value; if CRC_SEED = 1, then all 1’s are used for the CRC seed value.
Figure 15.Property 0x1200 PKT_CRC_CONFIG, Global CRC Polynomial Configuration
The CRC polynomial is selected by the CRC_POLYNOMIAL[3:0] field as follows:
? 0 = No CRC (polynomial coefficients are all 0s)
? 1 = X8 + X2 + X + 1
AN626
Rev. 0.2
11
? 2 = X16 + X14 + X12 + X11 + X9 + X8 + X7 + X4 + X + 1
? 3 = X16 + X15 + X12 + X7 + X6 + X4 + X3 + 1
? 4 = X16 + X15 + X2 +1
? 5 = X16 + X12 + X5 + 1
? 6 = X32+X30+X29+X28+X26+X20+X19+X17+X16+X15+X11+X10+X7+X6+X4+X2+X+1
? 7 = X32+X26+X23+X22+X16+X12+X11+X10+X8+X7+X5+X4+X2+X+1
? 8 = X32+X28+X27+X26+X25+X23+X22+X20+X19+X18+X14+X13+X11+X10+X9+X8+X6+1
Selection of CRC_POLYNOMIAL=0 does not result in disabling of CRC generation/checking, but instead sets the CRC polynomial coefficients to all zeroes. The proper method of disabling CRC is by clearing the CRC_ENABLE bit(s) in the appropriate PKT_FIELD_X_CRC_CONFIG properties.
3.3.6. Construction of a Variable Length TX Packet
The concept of a variable length packet in has little meaning in TX mode. There is no means of specifying a field as automatically variable in length when in TX mode; the length of each field is simply defined by its corresponding PKT_FIELD_X_LENGTH_12_0 property value. If all PKT_FIELD_X_LENGTH properties do not change from packet to packet, the packet is fixed in length. If one of the PKT_FIELD_X_LENGTH properties is re-programmed and modified between successive packets, the packet is (by definition) variable in length.
There are two methods by which TX packets with differing lengths may be constructed:
? Invoke the START_TX command with the TX_LEN parameter set to the desired number of bytes for each packet.
? Between packets, reconfigure the appropriate PKT_FIELD_X_LENGTH property for the desired number of bytes.
The first method is by far the simplest of the two methods. In this scenario, the number of data bytes specified by the TX_LEN parameter (passed to the START_TX command) are retrieved from the TX FIFO and packed into Data Field 1; there is no need to additionally configure the PKT_FIELD_1_LENGTH property on a packet-to-packet basis.
However, the downside of this approach is that all of the transmit data bytes are populated into Data Field 1, and thus there is no ability to apply different processing functions (i.e., Manchester encoding, data whitening, CRC checksum calculation) across different fields. When invoking the START_TX command with a passed TX_LEN parameter, the settings for the processing functions are taken from the existing settings for Field 1. If custom processing functions are required across different Data fields, it is necessary to invoke the START_TX command with a passed TX_LEN parameter of zero bytes and then fully configure each desired Data Field, as described in the sections above. If the START_TX command is invoked with a non-zero value for the TX_LEN parameter, any previously-configured value of the PKT_FIELD_1_LENGTH_12_0 property is overwritten by the passed TX_LEN_value.
For variable length packets, the RX side of the link obviously requires information regarding the packet length in order to correctly receive the packet. This packet length information is not automatically inserted into the transmitted packet structure. It is necessary for the user to explicitly load byte(s) containing the packet length information into the TX FIFO buffer, where they are retrieved and transmitted as any other data byte. Thus it is very important for the user to ensure that the correct value(s) of bytes are loaded into the TX FIFO at the location in the packet structure where the RX node expects to receive the packet length information.
In a similar fashion, Header or Match bytes are also not automatically inserted or appended to the transmit packet structure; it is necessary to explicitly load them into the TX FIFO for transmission with each packet.
3.3.7. Match (Header Bytes) in TX Packet
The Si446x family of chips provides for fully configurable Matching functionality on up to 4 data bytes in the Data Field(s) of the packet. The Match functionality is performed on the RX node, and thus there is no special configuration required to enable Match functionality on the TX side of the link. It is simply necessary for the user to ensure that the correct value(s) of bytes are loaded into the TX FIFO at the location(s) in the packet structure where the RX node expects to receive the Match byte(s). The chip does not automatically insert pre-defined Match byte(s) into the packet structure; they must be explicitly loaded into the TX FIFO by the user. On the TX side of the link these bytes appear as any other data bytes loaded into the TX FIFO. The intended meaning of each byte in the
AN626
12
Rev. 0.2
TX FIFO cannot be inferred until the configuration of the corresponding RX node is defined.
3.3.8. Setting the TX FIFO Almost Empty Threshold
The TX FIFO is 64 bytes in length. Packets of greater length may be accommodated by making use of a programmable threshold contained in the PKT_TX_THRESHOLD property at 0x120B.Figure
16.Property 0x120B PKT_TX_THRESHOLD, TX Almost Empty Threshold
The TX_THRESHOLD[7:0] field in this property specifies the TX FIFO Almost Empty Threshold, in number of bytes. When enough data has been shifted out of the TX FIFO such that the remaining empty space in the buffer is equal to or exceeds the almost empty threshold value, an interrupt will be generated. The host microcontroller must switch out of TX mode or fill more data into the TX FIFO.
4. Packet Handler in RX Mode
The functionality of the PH may be enabled or disabled in RX mode. Enabling/disabling of the PH functionality is provided in Property 0x1206 PKT_CONFIG1 by the PH_RX_DISABLE bit D6. The PH may only be disabled when the chip is operated in RX Direct mode; the functionality of the PH is required when operating in RX FIFO mode.Furthermore, the PH must remain enabled in some applications in Direct mode. One such example is reception of a packet with non-standard Preamble; while detection of a standard Preamble structure is performed in the Modem, detection of a non-standard Preamble is performed in the PH and thus it must remain enabled, even in Direct mode.
Figure 17.Property 0x1206 PKT_CONFIG1, General Packet Configuration Bits
4.1. Preamble Field
The Preamble field is configured through the Preamble property group 0x1000-0x1008. These properties may be used to configure parameters such as selection of a standard or non-standard preamble pattern, preamble detection threshold, and invalid preamble timeout.
4.1.1. Selection of Standard or Non-Standard Preamble
Selection of standard or non-standard Preamble pattern is specified by the STANDARD_PREAM[1:0] field in the PREAMBLE_CONFIG property 0x1004. A standard preamble pattern is one that consists of an alternating pattern of 1’s and 0’s, such as a 1010 pattern or a 0101 pattern. A 1010 pattern may be selected by setting STANDARD_PREAM = 2’b01, while a 0101 pattern may be selected by setting STANDARD_PREAM = 2’b10.Selection of either of those two standard preamble patterns results in identical operation in RX mode; the receiver cannot ensure that it received the first bit of the transmission as it may have been enabled in mid-packet, and thus cannot tell the difference between the two patterns anyway.
A non-standard preamble pattern is any regularly-repeating pattern that does not consist of alternating 1’s and 0’s.An example of a non-standard preamble pattern might be 11101110. Operation with a non-standard pattern may be selected by setting STANDARD_PREAM = 2’b00. It is necessary to additionally specify the actual structure of the non-standard repeating pattern, as discussed in “3.1.3. Configuration of Non-Standard Preamble Pattern” .
From the standpoint of the receiver, selection of standard or non-standard preamble determines whether the
AN626
Rev. 0.2
13
qualification of the Preamble is performed in the Modem or in the PH. Qualification of the Preamble (i.e.,generation of a PREAMBLE_VALID signal) is optimized when performed in the Modem, but is not possible when the pattern is not a regularly-alternating pattern of 1’s and 0’s.
Figure 18.Property 0x1004 PREAMBLE_CONFIG, Standard/Non-Standard Preamble Selection 4.1.2. Configuration of Non-Standard Preamble Pattern
When operation with a non-standard Preamble pattern has been selected by setting STANDARD_PREAM = 2’b00,it is additionally necessary to specify the desired non-standard pattern to be received. There are two aspects to configuring the non-standard Preamble pattern:
? Setting the number of bits that will be repeated (PATTERN_LENGTH)
? Configuring the actual value of this repetitive pattern (PREAMBLE_PATTERN_31_0)
Figure 19.Property 0x1002 PREAMBLE_CONFIG_NSTD, Length of Non-Standard Pattern
A complete discussion of the configuration of these properties was provided in “3.1.3. Configuration of Non-Standard Preamble Pattern” and will not be repeated here.
4.1.3. Preamble Detection Threshold
The Modem/PH provides Preamble Detection functionality to qualify reception of a signal with a valid Preamble.Preamble detection in the Modem of Standard Preambles remains available even if the PH_RX_DISABLE bit is set in property PKT_CONFIG1 at 0x1206. Preamble detection in the PH (required for reception of non-standard Preambles) is not available if the PH_RX_DISABLE bit is set.
The Preamble Detector circuitry searches for a minimum number of consecutive Preamble pattern bits (e.g.,“0101…’ for a standard Preamble), as specified in the RX_THRESH[6:0] field in the PREAMBLE_CONFIG_STD_1property at 0x1001. The value in this field corresponds to the number of consecutive bits that must be received correctly before a valid Preamble is considered to have been received. The RX_THRESH [6:0] value only specifies the threshold for detection of Standard Preambles; the detection threshold for Non-Standard Preambles is specified by the PREAMBLE_CONFIG_NSTD: PATTERN_LENGTH parameter.
Figure 20.Property 0x1001 PREAMBLE_CONFIG_STD_1, Preamble Detection Threshold
Upon correctly receiving the number of Preamble bits specified by the RX_THRESH[6:0] field, the chip issues a PREAMBLE_DETECT signal. The PREAMBLE_DETECT signal generated by the Modem (for qualification of
AN626
14
Rev. 0.2
Standard Preamble patterns) may be directly observed as an output on a GPIO pin as selected by the GPIO_PIN_CONFIG command; the PREAMBLE_DETECT signal generated by the PH (for qualification of Non-Standard Preamble patterns) is not currently selectable as an output signal on a GPIO pin. A typical PREAMBLE_DETECT signal is shown in Figure21. If Sync Word is successfully detected, the PREAMBLE_DETECT signal remains high for the duration of the packet; if the Sync Word is not detected, the search for Sync Word times out and the chip returns to searching for another Preamble. The chip may also be configured to generate an interrupt upon detection of the PREAMBLE_DETECT signal.
Detection of the Preamble is normally required for proper reception of the packet. Prior to issuing the PREAMBLE_DETECT signal, the bit clock recovery (BCR) circuitry operates in fast tracking mode. This allows for fast acquisition of bit clock timing, but results in higher clock jitter. If the chip were to remain in this fast tracking mode during the reception of the remainder of the packet, bit errors would likely result due to this excess clock jitter. Acquisition of the PREAMBLE_DETECT signal is commonly used as the gear switching event that signals the chip to switch to a slow tracking mode, resulting in lower clock jitter and error-free reception of bits.
However, it is possible to completely skip detection of the Preamble. A value of RX_THRESH[6:0] = 0 is a legal value, and results in skipping the Preamble Detection process. The chip will issue a PREAMBLE_DETECT signal immediately upon entering RX mode (i.e., a constant HIGH signal). This setting is likely useful only in applications in which there is no well-defined Preamble pattern, and it is desired to immediately proceed to searching for Sync Word.
Figure21.Typical PREAMBLE_DETECT and SYNC_DETECT Signals
4.1.4. Allowed Errors During Preamble Detection
If the Preamble Detection functionality is provided by the PH (as configured by selecting reception of a non-standard Preamble), it is possible to configure the PH to tolerate a small number of errors and yet consider the pattern as valid. The number of errors to be tolerated is specified by the RX_ERRORS[2:0] field in the PREAMBLE_CONFIG_NSTD property 0x1002, in number of bits. This field applies only to reception of a non-standard Preamble; no bit errors are tolerated during reception of a standard Preamble pattern by the detection circuitry based in the Modem. However, it is possible to select reception of a non-standard Preamble (thus enabling
AN626
Rev. 0.2
15
the PH-based detection circuitry) but program the expected pattern to be a “1010…’ pattern (i.e., a standard Preamble). It would possible to then use the RX_ERRORS field to specify the number of bit errors to be tolerated during reception of a standard Preamble pattern.Figure
22.Property 0x1002 PREAMBLE_CONFIG_NSTD, Allowed Errors During Non-Std Preamble
4.1.
5. Preamble Detection Timeout
The chip may be configured to provide an indication if a valid Preamble is not detected within a given period of time. This functionality is useful when rapidly scanning channels for the detection of a valid signal, as in a frequency hopping system. Support of two different frequency hopping scenarios is provided:
? The transmitter sends a very long Preamble, providing sufficient time for a receiver to rapidly scan all channels to search for the signal
? The transmitter rapidly hops through all channels, while the receiver waits on one channel for the
transmitter to arrive on that frequency
In the first scenario, a short timeout period is desirable; the receiver must spend the minimum amount of time possible on a given channel to verify the presence or absence of a valid signal such that enough time remains to hop through all the remaining channels in the frequency plan. This short timeout period is set by the RX_PREAMBLE_TIMEOUT[3:0] field in the PREAMBLE_CONFIG_STD_2 property 0x1003, and is specified in number of nibbles (4 bits). The RX_PREAMBLE_TIMEOUT_EXTEND[3:0] field must also be set = 0. If a PREAMBLE_DETECT signal is not issued before the timeout period specified by this field, the chip issues an INVALID_PREAMBLE signal. The chip may also be configured to generate an interrupt upon detection of an INVALID_PREAMBLE signal. The value of the RX_PREAMBLE_TIMEOUT field is typically set to a slightly higher value (in bits) than the RX_THRESH[6:0] field. In this fashion, the chip is allowed to search for Preamble for only a slightly longer period of time than the specified Preamble Detection Threshold, and is forced to hop soon after that period of time expires. The timeout period must be sufficient in length to allow for the group delay through the receiver chain (~2*Tb to ~4*Tb), the time required for the Bit Clock Recovery (BCR) circuit to acquire bit timing (~4*Tb to 8*Tb), and the time required to settle AFC (~4*Tb to 8*Tb, if enabled), in addition to the number of the bits specified for the Preamble Detection Threshold.
Figure 23.Property 0x1003 PREAMBLE_CONFIG_STD_2, Preamble Detection Timeout
In the second scenario, a very long timeout period is desirable; the receiver must wait on one channel for a sufficient length of time to allow the transmitter to hop to it. This long timeout period is set by configuring the RX_PREAMBLE_TIMEOUT_EXTEND[3:0] field for a non-zero value; in such a case, the value of the RX_PREAMBLE_TIMEOUT[3:0] field is ignored. The timeout period of the RX_PREAMBLE_TIMEOUT_EXTEND function is specified in increments of 15 nibbles (15 x 4 bits = 60 bits); a value of 4’b0101 = 5 in this field would result in an extended timeout period of 5 x 15 = 75 nibbles = 300 bits. If a PREAMBLE_DETECT signal is not issued before the timeout period specified by this field, the chip issues an INVALID_PREAMBLE signal. The chip
AN626
16
Rev. 0.2
may also be configured to generate an interrupt upon detection of an INVALID_PREAMBLE signal.
4.2. Detection of Sync Word Field
The PH provides Sync Word Detector functionality to verify that the packet is intended for the receiver in use. This functionality is available only when the PH is enabled by clearing the PH_RX_DISABLE bit D6 of the PKT_CONFIG1 property 0x1206, as the detection of the Sync Word is performed in the PH. Detection of the Sync Word is required for operation in FIFO Mode, as the chip uses the Sync Word to detect the start of the Payload Data field(s) that will be stored in the RX FIFO.
The Sync Word field is configured through the Sync property group 0x1100-0x1104. These properties may be used to configure such parameters as the number of bytes in the Sync Word and the actual value of the Sync Word bytes.
4.2.1. Setting the Length of the Sync Word
The length of the expected Sync Word is specified by the value of the LENGTH[1:0] field in the SYNC_CONFIG property 0x1100. The length of the Sync Word is equal to LENGTH[1:0] + 1, in bytes. As the value of the LENGTH field can range from 0 to 3, the number of bytes in the Sync Word can range from 1 to 4 bytes. For example, a value of LENGTH[1:0] = 2’b00 corresponds to a length of 1 byte, while a value of LENGTH[1:0] = 2’b11 corresponds to a length of 4 bytes.
Figure24.Property 0x1100 SYNC_CONFIG, General Sync Word Configuration Bits
4.2.2. Setting the Values of the Sync Word Bytes
The actual values of the expected Sync Word bytes are specified in the SYNC_BITS_31_0 properties 0x1101-0x1104 (refer to Figure9).
The Sync Word Detector circuitry searches for the number of Sync Word bytes specified by the LENGTH[1:0] field in the SYNC_CONFIG property 0x1100. Because the length of Preamble may be much greater than the RX_THRESH[6:0] value, the PREAMBLE_DETECT signal may be detected quite early during the Preamble. Thus there may be a significant number of remaining bits of Preamble before the Sync Word actually starts. The Sync Word detection process does not begin until a non-Preamble bit is received; that is, a bit that clearly does not fit in with the selected pattern of Preamble bits is required to trigger the search for Sync Word. Thus it is strongly recommended that the user not specify a Sync Word that is similar to the Standard Preamble pattern (e.g., 0xAAh or 0x55h). The chip will remain searching until either the Sync Word is detected, or until the timeout period is exceeded. The timeout period is fixed at the length of the Sync Word plus 4 bits.
The Sync Word bytes are received in descending order. Thus if LENGTH[1:0] = 2’b00 (corresponding to a Sync Word of 1 byte length), then the first received byte of Sync Word is compared against the value specified in Sync Word 3 (SYNC_BITS_31_24). If LENGTH[1:0] = 2’b01 (corresponding to a Sync Word of 2 bytes length), then the first received byte is compared against Sync Word 3, followed by comparing the second received byte against the value specified in Sync Word 2 (SYNC_BITS_23_16), and so on. Values programmed into Sync Word bit fields are ignored if the LENGTH[1:0] field is not configured for a Sync Word length that requires use of those SYNC_BIT fields.
Although the Sync Word byte(s) are transmitted (and of course received) in little-endian fashion (bit 0 first, bit 7 last), the comparison values stored in SYNC_BITS_31_0 should be entered in big-endian fashion. For example, a desired 2-byte Sync Word pattern of 2DD4h should be entered as SYNC_BITS_31_24 = 0x2D and SYNC_BITS_23_16 = 0xD4 on both the TX and RX sides of the link, although the time-wise appearance of the bits on the air interface will be 0xB42B.
Upon correctly receiving the Sync Word byte(s), the chip issues a SYNC_DETECT signal. This signal may be
AN626
Rev. 0.2
17
directly observed as an output on a GPIO pin as selected by the GPIO_PIN_CONFIG command. A typical SYNC_DETECT signal is shown in Figure 21. The SYNC_DETECT signal remains high until the end of the packet.The PREAMBLE_DETECT signal does not go low upon detection of the SYNC_DETECT signal, but remains high for the duration of the packet. The chip may also be configured to generate an interrupt upon detection of the SYNC_DETECT signal.
If the PH fails to detect the Sync Word within the timeout period, the chip issues an INVALID_SYNC signal. The chip may also be configured to generate an interrupt upon generation of the INVALID_SYNC signal.
4.2.3. Sync Word Search Timeout
It is not possible to configure the PH to completely skip searching for the Sync Word. Detection of the Sync Word is recommended (but not absolutely required) for proper reception of the packet. Verification of the Sync Word is the chip’s primary method of determining whether the received packet is intended for it, or is coming from an undesired transmitter. Also, detection of the Sync Word is required to determine the start of the Payload Data fields, and thus data bytes cannot be stored into the RX FIFO if the Sync Word is not detected. Failure to detect the Sync Word normally results in the chip switching back to fast tracking mode and resuming search for another Preamble. Thus in order for the chip to remain in slow tracking mode (with resulting low clock jitter), it is important for the chip to detect the Sync Word.
However, it is possible to configure the chip to ignore the Sync Word search timeout. This is done by setting the SKIP_SYNC_TIMEOUT bit D7 in the PREAMBLE_CONFIG_STD_1 property at 0x1001. If this bit is set, the chip still searches for the Sync Word but doesn’t care if it is detected; the chip will remain in slow tracking mode and continue to search for Sync Word after expiration of the Sync Word timeout period.
Figure 25.Property 0x1001 PREAMBLE_CONFIG_STD_1, Skip Sync Word Timeout
4.2.4. Manchester Decoding Across the Sync Word
Manchester decoding of the Sync Word is enabled by setting the MANCH bit D2 of the SYNC_CONFIG property 0x1100. The polarity of the Manchester encoding is determined by the MANCH_POL bit D3 in the PKT_CONFIG1property 0x1206 (see “3.3.1. General Configuration Bits for TX Packet Data Fields” ). (This configuration bit determines the polarity of Manchester encoding across all packet fields except the Preamble.) The Manchester decoding function is performed before the result is compared with the Sync Word value(s) stored in SYNC_BITS_31_0; the values stored should match with the decoded result and not with the Manchester-encoded sequence.
Figure 26.Property 0x1100 SYNC_CONFIG, Manchester Decoding Options
4.2.
5. 4(G)FSK Demodulation Across the Sync Word
4(G)FSK processing of the Sync Word is enabled by setting the 4FSK bit D3 of the SYNC_CONFIG property 0x1100. This enables the PH to decode the data bits received from the Modem in the proper fashion (i.e., as bit pairs, instead of as single bits); it remains necessary to additionally configure the Modem to operate in 4(G)FSK mode (i.e., configure the MODEM_MOD_TYPE property 0x2000).
AN626
18
Rev. 0.2
4.3. Data Field(s) in RX Mode
The Si446x family of chips provides for up to five independently configurable Data fields. The functionality of each Data field is configured through the Packet property group 0x1200-0x1234. These properties may be used to configure such parameters as the length of each Data field, enabling of Manchester decoding, enabling of data de-whitening, etc. The length of one of the Data fields may be re-configured on a packet-by-packet basis in order to accommodate variable-length packet structures.
There is no hard-coded mapping of functionality or content to a specific Data field; the content or “meaning” of a given Data field is exactly what the user intends, and no more. While it may be customary for the order of Data fields to occur in the sequence (e.g.) of Header-Packet_Length-Payload, there is no mandatory requirement for the field content to be defined in this fashion. One restriction is that if a variable-length Data field is present in the packet, it must occur after the field that contains the byte(s) specifying the length of that variable field. Also, only one Data field of variable length may be defined in the packet.
The total length of the Data Field is calculated as the sum of the lengths of each individual field. All of the received data bytes following the Sync Word are stored into the RX FIFO; with the possible exception of the LENGTH byte(s), no attempt is made to “strip off” certain data bytes prior to placing them into the RX FIFO. It is the responsibility of the user to retrieve the bytes from the RX FIFO and to process them in such a fashion as to have the intended meaning during transmission at the TX side of the link.
The primary purpose of providing multiple Data fields (instead of only one Data field) is to allow individual configuration of each field with respect to parameters such as Manchester decoding, data de-whitening, CRC checksum calculation, or logic matching (i.e., Header functionality). Thus it is possible (for example) to enable Manchester decoding on only Field 1, data de-whitening on only Field 2, and CRC checksum calculation on only Field 3, and so on. This provides for compatibility with a wide range of data protocols and regulatory standards. If there is no need for custom processing of individual fields, then it is often only necessary to configure the PH for one Data field and all transmit data bytes may be packed into that field.
Certain properties must be set that have a global effect across all Data fields in use. These properties include specifying bit order (MSB or LSB first), CRC bit inversion, and Manchester encoding/decoding polarity. Other types of properties must be set to individually configure each Data field in use. These properties include the length of each field, enabling of Manchester decoding across the field, enabling of data de-whitening across the field, and enabling of CRC checksum calculation across the field. Certain additional unique properties must be configured for Field 1 that need not be configured for subsequent fields.
4.3.1. General Configuration Bits for RX Packet Data Fields
General configuration bits for the RX Data fields may be configured in the PKT_CONFIG1 property at 0x1206.
Figure27.Property 0x1206 PKT_CONFIG1, General Packet Configuration Bits
The PH_FIELD_SPLIT bit D7 may be used to specify sharing or splitting of the Data field-level properties between TX and RX mode. In many applications, it is desirable to transmit and receive identical packet structures; in such a case, the same configuration of Data field properties may be used in both TX and RX mode. This is specified by clearing the PH_FIELD_SPLIT bit and configuring the various PKT_FIELD properties discussed in the following sections. However, in other applications an asymmetric link is desirable, in which the length and configuration of the TX packet is different than that of the RX packet. (One common example would be that of a short TX ACK message in response to correctly receiving a packet.) This may be specified by setting the PH_FIELD_SPLIT bit, and subsequently specifying the TX Data field properties in 0x120D to 0x1220 and the RX Data field properties in 0x1221 to 0x1234.
The MANCH_POL bit D3 may be used to specify the polarity of Manchester encoding/decoding used by all Data fields. If MANCH_POL = 0, a 01 Manchester bit pattern is decoded to a 1 data bit while a 10 Manchester bit pattern is decoded to a 0 data bit. If MANCH_POL =1, a 01 Manchester bit pattern is decoded to a 0 data bit while a 10
AN626
Rev. 0.2
19
Manchester bit pattern is decoded to a 1 data bit.
The CRC_INVERT bit D2 may be used to invert only the received CRC bits, prior to comparison with the calculated CRC checksum. If CRC_INVERT = 0, the CRC bits are received normally (without inversion). If CRC_INVERT = 1, only the received CRC bits are inverted prior to comparison with the calculated CRC checksum;all remaining received Data field bits are stored in the RX FIFO without inversion.
The CRC_ENDIAN bit D1 may be used to specify which bytes of the CRC checksum are expected to be received first. If CRC_ENDIAN = 0, the low bytes of the CRC checksum(s) are assumed to have been transmitted first. If CRC_ENDIAN = 1, the high bytes of the CRC checksum(s) are assumed to have been transmitted first.
The BIT_ORDER bit D0 may be used to specify which bit of the bytes in the Data field(s) are assumed to have been transmitted first. If BIT_ORDER = 0, the MSB is assumed to have been transmitted first time-wise for all Data fields. If BIT_ORDER = 1, the LSB is assumed to have been transmitted first time-wise for all Data fields. This bit does not affect the Preamble or Sync fields; the LSB is always transmitted first for the Preamble and Sync fields.
4.3.2. Setting the Field Length
The length of each individual Data field is configured by the PKT_FIELD_X_LENGTH_12_0 properties starting at 0x120D-0E, where “X" ranges from 1 to 5. This property specifies the length of the corresponding field in bytes. A value of zero in this property means that this Data field is not used. Data bytes will be received in all non-zero length fields and stored into the RX FIFO until the first field with LENGTH = 0 bytes is encountered, or until all five fields are received (in the event that all fields have a non-zero length). Thus it is not possible to (e.g.) configure Field 1 and Field 3 for non-zero length and to set Field 2 length = 0 bytes; bytes for storage into the RX FIFO will be retrieved only from Field 1 and will stop upon encountering unused Field 2. In the event that a field is defined as variable in length (see “4.3.4. Reception of a Variable Length RX Packet” ), the PKT_FIELD_X_LENGTH property defines the maximum possible length of the field.
Figure 28.Property 0x120D-0E PKT_FIELD_1_LENGTH_12_0, Field 1 Length
4.3.3. Reception of a Fixed Length RX Packet
There are two methods by which a fixed length RX packet may be received.
? Invoke the START_RX command with the RX_LEN parameter set to the desired number of bytes for each packet.
? Between packets, reconfigure the appropriate PKT_FIELD_X_LENGTH property for the desired number of bytes.
The first method is by far the simplest of the two methods. In this scenario, the number of data bytes specified by the RX_LEN parameter (passed to the START_RX command) are assumed to all come from Data Field 1 and are stored into the RX FIFO; there is no need to additionally configure the PKT_FIELD_1_LENGTH property on a packet-to-packet basis.
However, the downside of this approach is that all of the receive data bytes are retrieved from Data Field 1, and thus there is no ability to apply different processing functions (i.e., Manchester encoding, data whitening, CRC checksum calculation) across different fields. When invoking the START_RX command with a passed RX_LEN
parameter, the settings for these processing functions are taken from the existing settings for Field 1. If custom
AN626
20
Rev. 0.2
processing functions are required across different Data fields, it is necessary to invoke the START_RX command with a passed RX_LEN parameter of zero bytes and then fully configure each desired Data Field, as described in the sections above. If the START_RX command is invoked with a non-zero value for the RX_LEN parameter, any previously-configured value of the PKT_FIELD_1_LENGTH_12_0 property is overwritten by the passed RX_LEN value.
4.3.4. Reception of a Variable Length RX Packet
It is possible to receive a packet whose Payload Data field length is not known in advance. In such a scenario, the transmit packet must contain byte(s) that specify the length of the variable field. There is no requirement for the length byte(s) to occur at one mandatory location in the packet (e.g., immediately following the Sync Word).However, the receiver must obviously know in advance which byte(s) of the received packet represent the length value. Furthermore, these length bytes must be located in the packet before the variable length field, else the PH in the receiver will not have the information in time to allocate the received data bytes to the appropriate Data field.It is first necessary to specify which of the five possible Data fields should be considered by the receiver as containing the byte(s) of the received length value. This is specified by the SRC_FIELD[2:0] value in the PKT_LEN_FIELD_SOURCE property 0x1209. The valid range of values of this field is from 0 to 4; the source field for the received length bytes cannot be Data Field 5, as it would then necessarily occur after the variable length field (an invalid condition). A value of SRC_FIELD = 0 is considered the same as selecting Data Field 1.
The source field that contains the variable field length byte(s) must necessarily be a fixed length field. That field may contain other bytes of information (e.g., Header bytes) in addition to the variable field length bytes; however,the variable field length byte(s) must occur as the very last byte(s) in that fixed length field.Figure
29.Property 0x1209 PKT_LEN_FIELD_SOURCE, Packet Length Source Field Once the source field containing the length byte(s) has been specified, it is necessary to specify the configuration
of those length byte(s). This configuration is accomplished by bits in the PKT_LEN property 0x1208.
The SIZE bit D4 specifies the number of bytes comprising the variable field length information. The received length value is either 1 byte in length (SIZE = 0) or 2 bytes in length (SIZE = 1). As mentioned previously, these byte(s)must be positioned at the very end of its field.
The ENDIAN bit D5 specifies whether the received length value is little-endian (byte-wise). If ENDIAN = 0, the length field is considered to be held as least significant byte first. If ENDIAN = 1, the received length value is considered to be held as most significant byte first.
The IN_FIFO bit D3 specifies whether or not the received length value will be stored into the RX FIFO. If IN_FIFO = 0, the data byte(s) comprising the received length value are stripped off and not stored in the RX FIFO. If IN_FIFO = 1, these bytes are stored in the RX FIFO.
Figure 30.Property 0x1208 PKT_LEN, Packet Length Bytes Configuration
Next, it is necessary to specify the destination field to which the length byte(s) refer. This is configured by setting the DST_FIELD[2:0] value in bits D2-D0. The valid range of values of this field is 0, and 2 to 5. A value of DST_FIELD = 0 indicates that there is no variable length Data field (i.e., fixed packet length mode). A value of
课程设计任务书
目录1．实验目的2．实验要求3．预备知识4．课程设计分析5．实现过程6．程序流程图7．相关扩展8．实习体会9．参考文献
一．实验目的： 设计一个解析IP数据包的程序,并根据这个程序,说明IP数据包的结构及IP协议的相关问题,从而IP层的工作原理有更好的理解和认识. 二．实验要求： 本设计的目标是捕获网络中数据包,解析数据包的内容,将、结果显示在标准输出上,并同时写入日志文件. 程序的具体要求如下: 3)以命令行形式运行:ipparse logfile,其中ipparse是程序名,而logfile则代表记录结果的日 志文件. 4)在标准输出和日志文件中写入捕获的IP数据包的版本,头长度,服务类型,数据包总长度, 数据包标识,分段标志,分段偏移值,生存时间,上层协议类型,头校验和,源IP地址和目的IP地址等内容. 当程序接收到键盘输入Ctrl+C时退出. 三.预备知识 互联网络层是TCP/IP协议参考模型中的关键部分.IP协议把传输层送来的消息组装成IP数据包,并把IP数据包传送给数据链层.IP协议在TCP/IP协议族中处于核心地位,IP协议制定了统一的IP数据包格式,以消除个通信子网中的差异,从而为信息发送方和接收方提供了透明的传输通道.编制本程序前,首先要对IP包的格式有一定了解,图1给出了IP协议的数据包格式. IP数据包的第一个字段是版本字段,其度是4位,表示所使用的IP协议的版本.目前的版本是IPV4,版本字段的值是4,下一代版本是IPV6,版本字段值是6.本程序主要针对版本是IPV4的数据包的解析. 报头标长字段为4位,它定义了以4B为一个单位的IP包的报文长度.报头中除了选项字段和填充域字段外,其他各字段是定长的.因此,IP数据包的头长度在20—40B之间,是可变的. 0 4 8 16 19 24 图1 IP数据包的格式 服务类型字段共8位,用于指示路由器如何处理该数据包.该字段长度由4位服务类型(TOS)子域和3位优先级子域组成,1位为保留位,该字段结构如图2所示. B7 b6 b5 b4 b3 b2 b1 b0
内核协议栈数据包转发 目录 1 NAPI流程与非NAPI 1.1NAPI驱动流程 1.2非NAPI流程 1.3NAPI和非NAPI的区别 2内核接受数据 2.1数据接收过程 2.2 采取DMA技术实现 3 e100采用NAPI接收数据过程 3.1 e100_open 启动e100网卡 3.2 e100_rx_alloc_list 建立环形缓冲区 3.3 e100_rx_alloc_skb 分配skb缓存 3.4 e100_poll 轮询函数 3.5 e100_rx_clean 数据包的接收和传输 3.6 e100_rx_indicate 4 队列层 4.1、软中断与下半部 4.2、队列层 5采用非NAPI接收数据过程 5.1netif_rx 5.2轮询与中断调用netif_rx_schedule不同点 5.3 netif_rx_schedule 5.4 net_rx_action 5.5 process_backlog 6数据包进入网络层 6.1 netif_receive_skb(): 6.2 ip_rcv(): 6.3 ip_rcv_finish(): 6.4 dst_input(): 6.5本地流程ip_local_deliver： 6.6转发流程ip_forward()： 1 NAPI流程与非NAPI 1.1NAPI驱动流程： 中断发生 -->确定中断原因是数据接收完毕（中断原因也可能是发送完毕，DMA完毕，甚至是中断通道上的其他设备中断） -->通过netif_rx_schedule将驱动自己的napi结构加入softnet_data的poll_list 链表，禁用网卡中断，并发出软中断NET_RX_SOFTIRQ -->中断返回时触发软中断调用相应的函数net_rx_action，从softnet_data的poll_list
TCP/IP协议与编程实验 姓名: 班级： 学号： 实验题目用Wireshark抓包分析ip数据包 一、实验目的 1、了解并会初步使用Wireshark，能在所用电脑上进行抓包 2、了解IP数据包格式，能应用该软件分析数据包格式 3、查看一个抓到的包的内容，并分析对应的IP数据包格式 二、实验内容 Wireshark 是网络包分析工具。网络包分析工具的主要作用是尝试捕获网络包，并尝试显示包的尽可能详细的情况。 实验步骤： 1、打开wireshark，选择接口选项列表。或单击“Capture”，配置“option” 选项。
2、设置完成后，点击“start”开始抓包： 3、显示结果： 3、选择某一行抓包结果，双击查看此数据包具体结构。
4、捕捉IP数据报。 ① 写出IP数据报的格式。 IP数据报首部的固定部分中的各字段含义如下： (1)版本占4位，指IP协议的版本。通信双方使用的IP协议版本必须一致。目前广泛使用的IP协议版本号为4（即IPv4）。 (2)首部长度占4位，可表示的最大十进制数值是15。请注意，这个字段所表示数的单位是32位字长（1个32位字长是4字节），因此，当IP的首部长度为1111时（即十进制的15），首部长度就达到60字节。当IP分组的首部长度不是4字节的整数倍时，必须利用最后的填充字段加以填充。因此数据部分永远在4字节的整数倍开始，这样在实现IP协议时较为方便。首部长度限制为60 字节的缺点是有时可能不够用。但这样做是希望用户尽量减少开销。最常用的首部
3)区分服务占8位，用来获得更好的服务。这个字段在旧标准中叫做服务类型，但实际上一直没有被使用过。1998年IETF把这个字段改名为区分服务 DS(Differentiated Services)。只有在使用区分服务时，这个字段才起作用。 (4)总长度总长度指首部和数据之和的长度，单位为字节。总长度字段为16位，因此数据报的最大长度为216-1=65535字节。长度就是20字节（即首部长度为0101），这时不使用任何选项。 (5)标识(identification) 占16位。IP软件在存储器中维持一个计数器，每产生一个数据报，计数器就加1，并将此值赋给标识字段。但这个“标识”并不是序号，因为IP是无连接服务，数据报不存在按序接收的问题。当数据报由于长度超过网络的MTU而必须分片时，这个标识字段的值就被复制到所有的数据报的标识字段中。相同的标识字段的值使分片后的各数据报片最后能正确地重装成为原来的数据报。 (6)标志(flag) 占3位，但目前只有2位有意义。 标志字段中的最低位记为MF(More Fragment)。MF=1即表示后面“还有分片”的数据报。MF=0表示这已是若干数据报片中的最后一个。 标志字段中间的一位记为DF(Don’t Fragment)，意思是“不能分片”。只有当DF=0时才允许分片。 7)片偏移占13位。片偏移指出：较长的分组在分片后，某片在原分组中的相对位置。也就是说，相对用户数据字段的起点，该片从何处开始。片偏移以8 个字节为偏移单位。这就是说，每个分片的长度一定是8字节（64位）的整数倍。 (8)生存时间占8位，生存时间字段常用的的英文缩写是TTL(Time To Live)，表明是数据报在网络中的寿命。由发出数据报的源点设置这个字段。其目的是防止无法交付的数据报无限制地在因特网中兜圈子，因而白白消耗网络资源。最初的设计是以秒作为TTL的单位。每经过一个路由器时，就把TTL减去数据报在路由器消耗掉的一段时间。若数据报在路由器消耗的时间小于1秒，就把TTL值减1。当TTL值为0时，就丢弃这个数据报。 ＃TTL通常是32或者64，scapy中默认是64 (9)协议占8位，协议字段指出此数据报携带的数据是使用何种协议，以便使目的主机的IP层知道应将数据部分上交给哪个处理过程。（在scapy中，下层的这个protocol一般可以从上曾继承而来，自动填充，我们一般可以省略不填此项） (10)首部检验和占16位。这个字段只检验数据报的首部，但不包括数据部分。这是因为数据报每经过一个路由器，路由器都要重新计算一下首部检验和
实验4 IP协议分析 在这个实验里，我们将研究IP协议，通过执行traceroute程序来分析IP数据包发送和接收的过程。我们将研究IP数据包的各个字段，详细学习IP数据包的分片。 一、捕获traceroute 为了产生一个IP数据包，我们将使用traceroute程序来向一些目的地发送不同大小的数据包，这个软件我们在第一个实验已作过简单的尝试了。 但我们试图在IP头部首先发送一个或者更多的具有TTL的数据包，并把TTL的值设置为1；然后向同一个目的地发送一系列具有TTL值为2的数据包；接着向同一个目的地发送一系列具有TTL值为3的数据包等等。路由器在每次接收数据包时消耗掉一个TTL，当TTL达到0时，路由器将会向源主机返回一个ICMP的消息（类型为11的TTL溢出），这样一个TTL值为1的数据包将会引起路由器从发送者发回一个ICMP的TTL溢出消息产生一跳，TTL值为2的数据包发送时会引起路由器产生两跳，TTL值为3的数据包则会引起路由器产生3跳。基于这种方式，主机可以执行traceroute观察ICMP的TTL溢出消息，记录每个路由器的ICMP的溢出消息的源IP地址，即可标识出主机和目的地之间的所有路由器。 我们要运行traceroute让它发送多种长度的数据包，由Windows提供的tracert程序不允许改变由tracert程序发送的ICMP的回复请求消息的大小，在Windows下比较好的一个是pingplotter，它可以在以下网站下载共享版本（现在已下载好存在共享文件夹的压缩包中）： 安装pingplotter标准版（你有一个30天的试用期），通过对你所喜欢的站点执行一些traceroute来熟悉这个工具。ICMP回复请求消息的大小可以在pingplotter中设置：Edit-> Options->Default Setting->enginet，在packet size字段中默认包的大小是56字节。pingplotter 发送一系列TTL值渐增的包时，Trace时间间隔的值和间隔的个数在pingplotter中能够设置。按下面步骤做： 1启动Iris，开始包捕获； 2启动pingplotter，然后在“Address to Trace”窗口输入目的地目标的名字： 172.16.1.1 （1岛输入172.16.6.1） 在“# of times to Trace”区域输入3。然后选择Edit-> Options->Default Setting->engine，确认在packet size字段的值为56，点OK。然后按下 Trace按钮。你看到的pingplotter窗口类似如上：
本文欢迎自由转载，但请标明出处，并保证本文的完整性。 作者：Godbach 日期：2009/09/01 Normal 7.8 磅 2 false false false MicrosoftInternetExplorer4 st1\:*{behavior:url(#ieooui) } /* Style Definitions */ table.MsoNormalTable {mso-style-name:普通表格; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan;
font-size:10.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;} 一、构造数据包简析 这里并不详细介绍如何在内核中构造数据包，下文如有需要会在适当的位置进行分析。这里简单的分析讲一下内核态基于Netfilter框架构造数据包的方式。 内核中可以用到的构造数据包的方式，个人认为可以分为两种。 其一，我们直接用alloc_skb申请一个skb结构体，然后根据实际的应用填充不同的成员，或者基于当前数据包的skb，调用skb_copy_expand()函数等新申请一个nskb，并且拷贝skb的内容。 其二，也是个人比较常用的，就是直接在先前接收到的数据包skb上作修改，主要有源IP、目IP，如果是TCP/UDP协议的话，还有源端口目的端口号。总之，就是根据自己的需求去调整数据包的相关成员即可。 通常，这两种方式最终可能都要涉及到重新计算各个部分的校验和，这也是必须的。 二、如何发送构造的数据包 承接上文，数据包已经构造完毕，下一步关键就是如何发送数据包了。个人这里总结的有两种方法。 方法一，就是让数据包接着按照Netfilter的流程进行传输。因为数据包的一些内容已经被更改，尤其是当源IP和目的IP被更改，主要是交换的情况下，是需要确保有路由可查的。 NF框架中查路由的位置一是在PREROUTING之后，而是在LOCALOUT之后。又由于这里是需要将数据包从本地发送出去。因此，可以考虑让修改后的数据包从LOCALOUT 点发出。 内核代码中有这种方式的典型体现。本文涉及的相关内核代码的版本都是2.6.18.3。源文件为ipt_REJECT.c，函数send_reset用于往当前接收到数据包的源IP上发送RST 包，整个函数涉及了数据包的构造和发送，这里一起做个简单分析。 /* Send RST reply */ static void send_reset(struct sk_buff *oldskb, int hook) { struct sk_buff *nskb; struct iphdr *iph = oldskb->nh.iph; struct tcphdr _otcph, *oth, *tcph; struct rtable *rt; u_int16_t tmp_port; u_int32_t tmp_addr; int needs_ack; int hh_len; /* 判断是否是分片包*/
成绩评定表
课程设计任务书
目录 1 课程设计目的 (1) 2 课程设计要求 (2) 3 相关知识 (3) 4 课程设计分析 (6) 5 程序代码 (11) 6 运行结果与分析 (18) 7 参考文献 (18)
1 课程设计目的 IP数据包是网络成传输的基本数据单元，熟悉IP数据包结构对于理解网络工作原理具有重要意义。本课程设计的主要目的是通过接受与解析IP数据包，了解IP数据包的基本结构与IP协议的基本功能。
2 课程设计要求 根据后面介绍的IP数据包结构，编写程序接收并解析IP数据包。 1）以命令行形式运行; ParsePacket log_file 其中，ParsePacket为程序名，log_file为日志文件名。 2）输出内容：IP数据包的各字段值，包括版本、头部长度、服务类型、总长度、标识、分段标志、分段偏移值、生存时间、上层协议类型、头校验和、源IP地址 和目的IP地址等。 3）当程序接收到键盘输入Ctrl+C时退出。
3相关知识 互联网络层是TCP/IP协议参考模型中的关键部分.IP协议把传输层送来的消息组装成IP数据包,并把IP数据包传送给数据链层.IP协议在TCP/IP协议族中处于核心地位,IP 协议制定了统一的IP数据包格式,以消除个通信子网中的差异,从而为信息发送方和接收方提供了透明的传输通道.编制本程序前,首先要对IP包的格式有一定了解,图1给出了IP 协议的数据包格式. IP数据包的第一个字段是版本字段,其度是4位,表示所使用的IP协议的版本.目前的版本是IPV4,版本字段的值是4,下一代版本是IPV6,版本字段值是6.本程序主要针对版本是IPV4的数据包的解析. 报头标长字段为4位,它定义了以4B为一个单位的IP包的报文长度.报头中除了选项字段和填充域字段外,其他各字段是定长的.因此,IP数据包的头长度在20—40B之间,是可变的. 0 4 8 16 19 24 31(位) 图3.1 IP数据包的格式 服务类型字段共8位,用于指示路由器如何处理该数据包.该字段长度由4位服务类型(TOS)子域和3位优先级子域组成,1位为保留位,该字段结构如图2所示. 图3.1 服务类型字段结构
IP及IPSEC协议数据包的捕获与分析
IP及IPSEC协议数据包的捕获与分析 为了掌握掌握IP和IPSEC协议的工作原理及数据传输格式，熟悉网络层的协议。我进行了以下实验：首先用两台PC互ping并查看其IP报文，之后在两台PC上设置IPSEC互ping并查看其报文。最终分析两者的报文了解协议及工作原理。 一、用两台PC组建对等网： 将PC1与PC2连接并分别配置10.176.5.119和10.176.5.120的地址。如图1-1所示。 图1-1 二、两PC互ping： IP数据报结构如图1-2所示。 图1-2 我所抓获的报文如图1-3，图1-4所示：
图1-3 请求包 图1-4 回应包 分析抓获的IP报文： (1)版本：IPV4 (2)首部长度：20字节 (3)服务：当前无不同服务代码，传输忽略CE位，当前网络不拥塞
(4)报文总长度：60字节 (5)标识该字段标记当前分片为第1367分片 (6)三段标志分别指明该报文无保留、可以分段，当前报文为最后一段 (7)片偏移：指当前分片在原数据报（分片前的数据报）中相对于用户数据字段 的偏移量，即在原数据报中的相对位置。 (8)生存时间：表明当前报文还能生存64 (9)上层协议：1代表ICMP (10)首部校验和：用于检验IP报文头部在传播的过程中是否出错 (11)报文发送方IP：10.176.5.120 (12)报文接收方IP：10.176.5.119 (13)之后为所携带的ICMP协议的信息：类型0指本报文为回复应答，数据部分 则指出该报文携带了32字节的数据信息，通过抓获可看到内容为：abcdefghijklmnopqrstuvwabcdefghi 三、IPSec协议配置： 1、新建一个本地安全策略。如图1-5。 图1-5 2、添加IP安全规则。如图1-6.
网络数据包收发流程(1)：从驱动到协议栈 2013-06-26 14:47:19 标签：控制器数据包以太网网络流量 原文出处：https://www.doczj.com/doc/ce362206.html,/uid-24148050-id-464587.html 一、硬件环境 intel82546：PHY与MAC集成在一起的PCI网卡芯片，很强大 bcm5461：PHY芯片，与之对应的MAC是TSEC TSEC：Three Speed Ethernet Controller，三速以太网控制器，PowerPc 架构CPU里面的MAC 模块 注意,TSEC内部有DMA子模块 话说现在的CPU越来越牛叉了，什么功能都往里面加，最常见的如MAC功能。 TSEC只是MAC功能模块的一种，其他架构的cpu也有和TSEC类似的MAC功能模块。 这些集成到CPU芯片上的功能模块有个学名，叫平台设备，即platform device。 二、网络收包原理 网络驱动收包大致有3种情况： no NAPI：mac每收到一个以太网包，都会产生一个接收中断给cpu，即完全靠中断方式来收包 缺点是当网络流量很大时，cpu大部分时间都耗在了处理mac的中断。 netpoll：在网络和I/O子系统尚不能完整可用时，模拟了来自指定设备的中断，即轮询收包。缺点是实时性差 NAPI：采用中断+ 轮询的方式：mac收到一个包来后会产生接收中断，但是马上关闭。直到收够了netdev_max_backlog个包（默认300），或者收完mac上所有包后，才再打开接收中断 通过sysctl来修改https://www.doczj.com/doc/ce362206.html,dev_max_backlog 或者通过proc修改/proc/sys/net/core/netdev_max_backlog
亿豪公司仓库管理规定 为了使本公司的仓库管理规范化，保证财产物资的完好无损,根据企业管理和财务管理 的一般要求，结合本公司的一些具体情况，第一季度工作清单需定如下。 完成日常物资的接收、分类、计量、包装、分拣、配送、存盘，盘点等工作。 一、仓库管理工作的任务： 1、根据本规定做好物资出库和入库工作，并使物资储存、供应、销售各环节平衡衔接。 2、做好物资的保管工作，如实登记仓库实物账,经常清查、盘点库存物资，做到账、 物相符。 3、做好仓库安全保卫工作，确保仓库和物资的安全。、 4、对于物资验收入库过程中所发现的有关数量、质量、规格、品种等不相符的现象， 仓管员有权拒绝办理入库手续，并视其程度报告业务部门、财务部。 二、仓库物资的入库 1、采购部下定单时应该认真审核库存数量，做到以销定进。 2、采购部审核订单时，应根据公司实际情况，核定进货数，杜绝出现库存积压，滞销 等情况。 3、订单录入后，采购部通知供货商送货时间，并及时通知仓库。 4、当商品从厂家运抵至仓库时，收货员必须严格认真检查商品外包装是否完好，若出 现破损、是原装短少、邻近效期等情况。收货人必须拒绝收货，并及时上报采购部；若因收 货员未及时对商品进行检查，出现的破损，原装短少、邻近效期，所造成的经济损失由该收 货员承担。 5、确定商品外包装完好后，收货员必须依照相关单据：订单、随货同行联，对进货商 品品名、等级、数量、规格、金额、单价、效期进行核实，核实正确后方可入库保管；若单 据与商品实物不相符，应及时上报采购部；若进货商品未经核对入库，造成的货、单不相符，由该收货人承担因此造成的损失。 6、入库商品在搬运过程中，应按照商品外包装上的标识进行搬运；在堆码时，应按照 仓库堆放距离要求、先进先出的原则进行。若未按规定进行操作，因此造成的商品损坏由收 货人承担。 7、入库商品明细必须由收货员和仓库管理员核对签字认可，做到帐、货相符。商品验 收无误后，仓库管理员依据验收单及时记账，详细记录商品的名称、数量、规格、入库时间、单证号码、验收情况、存货单位等，做到帐、货相符。若不按照该制度执行验收造成的经济 损失由仓库管理员承担。 8、按收货流程进行单据流转时，每个环节不得超出一个工作日。 三、仓库物资的出库 公司仓库一切商品货物的对外发放，一律凭电脑出库单，一式三份，一份留给仓库，一 份留给收货方，还有一份给送货人； 做好各种单据和物品的发放工作；要用完了要及时上报，及时备货，做到及时下发，充足； 办理材料物资的出库，库管员要填制出库凭证，由库管人员、经手人双方同时签字，由经手人持一式三联的凭证送经手人主管审核，经手人持主管审核签字后的凭证到财务部门由 会计审核，经审核过的凭证留下第二联做记帐依据，第一联由经手人留存，持第三联到仓库办理材料的出库。
Linux内核分析- 网络[一]：收发数据包的调用 分类：内核协议栈2010-12-01 15:08 7355人阅读评论(7) 收藏举报 linux内核网络structlistaction 内核版本：Linux-2.6.34 网卡驱动：B4401 什么是NAPI NAPI是linux一套最新的处理网口数据的API，linux 2.5引入的，所以很多驱动并不支持这种操作方式。简单来说，NAPI是综合中断方式与轮询方式的技术。数据量很低与很高时，NAPI 可以发挥中断方式与轮询方式的优点，性能较好。如果数据量不稳定，且说高不高说低不低，则NAPI会在两种方式切换上消耗不少时间，效率反而较低一些。 下面会用到netdev_priv()这个函数，这里先讲解下，每个网卡驱动都有自己的私有的数据，来维持网络的正常运行，而这部分私有数据放在网络设备数据后面(内存概念上)，这个函数就是通过dev来取得这部分私有数据，注间这部分私有数据不在dev结构体中，而是紧接在dev内存空间后。 static inline void *netdev_priv(const struct net_device *dev) { return (char *)dev + ALIGN(sizeof(struct net_device), NETDEV_ALIGN); } 弄清这个函数还得先清楚dev这个结构的分配 alloc_netdev() -> alloc_netdev_mq() struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name, void (*setup)(struct net_device *), unsigned int queue_count) { …… alloc_size = sizeof(struct net_device); if (sizeof_priv) { /* ensure 32-byte alignment of private area */ alloc_size = ALIGN(alloc_size, NETDEV_ALIGN); alloc_size += sizeof_priv; } /* ensure 32-byte alignment of whole construct */ alloc_size += NETDEV_ALIGN - 1; p = kzalloc(alloc_size, GFP_KERNEL); if (!p) { printk(KERN_ERR "alloc_netdev: Unable to allocate device./n");
< 解析IP数据报实验报告 - … （
目录 目录 (2) 1、课程设计目的 (2) 2、课程设计要求 (2) < 3、相关知识 (2) 4、课程设计分析 (6) 网卡设置 (6) 使用套接字 (7) 接收数据包 (7) 定义IP头部的数据结构 (8) IP包的解析 (9) 协议的定义 (9) ; 捕获处理 (9) 5、运行结果 (10) 6、总结 (11) 7、课程设计参考资料 (11) 8、源程序代码 (11) ， /
, 1、课程设计目的 本课程设计的目的就是设计一个解析IP数据包的程序，并根据这个程序，说明IP数据包的结构及IP协议的相关问题，从而对IP层的工作原理有更好的理解和认识。 2、课程设计要求 本设计的目标是捕获网络中的IP数据包，解析数据包的内容，将结果显示在标准输出上，并同时写入日志文件。 程序的具体要求如下： 1）以命令行形式运行：ipparse logfile，其中ipparse是程序名, 而logfile 则代表记录结果的日志文件。 2）在标准输出和日志文件中写入捕获的IP包的版本、头长度、服务类型、数据包总长度、数据包标识、分段标志、分段偏移值、生存时间、上层协议类型、头校验和、源IP地址和目的IP地址等内容。 3）当程序接收到键盘输入Ctrl+C时退出。 3、相关知识 互联网络层是TCP/IP协议参考模型中的关键部分.IP协议把传输层送来的消息组装成IP数据包,并把IP数据包传送给数据链层.IP协议在TCP/IP协议族
中处于核心地位,IP协议制定了统一的IP数据包格式,以消除个通信子网中的差异,从而为信息发送方和接收方提供了透明的传输通道.编制本程序前,首先要对IP包的格式有一定了解,图1给出了IP协议的数据包格式. - IP数据包的第一个字段是版本字段,其度是4位,表示所使用的IP协议的版本.目前的版本是IPV4,版本字段的值是4,下一代版本是IPV6,版本字段值是6.本程序主要针对版本是IPV4的数据包的解析. 报头标长字段为4位,它定义了以4B为一个单位的IP包的报文长度.报头中除了选项字段和填充域字段外,其他各字段是定长的.因此,IP数据包的头长度在20—40B之间,是可变的. 0 4 8 16 19 24 31 图1 IP数据包的格式 服务类型字段共8位,用于指示路由器如何处理该数据包.该字段长度由4位服务
仓库管理工作流程
仓库管理工作流程 一、原料进仓管理流程： 1.采购部将申批签字确认的《采购订单》下达给仓库； 2.供应商送货到达后，提供《送货清单》给收货仓管员，《送货清单》应 清晰显示送货单位名称、送货单位印章或经手人签名、货品的名称、规 格、数量、采购订单号。 3.收货仓管员将《送货清单》和对应的《采购订单》相核对。如核对不符 予以拒收。核对相符仓管员以《送货清单》和《采购订单》验收货品， 收货量大于定购量时，仓库管理员要通过采购部同意和取得公司有权人 的书面通知后才能超量收货。 4.仓管员收货无误后，在《送货清单》上签收，并加盖收货专用章，一联 自留，一联交对方。同时开具《入库单》，一式三联仓管员签字加盖收 货专用章后，第一联存根自留，第二联财务联连同送货单位的《送货清 单》交财务，第三联对方联交给供应商送货员（司机）作为凭证结款。 二、原料出库管理流程： 1.生产部根据仓库《库存日报表》和生产需要开具《原料领用单》，并经 生产部负责人审批签字到仓库领料； 2.仓库根据生产开具的《原料领用单》发货，并将单据留存； 三、成品进仓管理流程： 1.生产部完成的成品，经质检部门检验合格后，开具《成品入库单》并经 生产部负责人签字确认后到仓库办理入库手续；
2.仓库根据《成品入库单》点检数量入库，并将单据签字留存； 四、成品出仓管理流程： 1.销售部将申批签字确认的《销售订单》下达给仓库； 2.仓管员根据客户持有的已盖章《销售订单》或财务开具的付款发票发 货。并开具《出仓单》一式三份，由仓管员、仓库主管和客户签字，一 份交客户，一份仓库自留，一份交财务。 五、仓库货物管理： 1.所有出入库单据留存，按月整理入档，定期将财务要求的单据提交给财 务部门； 2.所有产品必须根据出入库单据建立《出入库明细账》，账本记录详细出 入库日期、单据号、出入库数量、相应办理出入库的单位名称、产品结 存； 3.仓库内的货物要设置出入库卡，记录出入库数据； 4.财务部门与仓库所建账簿及顺序编号必须互相统一，相互一致； 5.做好各类物料和产品的日常核查工作，仓库保管员必须对各类库存物资 定期进行检查盘点，并做到账、物、卡三者一致； 六、仓库报表： 1.《原材料库存日报表》供生产和采购部门使用； 2.《成品库存日报表》供生产和销售部门使用； 3.《月末盘存表》、《月末出入库结存报表》供财务部门结算使用； 七、产品盘点流程： 1.根据仓库明细帐中的结存数量仓库要定期进行自盘；
《
课程设计任务书 目录 1．实验目的 2．实验要求 ) 3．预备知识 4．课程设计分析 5．实现过程 6．程序流程图 ! 7．相关扩展 8．实习体会
9．参考文献 一．实验目的： 设计一个解析IP数据包的程序,并根据这个程序,说明IP数据包的结构及IP协议的相 关问题,从而IP层的工作原理有更好的理解和认识. 、 二．实验要求： 本设计的目标是捕获网络中数据包,解析数据包的内容,将、结果显示在标准输出上, 并同时写入日志文件. 程序的具体要求如下: 3)以命令行形式运行:ipparse logfile,其中ipparse是程序名,而logfile则代表记录 结果的日志文件. 4)在标准输出和日志文件中写入捕获的IP数据包的版本,头长度,服务类型,数据包总长 度,数据包标识,分段标志,分段偏移值,生存时间,上层协议类型,头校验和,源IP地址 和目的IP地址等内容. 当程序接收到键盘输入Ctrl+C时退出. ~ 三.预备知识 互联网络层是TCP/IP协议参考模型中的关键部分.IP协议把传输层送来的消息组装成IP数据包,并把IP数据包传送给数据链层.IP协议在TCP/IP协议族中处于核心地 位,IP协议制定了统一的IP数据包格式,以消除个通信子网中的差异,从而为信息发送 方和接收方提供了透明的传输通道.编制本程序前,首先要对IP包的格式有一定了解, 图1给出了IP协议的数据包格式. IP数据包的第一个字段是版本字段,其度是4位,表示所使用的IP协议的版本.目前的版本是IPV4,版本字段的值是4,下一代版本是IPV6,版本字段值是6.本程序主要 针对版本是IPV4的数据包的解析. 报头标长字段为4位,它定义了以4B为一个单位的IP包的报文长度.报头中除了选项字段和填充域字段外,其他各字段是定长的.因此,IP数据包的头长度在20—40B 之间,是可变的. 0 4 8 16 19 24 31
在对数据进行捕获时, 主要有两种方法: 1. 主要借助原始套接字Socket , 套接字是网络应用编程接口, 应用程序可以使用它进行网络通信发送和接收网络层以上的原始数据包, 而对底层的细节是透明的. 2. 使用系统抓包库Libpcap 和Winpcap, 通过数据链路层获取以太帧, 可以从网卡捕获或者发送原始数据包, 同时能过滤及存储数据包.这种方式的捕获是工作在网络底层数据链路层,能拦截所有正在网络上传送的数据包,并且可以通过相应的处理,从而实时的分析数据包的内容,使用数据包捕获函数来获得底层数据。 2. 1 Libpcap 方法开发的过程 采用Libpcap捕获网络数据包的开发过程. 主程序的流程如下图所示: 捕获网络数据包过程按以下步骤进行, 程序开发过程中主要语句的实现: char * dev, errbuf [ PCAP- ERRBU FSIZE] ; / / 定义接口设备名和缓冲区的大小 pcap- t p; / / 捕获数据包句柄, 非常重要的数据结构
int snaplen = 65535; / / 代表用户期望的捕获数据包最大长度 int t imeout= 1000; / / 代表函数超时返回的时间 ( 1) 进行本地网络设置检测, 获得网络接口设备. 调用函数dev= pcap- lookupdev ( er rbuf ) . Linux中最常见的接口设备名eth0 和lo, 而eth0 对应了实际的网卡, 数据包的传输都要经过eth0. ( 2) 设备找到后, 打开以准备捕获数据包. 调用的主函数是p = pcap- open- live ( dev, snaplen, 1,timeout , errbuf ) , 根据给定的接口设备名dev, 获得一个结构为pcap- t 的捕获句柄p, 函数中的1 代表设置接口为混杂模式. ( 3) 若用户设置了过滤条件, 则编译和安装过 滤代码. 编译过滤规则调用函数pcap- compile( p,&f ilter , f ilter- app, 0, net ) , 函数将规则字符串转化为内核过滤程序. 根据过滤规则设置过滤器pcap- set filter( p, &filter) 传给BPF, 由BPF 过滤器捕获用户所需要的数据包. ( 4) 反复捕获数据包. 调用pcap- loo p( p, cnt ,packet - print , NULL) 进入循环捕获, 对捕获的数据包处理放在回调函数( 如packet - print ( ) ) 中进行. ( 5) 关闭设备. 调用pcap- close ( p) , 将打开设备时得到的结构为pcap- t 的捕获句柄, 作为参数传入. 2. 2 对数据包处理的回调函数的开发过程 在实现对捕获的数据包处理的回调函数packet- print ( ) 中, 具体分析的流程如图所示:
目录 一、课程设计的目的 (1) 二、课程设计要求 (1) 三、需求分析 (1) 1.先对网卡进行编程，以便连接IP层的数据包。 (1) 2.预先创建一个logfile文件来保存所解析的IP数据包。 (1) 3.使用recv函数实现接收数据包的功能。 (1) 四、设计分析 (1) 4.1 网卡设置 (1) 4.2 使用套接字 (2) 五、程序测试 (3) 六、小结 (5) 七、附录 (5)
一、课程设计的目的 本章课程设计的目的就是设计一个解析IP数据包的程序，并根据这个程序，说明IP数据包的结构及IP协议的相关问题，从而对IP层的工作原理有更好的理解和认识。 二、课程设计要求 本设计的目标是捕获网络中的IP数据包，解析数据包的内容，将结果显示在标准输出上，并同时写入日志文件。 程序的具体要求如下： 1）以命令行形式运行：ipparse logfile，其中ipparse是程序名, 而logfile 则代表记录结果的日志文件。 2）在标准输出和日志文件中写入捕获的IP包的版本、头长度、服务类型、数据包总长度、数据包标识、分段标志、分段偏移值、生存时间、上层协议类型、头校验和、源IP地址和目的IP地址等内容。 3）当程序接收到键盘输入Ctrl+C时退出。 三、需求分析 1.先对网卡进行编程（使用套接字进行编程），以便连接IP层的数据包。 2.预先创建一个logfile文件来保存所解析的IP数据包。 3.使用recv函数实现接收数据包的功能。 4.编写ipparse函数解析捕获的数据包的版本、头长度、服务类型、数据包总长度、数据包标识、分段标志、分段偏移值、生存时间、上层协议类型、头校验和、源IP地址和目的IP地址等内容。 四、设计分析 4.1 网卡设置
仓库管理的标准化作业流程 仓库管理也叫仓储管理，指的是对仓储货物的收发、结存等活动的有效控制，其目的是为企业保证仓储货物的完好无损，确保生产经营活动的正常进行，并在此基础上对各类货物的活动状况进行分类记录，以明确的图表方式表达仓储货物在数量、品质方面的状况，以及目前所在的地理位置、部门、订单归属和仓储分散程度等情况的综合管理形式。本文对仓库管理流程进行了总结。 流程一：订单处理作业 流程二：采购作业 流程三：进货入库作业 当采购单开出之后，于采购人员进货入库跟踪催促的同时，入库进货管理员即可依据采购单上预定入库日期，做入库作业排程、入库站台排程，而后于商品入库当日，当货品进入时做入库资料查核、入库品检，查核入库货品是否与采购单内容一致，当品项或数量不符时即做适当的修正或处理，并将入库资料登录建档。入库管理员可依一定方式指定卸货及栈板堆叠。对于由客户处退回的商品，退货品的入库亦经过退货品检、分类处理而后登录入库。
一般商品入库堆叠于栈板之后有两种作业方式，一为商品入库上架，储放于储架上，等候出库，需求时再予出货。商品入库上架由电脑或管理人员依照仓库区域规划管理原则或商品生命周期等因素来指定储放位置，或于商品入库之后登录其储放位置，以便于日后的存货管理或出货查询。另一种方式即为直接出库，此时管理人员依照出货要求，将货品送往指定的出货码头或暂时存放地点。在入库搬运的过程中由管理人员选用搬运工具、调派工作人员、并做工具、人员的工作时程安排。 流程四：库存管理作业 库存管理作业包含仓库区的管理及库存数控制。仓库区的管理包括货品于仓库区域内摆放方式、区域大小、区域的分布等规划；货品进出仓库的控制遵循：先进先出或后进先出；进出货方式的制定包括：货品所用的搬运工具、搬运方式；仓库区储位的调整及变动。库存数量的控制则依照一般货品出库数量、入库所时间等来制定采购数量及采购时点，并做采购时点预警系统。订定库存盘点方法，于一定期间印制盘点清册，并依据盘点清册内容清查库存数、修正库存帐册并制作盘亏报表。仓库区的管理更包含容器的使用与容器的保管维修。 流程五：补货及拣货作业
２００８．１ 26网络安全技术与应用网络数据包截获方法 安志强 刘峰 张春 北京交通大学计算机与信息技术学院 北京 １０００４４ 摘要：本文在分析ｌｉｂｐｃａｐ基础上，引入一种新的网络监测方法，它可以动态的监测网络通信量，适用于不同的网络环境中。关键词：网络安全；数据包；截获；动态网络监视接口 ０ 引言 网络数据包截获机制是网络管理系统的基础组件之一。数据包截获机制是网络性能分析工具和网络安全工具的实现基础。一方面，网络数据截取要能保证捕获到所有网络上的数据包，尤其是检测到被分片的数据包；另一方面，网络截取数据包的效率也是很重要的，它直接影响整个入侵检测系统的运行速度。 １ 数据流截获方法 １．１ 利用广播截取网络数据流 数据包的截取技术是依赖网卡的，而网卡可以通过广播监听到以太网络上的数据包，这就是数据包截取技术的基础。 要想截获不是给自己数据流，就必须绕开系统正常工作的机制，直接通过设置网卡的的工作模式为混杂模式，使之可以接受目标地址不是自己的ＭＡＣ地址的数据包，直接访问数据链路层，获取数据。 １．２ 各系统截取数据包机制 Ｌｉｎｕｘ系统为用户提供一种在理论上是数据链路层的，基于网卡驱动程序的，可以不用操作系统自身协议栈的接口——ＳｏｃｋＰａｃｋｅｔ。这种套接字可以从数据链路层上直接截取所有链路层数据包。而Ｕｎｉｘ系统则是通过ｌｉｂｐｃａｐ库直接与内核交互，实现网络截取，如ｌｉｂｐｃａｐ、ｔｃｐｄｕｍｐ等。 ＢＳＤ Ｐａｃｋｅｔ Ｆｉｌｔｅｒ（ＢＰＦ）机制来截取数据包。ＢＰＦ可以说是各系统中较好的截获方式。Ｗｉｎｄｏｗｓ系统也有类似情况，如：Ｗｉｎ系列上有＊．ｖｘｄ和网卡．ｓｙｓ来驱动网卡截取数据包。 ２ 基于ｌｉｂｐｃａｐ库的通用数据截获技术 ｌｉｂｐｃａｐ是用户态的数据包截获ＡＰＩ函数接口，有独立和可移植性。最初，ｌｉｂｐｃａｐ是为了强大、健壮ｔｃｐｄｕｍｐ而编写的。它支持ＢＰＦ过滤机制。Ｓｎｏｒｔ就是依赖于ｌｉｂｐｃａｐ库进行数据包截取的程序之一。它的优点是可以从任何Ｕｎｉｘ内核平台上截取数据包，而不考虑什么芯片类型的网卡和驱动程序。 更重要的是，它可以使开发人员编写自己的解码、显示、记录等程序。 ３ Ｓｎｏｒｔ调用Ｌｉｂｐｃａｐ 在Ｓｎｏｒｔ运行启动时，Ｓｎｏｒｔ调用ｌｉｂｐｃａｐ库。当调用ｌｉｂｐｃａｐ函数并初始化接口时，进入截取数据的循环模块——ｐｃａｐ循环。 在这个主循环——ｐｃａｐｌｏｏｐ（），当网卡从网络介质上接收数据开始，ｐｃａｐ＿ｌｏｏｐ便对采集来的每个数据包都ＰｒｏｃｅｓｓＰａｃ－ｋｅｔ（）函数处理，如果出错或达到指定的处理包数就退出。即ｐｃａｐ＿ｌｏｏｐ（）最后根据数据链路类型来选择数据包，然后由ＰｒｏｃｅｓｓＰａｃｋｅｔ（）来进行协议分析，实施信息流的匹配。 ４ 网络通信量动态监视的设计 网络监视是指捕获穿越ＩＰ网的数据包，打开并进行分析。该操作是个被动行为，不对数据包作任何修改，数据包仍会继续在网络上向目的地传输。随着网络链接速度的增快，现有的网络监视体系已不能满足网络管理中对监视的需求，特别是对一些新的网络应用原有的监视工具不能进行监视，或者监视起来系统开销太大，比如要确定点对点的文件共享（ＦＴＰ）、多媒体会议等动态分配端口的网络应用对网络的使用情况，就不太可能。另外，对于一些安全应用程序，如入侵检测系统，传统的监视应用程序提供的信息往往是不够用的。 为了解决上述问题，传统的做法是获取通信中的全部数据包，这样会使网络管理员去处理海量的数据。这样做还有一个局限性，便是不具备通用性，不能在不同的硬件平台上使用。 故引入一种新的动态网络监视接口，它可根据用户的需要捕获相关数据包，也允许用户去触发自定义的处理例程。 ４．１ 网络通信量动态监视的详细设计 在动态网络监视接口中，无需详细了解底层硬件的构成，网络流定义为满足给定条件的一组数据包序列。对于数据包的协议分析和审查而言，给定的条件是不受限制的。而原有的网络流定义为在一个给定的时间段内有相同源、目的ＩＰ地 作者简介：安志强（１９８０－），男，北京交通大学计算机学院２００５级硕士研究生，研究方向：网络管 理。刘峰（１９６１－），男，北京交通大学计算机学院副院长、教授，硕士生导师。张春（１９６６－），女，北 京交通大学计算机学院网管研究中心高级工程师。