Testing PCsensor's TEMPerHUM Part 3 - Linux (Hardware Logging)

Testing PCsensor's TEMPerHUM Part 3 - Linux (Hardware Logging)

Testing PCsensor's “TEMPerHUM”

Phase 3: Testing PCsensor's “TEMPerHUM” in Linux environment

As we discussed in Phase 1 & 2, it was possible to use TEMPerHUM on a Microsoft Windows -based computer without any software, thankfully to the hardware’s ability to send monitored data to an empty file that was previously opened in the Windows’ OS foreground. To activate monitoring the temperature and humidity, it was enough to press the “TXT” button on the sensor device.

To check how things would work in Linux environment, we booted our (dual-boot) computer into Linux Debian 7.11 (“Wheezy”), and experimented with various office programs.

1. gedit v. 3.4.2 (gedit is a small and lightweight text editor for GNOME Desktop in Linux)

As seen above, pressing the “TXT” button invokes the 'device greeting' in form of “www.pcsensor.com, type:hs10, caps lock ...” and then starts monitored data flow. The problem is that the file must be opened constantly and always be in the foreground. (If a user switches to some other window that previously was in the background, including some window opened by some other software, the monitored data stream goes to that other window – but only if that other window is applicable for inserting data, such as another text editor, or text processor, or a spreadsheet software. Otherwise, if not applicable, the incoming data stream produces instability of the operating system by means that every peace of incoming data activates some random activity, such as opening some unwanted programs, or switching from one window to another – without any user intervention, or even trying to restart/shutdown the computer.)

However, if the text editor, or text processor, or spreadsheet software is solely used on a machine, there might be some possibility to fill-in the incoming data stream to a previously opened and already used/saved file (i.e. a file that already had a filename), in order to use that filename and path as a predefined source for an amateur radio software that would use that data for further processing. The problem with that possible approach is that the device periodically breaks the monitored data stream by sending its 'device greeting' in form of “www.pcsensor.com, type:hs10, caps lock ...” and then resumes the data stream again. That behavior is shown in the next picture. If a user needs some further processing of data, some kind of software ‘filter’ would be needed to ‘keep a blind eye’ whenever a 'device greeting' appears on the screen.

2. LibreOffice Writer Build ID: 350m1(Build:2)

From unknown reasons, this text processor sometimes did not properly format the incoming data stream. Besides that, the device's behavior of periodically inserting the 'device greeting' has produced an effect such as shown in the next picture:

3. LibreOffice Calc Build ID: 350m1(Build:2)

LibreOffice's Calc speadsheet software performed the best by means how it presented the incoming data stream. In fact, it provided system’s date and time in the first two columns, following by monitored data in the next three columns. However, the periodically inserted 'device greeting' confirmed our speculation that it was a feature of the device's internal design, intentionally added by the factory. (Although somebody might find that feature as useful because it periodically ‘reminds’ the user that pressing “Caps Lock” and “Num Lock” can deactivate and reactivate reading the data stream, our tests showed that those two actions did not work at all in our Linux environment.

4. Kate v. 3.8.4 (an advanced text editor for the KDE Desktop)

Here we had again a 3-column presentation of incoming data (temperature, humidity, and interval of reading the data), similarly as in gedit. A slight dis-formatting in between the columns’ headers positions (c, %rh, interval) and the data content was visible here, as it was in LibreOffice Writer. Periodically inserted 'device greeting' confirmed once again that it was a feature of the device's internal design. It remains unclear why the producers wanted it to appear every half a minute or so? If the idea was to make an advertisement for the company, in form of its URL, we consider that as a not much clever decision. However, if  Pcsensor company decides to develop a ‘filter’ for that in the future, we would appreciate that as an upgrade. In opposite, it will remain as the annoying detail, see the next picture ...

Once again, a user needs to keep in mind that PCsensor's TEMPerHUM temperature & humidity sensor does not install itself as a real hardware USB device (but as we saw in Windows, rather as a HID device – Human  Interface Device – and as such probably belongs to the same group of user input devices such as keyboards and mice.) As a consequence, it appears that those devices somehow interact each-other in bad way. That means, as long as the user keeps the opened file in the foreground and does not do anything with his/her keyboard and mouse while the sensors transfers 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 data goes wrong, by means that the new data are not going to be sent to the end of the file (as it should be) but rather become ‘inserted’ somewhere in the middle of the screen (or just randomly anywhere in the screen).

In our Linux environment, similarly to Windows, the computer may also go out of control, by means that operating system actions and unwanted software activities may start randomly and without any user intervention. Having said that, there is a high probability that the user will not be capable to go back to the opened data window. Sometimes, the only solution is to pull the sensor physically out of the computer.

The above tests were performed in Linux GUI (graphical user interface). For those who prefer Linux CLI (command line interface), it would be needed to make appropriate software for Linux by yourself because Pcsensor company has obviously not wanted (or planned) to dispatch any Linux equivalent for TEMPerHUM software. By searching the Web we managed to find some suggestions on how to (better) use TEMPerHUM temperature & humidity sensor in Linux. Those solutions were based on source code packages provided by individual programmers, and it is expected that the end-users produce the executable programs on their own machines. More on this next time.

1 comment



How we can decode on python?

How we can decode on python?

Leave a comment

All comments are moderated before being published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.