Testing PCsensor's TEMPerHUM Part 2 - Windows XP (Hardware Logging)
Testing PCsensor's “TEMPerHUM”
Phase 2: Testing PCsensor's “TEMPerHUM” in Windows XP environment
As we discussed in Phase 1, it was needed to have .NET Framework installed on a Microsoft Windows based computer in order to install PCsensor’s software TEMPerHUM. However, some users might not want to install that software, but instead to use the TEMPerHUM hardware’s ability to send monitored data to an empty file that was previously opened in the Windows’ foreground. (Why the term foreground is important here, we’ll see later.)
For example, a user can open an empty file in Notepad, and then activate the monitoring the temperature and humidity by pressing “TXT” button on the sensor device:
As you can see above, after pressing “TXT” button, the sensor starts its function by sending its ‘greeting’ (in form of “www.pcsensor.com, type:hs10, ...”), followed by filling-in the screen with monitored temperature in Celsius degrees (the 1st column) and relative humidity (the 2nd column), and it sends those measurements in two second intervals (as reported in the 3rd column). Nevertheless, every few dozens of lines, the hardware’s ‘greeting’ reappears on the screen:
So far – so good. However, having in mind that PCsensor's TEMPerHUM temperature & humidity sensor installs as a HID device (Human Interface Device) – and does not list as a real hardware USB device, it probably belongs to the same group of user input devices such as keyboards and mice, and it appears that they somehow interact each-other. That means, as long as the user keeps the opened file in the foreground and does not much or anything with his/her keyboard and mouse while the sensors sends the monitored data to the screen – everything looks fine. However, if the user performs some activity – especially with the mouse, say to open another program or something like that, which in turn sends the previously opened window to the background, the transfer & appearance of the monitored data goes wrong, by means that the new data are not sent to the end of the file, as it should be, but rather get ‘inserted’ somewhere in the middle of the screen (or just randomly anywhere in the screen), such as shown in the next picture ...
To make things worse, the computer sometimes goes completely out of control, by means that various operating system operations and software activities may start by themselves – without the user’s intervention, and the user is not capable to switch back to the opened window anymore. In some cases, the only solution to return back to normal is to pull out the sensor from the machine. In the worst scenario we have experienced, the uncontrolled behavior ended by rebooting the computer on its own! (In less terrible situations, where the user can return to the opened window, the keyboard combination CTRL-End resumes the proper filling-in the monitored data.)
Instead of Notepad, a user can open an empty file in Windows’ Wordpad. On a first sight, it looked better because it started without any ‘greeting’ from the sensor, but the ‘greeting’ did appeared from time to time …
By the way, if a user performed something in the foreground as mentioned, such as opening an empty Notepad file, then the new window would 'take over' receiving the monitored data:
Furthermore, the user can switch from Notepad back to Wordpad (that was temporarily running in the background), so the Wordpad window will resume its filling-in again …
... and so on, and so on ... However, that would continue without visible problems as long as the user switches from one window to another by using the keyboard's ALT-TAB combination. In opposite, if the user performs the changeover by using the mouse, the 'interference' is inserted again to the active window, probably as a result of the mouse movements:
... As shown above, the columns were 'shaking' again and the new data were written randomly on the each program’s screen. To escape from the random writings, the keyboard’s combination CTRL-End returns to the normal operation:
We did not try to receive the monitored data by any word processing or spreadsheet software, such as Microsoft Office or like, because our test machine was not equipped with any of them. Nevertheless, it is high probability that results would be pretty the same as with Notepad and Wordpad.
To conclude our Windows-based experiments, it should be said that PCsensor's TEMPerHUM temperature & humidity sensor satisfies basic needs of an average user. That means you will get various interpretations of monitored temperature & humidity, depending on your personal preferences in using (or not using) the device manufacturer’s software. On the other side, some more complex usage of monitored data we wanted to perform, such as transferring the data to an amateur radio software for further processing and retransmitting to the air, by using packet-radio modems and amateur radio stations, will require some additional research. At the time of writing this, we did not find a solution.