Signal Loss via DataSocket / Wireless LAN

[clareokane]

I am sending signals from a computer to a notebook on a small vehicle. The signals are used to drive a servo controller board on the vehicle, and hence the speed/steering of the vehicle. The signals are currently being sent over a wireless LAN, using DataSocket. However, there seems to be an occssional loss of the connection, and the signals to control the vehicle stop being recieved. This is causing us many problems as it means the vehicle runs away in whatever direction it is going if it doesn't recieve a new signal to stop or change direction!

The problem is more apparent when running over a peer-to-peer netwrok (IP addresses 169.xxx.xxx.xxx), and is virtually non-existent when running via an access node with ethernet conn
ection (IP addresses 158.xxx.xxx.xxxx). It is noticeable, but minor when running over an access node with ethernet connection and IP addresses 131.xxx.xxx.xxx. when running over an access node without an enthernet connection (IP addresses 169 etc again), the performance is similar to peer-to-peer networking.

Can anyone shed any light on this problem and it's causes? Or can anyone suggest a solution? Is it a networking problem or is there soem other cause? It's getting quite annoying when our kit randomly decides to trundle off into the great blue yonder, or crash into the nearest tree!

Many Thanks,
Clare

[Matthew_Williams]

Do both ends of the link have hardcoded (i.e. not DHCP) addresses? Does the comm loss recover by itself? How long does the loss last?

Is this a closed network, meaning no other devices on the network and no internet or other network access?

Can you demonstrate losses in communication with medium sized repetitive ping packets? This would give you a good baseline if it accurately reflects the in-use errors.

Are there other RF sources that might be intefereing? The ping tests might also help track this down. What is the wireless hardware?

Sounds like at a minimum an 'all stop on comm loss' watchdog might be nice.

Sorry to ask so many questions without giving any answers.

Matt

[Mads]

Does the application take into account that data can easily be lost when using data socket? There is no buffering or other mechanism in datasocket that ensures that all written data is read/sampled prior to being overwritten...that requires additional code; the clients need to acknowledge that they have recieved the last value etc.

[clareokane]

Matt,

We have used both fixed IP addresses and DHCP assigned values, with the same results. The comms loss usually recovers, with the loss lasting up to 10 seconds. Occasioanlly, it does not recover, and we have to restart the vi to resume control.

We have also used both a closed network, and a network with internet access, and bizarrly, performance is better when there is an internet connection! We have stripped the system down completely to remove all other RF sources, but there is no improvement.

The wireless hardware is a PCMCIA Q-lynx card in a Xybernaut Wearable computer on the user side, and a 3com usb wireless adaptor, connected to a Sony Vaio on the vehicle side.

We have not yet tried using ping tests, but i will try it first thing
tomorrow, thanks for the suggestion!

Clare

[clareokane]

I wasn't aware the DataSocket sometimes lost data, thanks for bringing that to my attention! The system is tolerant of ocassional losses of data - even if it only recieved new data 2 or 3 times a second it would be sufficient for our purpose. However, we sometimes fail to receve data for more than several seconds at a time. Is this common for datasocket?

Clare

[Greg_McKaskle2]

> I wasn't aware the DataSocket sometimes lost data, thanks for bringing
> that to my attention! The system is tolerant of ocassional losses of
> data - even if it only recieved new data 2 or 3 times a second it
> would be sufficient for our purpose. However, we sometimes fail to
> receve data for more than several seconds at a time. Is this common
> for datasocket?
>

I'm not a datasocket expert, but I believe the comment was about the
difference between a blind protocol like datasocket and one with
acknowledgement. By this I mean that the code writing to a datasocket
isn't necessarily notified when the write has propagated to the various
readers or if there was a problem. I know that datasocket write on the
diagram has an error out,
and I believe it will notify you of any
problems with the existing connection, but the function returns before
the data has necessarily arrived at all destinations. The DataSocket
Connection... feature on front panel controls doesn't provide an error
otuput at all. You can read the status using a property node, but
notification of a problem isn't necessarily tied to a particular write.

It adds complexity, but if you want more verification, you might want to
look at using the VI Server to execute VIs or access controls and
indicators on remote computers, or use TCP and your own protocol for
sending text or binary information.

Greg McKaskle