Airview2 on openSUSE 11

[Armwheet]

Hi all,

I'm writing to let you know that Airview 2 on openSUSE 11 and openSUSE 11.1 doesn't work...yet;)

It is detected,

Apr 17 18:52:15 0xf kernel: usb 3-1: new full speed USB device using uhci_hcd and address 3
Apr 17 18:52:15 0xf kernel: usb 3-1: configuration #1 chosen from 1 choice
Apr 17 18:52:15 0xf kernel: drivers/usb/class/cdc-acm.c: This device cannot do calls on its own. It is no modem.
Apr 17 18:52:15 0xf kernel: cdc_acm 3-1:1.0: ttyACM0: USB ACM device
Apr 17 18:52:15 0xf kernel: usb 3-1: New USB device found, idVendor=1f9b, idProduct=0241
Apr 17 18:52:15 0xf kernel: usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 17 18:52:15 0xf kernel: usb 3-1: Product: AirView
Apr 17 18:52:15 0xf kernel: usb 3-1: Manufacturer: Ubiquiti
Apr 17 18:52:15 0xf kernel: usb 3-1: SerialNumber: 0123456789


and after first run I see:
No AirView USB devices found!
Please plug in an AirView USB device, wait a few seconds then click "Search again" to repeat search or "cancel" to exit the application.....
and then suddenly it's stopping in Searching for AirView USB device ... (attempt #123;)

Java version is: java-1_6_0-sun-1.6.0.u13-0.1.

runtime.log
2009-04-17 19:18:55.212 INFO (main) [e] Initializing ...
2009-04-17 19:18:55.275 INFO (main) [ClassPathXmlApplicationContext] Refreshing org.springframework.context.support.ClassPathXmlApplicationContext@1589e56: display name [org.springframework.context.support.ClassPathXmlApplicationContext@1589e56]; startup date [Fri Apr 17 19:18:55 CEST 2009]; root of context hierarchy
2009-04-17 19:18:55.352 INFO (main) [XmlBeanDefinitionReader] Loading XML bean definitions from URL [jar:file:/home/armwheet/ubnt/AirView-Spectrum-Analyzer-v1.0.08/airview-o.jar!/beanRefContext.xml]
2009-04-17 19:18:55.354 DEBUG (main) [DefaultDocumentLoader] Using JAXP provider [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl]
2009-04-17 19:18:55.359 DEBUG (main) [BeansDtdResolver] Found beans DTD [http://www.springframework.org/dtd/spring-beans.dtd] in classpath: spring-beans.dtd
2009-04-17 19:18:55.374 DEBUG (main) [DefaultBeanDefinitionDocumentReader] Loading bean definitions
2009-04-17 19:18:55.402 DEBUG (main) [XmlBeanDefinitionReader] Loaded 3 bean definitions from location pattern [classpath*:beanRefContext.xml]
2009-04-17 19:18:55.402 INFO (main) [ClassPathXmlApplicationContext] Bean factory for application context [org.springframework.context.support.ClassPathXmlApplicationContext@1589e56]: org.springframework.beans.factory.support.DefaultListableBeanFactory@ff8c74
2009-04-17 19:18:55.416 INFO (main) [DefaultListableBeanFactory] Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@ff8c74: defining beans [com.ubnt.application,com.ubnt.application.test.harness,com.ubnt.application.test]; root of factory hierarchy
2009-04-17 19:18:55.417 DEBUG (main) [DefaultListableBeanFactory] Creating shared instance of singleton bean 'com.ubnt.application'
2009-04-17 19:18:55.418 DEBUG (main) [DefaultListableBeanFactory] Creating instance of bean 'com.ubnt.application'
2009-04-17 19:18:55.499 DEBUG (main) [BeanUtils] No property editor [org.springframework.context.ApplicationContextEditor] found for type org.springframework.context.ApplicationContext according to 'Editor' suffix convention
2009-04-17 19:18:55.502 INFO (main) [ClassPathXmlApplicationContext] Refreshing org.springframework.context.support.ClassPathXmlApplicationContext@1dec1dd: display name [org.springframework.context.support.ClassPathXmlApplicationContext@1dec1dd]; startup date [Fri Apr 17 19:18:55 CEST 2009]; root of context hierarchy
2009-04-17 19:18:55.504 INFO (main) [XmlBeanDefinitionReader] Loading XML bean definitions from class path resource [applicationContext.xml]
2009-04-17 19:18:55.505 DEBUG (main) [DefaultDocumentLoader] Using JAXP provider [com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl]
2009-04-17 19:18:55.511 DEBUG (main) [BeansDtdResolver] Found beans DTD [http://www.springframework.org/dtd/spring-beans.dtd] in classpath: spring-beans.dtd
2009-04-17 19:18:55.530 DEBUG (main) [DefaultBeanDefinitionDocumentReader] Loading bean definitions
2009-04-17 19:18:55.535 DEBUG (main) [XmlBeanDefinitionReader] Loaded 5 bean definitions from location pattern [applicationContext.xml]
2009-04-17 19:18:55.535 INFO (main) [ClassPathXmlApplicationContext] Bean factory for application context [org.springframework.context.support.ClassPathXmlApplicationContext@1dec1dd]: org.springframework.beans.factory.support.DefaultListableBeanFactory@11756a4
2009-04-17 19:18:55.540 DEBUG (main) [DefaultListableBeanFactory] Creating shared instance of singleton bean 'propertyConfigurer'
2009-04-17 19:18:55.540 DEBUG (main) [DefaultListableBeanFactory] Creating instance of bean 'propertyConfigurer'
2009-04-17 19:18:55.545 DEBUG (main) [DefaultListableBeanFactory] Eagerly caching bean 'propertyConfigurer' to allow for resolving potential circular references
2009-04-17 19:18:55.554 DEBUG (main) [DefaultListableBeanFactory] Creating shared instance of singleton bean 'propertyFileList'
2009-04-17 19:18:55.554 DEBUG (main) [DefaultListableBeanFactory] Creating instance of bean 'propertyFileList'
2009-04-17 19:18:55.562 DEBUG (main) [DefaultListableBeanFactory] Eagerly caching bean 'propertyFileList' to allow for resolving potential circular references
2009-04-17 19:18:55.562 DEBUG (main) [DefaultListableBeanFactory] Finished creating instance of bean 'propertyFileList'
2009-04-17 19:18:55.563 DEBUG (main) [DefaultListableBeanFactory] Finished creating instance of bean 'propertyConfigurer'
2009-04-17 19:18:55.563 INFO (main) [PropertyPlaceholderConfigurer] Loading properties file from class path resource [application.properties]
2009-04-17 19:18:55.568 INFO (main) [PropertyPlaceholderConfigurer] Loading properties file from class path resource [build.properties]
2009-04-17 19:18:55.569 INFO (main) [PropertyPlaceholderConfigurer] Loading properties file from class path resource [test.properties]
2009-04-17 19:18:55.570 WARN (main) [PropertyPlaceholderConfigurer] Could not load properties from class path resource [test.properties]: class path resource [test.properties] cannot be opened because it does not exist
2009-04-17 19:18:55.570 INFO (main) [PropertyPlaceholderConfigurer] Loading properties file from class path resource [user.properties]
2009-04-17 19:18:55.570 WARN (main) [PropertyPlaceholderConfigurer] Could not load properties from class path resource [user.properties]: class path resource [user.properties] cannot be opened because it does not exist
2009-04-17 19:18:55.573 DEBUG (main) [DefaultListableBeanFactory] Creating shared instance of singleton bean 'com.ubnt.app.AirViewer'
2009-04-17 19:18:55.574 DEBUG (main) [DefaultListableBeanFactory] Creating instance of bean 'com.ubnt.app.AirViewer'
2009-04-17 19:18:55.605 DEBUG (main) [DefaultListableBeanFactory] Eagerly caching bean 'com.ubnt.app.AirViewer' to allow for resolving potential circular references
2009-04-17 19:18:55.606 DEBUG (main) [DefaultListableBeanFactory] Creating shared instance of singleton bean 'com.ubnt.device.AirViewDeviceLocator'
2009-04-17 19:18:55.606 DEBUG (main) [DefaultListableBeanFactory] Creating instance of bean 'com.ubnt.device.AirViewDeviceLocator'
2009-04-17 19:18:55.613 DEBUG (main) [DefaultListableBeanFactory] Eagerly caching bean 'com.ubnt.device.AirViewDeviceLocator' to allow for resolving potential circular references
2009-04-17 19:18:55.613 DEBUG (main) [DefaultListableBeanFactory] Invoking init method 'init' on bean with name 'com.ubnt.device.AirViewDeviceLocator'
2009-04-17 19:18:55.613 DEBUG (main) [DefaultListableBeanFactory] Finished creating instance of bean 'com.ubnt.device.AirViewDeviceLocator'
2009-04-17 19:18:55.650 DEBUG (main) [DefaultListableBeanFactory] Finished creating instance of bean 'com.ubnt.app.AirViewer'
2009-04-17 19:18:55.650 INFO (main) [DefaultListableBeanFactory] Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@11756a4: defining beans [propertyFileList,systemPropertiesLoader,propertyConfigurer,com.ubnt.device.AirViewDeviceLocator,com.ubnt.app.AirViewer]; root of factory hierarchy
2009-04-17 19:18:55.650 DEBUG (main) [DefaultListableBeanFactory] Returning cached instance of singleton bean 'propertyFileList'
2009-04-17 19:18:55.650 DEBUG (main) [DefaultListableBeanFactory] Creating shared instance of singleton bean 'systemPropertiesLoader'
2009-04-17 19:18:55.650 DEBUG (main) [DefaultListableBeanFactory] Creating instance of bean 'systemPropertiesLoader'
2009-04-17 19:18:55.651 DEBUG (main) [DefaultListableBeanFactory] Eagerly caching bean 'systemPropertiesLoader' to allow for resolving potential circular references
2009-04-17 19:18:55.654 DEBUG (main) [DefaultListableBeanFactory] Returning cached instance of singleton bean 'propertyFileList'
2009-04-17 19:18:55.654 DEBUG (main) [DefaultListableBeanFactory] Invoking init method 'init' on bean with name 'systemPropertiesLoader'
2009-04-17 19:18:55.654 INFO (main) [SystemPropertiesLoaderBean] Loading properties file from class path resource [application.properties]
2009-04-17 19:18:55.655 INFO (main) [SystemPropertiesLoaderBean] Loading properties file from class path resource [build.properties]
2009-04-17 19:18:55.655 INFO (main) [SystemPropertiesLoaderBean] Loading properties file from class path resource [test.properties]
2009-04-17 19:18:55.655 WARN (main) [SystemPropertiesLoaderBean] Could not load properties from class path resource [test.properties]: class path resource [test.properties] cannot be opened because it does not exist
2009-04-17 19:18:55.655 INFO (main) [SystemPropertiesLoaderBean] Loading properties file from class path resource [user.properties]
2009-04-17 19:18:55.655 WARN (main) [SystemPropertiesLoaderBean] Could not load properties from class path resource [user.properties]: class path resource [user.properties] cannot be opened because it does not exist
2009-04-17 19:18:55.655 INFO (main) [SystemPropertiesLoaderBean] Added all configured properties to system properties.
2009-04-17 19:18:55.656 DEBUG (main) [DefaultListableBeanFactory] Finished creating instance of bean 'systemPropertiesLoader'
2009-04-17 19:18:55.656 DEBUG (main) [DefaultListableBeanFactory] Returning cached instance of singleton bean 'propertyConfigurer'
2009-04-17 19:18:55.657 DEBUG (main) [DefaultListableBeanFactory] Eagerly caching bean 'com.ubnt.application' to allow for resolving potential circular references
2009-04-17 19:18:55.657 DEBUG (main) [DefaultListableBeanFactory] Invoking afterPropertiesSet() on bean with name 'com.ubnt.application'
2009-04-17 19:18:55.658 DEBUG (main) [DefaultListableBeanFactory] Finished creating instance of bean 'com.ubnt.application'


and finally AirView.properties

#AirView saved preferences. Please do not edit manually.
#Fri Apr 17 19:18:56 CEST 2009
avgTrace.enabled=true
avgTrace.shaded=true
__propFilepath__=/home/armwheet/Ubiquiti-Networks/AirView.properties
currentTrace.enabled=true
maxTrace.enabled=true
maxTrace.shaded=false


If you need any additional info - just let me know..

[cz_ranger]

Hi,

I can confirm the above... absolutely no luck on OpenSuse 11 :cry:

Tom

[afalout]

Same here; I am yet to see a success report from a Linux machine - did anyone see one anywhere?

Am I the only one disappointed that the product was and is advertised as "Windows XP, Vista, Apple OSX, Linux" compatible? I would have certainly not bought mine if it was not so...

UBNT, when can we hope for some update regarding this issue?

[Oliver]

FYI:
I've had limited success on Ubuntu 8.10 Desktop. It has worked several times, but the software didn't detect the device reliably. Since upgrading to 9.04, it stopped working under Linux completely. Under Windows, there don't seem to be any problems, even when run from VMWare.


Grtz,

Oliver

[wireless_guy]

Hi all,

I

If you need any additional info - just let me know..

Hi Guys,

Any trial version for these..say 1yr :wink:

Any USB wifi dongle can be used for this?

A multi cursor can be turned on and off as a feature.

thanks

[WHT]

Any USB wifi dongle can be used for this? It would require some very serious mod work that would make buying a refurbed laptop with Windows on it seem a better bet.

[afalout]

[quote="Oliver"]FYI:
I've had limited success on Ubuntu 8.10 Desktop. It has worked several times, but the software didn't detect the device reliably. Since upgrading to 9.04, it stopped working under Linux completely.

Oliver, can you please post the logs from 8.10 if you still have it/them? I have 8.10 here myself (intrepid) but never managed it to recognize the device. Also tried Centos v5.2 which is supposed to be supported together with Fedora 9/10, and Suse 11, 10.3 and 10.1, several Ubuntu versions inc 9.04 Jaunty, and BackTrack 3 and 4 Beta.

Also, was 8.10 under VM or on hardware?

Thanks,
Andrej

[Oliver]

Hey afalout,

I'll see if I can still find some logs. Also, it worked on some machines, while it didn't work on others. These could have been running slightly different kernel-versions and the hardware definately differed. On the machine where it did work, it didn't do so reliably. All of my tests under Linux where on real hardware.


Grtz,

Oliver

[UBNT-Ramin]

Armwheet (and others),

It's very likely that it's a user/group permission issue. I apologize for not having made mention of it anywhere.

Please refer to my 5/20 post in the following thread on how to fix it: http://forum.ubnt.com/forum/viewtopic.php?t=11136

Let me know if this solved it for you folks as I don't have a copy of Suse/OpenSuse available to me at the moment.

Thanks,

[UBNT-Ramin]

I've had limited success on Ubuntu 8.10 Desktop. It has worked several times, but the software didn't detect the device reliably. Since upgrading to 9.04, it stopped working under Linux completely. Under Windows, there don't seem to be any problems, even when run from VMWare.

I've done some additional testing and I can tell you that on Ubuntu 8.04 (Hardy?) it worked every single time. Apparently with later versions of Ubuntu and openSUSE 11.x there has been some major changes to the way the O/S deals with byte streams. Not enough to effect any native code, but apparently just enough to screw with the way the JVM retrieves data from streams. :x I'm trying to figure out a fix/workaround for this right now.

So aside from the user/group permission issue, there's also this issue, which is going to require a fix from us to make the AirView UI app to work on openSUSE and latest versions of Ubuntu.

Please keep an eye on the AirView Release Notes (http://forum.ubnt.com/forum/viewtopic.php?t=9840) thread for the bug fix release.

Thanks,

[UBNT-Ramin]

Folks,

I'm happy to report that I diagnosed and fixed the byte stream issues I reported on earlier. :D

For some reason latest versions of Ubuntu and openSUSE were affected by this but RedHat/Fedora/Centos weren't. Version 1.0.09 (for Linux & Mac only) is now available from the downloads page. Please get it, untar & run it, and let me know if it works for you.

Please note that the comments about the user/group permissions still apply. Please read the notes about this on the AirView Release Notes (http://forum.ubnt.com/forum/viewtopic.php?t=9840) post.

Thanks,

[afalout]

Hello *,

I already spent far too much time on this, so I'll keep to the facts.

In the process of testing AirView I wrote a little script that can help you install and configure AirView correctly, to the best of my knowledge. I wrote it to provide some consistency for testing and to automate installations on multiple machines I was testing:

1. Get the script: 'wget -O - http://falout.org/site/tiki-download_file.php?fileId=1 > /tmp/airview2.sh'
2. Install AirView: 'bash /tmp/airview2.sh install'
3. Run AirView: as root: '/opt/airview/airview2.sh' as non-root: '~/airview/airview2.sh'
4. Help & options: 'airview2.sh help'

I re-tested everything with yesterday released v1.0.09. I tested 5 AirView devices on 6 computers in total.

Software "runs" on (hardware):

* Suse 11.1 64 bit (With 64 bit librxtx)
* SlackWare 12 (BackTrack 3)
* CentOs 5.2 (With messages "Handling unresponsive device" approximately every 10 seconds) v1.0.08 only v1.0.09 did not work at all

Software "runs" on (VMware):

* CentOs 5.2 (With messages "Handling unresponsive device" approximately every 10 seconds) v1.0.08 only v1.0.09 did not work at all
* Windows XP SP3 (Not SP2)
* Suse 11 64 bit (With messages "Handling unresponsive device" approximately every 10 seconds) v1.0.09

Other users reported:

* Ubuntu 8.10 Desktop (Oliver) ("it worked on some machines, while it didn't work on others.On the machine where it did work, it didn't do so reliably")
* Ubuntu 9.04 (nvmtnlion) Works
* Windows on VMware (Oliver) Works

I did not manage to get AirView app running (recognizing the device) at all on:

* Windows XP SP2
* Suse 11 32 bit
* Ubuntu 8.10 (BackTrack 4)

SlackWare 12 (BackTrack 3) that did run on hardware, did not on VMware. CentOs 5.2 had "Handling unresponsive device" problem on both hardware and VMware

I also tested few other distros, but I guess everything other then "Redhat (and offshoots - ie: Centos 5.x/Fedora 9/10) and Ubuntu distros" that are apparently supported according to the release notes, is only of academic interest.


Here are few observations about the results, when the device is recognized, and software does run:

* Looking at libusb timing statistics, the drift is ... well. puzzling. I am not a great expert on USB, so I wont comment further, but I suspect it has something to do with the results - it can explain why it works on some ports/hubs but not on the others, why it work on some ports/hubs only sometimes when it feels like it, and in my opinion, why all Linux VMware installs that do manage to recognize the device, fail with "Handling unresponsive device". It may be/likely is lib RXTX issue. I might be tempted to recompile librxtx from CVS sources if I had the time.
* After comparing five devices simultaneously running in same location with antennas next to each other, all I can say is that data shown by AirView looks inconsistent, if not random. If you did not know better, every reasonable person would be convinced that each device shows spectrum data from completely different sites.
* Even the same device shows completely different results on same location, each time it is started, just minutes after it was showing a completely different picture (that I saved as PNG images and just to be sure asked 2 more people to compare)
* I did not have the time or motivation to test the above on Windows
* I would expect that the fact that AirView runs on Windows XP on VMware shows that there is nothing inherently wrong with VMware that is causing AirView not to run on Linux when in VMware. In my opinion it is more likely that timing issue present a bigger challenge on Linux then they do on Windows. The device itself is a USB1 device, and therefore the chances of VMware "interfering" with USB bus are even more remote. We are using many USB2 adapters with VMware for a long time, and had no issues at all.


As the things stand now, our five AirViews are going back, unless I can find the solution/explanation for complete inconsistency of data displayed. We can live without VM support, reluctantly, but we have to be able to trust what the device is showing us.

Again a reminder that I did not test this on Windows, it may be a completely different story. However, for our purpose this is of no use.

Kind regards,
Andrej Falout

PS. Thanks to Ramin for his help.

[UBNT-Ramin]

Andrej,

First, thank you very much for the time you've spent running/diagnosing the app on your machine HW. And thank you for that script. I realize this will sound like a bit of a cop-out but the decision to release AirView on Linux with a minimal and simplistic script was one that was not made lightly. There were a lot of other factors that had to be considered balancing out time spent on installation/rutime scripts vs. providing application functionality and platform support. Nonetheless we thank you very much for providing that script and I'll be sure to utilize ideas based on it for next release of AirView application for Linux.

As far as VMWare issues, all I can say is that something in the combination of Linux distro, host O/S used to run VMWare, and the VMWare player for the target O/S is causing the issue(s). As you noted yourself on Windows ran as a VM it performs just the same as Windows ran on real HW, whereas the same isn't true about other Linux distros.

Trying to chase down problems caused by every single combination of Linux distro, host VMWare O/S, and VMWare player for target O/S is a huge time sink and we felt our development time for this initial release of AirView would be much better spent concentrating on producing a robust and accurate application with easy-to-use features.

* CentOs 5.2 (With messages "Handling unresponsive device" approximately every 10 seconds) v1.0.08 only v1.0.09 did not work at all
I really don't know what to tell you about this one. I have a real HW install of CentOS 5.2 on a Lenovo desktop machine (Core2 Duo @ 2.2 GHz) with pretty standard HW, running Gnome X desktop, that I've been using all along for Linux testing. AirView has ran on this machine literally for weeks on end without a hitch, without restarting the app. No "unresponsive device" messages, ever! Never mind every 10 seconds. And this same machine is running a video camera DVR application in the background to boot! That DVR app sucks away huge machine resources, and even with that AirView app continues to run flawlessly.

And yes, 1.0.09 was tested on this same CentOS 5.2 machine before I released it. I've ran it both while connected to directly to the machine's USB port, as well as through a 4-port USB hub (Kensington PocketHub Mini), and it's worked flawlessly regardless.

So I really don't know what to tell you on this one other than I'd have to really investigate the HW differences between our two installations, purchase the exact same make/model of machine, install the exact same set of pkgs/apps you have running on yours, and try it to see what could be causing the issues you're seeing.

I did not manage to get AirView app running (recognizing the device) at all on:

* Windows XP SP2
* Suse 11 32 bit
* Ubuntu 8.10 (BackTrack 4)

I also tested few other distros, but I guess everything other then "Redhat (and offshoots - ie: Centos 5.x/Fedora 9/10) and Ubuntu distros" that are apparently supported according to the release notes, is only of academic interest.
Again, I developed the AirView app on my trusty HP/Compaq laptop running Windows XP SP2. And although it worked fine on my laptop I had heard from other testers that with SP2 there were intermittent problems with USB serial devices. This is why the release notes states to upgrade your Windows install to the latest SP appropriate for your edition of Windows. This is something most application vendors (including Microsoft) recommend anyways.

* Looking at libusb timing statistics, the drift is ... well. puzzling... It may be/likely is lib RXTX issue.
Although I'm not quite sure what you mean by "drift", librxtx is AirView's main communication component so any issues with that binary for whichever platform you're running will have consequences on the app.

* After comparing five devices simultaneously running in same location with antennas next to each other, all I can say is that data shown by AirView looks inconsistent, if not random. If you did not know better, every reasonable person would be convinced that each device shows spectrum data from completely different sites.
The RF spectrum readout data coming from the AirView2 device was verified by feeding signals via a caliberated/tested signal generator. The device measurements of the RF signal input were "dead on" as to what the signal generator was outputting. Both me and my firmware developer partner (who wrote the FW for the device) verified the devices ability to accurately measure input signals using 2 separate signal generators.

You can verify this yourself if you have an AirView2-EXT and an accurate and calibrated signal generator that can output signals in the 2400-2485 MHz range (ala Anritsu MS2721A). You'll see that both devices show very close readouts at the same location, at the same time.

* Even the same device shows completely different results on same location, each time it is started, just minutes after it was showing a completely different picture (that I saved as PNG images and just to be sure asked 2 more people to compare)
I'm not sure why you're so surprised by this. RF devices operate on burst of emissions whose power levels, aside from being temporal, vary greatly based on how much they reflect off different surfaces, what obsticles are in the way, and what other RF sources are interfering with them, at the time they're measured. The very same spot can see wildly varying power levels from one min to the next. This is just nature of wireless communications.

Measuring live wifi signals on air is kind of like staring on the side of a busy highway -- you'll get a different picture every second you look. Only if you looked at long term averages would you expect to see similarities. The fact that Airview scans relatively slowly (3.7 fps vs. high-priced spec-an devices at 20 or 30 fps) means that it will take a while to catch a lot of representative data, and it by definition means that not all units that are on will catch the same transient events -- it's just a fact; stuff will get missed.

As the things stand now, our five AirViews are going back, unless I can find the solution/explanation for complete inconsistency of data displayed. We can live without VM support, reluctantly, but we have to be able to trust what the device is showing us.
I'm sorry to hear that even though the app has been verified to work on at least 5 separate distros (RH, CentOS, Fedora, Ubuntu, openSUSE), you're unable to use it for your purposes. I highly recommend verifying the AirView readouts with another spectrum analyzer, side-by-side, and even more impotantly, AT THE SAME TIME before you send your units back. I guarantee you'll find the AirView data to be just as accurate as data produced by scanners that cost 1000s of $$$.

Again a reminder that I did not test this on Windows, it may be a completely different story.
Hmm... I'm a little confused. Earlier you'd mentioned having tested this on both Windows XP SP2 and XP3, so I'm not sure what you mean by this.

PS. Thanks to Ramin for his help.
You're quite welcome and once again thank you for the time you put into evaluating AirView.

Regards,