WifiNigel

Designing WLAN's is a pretty tricky business at the best of times, but trying to design a WLAN that works well for all clients is hard as they vary so wildly in terms of form-factor, wireless chip-sets, antenna counts and a plethora of other factors that mean they all see the wireless world in their own annoyingly unique way. The upshot of this is that when designing a WLAN we have to spend time trying to figure out how well (or badly) each client-type we need to support in our design sees our proposed wireless network. In simple terms, some will "hear" it more clearly than others due to their better antennas, build and sensitivity. A wise man once said that we should design our networks for our "most important, least capable" devices (...don't let him hug you, he WILL squish you). Once we've figured this device out, we have to work out the offset between our client of choice and our survey equipment or RF modelling software. To get this "offs...

I've had a number of occasions when it would have been really useful to deploy a wireless client device on a WLAN to monitor performance over time from a client perspective. Too often, when troubleshooting a wireless network, everything looks fine from the data provided by your infrastructure kit, but the user experience is a whole different story. Unfortunately, when this requirement has arisen, persuading anyone in the organization in which I was working to invest in a wireless probe-type solution has been an uphill battle. Around 18 months ago I got to the point when working on an issue that I could not progress and had no choice but to roll my own rudimentary client probe solution. It was a Python script installed on a Raspberry Pi acting as a client on a particular SSID that was having issues. It reported wireless connectivity data and a few client tests (e.g. speedtest & ping) to a Google spreadsheet. The same code also ran on a WLAN Pi, so that I could have two pro...