Caveat: please note that there seems to be no official documentation about the used protocol. The only valuable source of help was ELV’s documentation of the ULA 200 (an USB-to-LCD converter), which uses the same protocol principle. Everything described below is just the result of snooping the USB bus and analyzing the data when controlling the logger via the Windows software. So, the information here might be (partially) wrong and/or incomplete. And, of course, it’s always possible that the manufacturer might have incompatibly changed the logger’s firmware meanwhile. Use at your own risk.

The serial interface parameters are 38400,E,1. The protocol is relatively simple: the PC sends a command sequence to the logger and the logger answers with an appropriate message. All data transfers are in binary format.

The following ASCII control codes are used in data transfers:

Name Hex-Code
STX 0x02
ETX 0x03
ENQ 0x05
ACK 0x06
NAK 0x15

All commands are of the form

<STX> <cmd> <parameters> <ETX>

and will be answered with the sequence:

<STX> <cmd> <response> <ETX>

Since all data transfers are done in binary format, the following translation of the characters in <parameters> and <response> has to be done: if any of the characters <STX>, <ETX> or <ENQ> is to be transmitted, this character must be replaced with the two character sequence <ENQ> <c+0x80>. Consequently, the receiving side has to translate this two character sequence back into the original character.

Known command sequences

If the logger is busy, or there is an error in the command sequence (though some errors will simply be ignored), the <response> field of the answer is always <NAK>. So, in the following description, only the answers in case of success are given.

The date sequence used in the communication is a sequence of seven bytes in the following format:

yearlo yearhi month day hours minutes seconds

The year is to be interpreted as a 16bit number (LSB first); month ranges from 0 (January) to 11 (December); the other bytes are to be interpreted as expected.

Note that this interpreting is just done by the controlling software on the PC. The logger itself does not do anything with the date, but just stores it in the eeprom and sends it back later. So, theoretically, we could send any seven byte sequence to the device here as long as we don’t use the original windows software for controlling the device.

Response:lo hi
Description:Get version number. To be interpreted as a 16bit number (LSB first). The original windows software seems to be using this command to periodically check whether the logger is currently active or not.

Response:lo hi
Description:Get number of stored data points. To be interpreted as a 16bit number (LSB first).

Parameters:starttime mode interval
Description:Start logging. starttime is a date sequence as described above; mode is 2 for temperature only and 3 for temperature plus humidity; interval is either 1 or 5.

Description:Stop logging. stoptime is a date sequence as described above.

Response:starttime mode interval stoptime
Description:Get starttime, endtime, mode and interval. See S and E commands for the meaning of the response.

Response:tlo thi hum ...
tlo thi ...
Description:Get first data record. Depending on the logging mode, either two or three bytes per data point will be sent. The temperature values are to be interpreted as 16bit values (LSB first) with 1/10°C unit. The humidity value can be taken directly.
Note that since the USB protocol is block oriented, the data record may contain more data points than available. These excess points have to be ignored.

Response:tlo thi hum ...
tlo thi ...
Description:Get next data record if there are more stored data points than can be retrieved by the R command. The same comment as for the R command applies.

Response:tlo thi hum ...
tlo thi ...
Description:Unknown command. Response is the same as from the previous R or N command.