802.11g does not work on WLS-9163

[Burnt Fingers]

I have a NI-9237 four channel strain amp in a WLS-9123 wired/wireless C series carrier.  In wired mode, my application works like a champ for days on end with no errors of any sort.  However when I go to wireless mode, the application will not run for more than a few seconds.  Details follow:

LabView 8.6

DAQmx Version 8.9.0f4

WLS-9123 firmware 1.1.0f2

Routers attempted: Netgear WGT624, Linksys WRT54G2 - both with latest firmware.

I am very familiar with the discussions and papers on wireless connectivity.  The 9123 fails to function on both a long standing WLAN with many other functioning wireless machines, and a new separate WLAN on an unused channel.  No other network in my area uses a wireless channel below 6 so I configured the new WLAN to use channel 1 although I have tried other channels as well.  Other devices work flawlessly on the new WLAN.

The behavior difference between wired and wireless mode is immediately noticeable.  My application has numerical displays that are updated by a 100 millisecond loop.

In wired mode, these values jump around continuously.  In wireless mode, they start that way but within a second or two, beging to update more slowly and eventually quit changing.  After about 10 - 15 seconds, I get Error 200284 from DAQmx Read: "Some or all of the samples requested have not yet been acquired".

The 9237 is set to sample at 1.613Ks/sec in continuous mode with a 2K buffer.  The loop is reading (wait until data is available) 161 samples from all four channels of the 9237 so the chunk of data is large but not huge.  My application averages the 161 readings to give me a nice value 10 times a second.  In wired mode, I get exactly what I expect.

I have tried this under many different configurations of wireless security (including none) and may different physical arrangements (near and far) between the router and the 9123.  Nothing seems to work.  I have to do demo with this device in a battery powered mobile application (within a room) in 8 days!

Helllp!

[CharlesD]

Hey Burnt,

I would try two things first as initial trouble shooting steps. 

1. Lets try setting the timeout value on the DAQmx Read to -1.  This means that it will wait until a sample is in the DAQmx Buffer (on the computer) to return a value.   If you are using the DAQ assistant the timeout is inside of the DAQ assistat under the Advanced Timing Tab. Let's see if we get any kind of data back.

2. Let's try to use a different wireless channel.  Sometimes even though there are no other wireless networks around ch1, it is possible that there is other interferences that are working on channel 1.  Therefore I would try a bunch of different channels and more implortantly try channels that are on the other side of the spectrum.  

All in all this sounds like the WLS is establishing communication and is acquiring data on its side of things, but it is not transmitting properly back to the Computer and putting data in the DAQmx buffer. 

Let's try those steps and let us know how they work out!

[Burnt Fingers]

Hi Charles,

Thanks for your response.  I tried channel 6 too.

The timeout is currently the default (10 seconds).  For a 100 mSecond loop, that's essentially forever.   Note that the timed loop is set to not skip missed periods and not try to maintain original phase.

I don't have time to do many experiments right now but will be happy to run some in a few days.  Remember that when I run in wireless mode, I do get some data initially but then it seems like things bog down almost immediately.  I could run a sniffer and get packet sizes and timestamps.

Also note that I can successfully run calibrations, self tests, etc. in wireless mode.  The only thing that might be noticeable there is that it seems to (very subjective) take longer to "reconnect" in wireless mode after rebooting the 9123.

The following are ping times, with comments.  Note that just having the radio on in the 9123 seems to slow it significantly.  In the test, both the wired and wireless links are handled by the same router.  I presume it (Linksys WRT54G2 router) is being a good switch and sending the ping only through the wired port rather than duplicating the ping on both wired and wireless sides.   My tests in my initial message were with the actual LabView application were with either the radio on and the wired ethernet disconnected, or with the wired link connected and the radio disabled.  I never tested with both links enabled but I can guess at the outcome based on the timings below.

$ ping -n 20 192.168.0.124  //Wireless 802.11g

Pinging 192.168.0.124 with 32 bytes of data:

Reply from 192.168.0.124: bytes=32 time=58ms TTL=64
Reply from 192.168.0.124: bytes=32 time=14ms TTL=64
Reply from 192.168.0.124: bytes=32 time=7ms TTL=64
Reply from 192.168.0.124: bytes=32 time=4ms TTL=64
Reply from 192.168.0.124: bytes=32 time=51ms TTL=64
Reply from 192.168.0.124: bytes=32 time=75ms TTL=64
Reply from 192.168.0.124: bytes=32 time=31ms TTL=64
Reply from 192.168.0.124: bytes=32 time=20ms TTL=64
Reply from 192.168.0.124: bytes=32 time=43ms TTL=64
Reply from 192.168.0.124: bytes=32 time=66ms TTL=64
Reply from 192.168.0.124: bytes=32 time=22ms TTL=64
Reply from 192.168.0.124: bytes=32 time=10ms TTL=64
Reply from 192.168.0.124: bytes=32 time=33ms TTL=64
Reply from 192.168.0.124: bytes=32 time=56ms TTL=64
Reply from 192.168.0.124: bytes=32 time=12ms TTL=64
Reply from 192.168.0.124: bytes=32 time=36ms TTL=64
Reply from 192.168.0.124: bytes=32 time=2ms TTL=64
Reply from 192.168.0.124: bytes=32 time=48ms TTL=64
Reply from 192.168.0.124: bytes=32 time=2ms TTL=64
Reply from 192.168.0.124: bytes=32 time=2ms TTL=64

Ping statistics for 192.168.0.124:
    Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 75ms, Average = 29ms


$ ping -n 20 192.168.0.125  //Wired but with Wireless 802.11g radio still on in the 9123

Pinging 192.168.0.125 with 32 bytes of data:

Reply from 192.168.0.125: bytes=32 time=38ms TTL=64
Reply from 192.168.0.125: bytes=32 time=61ms TTL=64
Reply from 192.168.0.125: bytes=32 time=84ms TTL=64
Reply from 192.168.0.125: bytes=32 time=6ms TTL=64
Reply from 192.168.0.125: bytes=32 time=29ms TTL=64
Reply from 192.168.0.125: bytes=32 time=53ms TTL=64
Reply from 192.168.0.125: bytes=32 time=9ms TTL=64
Reply from 192.168.0.125: bytes=32 time=33ms TTL=64
Reply from 192.168.0.125: bytes=32 time=20ms TTL=64
Reply from 192.168.0.125: bytes=32 time=43ms TTL=64
Reply from 192.168.0.125: bytes=32 time=67ms TTL=64
Reply from 192.168.0.125: bytes=32 time=90ms TTL=64
Reply from 192.168.0.125: bytes=32 time=11ms TTL=64
Reply from 192.168.0.125: bytes=32 time=37ms TTL=64
Reply from 192.168.0.125: bytes=32 time=57ms TTL=64
Reply from 192.168.0.125: bytes=32 time=80ms TTL=64
Reply from 192.168.0.125: bytes=32 time=1ms TTL=64
Reply from 192.168.0.125: bytes=32 time=25ms TTL=64
Reply from 192.168.0.125: bytes=32 time=48ms TTL=64
Reply from 192.168.0.125: bytes=32 time=5ms TTL=64

Ping statistics for 192.168.0.125:
    Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 90ms, Average = 39ms


$ ping -n 20 192.168.0.125  //Wired but with Wireless 802.11g radio disabled in the 9123

Pinging 192.168.0.125 with 32 bytes of data:

Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64
Reply from 192.168.0.125: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.0.125:
    Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

[CharlesD]

Hey,

First the ping times are to be expected,  In the case where you have it wired and wireless radio on, when you ping the wired connection IP address the device gets to choose which medium it will transmit its response back to the computer  As such it defaults to the wireless communication medium.  The reason for this is that the device sees the host machine as the same location irrespective of which commmunication it uses to answer the ping. 

Now as for the magnitudes of response times, it is possible that those large response times are caused by a poor channel selection.  It is truly imperative that you try many channels.  You should deffinitely try ch 3,4,9,11 to see if you can get better performance. To get this done you will have to do some trial and error to determine your best channel.  I understand that you are able to reset the device and other configuration options but sending these commands constitutes very small amount of data.  This is not the case for the transfer of the data back to the DAQmx buffer. 

Give those other channels a shot and let us know if you are stillhaving performance issues!

Thank you 

[Burnt Fingers]

Hi Charles,

You didn't say why you thought selecting different channels might improve performance.  I presume that if there were no other radio signals around, that any channel might work reasonably well.  Therefore, I took the unit out into the field, literally.  I was running the 9163 and the wireless router off separate batteries, my laptop too.

Here was my experiment:

Laptop wired to Linksys router sitting about 6 feet away on one picnic table. Prior scan for wireless networks showed no signals (1/4 mile to nearest structure).  Set 9163/9237 and its battery on separate picnic table about 15 feet away, open air between router and 9163.  Running WPA-personal, SSID Broadcast - neither of which make any difference, using channel 1.

Repeated self tests pass.

Then I ran ping with the following results:

$ ping -n 10 192.168.1.102

Pinging 192.168.1.102 with 32 bytes of data:

Reply from 192.168.1.102: bytes=32 time=282ms TTL=64
Reply from 192.168.1.102: bytes=32 time=101ms TTL=64
Reply from 192.168.1.102: bytes=32 time=21ms TTL=64
Reply from 192.168.1.102: bytes=32 time=45ms TTL=64
Reply from 192.168.1.102: bytes=32 time=69ms TTL=64
Reply from 192.168.1.102: bytes=32 time=91ms TTL=64
Reply from 192.168.1.102: bytes=32 time=113ms TTL=64
Reply from 192.168.1.102: bytes=32 time=34ms TTL=64
Reply from 192.168.1.102: bytes=32 time=160ms TTL=64
Reply from 192.168.1.102: bytes=32 time=80ms TTL=64

Ping statistics for 192.168.1.102:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 21ms, Maximum = 282ms, Average = 99ms

Note that ping times between the laptop and the router were all less than 1 ms.

I tried channels 6 and 11 with similar results.

Summarizing this and previous tests:

802.11g performance is low regardless of:

1.  Router Vendor (tried Netgear and Linksys/Cisco)

2.  Security mode (tried Open and WPA-personal)

3.  Channel (apparently.  I didn't try all channels but clearly there was no interference in the last experiment.)

This device must operate in a client's WLAN where I have no control over the channel number and where the channel number will change as the device moves around.   I presume the device will manage to switch to a dominant signal like all other WLAN endpoints.  I just can't help but think that either a) this particular device is deffective in a very odd way, or b) the device software cannot support anything above a very low data rate.

[CharlesD]

Hi! 

Thank you very much for the post!  I spoke with our Wireless DAQ R&D department and we have seen the W:S-9234 run at full speed under various conditions.  

I truly appreciate your hard work and  am very interested in all of this data that you are getting.  I understand that it most likely took a lot of effort on your part.With that would you be able to perform the same test on channels 3, 4, and 9, specifically because they are known to be in the middle ground of most 802.11g networks.  Also realize that even though you are not detecting particular networks their could be other interferences around the frequency range of the 802.11g frequency protocol. Therefore it is possible there are other interferences going around the frequency of ch1.. 

Please let me know if you can do this

[rezaravani]

Hello everybody,

I have a problem regarding WLS 9206. Actually when the connection to WLS lost even for a short period of time, in DAQ Read function prompts an error. I have set the timeout to 10, or even -1 (for infinite wait) but DAQ read has the same problem and error.

this is the error message: Error -88710 occurred at DAQmx Read (Analog 2D DBL NChan NSamp )

I also check with simulation device, when I delete it from Measurement & Automation explorer and again adding it immediately, I see this problem from DAQ read again.

I expect after removing the device and adding it again, DAQ can read and continues its normal operation. In other words it seems -1 for timeout is not working at all.

I will appreciate if somebody answer me, Thanks! 

[foowho]

Hi Everyone,

Thought I should update this discussion with a success.  NI engineering eventually got involved and reproduced the problem.  They returned my unit with new firmware a couple weeks ago and it has been working smoothly under the desired conditions.

Burnt Fingers...

[CharlesD]

Hey Everyone,

To expand on  FooHo's post,  The overall reliability and performance of the WLS-9163/ENET-9163 carrier has been dramatically improved with the release of a new firmware. "Using an advanced adaptive interference immunity (ANI) control algorithm, NI WLS-9163 devices can now adjust wireless receiver and transmitter characteristics automatically in response to changing RF conditions. The result is significant improvement in wireless data throughput."  If you are using either of these two C-series carriers with the old firmware it is strongly recommended that you upgrade the firmware directly by going to the following link: http://joule.ni.com/nidu/cds/view/p/id/1615/lang/en 

Thank you and have a great day!