Hello,
I arranged an experiment to test the WiFi connection stability.
I connected a wired Labjack and a wireless Labjack(which stood closely to a router) to a new, valid router for 5 days.
The wired Labjack was not disconnected, while the wireless Labjack was disconnected 18 times for more than 3 seconds(and more disconnections for less time).
Right now, my company can't use such an unreliable product.
What can I do to improve the reliability of the connection over WiFi?
.png%3Fitok=PHGBxf6M "EEV Blog Reviews LabJack T7-Pro & Software Tools")
.jpg%3Fitok=B1YcuDFK)
.png%3Fitok=Ybt-OlgU "LabJack + JEDI One Can Create a Powerful Distributed DAQ Ecosystem")
If we define 100% uptime as the ability to transfer 1 packet within any 500 ms interval over some time, then I would say that with wired Ethernet is is normal to get 100% uptime over many days, but with wireless Ethernet (aka "WiFi") it is not normal to have 100% uptime over many days. There are so many sources of wireless interference that can cause brief disruptions, such as someone walking down the hall and blocking the wireless signal during a test.
That said, I often do WiFi tests without a single error over the course of days, so it is possible to have extra solid conditions. I have started a fresh test here at the office using the attached simple program for Windows. Perhaps try the same yourself and avoid running any other related software (e.g. Kipling, LJLog, LJStream, etc.) at the same time.
For my test I have a T7-Pro sitting in my desk in my office about 10 yards from the wireless access point. I'm using a static IP rather than DHCP. My typical RSSI is -35, and then I see it dip whenever anyone walks in between. It has run about 30 minutes so far with 0 errors to this point.
Thanks for your respond.
Please let me know what are the test result, and if you have any ides how to enhance the stability of the WIFI connection for the Labjack.
Ran the test app for a few days. It is hard to define "reliability" for a test like this, but I would call it 100% since it is still running and collecting data. The detail comes into defining uptime or perhaps "data recovery rate".
I have seen that during the day, there are perhaps 4-8 times where my read returns an error. The test app logs this as STOP and then logs a START when it is able to talk to the device again. I see that most of these last 5, 10, or 15 seconds. I did not look too close, but the test app or driver must use a 5 second timeout before each retry. During the night I see no errors at all.
The errors are apparently related to temporary disruption of the wireless network when the office is busy. Perhaps people standing between my T7-Pro and the router, or perhaps just RF pollution? The following page has tips at the bottom, some of which could be followed to try and improve wireless network quality:
https://labjack.com/support/app-notes/wifi-and-ethernet-t7-t4-t7-pro
So uptime here depends on how software attempts retries, how long disruptions last, and what my required interval is. In my case, if I defined my required interval as a reading every 30s, my uptime would likely be 100%. If I defined my required interval as a reading every 500 ms, my uptime would be perhaps 99.99%.
For comparison, with a wired connection, I would say uptime over a week on a office network with normal congestion would typically be 100% with the 500 ms requirement. WiFi networks are quite good, but wired will always be a little better.
I am having the same problem. Our T7 topology:
2-way communication via ethernet and wireless at the same time. As ethernet is also coupled via a wireless station, we do have the same wireless (2.4GHz) situation on both ways. The Ethernet solution is very stable, but the wireless solution running in parallel shows some like cyclical interruptions (about every minute) disconnecting and connecting automatically again. Pinging via ethernet is stable <1ms max 2ms, pinging on wireless shows the described interruptions and timeouts and for a while the same same stable behavior as the ethernet way. Watchdog is configured for 90sec. but disabling watchdog shows no change in behavior. Disabling ethernet also does not change behavior. Therefore, T7 wireless is not reliable enough for our application. As the second solution is working, we do not have problems with our clients. But for miniaturization efforts (second solution needs an extra wireless station) we would prefer a slim solution only via the T7. There is no IP conflict, as all devices work with deterrent static IP’s. Do you have some hints we could check?
Once a minute is not normal for a good connection on a good network. I would start with the test described in #2 and #4 above. A zip file is attached earlier in this topic or you can find WiFi-Testing.exe here:
http://files.labjack.com/utilities/
Just put in the correct identifier for your T7-Pro and then click the run arrow at the upper left. Watch the "Start/Stop" log to see how often there is a communication problem.
Update to the latest software and firmware so you are using the same as us. I have:
LJM 1.2000 (see "Settings" in Kipling)
T7 Firmware 1.2700
https://labjack.com/support/software/installers/ljm
I started the test program Tuesday, and over the course of 48 hours I've had 17 interruptions. Most recovered in about 10 seconds, but a few took up to a minute for the network to come back.
Many of these interruptions are likely from Kipling doing a WiFi search. LJM's WiFi search will often cause a temporary disruption and as you can imagine we often have many computers running Kipling around here.