|
|
|
|
GIGEXD Software/Firmware DownloadSoftware/Firmware Version Info: Below is a zip package with the latest firmware and software for the GIGEXD. The User's Guide is listed separately for download but is also incorporated into zip package of software. Development for the GIGEXD Rev 1 ended with version 1.9 New features and product advancements will continue for the GIGEXD Rev 2. Software/Firmware release 2.0 and higher will ONLY work with the GIGEXD Rev2. GIGEXD Rev 1 users should use version 1.9. GIGEXD Rev 2 users are strongly encouraged to use version 2.0 or higher. Enhancements for version 1.9: 1)Added Packet Count Sequence in SDDS Packet Header for detection of dropped packets by host. 2)Added Software/documentation for maximizing GIGE throughput into host GigE port. 3)Added real tuner mode 4)Added Little Endian 16 bit data mode (saves Host Endian Convert of 16 bit or complex 16 bit data for better throughput) 5)Added Support For Clocking E2D on Falling Edge of Input Clock 6)Added Support For User To Assign an external offset (positive or negative) to Acquired Timecode 7)Added Support For GIGEXD Rev 2 of Hardware 8)Added Support For 1023 Tap Filter with Minimum Decimation of 32 9)Added Support For External Timecode Offset Delay Calculations 10)Updated documentation. The string ***New Feature*** shows a description of each new feature. A search of this string in the PDF document will show various places where the new features have been documented.
Enhancements for the GIGEXD Rev 2. All Enhancements for version 1.9 and in addition: 1) Added VLAN support. A) The GIGEXD can be configured or programmed from networks that are 802.1Q(VLAN) enabled or disabled. B) The GIGEXD can send out multicast data packets that are 802.1Q (VLAN) enabled or disabled. 2) Added insertion of sample rate into SDDS packet header. 3) Added Incoming Data 0-7 Bit Shift Toward MSB Capability. 4) Added support for A2DR9-D 200Mhz 12 Bit A/D converter.
Latest (Most Advanced) Download For GIGEXDR2 GIGEXD Rev 2 Software Version 2.03: gigexdv2_03.zip GIGEXD Rev 2 User's Guide Version 2.03: GIGEXD_User_Guidev2_03.pdf
Previous GIGEXD Rev 2 Software Versions: gigexdv2_02.zip
Download For GIGEXDR1 GIGEXD Rev 1 Software Version 1.9: gigexdv1_9.zip GIGEXD Rev 1 User's Guide Version 1.9: GIGEXD_User_Guidev1_9.pdf
An incorrect oscillator frequency on the UDP/SDDS, (modules used in combination with the ICE-PIC4 series only) has been discovered. Please follow the link below to read IMPORTANT information on UDP/SDDS recall information for UDP/SDDS modules purchased before April 1, 2005. UDP/SDDS For PIC4 Recall Info Page
RI(ICE)-UDP/RI(ICE)-SDDS Module Firmware DownloadThe most recent version of ICE software is ice319b10 ( ICE version 3.19b10). It is recommended for UDP/SDDS module use. Please note that there are no known issues with this release as it pertains to the SDDS interface module. ICE Bundled Software Package: www.ice-online.com Features of the firmware download & C library for ice317b30 and LATER releases: SDDS moved to a 802.1Q ("trunked" VLAN) architecture. Older versions of SDDS network connections were made through Multicasts joins of groups. New SDDS connections are now made through Multicasts joins but with a VLAN extension. The new firmware download icesddsv.prm supports packets with 802.1Q VLAN extensions that are connected to a "trunked" VLAN port. The new firmware download icesdds.prm supports packets WITHOUT 802.1Q VLAN extensions that are connected to "generic" NON-802.1Q ports. Which particular download goes to the module depends on the type of interface to which the user is connected. In other words, the user MUST know to what type of port they are connected and use the appropriate hardware commands depending on their interface. Below are examples of how the module is reset to accommodate 802.1Q port or NON-802.1Q port connections. IT IS VERY IMPORTANT that the examples below are followed or else unpredictable results will occur. Native Mode vs. Raw Mode: Native mode use of the module and ICE hardware causes the data to be formatted such that data appears as though it were being presented in a "clock and parallel data" form as opposed to packetized with headers. In this mode, packet headers are removed, parity packets are removed, data is unpacked, and time code is stripped out and stored. Using native mode all that is presented to the user is the formatted data from the SDDS packet. Native mode data allows the user to simultaneously take advantage of the ICE card on-board tuner chips, store the data to disk, or to pass the data to "downstream" processing that is only capable of processing data that is in parallel format and associated with a clock. Raw mode use of the module and ICE hardware causes data to be input with SDDS headers and data together. No formatting of the data is done. Data is passed to the workstation packed with its associated SDDS header. Parity packets are NOT removed. In short, any packet identifying itself as an SDDS packet is passed to the user. From each SDDS packet you will receive 1080 bytes of data, 56 bytes of the SDDS header and 1024 bytes of actual packed data. Other packet types that are not SDDS are handled on the module and these NON-SDDS packets are not passed to the workstation. So in short there are 4 modes to SDDS acquisition (There are other modes of collecting ALL packets regardless of if they are SDDS or not but only the main 4 modes are discussed here--other modes are discussed after the examples below) . VLAN Raw, VLAN Native, NON-VLAN Raw and NON-VLAN Native are the 4 modes described below. X-Midas and C Program: Below are examples of how to acquire data using each of the 4 modes. The examples are using X-midas. I have also written a C example and will give details on how to acquire data using the C program in each of the 4 modes. In short, the default use of the module is for NON-VLAN mode. Use of the flag IPVLAN=x will set the download and the configuration programming of the module for VLAN (802.1Q support). The IPVLAN=x flag must be present during both the reset of the hardware, and the start of acquisition to enable VLAN support. Also, the default use of the module is for Native acquisitions. The flag rxrawsdds turns on Raw mode. The flag rxrawsdds does not need to be present for the reset of the hardware, but must present for the start of acquisitions to enable Raw acquisitions. Flags-ipvlan=x, reset with iis = VLAN Native Mode Flags-rxrawsdds, ipvlan=x reset with ii = VLAN Raw Mode Flags-reset with iis = NO VLAN Native Mode Flags-rxrawsdds, reset with ii = NO VLAN Raw Mode With any of the Raw modes, a single module may be joined to at MOST 4 groups. The primary flags for Raw mode are: RXRAWBURST, RXRAWDATA, RXRAWSDDS, RXPKTSDDS, RXSDDSDATA. Each of these flags brings in raw data with associated headers that are defined by each of the flags. When using any of the Raw modes, the hardware interface should be set to 16 bit (SI) data and 60 MHz clock rate even though the data contained in each packet may have different characteristics-ie. 8 bit data at 12.5 Mhz, etc. Example: pic create ramf sb 1m 12.5e6 <return> --create RAM buffer of signal characteristics picd reset pic1iisd ii <return> -- reset module for Non-VLAN Raw Mode picd/port=module1/bits=16/srate=60e6/flags=rxrawsdds|ipaddr1=192.9.200.101|join1=224.1.2.3 acquire pic1iisd ramf <return> -- The use of the switches /srate=60e6 and /bits=16 overrides the sample rate and sample size of the previously created RAM buffer during acquisition but the data is held in RAM and accessed by the user as 8 bit, 12.5Mhz data. With Native mode, a single module may be joined to only 1 group, unless "Strict Verification" is disabled. (Description of Strict Verification below.) When Strict Verification is turned off, a single module may be joined to at MOST 4 groups. The primary flag for Native mode is: RXICESDDS or no primary flag specified (default mode). This flag (or none) brings in data associated as clock and parallel data, stores time code for retrieval, and presents the data in a format that could be used with the ICE hardware digital tuners. Multicast Join and Leave Info ***A new interface has been developed for Multicast "join" and "leave" commands. The previous ICE SETKEY interface is still available, but the new pic driver (picd) interface allows the user to specify Multicast addresses in "dot" notation. Also, the previous ICE SETKEY interface, under Xmidas, interpreted Big Endian addresses as 2's complement numbers thereby causing problems for addresses that had the MS Bit Set--ex. 0xff0000e0. The picd interface does not suffer this problem and allows for a more user friendly dot notation. In short, the picd interface is recommended for Xmidas users. picd commands take the form of: picd/port=module<num> <join> or <leave> <card alias> <Dot Notation MC Address> Example picd interface commands: picd join pic1iisd 224.1.2.3 -- instruct module 1 to join Multicast group 224.1.2.3 picd leave pic1iisd 224.1.2.3 -- instruct module 1 to leave Multicast group 224.1.2.3 picd/port=module2 join pic1iisd 224.1.2.3 -- instruct module 2 to join Multicast group 224.1.2.3 picd/port=module2 leave pic1iisd 224.1.2.3 -- instruct module 2 to leave Multicast group 224.1.2.3 --Note: port=module1 is the default module number. If port=module<number> is not present in the picd command, then port=module1 is assumed. picd/port=module1 join pic1iisd 224.1.2.3 -- also valid for port 1 join/leave commands
Example X-midas/Nextmidas Commands: VLAN Raw: -- pic1iisd alias: PIC1IISD==ICEPIC,DEVNO=0,,IOM=SDDSXD, -- look to <install path>/iceXXX/dat/hwconfig.key file for other definitions of aliases used here X-midas> picd/flags=ipvlan=1 reset pic1iisd ii <return> --with the flag of ipvlan=x, VLAN support is enabled. The module download icesddsv.prm is sent to the module. --For Raw Mode, the file ii is called to reset the ICE card.
X-midas> pic create ramf si 34560k 60e6 <return> --All accesses to data when the module is used in Raw mode is 16 bit or SI data.
Xmidas>pic/port=module1/nospectra/flags=rxrawsdds|ipaddr1=192.9.200.101|ipvlan=1|join1=224.1.2.3 test/rt pic1iisd ramf 1080 1080 <return> -- after the above command the module may also be successfully "pinged" from another network source. -- the use of the flag rxrawsdds configures the acquisition for RAW acquisition -- the use of the flag ipvlan=x must be present. Using the ipvlan=1 sets the "active vlan" register (in this case to a value of 1) for the multicast address of 224.1.2.3. If the multicast address is not known at acquisition start, the join1=aa.bb.cc.dd may be left out but the flag ipvlan=x must still be present to call the correct functions in the ICE library. The actual VLAN value may be changed later when the multicast address is known. Once the above software is running if data is being sent to multicast address 224.1.2.3 on VLAN #1 the SDDS input module will acquire it. To leave the group/multicast address of 224.1.2.3 the user from within ANOTHER X-midas session/window would type: X-midas> picd set pic1iisd ipdisc 0x030201e0 <return> --Example using ICE SETKEY or X-midas> picd leave pic1iisd 224.1.2.3 <return> -- Example PIC Driver, (New Interface)
This is a disconnect or leave of a Group 224.1.2.3 on VLAN #1. A few seconds after issuing this command data will halt. The VLAN register was set to 1 from the start of the acquisition. To restart data and join another group at address 224.7.8.9 the command would be: X-midas> picd set pic1iisd ipconn 0x090807e0 <return> or X-midas> picd join pic1iisd 224.7.8.9 <return> This causes the module to join the group 224.7.8.9 on VLAN #1. Note that when using the SETKEY interface addresses are specified in Big Endian format.
If while now connected to VLAN #1 group 224.7.8.9 the user wishes to connected to VLAN #2 and group address 224.7.7.7 the user must first reset the VLAN register on the module. From the start command above using the flag ipvlan writes the VLAN register with a value of 1. This register must be re-written before joining or leaving a group on a VLAN that is not the current VLAN of 1. Rewriting the VLAN register, joining, or leaving groups does not affect an ongoing acquisition. X-midas> picd set pic1iisd ipvlan 2 <return> --reset the current VLAN register to 2 such that any joins or leaves of groups will go out to VLAN 2 X-midas> picd set pic1iisd ipconn 0x070707e0 <return> or X-midas> picd join pic1iisd 224.7.7.7 <return> -- at this point the user will be receiving data from both VLAN #1 Group address 224.7.8.9 and VLAN #2 Group address 224.7.7.7 If the user wishes to leave the group 224.7.8.9 on VLAN #1, the VLAN register must be changed back to VLAN 1 then the disconnect message must be sent. X-midas> picd set pic1iisd ipvlan 1 <return> --reset the current VLAN register to 1 such that any joins or leaves of groups will go out to VLAN 1 X-midas> picd set pic1iisd ipdisc 0x090807e0 <return> or X-midas> picd leave pic1iisd 224.7..8.9 <return> --This causes the module to leave the group 224.7.8.9 on VLAN #1. Data from VLAN #1 group address 224.7.8.9 will stop being acquired from 224.7.8.9 once this command is sent. The only data that will be acquired will be from the previous join of VLAN #2 group address 224.7.7.7 NON-VLAN Raw: For NON-VLAN Raw mode the flag ipvlan=x must NOT be present in both the reset operation and the initial start of the acquisition. This will cause the module download to be icesdds.prm which does not contain support for trunked VLAN interfaces. -- pic1iisd alias: PIC1IISD==ICEPIC,DEVNO=0,,IOM=SDDSXD, From the above discussion for VLAN Raw mode, acquisitions using NON-VLAN Raw mode would be started in the same manner only without the use of the flag ipvlan=x. X-midas> picd reset pic1iisd ii <return> --without the flag of ipvlan=x, NON-VLAN support is enabled. The module download icesdds.prm is sent to the module. --For Raw Mode, the file ii is called to reset the ICE card.
X-midas> pic create ramf si 34560k 60e6 <return> --All accesses to data when the module is used in Raw mode is 16 bit or SI data.
X-midas>pic/port=module1/nospectra/flags=rxrawsdds|ipaddr1=192.9.200.101|join1=224.1.2.3 test/rt pic1iisd ramf 1080 1080 <return> -- the flag ipvlan=1 has been removed from the earlier example of VLAN RAW data collection. -- use of the flag rxrawsdds places the acquisition in Raw mode. From another Xmidas session the joining of groups is accomplished in the same manner using: X-midas>picd set pic1iisd ipconn <Big E address> or X-midas>picd join pic1iisd <"Dot" Address> The leaving of groups is accomplished in the same manner using: X-midas>picd set pic1iisd ipdisc <Big E address> or X-midas>picd leave pic1iisd <"Dot" Address> The need to set the VLAN register (using: picd set pic1iisd ipvlan x) is no longer necessary. But, it should be noted that calls to set the VLAN register after reset and after the start of acquisition do NOT affect acquisitions. So calls to picd set pic1iisd ipvlan x in a macro would not affect the operation of the module in NON-VLAN mode.
VLAN Native: --Note: For Native mode of operation the default setting is for Strict Verification. Strict Verification only allows for 1 Multicast address to be joined at a time. Under ice317 (non-beta) joining of a 2nd address will cause an automatic leave of the 1st joined address. Strict Verification enables strict checking of the Multicast IP address of the data source such that only data from the single joined address will passed to the user-all other data is filtered. Also, as a default Parity Packets are filtered and Non-Standard SDDS packets are removed. (Standard SDDS packets have the SF bit set in the Format ID byte of the header-Non-Standard SDDS packets do not.) The following flags are useful in changing the default acquisition characteristics of VLAN Native: RXSTRICTOFF -Turn off Strict Verification, allow up to 4 Groups to be joined at one time. RXALLOWNSPKT - Allow acquisition of Non-Standard SDDS packets. RXALLOWPRYPKT - Allow acquisition of Parity Packets VLAN Native mode requires the use of iis in the reset call to the card and the removal of the rxrawsdds flag from the start of acquisition. -- pic1iisd alias: PIC1IISD==ICEPIC,DEVNO=0,,IOM=SDDSXD,
X-midas> picd/flags=ipvlan=1 reset pic1iisd iis <return> --with the flag of ipvlan=x, VLAN support is enabled. The module download icesddsv.prm is sent to the module. --For Native Mode, the file iis is called to reset the ICE card.
X-midas> pic create ramf si 34560k 60e6 <return> --All accesses to data should be set to the type of data in the packet. If this is unknown, then setting the data size to SI (16 bit) will ensure all data is collected. After reviewing the data, the size can be reset to the appropriate value for the next acquisition.
X-midas>pic/port=module1/nospectra/flags=ipaddr1=192.9.200.101|ipvlan=1|join1=224.1.2.3 test/rt pic1iisd ramf 1k 1k <return> -- after the above command the module may also be successfully "pinged" from another network source. -- the flag rxrawsdds is not used in the start of acquisition. Without the flag rxrawsdds data acquisition will occur in Native mode. -- the use of the flag ipvlan=x must be present. Using the ipvlan=1 sets the "active vlan" register (in this case to a value of 1) for the multicast address of 224.1.2.3. If the multicast address is not known at acquisition start, the join1=aa.bb.cc.dd may be left out but the flag ipvlan=x must still be present to call the correct functions in the ICE library. The actual VLAN value may be changed later when the multicast address is known. Joins and leaves occur as they did for VLAN Raw mode-where the user must set the VLAN register and the multicast join/leave addresses. X-midas> picd set pic1iisd ipvlan 2 <return> --reset the current VLAN register to 2 such that any joins or leaves of groups will go out to VLAN 2 X-midas> picd set pic1iisd ipconn 0x070707e0 <return> or X-midas> picd join pic1iisd 224.7.7.7 <return> -- under software ice317, at this point the user will be receiving data from ONLY VLAN #2 Group address 224.7.7.7 VLAN #1 Group Address 224.1.2.3 would have been automatically left before joining 224.7.7.7. -- If the flag RXSTRICTOFF had been used, the user would be receiving data from both VLAN #1 Group address 224.1.2.3 and VLAN #2 Group address 224.7.7.7
NON-VLAN Native: --Note: For Native mode of operation the default setting is for Strict Verification. Strict Verification only allows for 1 Multicast address to be joined at a time. Under ice317 (non-beta) joining of a 2nd address will cause an automatic leave of the 1st joined address. Strict Verification enables strict checking of the Multicast IP address of the data source such that only data from the single joined address will passed to the user-all other data is filtered. Also, as a default Parity Packets are filtered and Non-Standard SDDS packets are removed. (Standard SDDS packets have the SF bit set in the Format ID byte of the header-Non-Standard SDDS packets do not.) The following flags are useful in changing the default acquisition characteristics of VLAN Native: RXSTRICTOFF -Turn off Strict Verification, allow up to 4 Groups to be joined at one time. RXALLOWNSPKT - Allow acquisition of Non-Standard SDDS packets. RXALLOWPRYPKT - Allow acquisition of Parity Packets For NON-VLAN Native mode the flag ipvlan=x must NOT be present in both the reset operation and the initial start of the acquisition. This will cause the module download to be icesdds.prm which does not contain support for trunked VLAN interfaces. -- pic1iisd alias: PIC1IISD==ICEPIC,DEVNO=0,,IOM=SDDSXD, From the above discussion for VLAN Native mode, acquisitions using NON-VLAN Raw mode would started in the same manner only without the use of the flag ipvlan=x.
X-midas> picd reset pic1iisd iis <return> --without the flag of ipvlan=x, NON-VLAN support is enabled. The module download icesdds.prm is sent to the module. --For Native Mode, the file iis is called to reset the ICE card.
X-midas> pic create ramf si 34560k 60e6 <return> --All accesses to data should be set to the type of data in the SDDS packet. If this is unknown, then setting the data size to SI (16 bit) will ensure all data is collected. After reviewing the data, the size can be reset to the appropriate value for the next acquisition.
X-midas>pic/port=module1/nospectra/flags=ipaddr1=192.9.200.101|join1=224.1.2.3 test/rt pic1iisd ramf 1k 1k <return> -- the flag ipvlan=1 has been removed from the earlier example of VLAN RAW data collection. -- the flag rxrawsdds is not used in the start of acquisition. Without the flag rxrawsdds data acquisition will occur in Native mode. From another Xmidas session the joining of groups is accomplished in the same manner using: X-midas>picd set pic1iisd ipconn <Big E address>. or X-midas> picd join pic1iisd <Dot Notation>
The leaving of groups is accomplished in the same manner using: X-midas>picd set pic1iisd ipdisc <Big E address> or X-midas> picd leave pic1iisd <Dot Notation> The need to set the VLAN register (using: picd set pic1iisd ipvlan x) or use the ipvlan=x flag is no longer necessary. UDP Module Flags: RXRAWBURST-Disable Tx response to packets that normally require a response (pings, etc) thereby increasing Rx throughput to maximum rate. The user will get ALL packets that arrive on at the Rx input of the module. This mode is best used when the module is connected to a live network via an "optical splitter" and does not need to reply to Rx packets. Without the use of this flag the default operation is to reply to received packets that need acknowledgement. RXPREAMBEN-Enable the preamble to come in with the packet. Normally the preamble is "stripped" and the Ethernet frame is passed through to the user. Using this flag will cause the preamble bytes to be acquired with the Ethernet frame. RXCRCEN-Enable the CRC at the end of the Ethernet frame data to be acquired with the Ethernet frame. NOLINK-Before the module begins acquisition of data it requires Autonegotiation to occur thereby setting up a link. Using the NOLINK flag will bypass this requirement. This flag is also useful when the module sits at the end of a connection that is being established via an optical splitter. Tx & Rx SDDS Module Flags: IPVLAN1/IPVLAN2/IPVLAN-Write the VLAN register and set the default VLAN where join and leave messages are to be sent. IPVLAN1 applies to module 1. IPVLAN2 applies to module 2. IPVLAN applies to setting the VLAN for both modules. The form of this flag is IPVLAN=x where x is a valid VLAN designator for the VLAN of interest. In Tx mode, the IPVLAN flag specifies the destination IPVLAN. IPADDR1/IPADDR2-Set the IP address for module #1 or #2 respectively. The form of this flag is IPADDR1=aa.bb.cc.dd where aa.bb.cc.dd is in standard network address notation (192.9.200.100). This is the IP address that the module will reply to when "pinged". Rx SDDS Module Flags (Input Mode): Raw Mode Flags--Use With ii ICE Download RXRAWBURST-Disable Tx response to packets that normally require a response (pings, etc) thereby increasing Rx throughput to maximum rate. The user will get ALL packets that arrive on at the Rx input of the module regardless of hardware or IP address. This mode is best used when the module is connected to a live network via an "optical splitter" and does not need to reply to Rx packets. RXRAWDATA-Enable Tx response to packets that normally require a response (pings, etc.) but also acquire ALL of the packets that are received on the Rx port regardless of hardware or IP address. RXRAWSDDS-Acquire only SDDS data and headers (data/1024 + header/56 = 1080 byte blocks). Tx response to packets is enabled. RXSDDSDATA-. Use of this flag will strip off all headers including the SDDS header and only acquire SDDS data (data = 1024 byte blocks). Tx response to packets is enabled. NOTE-In ice317, SDDS data that has 16 bit samples (set in the SDDS header as 16 bit data) will be converted to little Endian format before being passed to the user. This mode is useful for data sources that have time code embedded with the data in serial format, using the RXSDDSDATA flag in VLAN or Non-VLAN Raw mode will enable the user to process the data with the embedded time code. RXPKTSDDS - Acquire special 8 byte ICE header, SDDS header, and SDDS data. RXPKTSDDS is useful in Raw mode when multiple Multicast Address groups have been joined and data is being archived. Data consists of: 8 ICE header bytes + 56 SDDS header bytes + 1024 SDDS payload bytes = 1088 Bytes. The inclusion of the source Multicast address in the 8 bytes of ICE header provide the user with a reference as to which source the data has been acquired. The 8 bytes of ICE header take the form of: 1. (2 bytes) 0xA5A5 (Begin Packet Delimiter) 2. (2 bytes) RFU (Reserved For Future Use) 3. (2 bytes) MC Address (High Word of Multicast Source Address) 4. (2 bytes) MC Address (Low Word of Multicast Source Address) Native Mode Flags--Use With iis ICE Download RXICESDDS or No flags-Acquire data and manipulate such that data source, from a user's point of view, appears to be a clock and parallel data. The use of the RXICESDDS flag or no flags puts the module in Native mode. Native mode manipulates the data such that time code is removed for user retrieval and data is formatted to appear as clock and parallel data. In Native mode, ICE digital hardware tuners can be used and time code extracted. Standard implementation is for Strict Verification and to filter Parity and Non-Standard SDDS packets. Using Strict Verification a user is allowed to join only 1 group. The following flags can be used in Native mode to "unrestrict" the data acquisition: RXSTRICTOFF-turn off Strict Verification, allow up to 4 groups to be joined RXALLOWNSPKT-allow Non-Standard SDDS packets (packets that do NOT have the SF bit set in the Format ID byte of the SDDS header) RXALLOWPRYPKT-allow Parity packet data acquisition. Shared Native & Raw Mode Flags IPVLAN1/IPVLAN2-Set the IPVLAN register to the current working VLAN. All joins and leaves will apply to the VLAN that is stored in the IPVLAN register. picd/port=moduleX set pic1iisd ipvlan Y <return> where moduleX represent module1 or module2 where Y represents a valid VLAN number JOIN1/JOIN2-Join a multicast group to enable a router to send data over the network to module #1 or #2 respectively. The form of this flag is JOIN1=aa.bb.cc.dd where aa.bb.cc.dd is in standard network address notation (224.1.2.3). NOLINK-Before the module begins acquisition of data it requires Auto-negotiation to occur thereby setting up a link. Using the NOLINK flag will bypass this requirement. This flag is also useful when the module sits at the end of a connection that is being established via an optical splitter. Tx SDDS Module Flags (Output Mode): TXRAWDATA-Data payload after the UDP header is 1080 bytes. All data that is sent to the module must be in 16 bit format. Data is loaded into a packet as 1080 bytes then sent to TXDESTIP address. This Tx mode is useful when the user has assembled SDDS headers with accompanying SDDS data and wants to output SDDS header and SDDS data. The rate of data transfer is set by the user by choosing an output clock source. In choosing the output clock rate, the user needs to include in calculations the SDDS header with the SDDS data. TXRAWSDDS-Data after the UDP header is "hard coded" 56 bytes of SDDS header. The SDDS header is filled in with data size and the proper data type bits are set. Timecode is NOT added. The data payload size of each packet is 1024 bytes. The data size can be 16, 8, 4, or 1 bit. When data is sent to the module, data sizes 8, 4, and 1 are packed to produce 16 bit UDP samples. Once a full 1024 bytes of data has been sent to the module, The pre-assembled SDDS header and the 1024 bytes of data are sent out. This Tx mode is useful when a user has raw data that has to be sent out via SDDS protocol. The data is sent 1024 bytes at a time in a SDDS packet with the pre-configured SDDS header and the user's data. The rate of data transfer is set by the user by choosing an output clock source. TXDESTIP1/TXDESTIP2-Set the destination IP address for module #1 or #2 respectively. The form of this flag is IPADDR1=aa.bb.cc.dd where aa.bb.cc.dd is in standard network address notation (192.9.200.100). This is the IP address to where data will be transmitted. If the address is in the range of multicast addresses the module will handle setting up multicast protocols. If the address in not in the range of multicast addresses the module will first issue a "ping" to the destination IP address to retrieve the HW (MAC) address of the destination IP address. TXDESTPRT1/TXDESTPRT2-Set the destination port number for module #1 or #2 respectively. The form of this flag is TXDESTPRT1=x, where x is in the range of valid UDP port numbers. If this flag is not used, the destination port will default to the standard SDDS port number. ICE Snapper Macro The ICE Snapper macro can be used to display the data and do a realtime archive of the data to disk. X-Midas> picd reset pic1iisd ii <return> --setup for NON-VLAN Raw Mode X-Midas> pic/tsp/noreset snap pic1iisd rxrawsdds|ipaddr1=192.9.200.101|join1=224.1.2.3 <return> -- note for Nextmidas put the flags in parenthesis separated by commas. (rxrawsdds,ipaddr=......) The above command launches the Snapper macro while setting the module IP address to 192.9.200.101. A multicast join command will be sent for the address of 224.1.2.3 Set the Configuration fields on the left of the GUI to the following values: Port=Module1 Format=SI Rate=60Mhz Clock=N Length = 1 Sec Frame Size = 1080 All other parameters leave at their default value.
On the right side of the GUI choose RTSpectra to see a Realtime display of the SDDSData and header. To do a realtime archive of the data to disk, choose RTArchive. The Snapper macro will prompt you for a filename and data will be written to the write aux directory to the file <filename>.tmp In short, to leave or join another group a user from another X-midas/Nextmidas window would type: X-midas> picd set pic1iisd ipdisc 0xYYYYYYYY <return> --to leave a joined group using SETKEY or X-midas> picd leave pic1iisd aa.bb.cc.dd <return> --to leave a joined group using pic driver
X-midas>picd set pic1iisd ipconn 0xZZZZZZZZ <return> --to join a group using SETKEY or X-midas> picd join pic1iisd aa.bb.cc.dd <return> --to join group using pic driver To change the VLAN where the Join/Leave message will be sent : X-Midas> picd set pic1iisd ipvlan x <return> --where x is the VLAN number C Program Below is the zipped package sddscfiles.zip This zip package contains 2 files: testsdds.c and buildsdds.lnx This zip package should be copied to the <install path>/iceXXX/test directory. Where <install path> represents the directory where the ICE software tree was initially installed and iceXXX represents the version number of your current software-Ex. ice316 represents version 3.16 of the software tree. Once copied the file sddscfiles.zip should be unzipped. The file buildsdds.lnx is a Linux build script for the file testsdds.c. To build an executable under Linux type: source buildsdds.lnx The C source file testsdds.c should build without errors. (As a note, the C file and build script should work for Solaris users also. In the file testsdds.c you will need to add the flag O_LARGEFILE to the open call where the data file is opened for creation. No other modifications should be necessary--I think!) The new program sets up the ICE PIC4T for acquisition to file on disk using port 1(A), 2(B) or both 1 & 2 (A & B) of the UDP/SDDS module . After compiling, at the command prompt, typing ./testsdds will cause the program to list the needed command line parameters for the program to execute. Below is a copy of that list.
C Program Date : September 6, 2004 Program modified to work with beta version ice316b16 or the official release ice316 and higher. Zipped version of testsdds.c AND buildsdds.lnx: sddscfiles.zip
At execution the program makes some assumptions: 1.) You have at least 128 MBytes of mappable memory available per module from the driver for a data buffer. 2.) The disk/RAID available will be able to handle the data rate of the incoming data. If not "Overflow" messages will be output when the 128MB memory buffer overflows because data can't be written to disk quickly enough.
prompt>> ./testsdds <devtype> <devno> <test> <size in GB> <loops>
<numbits> <ports>
<filename> <filename> <flags> <numbits>
= # bits per sample using Native Mode, ALWAYS 16 for Raw Mode Below are some examples of how to use the program:
NON-VLAN RAW on port 1
card 0:
./testsdds pic 0 acq 5 1 16
1 /data11/xmidas/t1a.dat ioc=iis,ipaddr1=129.0.0.2,,join1=224.1.2.3 <return> If the Sample size of
the data was 8 bits then in the command above 16 should be changed to 8. ./testsdds pic 0 acq 5 1 16
1 /data11/xmidas/t1a.dat ioc=iis,ipaddr1=129.0.0.2,ipvlan=1,,join1=224.1.2.3 <return>
RI(ICE)-SONETR2 Module Firmware DownloadSoftware/Firmware Version Info: ICE software version ice316 contain the final baseline firmware/software code for the RI(ICE)-SONETR2 module. ice316 has had a full year of testing with all of the modes of operation and has been shown to meet or surpass test criteria. Therefore, ice316 or higher should be used to take advantage of features listed below. The module type designation for the SonetR2 module in the ICE software tree (package) HAS changed as of software version ice318b11. The old designation was SNTR2XD for input and DXSNTR2 for output. The new designation for input is SNTXDR2, output designation remains the same as DXSNTR2 (SNTXDR2 - Sonet to Digital Conversion Rev 2, DXSNTR2 - Digital to Sonet Rev 2 Conversion). ICE Bundled Software Package: www.ice-online.com Example Code: For X-Midas users, an example X-Midas macro is included in the ICE software option tree and is available to you once the ICE tree is built. The X-Midas macro is named testsnt and is in the <install path>/iceXXX/mcr directory of the tree. Flags Usage: From the RI(ICE)-SonetR2 hardware page, the module is capable of many different acquisition and playback types. Below are some examples, of how to use the software flags for each of the different scenarios. Flags Description OC3 Enable OC3 Playback or Acquire OC12 Enable OC12 Playback or Acquire OC24 Enable OC24 Playback or Acquire OC48 Enable OC48 Playback or Acquire OC192 Enable OC192 Playback or Acquire Note: The signal type flags of OC3, OC12, OC24, OC48, and OC192 relate to what type of signal should be at the Fiber transceiver interface. (For acquisitions/playback, what type of signal will be at the Rx/Tx port of the Fiber transceiver). If none of the flags above are used then OC3 is assumed. OC3FROMOCX For Acquisition - Pull Out Single OC3 Stream From Either an OC12, OC24, OC48, or OC192 Source. For Playback - Replicate the data N times within hardware to form a higher rate signal. For OC12 N is 4, OC24 N is 8, OC48 N is 16, and for OC192 N is 64. For This flag, in addition, requires use of OC12, OC24, OC48, or OC192 flag. OC3NUM=x For Acquisition - Which OC3 To Pull From OC12, OC24, OC48, or OC192 signal. For Playback - Specify Any Number For x This flag requires the use of the OC3FROMOCX flag. Values of x for an incoming/outgoing OC12 are 0 thru 3 Values of x for an incoming/outgoing OC24 are 0 thru 7 Values of x for an incoming/outgoing OC48 are 0 thru 15 Values of x for an incoming/outgoing OC192 are 0 thru 63 OC12FROMOCX For Acquisition - Pull Out Single OC12 Stream From Either an OC24 or OC48 Source. For Playback - Replicate the data N times within hardware to form a higher rate signal. For OC24 N is 2, and OC48 N is 4. This flag, in addition, requires use of OC24, OC48, or OC192 flag. OC12NUM=x For Acquisition - Which OC12 To Pull From OC24, or OC48 signal. For Playback - Specify Any Number For x This flag requires the use of the OC12FROMOCX flag. Values of x for an incoming/outgoing OC24 are 0 or 1 Values of x for an incoming/outgoing OC48 are 0 thru 3 Values of x for an incoming/outgoing OC192 are 0 thru 15 OC24FROMOCX For Acquisition - Pull Out Single OC24 Stream From an OC48 Source. For Playback - Replicate the data N times within hardware to form a higher rate signal. For OC48 N is 2. This flag, in addition, requires use of OC48 or OC192 flag. OC24NUM=x For Acquisition - Which OC24 To Pull From OC48 signal. For Playback - Specify Any Number For x This flag requires the use of the OC24FROMOCX flag. Values of x for an incoming OC48 are 0 or 1 Values of x for an incoming OC192 are 0 thru 7 OC48FROMOCX For Acquisition - Pull Out Single OC48 Stream From an OC192 Source. For Playback - Replicate the data N times within hardware to form a higher rate signal. For OC192 N is 4. This flag, in addition, requires use of OC192 flag. OC48NUM=x For Acquisition - Which OC48 To Pull From OC192 signal. For Playback - Specify Any Number For x This flag requires the use of the OC48FROMOCX flag. Values of x for an incoming OC192 are 0 thru 3 G709FEC-(For SonetR4 & SonetR5 Modules Only) Enable either OC192 or OC48 G.709 FEC input. This flag must be used in conjunction with the flag OC192 for G.709 FEC encoded OC192 signals. This flag must be used in conjunction with the flags OC48 and FRAMINGOFF for OC48 G.709 FEC inputs. Note that for FEC OC192 signals that demuxing for acquisition is supported. Demux operations for G.709FEC OC48 is not supported and the use of the flag FRAMINGOFF is used to bring in the raw binary stream. Playback of an G.709FEC OC192 signal is not yet supported but playback of an G.709FEC OC48 with the use of the flag FRAMINGOFF is supported. FRAMINGOFF-Acquire or playback data as it appears on the fiber optic line. Frame alignment and De-scrambling of data is turned off. RXCLKFORTX (For SonetR2 & SonetR1 Modules Only) This flags allows the user to plug a Sonet source into the Rx port of the module. When Tx operations are performed the module can optionally use its on board oscillator as a reference or a derived reference that is taken from the signal on the Rx port. The use of this flag allows for a known clock from the Rx signal supplied to be used to clock data out of the module during a Tx operation. Without this flag, data Tx operations will use the on board reference oscillator that will be within Sonet specifications but not exactly the same as a local clock source that is being used by other Sonet equipment. This flag and mode of operation are useful when the Tx data from the module is being "muxed" with other data from other equipment. This allows for low pointer manipulations by the mux equipment. For other scenarios, using the on board reference and not supplying a valid signal on the Rx port will be advantageous. ERRDETON (For SonetR2 & SonetR1 modules only) Frame Aligns All Data Such That Octet Data After End Of Frame Count Will Not Be Acquired. All Acquisitions Are Will Now Consist Of Only Good Frames. SCRAMOFF Do NOT Descramble Data For Acquisitions or Do NOT Scramble Data For Playback. Data That Is On The Fiber Line Will Be Acquired As It Appears On The Line or Data Will Be Played Out Exactly As It Appears In File. This option should NOT be used when using the module in demux acquisition or cloning playback modes. X-Midas Examples: --Create File In Memory For Acquisitions, Needed For Either Acquisition Or Playback pic create ramfile sb 20m 20e6 Acquisitions: --Reset Alias Name pic1iisr2-In Hardware File pic1iisr2, IOM=SNTXDR2 picd reset pic1iisr2 ii --Acquire OC12 Signal Data From Module2 To File In Memory picd/port=module2/flags=iom=sntxdr2|OC12 acquire pic1iisr2 ramfile or --Acquire 3rd OC3 Signal Data From OC48 From Module2 To File In Memory picd/port=module2/flags=iom=sntxdr2|OC48|OC3FROMOCX|OC3NUM=2 acquire pic1iisr2 ramfile or --Acquire OC3 Signal Data From Module2 To File In Memory picd/port=module2/flags=iom=sntxdr2 acquire pic1iisr2 ramfile --Acquire 2nd OC48 Signal Data From G.709 FEC OC192 Input From Module 1 Of SonetR4 pic create ramfile sb 320m 320e6 --Create File In Memory For Acquisitions, Needed For Either Acquisition Or Playback picd reset pic1iisr4 --Reset Alias Name pic1iisr2-In Hardware File pic1iisr4, IOM=SNTXDR4 picd/port=module1/flags=iom=sntxdr4|G709FEC|OC192|OC48FROMOCX|OC48NUM=1 acquire pic1iisr4 ramfile Playback: --Reset Alias Name pic1oosr2-In Hardware File pic1oosr2, IOM=DXSNTR2 picd reset pic1oosr2 oo --Playback OC12 Signal Data Via Module2 From File In Memory picd/port=module2/flags=iom=dxsnt|muxclk=b|OC12 play pic1oosr2 ramfile or --Playback OC3 Signal Data Via Module2 From File In Memory picd/port=module2/flags=iom=dxsntr2|muxclk=b play pic1oosr2 ramfile
--Playback OC48 Signal From OC3 Data (Mux Mode) Via Module2 From File In Memory picd/port=module2/flags=iom=dxsntr2|muxclk=b|oc48|oc3fromocx|oc3num=0 play pic1oosr2 ramfile
C Examples: Below is the zipped package sntcfiles.zip This zip package contains 2 files: testsntr2.c and buildsntr2.lnx The program works with the SonetR2 module only. This zip package should be copied to the <install path>/iceXXX/test directory. Where <install path> represents the directory where the ICE software tree was initially installed and iceXXX represents the version number of your current software-Ex. ice313 represents version 3.13 of the software tree. Once copied the file sntr2cfiles.zip should be unzipped. The file buildsntr2.lnx is a Linux build script for the file testsntr2.c. To build an executable under Linux type: source buildsntr2.lnx The C source file testsntr2.c should build without errors. (As a note, the C file and build script should work for Solaris users also. In the file testsntr2.c you will need to add the flag O_LARGEFILE to the open call where the data file is opened for creation. No other modifications should be necessary--I think!) The new program sets up the ICE PIC4T for acquisition or playback to/from file on disk using port 1(A), 2(B) or both 1 & 2 (A & B) of the SonetR2 module . The earlier versions of this program only allowed for output on port 2(B). At the command prompt, typing ./testsntr2 will cause the program to list the needed command line parameters for the program to execute. Below is a copy of that list:
At execution the program makes some assumptions: 1.) You have at least 640 MBytes of mappable memory available from the driver for a data buffer. 2.) The disk/RAID available will be able to handle the data rate of the incoming data. If not "Overflow" messages will be output when the 640MB memory buffer overflows because data can't be written to disk quickly enough.
C Program Memory Buffers The default memory setting of 640 MBytes is to accommodate OC48 rates. Typically a buffer size that is a power of 2 and about 1 to 2 Seconds of the data rate in size should be specified. Therefore, if either by demuxing or by total signal collection (no demuxing) the rates are slower than OC48 data rates (311 MBytes per Second) then the user can edit the C program testsnt.c and change the #define MEGMEMBUF 640 to accomodate the slower rates. Below are some examples of memory buffer settings for signal types. OC3 64 MBytes OC12 128 MBytes OC24 256 MBytes OC48 640 MBytes These memory sizes apply for the data rate that is being acquired-it only applies to the line rate if the entire line rate is being acquired, no demuxing. For instance, if an OC48 is being acquired then 640MBytes as a memory buffer should be used. If however only a single OC3 is being pulled (using the OC3FROMOCX, OC3NUM=x flags) then the memory size may be set to 64 MBytes). In short, larger memory buffers won't hurt the acquisition but will result in long delays in status from the program. However, smaller than required memory buffers will cause data to be lost because of memory "overruns". The #define MEGMEMBUF should be set according to your system and signal requirements.
prompt>> ./testsntr2 <devtype> <devno> <test> <size in GB> <loops> <ports>
<filename> <filename> <flags> Below are some examples of how to use the program:
If you want to acquire 2 channels then the command is:
t1a.dat is played out module A. t1b.dat is played out module B.
******Example of the New Mux Mode Output Download****** >> ./testsntr2 pic 0 play 5 8 2 /data/sonet.dat OC48,OC3FROMOCX,OC3NUM=0 <return> The above plays back an OC48 signal that is created from OC3 data (replicated or "cloned" 16 times in the hardware) from the file /data/sonet.dat looping through the first 5 Gigabytes of data 8 times.
C Program Date : July 22, 2004 Program modified to work with ice318b10 or older versions of ICE software. Support for Sonet R1 and R2 modules only. Zipped version of testsntr2.c AND buildsntr2.lnx: sntr2cfiles.zip Program works with ice318b11 (and higher). Support for SonetR1, R2, R4 and R5 modules. Zipped version of testsnt.c AND buildsnt.lnx: sntcfiles.zip
Software Development ConsultingSoftware development for the ICE and rumeL line of products can be arranged through a consulting agreement. Initial inquiries can be made via the link below. |
