acurite R3 messages
185 views
Skip to first unread message
mwall
Mar 1, 2015, 8:37:34 AM3/1/15
to weewx-de...@googlegroups.com
> I'd been trying to understand the USB protocol on my 01036, then came across your acurite.py on the Acurite support forum.
> You seem a lot further along than me, though I believe I have decoded a lot of the R3 historical format going at things
> backwards (comparing packet captures with CSV data from acu-link). No code yet, just notes.
>
> I don't have weewx (yet), I'm still trying to get the box running. I keep getting P71 protocol errors, both from my own
> Perl code and then when that didn't work, acurite.py modified to work without weewx. It's flaky with acu-link, too,
> but there it just doesn't reply, rather than giving P71. It's more reliable with the newer VIS.
> I'm not an expert USB programmer, but my hardware and libraries work OK with code I wrote for my USBmicro
> interface board.
>
> I wondered if you had any insights.
>
> Andrew
hello andrew,
i have not decoded any of the R3 messages. i am still trying to figure out the right way to *get* R3 messages. vis first sends a command and gets a 2 byte response, followed by the request for the R3. but i do not know what the 2 byte response means (size of data in R3?), and i do not know the proper protocol for R3 (the number of bytes returned by R3 seems to depend on timing, and sometimes getting the R3 will wedge the usb communications, requiring a soft reset or sometimes hard reset to communicate again).
i do not know what P71 is
m
> You seem a lot further along than me, though I believe I have decoded a lot of the R3 historical format going at things
> backwards (comparing packet captures with CSV data from acu-link). No code yet, just notes.
>
> I don't have weewx (yet), I'm still trying to get the box running. I keep getting P71 protocol errors, both from my own
> Perl code and then when that didn't work, acurite.py modified to work without weewx. It's flaky with acu-link, too,
> but there it just doesn't reply, rather than giving P71. It's more reliable with the newer VIS.
> I'm not an expert USB programmer, but my hardware and libraries work OK with code I wrote for my USBmicro
> interface board.
>
> I wondered if you had any insights.
>
> Andrew
hello andrew,
i have not decoded any of the R3 messages. i am still trying to figure out the right way to *get* R3 messages. vis first sends a command and gets a 2 byte response, followed by the request for the R3. but i do not know what the 2 byte response means (size of data in R3?), and i do not know the proper protocol for R3 (the number of bytes returned by R3 seems to depend on timing, and sometimes getting the R3 will wedge the usb communications, requiring a soft reset or sometimes hard reset to communicate again).
i do not know what P71 is
m
mwall
Mar 1, 2015, 8:48:27 AM3/1/15
to weewx-de...@googlegroups.com
> Thanks for the reply.
>
> What do you mean, "soft reset" or "hard reset" ? Pushing the reset button under the battery cover ?
> Disconnecting the USB connector ? USB reset command ?
>
> Currently, I haven't managed to read the device at all under Linux, only in Windows. I mean,
> lsusb gets some data but otherwise I was getting this P71 error. I'm not quite sure what the
> Windows code is doing different. I have libusb 0.1 on Fedora 9 on my laptop, and a slightly
> later sub-version on my desktop with CentOS 6. Works with the USBmicro boards, my camera,
> webcam etc.
>
> I see on Michael Walsh's VIS forum he says that the 02xx firmware is bad, and he's not sure
> about the 01036, and has dropped support for R3 altogether. He also says something about
> VIS being re-written to do a better job resetting the device out of odd states, which I think is true.
>
> I have pcap files from running USB capture on Windows running acu-link, with R1 and R2
> records that agree with the debug logs from VIS, and R3 records that seem pretty stable at
> 33 bytes. But how they were setup to be downloaded, I don't know. I also haven't reliably
> found the date/time in the records, only temperature, pressure etc.
>
> As best I can tell:
byte value
1 3,3 ?
2 0 ,0 (to 180 at last point) ?
3 rainfall 1/100 inches
4 15, 15 (to 0 at last point) year 2015 ??
5 2, 2 (to 0 at last point) month 2 ??
6 8, 13 (to 0 at last point) day ??
7 22, 19 (to 0 at last point) ?
8 29, 23 (to 238 at last point) ?
9 29, 23 (to 238 at last point) ?
10 8 8 MSB
11 indoor temp = (X+248)/18 LSB temp = X/18 - 100
12 7,7 ?
13 206-188,0-220 ?
14 0, 0 ?
15 indoor humidity %
16 0, 0 ?
17 outdoor humidity %
18 7 , 7 MSB
19 wind chill = (X-8)/18 LSB temp = X/18 - 100
20 MSB
21 outdoortemp = (X-8)/18 LSB temp = X/18 - 100
22 MSB
23 dew point = (X-8)/18 LSB temp = X/18 - 100
24 MSB
25 LSB pressure
26 160-0, 300-0 ?
27 ?? wind direction
28 MSB?
29 LSB current wind kph / 16
30 MSB
31 LSB peak wind kph / 16
32 MSB ? 0
33 LSB average wind kph / 16
> regards, Andrew
On 26 Feb 2015, at 15:58, Andrew Daviel wrote:
> What do you mean, "soft reset" or "hard reset" ? Pushing the reset button under the battery cover ?
> Disconnecting the USB connector ? USB reset command ?
after doing R3 requests for awhile, i often get 'broken pipe' errors. sometimes unplugging then replugging the usb connector will get comms back. other times the only way to get usb communication back is to power cycle the console.
sometimes after initial power on of station and computer, the computer cannot communicate with the station. i have seen this with both vis and the weewx acurite driver. typically comms will work after waiting 2-3 minutes. infrequently the weewx acurite driver will *never* work - a power cycle of the station is required.
of course, since the station defaults to usb mode 2 one must always change the usb mode after power cycling the station. that makes it unsuitable for unattended sites.
> I see on Michael Walsh's VIS forum he says that the 02xx firmware is bad, and he's not sure
> about the 01036, and has dropped support for R3 altogether. He also says something about
> VIS being re-written to do a better job resetting the device out of odd states, which I think is true.
michael's rant-to-fact ratio is rather high, but from what i can tell:
- he thinks there are bugs in the 02032 firmware, but he does not explain what they are
- he thinks that using mode 3 will destroy the logger memory of *any* acurite station
- he implies that using mode 4 will 'brick' a 02032 station
it sounds like michael's first implementations did not do much error checking.
i am guessing that the 01035/01036 stations have one version of firmware and the 02032 have a different firmware (and 01025 probably have another). i'm sure those firmwares behave differently. it is quite possible that michael is only learning by trial and error how they differ.
it is possible that there are timing issues, for example if you try to communicate via usb while the firmware is updating logger memory or getting data from the sensors then you might get a bogus usb response. the fine offset stations suffer from this (older stations with one firmware do not have the problem, newer ones do). in the case of fine offset stations, the usb comms lock up completely.
> I have pcap files from running USB capture on Windows running acu-link, with R1 and R2
> records that agree with the debug logs from VIS, and R3 records that seem pretty stable at
> 33 bytes. But how they were setup to be downloaded, I don't know. I also haven't reliably
> found the date/time in the records, only temperature, pressure etc.
i'll take a look at your decoding to see if that works for my station.
meanwhile, could you do some usb captures on windows to see how vis reader handles failures?
in particular, we want to figure out if vis reader sends any usb resets or any special usb commands.
all of the sniffs i have done show nothing special in the way vis reader communicates with the station. afaik these are the only commands sent to the usb device:
- read 10 bytes (read_R1) (0x0101, ENDPOINT_IN, REQ_CLEAR_FEATURE)
- read 25 bytes (read_R2) (0x0102, ENDPOINT_IN, REQ_CLEAR_FEATURE)
- read 33 bytes (read_R3) (0x0103, ENDPOINT_IN, REQ_CLEAR_FEATURE)
- read 2 bytes (X) (0x0201, REQ_SET_CONFIGURATION)
the X command is sent before each set of read_R3 commands
if you can spot any other communication from vis that would be helpful.
also helpful would be to figure out the meaning of the two byte returned from the X command. perhaps it indicates how many R3 records are available?
m
>
> What do you mean, "soft reset" or "hard reset" ? Pushing the reset button under the battery cover ?
> Disconnecting the USB connector ? USB reset command ?
>
> Currently, I haven't managed to read the device at all under Linux, only in Windows. I mean,
> lsusb gets some data but otherwise I was getting this P71 error. I'm not quite sure what the
> Windows code is doing different. I have libusb 0.1 on Fedora 9 on my laptop, and a slightly
> later sub-version on my desktop with CentOS 6. Works with the USBmicro boards, my camera,
> webcam etc.
>
> I see on Michael Walsh's VIS forum he says that the 02xx firmware is bad, and he's not sure
> about the 01036, and has dropped support for R3 altogether. He also says something about
> VIS being re-written to do a better job resetting the device out of odd states, which I think is true.
>
> I have pcap files from running USB capture on Windows running acu-link, with R1 and R2
> records that agree with the debug logs from VIS, and R3 records that seem pretty stable at
> 33 bytes. But how they were setup to be downloaded, I don't know. I also haven't reliably
> found the date/time in the records, only temperature, pressure etc.
>
> As best I can tell:
byte value
1 3,3 ?
2 0 ,0 (to 180 at last point) ?
3 rainfall 1/100 inches
4 15, 15 (to 0 at last point) year 2015 ??
5 2, 2 (to 0 at last point) month 2 ??
6 8, 13 (to 0 at last point) day ??
7 22, 19 (to 0 at last point) ?
8 29, 23 (to 238 at last point) ?
9 29, 23 (to 238 at last point) ?
10 8 8 MSB
11 indoor temp = (X+248)/18 LSB temp = X/18 - 100
12 7,7 ?
13 206-188,0-220 ?
14 0, 0 ?
15 indoor humidity %
16 0, 0 ?
17 outdoor humidity %
18 7 , 7 MSB
19 wind chill = (X-8)/18 LSB temp = X/18 - 100
20 MSB
21 outdoortemp = (X-8)/18 LSB temp = X/18 - 100
22 MSB
23 dew point = (X-8)/18 LSB temp = X/18 - 100
24 MSB
25 LSB pressure
26 160-0, 300-0 ?
27 ?? wind direction
28 MSB?
29 LSB current wind kph / 16
30 MSB
31 LSB peak wind kph / 16
32 MSB ? 0
33 LSB average wind kph / 16
> regards, Andrew
On 26 Feb 2015, at 15:58, Andrew Daviel wrote:
> What do you mean, "soft reset" or "hard reset" ? Pushing the reset button under the battery cover ?
> Disconnecting the USB connector ? USB reset command ?
after doing R3 requests for awhile, i often get 'broken pipe' errors. sometimes unplugging then replugging the usb connector will get comms back. other times the only way to get usb communication back is to power cycle the console.
sometimes after initial power on of station and computer, the computer cannot communicate with the station. i have seen this with both vis and the weewx acurite driver. typically comms will work after waiting 2-3 minutes. infrequently the weewx acurite driver will *never* work - a power cycle of the station is required.
of course, since the station defaults to usb mode 2 one must always change the usb mode after power cycling the station. that makes it unsuitable for unattended sites.
> I see on Michael Walsh's VIS forum he says that the 02xx firmware is bad, and he's not sure
> about the 01036, and has dropped support for R3 altogether. He also says something about
> VIS being re-written to do a better job resetting the device out of odd states, which I think is true.
michael's rant-to-fact ratio is rather high, but from what i can tell:
- he thinks there are bugs in the 02032 firmware, but he does not explain what they are
- he thinks that using mode 3 will destroy the logger memory of *any* acurite station
- he implies that using mode 4 will 'brick' a 02032 station
it sounds like michael's first implementations did not do much error checking.
i am guessing that the 01035/01036 stations have one version of firmware and the 02032 have a different firmware (and 01025 probably have another). i'm sure those firmwares behave differently. it is quite possible that michael is only learning by trial and error how they differ.
it is possible that there are timing issues, for example if you try to communicate via usb while the firmware is updating logger memory or getting data from the sensors then you might get a bogus usb response. the fine offset stations suffer from this (older stations with one firmware do not have the problem, newer ones do). in the case of fine offset stations, the usb comms lock up completely.
> I have pcap files from running USB capture on Windows running acu-link, with R1 and R2
> records that agree with the debug logs from VIS, and R3 records that seem pretty stable at
> 33 bytes. But how they were setup to be downloaded, I don't know. I also haven't reliably
> found the date/time in the records, only temperature, pressure etc.
i'll take a look at your decoding to see if that works for my station.
meanwhile, could you do some usb captures on windows to see how vis reader handles failures?
in particular, we want to figure out if vis reader sends any usb resets or any special usb commands.
all of the sniffs i have done show nothing special in the way vis reader communicates with the station. afaik these are the only commands sent to the usb device:
- read 10 bytes (read_R1) (0x0101, ENDPOINT_IN, REQ_CLEAR_FEATURE)
- read 25 bytes (read_R2) (0x0102, ENDPOINT_IN, REQ_CLEAR_FEATURE)
- read 33 bytes (read_R3) (0x0103, ENDPOINT_IN, REQ_CLEAR_FEATURE)
- read 2 bytes (X) (0x0201, REQ_SET_CONFIGURATION)
the X command is sent before each set of read_R3 commands
if you can spot any other communication from vis that would be helpful.
also helpful would be to figure out the meaning of the two byte returned from the X command. perhaps it indicates how many R3 records are available?
m
Andrew Daviel
Mar 2, 2015, 7:21:59 PM3/2/15
to weewx-de...@googlegroups.com
On Sunday, 1 March 2015 05:48:27 UTC-8, mwall wrote:
if you can spot any other communication from vis that would be helpful.
also helpful would be to figure out the meaning of the two byte returned from the X command. perhaps it indicates how many R3 records are available?
m
I have VIS and acu-link running now on Vista in virtualbox, so maybe I can get some capture files consistent with my attempts to run acurite.py etc.
I built a recent Wireshark and libpcap that supports USB sniffing. More later.
Last year I had been running acu-link on XP in virtualbox but that quit working for some reason - the station got into a bad state I guess - and recovered with some button-pushing and reconnecting in acu-link on Win 8.1.
I built a recent Wireshark and libpcap that supports USB sniffing. More later.
Last year I had been running acu-link on XP in virtualbox but that quit working for some reason - the station got into a bad state I guess - and recovered with some button-pushing and reconnecting in acu-link on Win 8.1.
Brett Warden
Mar 4, 2015, 1:24:19 PM3/4/15
to weewx-de...@googlegroups.com
On Sunday, March 1, 2015 at 5:48:27 AM UTC-8, mwall wrote:
michael's rant-to-fact ratio is rather high, but from what i can tell:
- he thinks there are bugs in the 02032 firmware, but he does not explain what they are
- he thinks that using mode 3 will destroy the logger memory of *any* acurite station
- he implies that using mode 4 will 'brick' a 02032 station
I've been in contact with AcuRite regarding my 02032C (which shows the same symptoms that Michael has reported), and they've setup an RMA. I haven't shipped it yet, but when I do, and get the replacement, I'll report back on whether it's at least more stable. Aside from the flaky USB communications, it also acts like it's logging even in mode 4 (or mode 2), and once it thinks the log is full, communications get even worse. Only resetting the console seems to clear it -- their own software can't even fetch the alleged log.
-- Brett
Andrew Daviel
Mar 21, 2015, 2:25:13 PM3/21/15
to weewx-de...@googlegroups.com
On Sunday, 1 March 2015 05:48:27 UTC-8, mwall wrote:
if you can spot any other communication from vis that would be helpful.
I cannot see any other communication from vis that is different from acu-link.
There are R1 and R2 requests, and R3 requests in mode 3 with the 0x201 setup command.
I can't see any data returned by the 0x201 command; it seems to return two bytes of zero.
Experimentally, if the station starts in a good state, and I issue 0x0103 commands, it returns successive 33-byte lines of data until eventually it times out during a request. Continued 0x0103 commands continue to time out.
Sending an 0x201 command resets it so that further 0x0103 commands return data, until there is no more and it times out as before. Unless 12 minutes has passed, there won't be any more actual weather data.
I have figured out most of the R3 data - or at least, the historical weather data that matches the CSV returned by acu_link. I thought it was simple enough, that after an initial header that each 33-byte record returned corresponded to weather data for one 12-minute interval. But it's not quite that. The data appears to be in 33-byte chunks, true, but it's offset from the records as read. Mostly it's offset by about 8 bytes, but sometimes by about 15. That means the rain data is in the "next" line.
Starting from the top, there's about 17*33 bytes of variable-length header that I have not decoded at all. Then there's a magic marker "ff aa 55", then at a fixed offset a 16-bit value that is proportional to the number of data records to be downloaded
(N = (x-768)/257). Then there are that many 33-byte weather data records, which as I say are not aligned with the USB records, most recent first. Then a final record which includes a timestamp.
The timestamp does not seem to include a seconds field, yet CSV data from acu_link does. Also, the times do not line up exactly - it may be that the most recent record is from 12 minutes ago although the timestamp seems to match the current time. Also, the clock on my weather station may be off; I have not checked. For VIS, as I recall it was recommended to set the clock slightly slow, or at least not in advance of the computer time, to avoid unspecified problems.
I have not yet cleaned up my code into one single program. There's one to read R3 data and make a hex data dump, and another to read the data dump. That also works to read transmogrified data from e.g. "tshark -x -V -r xxx.pcap" and possibly debug data from VIS.
They are in Perl because that's what I'm familiar with.
rd-acurite-log.R3.pl - read the hex data and write whitespace-separated records for gnuplot
rd-acurite.R3.pl - read the R3 data and write hex
rd-tx-usb.pl - convert tshark output
Andrew
There are R1 and R2 requests, and R3 requests in mode 3 with the 0x201 setup command.
I can't see any data returned by the 0x201 command; it seems to return two bytes of zero.
Experimentally, if the station starts in a good state, and I issue 0x0103 commands, it returns successive 33-byte lines of data until eventually it times out during a request. Continued 0x0103 commands continue to time out.
Sending an 0x201 command resets it so that further 0x0103 commands return data, until there is no more and it times out as before. Unless 12 minutes has passed, there won't be any more actual weather data.
I have figured out most of the R3 data - or at least, the historical weather data that matches the CSV returned by acu_link. I thought it was simple enough, that after an initial header that each 33-byte record returned corresponded to weather data for one 12-minute interval. But it's not quite that. The data appears to be in 33-byte chunks, true, but it's offset from the records as read. Mostly it's offset by about 8 bytes, but sometimes by about 15. That means the rain data is in the "next" line.
Starting from the top, there's about 17*33 bytes of variable-length header that I have not decoded at all. Then there's a magic marker "ff aa 55", then at a fixed offset a 16-bit value that is proportional to the number of data records to be downloaded
(N = (x-768)/257). Then there are that many 33-byte weather data records, which as I say are not aligned with the USB records, most recent first. Then a final record which includes a timestamp.
The timestamp does not seem to include a seconds field, yet CSV data from acu_link does. Also, the times do not line up exactly - it may be that the most recent record is from 12 minutes ago although the timestamp seems to match the current time. Also, the clock on my weather station may be off; I have not checked. For VIS, as I recall it was recommended to set the clock slightly slow, or at least not in advance of the computer time, to avoid unspecified problems.
I have not yet cleaned up my code into one single program. There's one to read R3 data and make a hex data dump, and another to read the data dump. That also works to read transmogrified data from e.g. "tshark -x -V -r xxx.pcap" and possibly debug data from VIS.
They are in Perl because that's what I'm familiar with.
rd-acurite-log.R3.pl - read the hex data and write whitespace-separated records for gnuplot
rd-acurite.R3.pl - read the R3 data and write hex
rd-tx-usb.pl - convert tshark output
Andrew
mwall
Mar 22, 2015, 1:25:55 PM3/22/15
to weewx-de...@googlegroups.com
andrew,
that is great sleuthing! nicely done!
i wonder if the acurite stations use some of the same components as the fine offset stations. it may be nothing, but the fine offset stations also have a pair of 'magic number' bytes: aa 55
do you have any sense of the volatility of the 17 33-byte readings? do yours change over the course of a day? hour? minutes? i'm wondering if the current value of the inside humidity sensor is hiding in there. if not then we can only get inside humidity by reading historical records.
i have seen the following values returned in the two-byte response to 0x0201:
84 e2
7c e2
here is a block of R3 data. does it match your hypothesis?
2015-01-24 09:58:03 EST (1422111483) 7c e2
2015-01-24 09:58:03 EST (1422111483) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2015-01-24 09:58:03 EST (1422111483) 03 00 28 00 28 00 28 00 28 00 28 00 28 01 e0 0c 03 00 00 0f 01 18 09 30 06 00 00 0f 01 18 09 30 06
2015-01-24 09:58:03 EST (1422111483) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2015-01-24 09:58:03 EST (1422111483) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 03 e7 0f 01 18 09 30 06 03 e7 0f 01 18 09 30 06
2015-01-24 09:58:03 EST (1422111483) 03 08 8e 0f 01 18 09 31 06 08 84 0f 01 18 09 30 06 08 70 0f 01 18 09 30 06 08 70 0f 01 18 09 30 06
2015-01-24 09:58:03 EST (1422111483) 03 00 27 0f 01 18 09 30 06 00 26 0f 01 18 09 33 06 00 28 0f 01 18 09 30 06 00 28 0f 01 18 09 30 06
2015-01-24 09:58:03 EST (1422111483) 03 08 70 0f 01 18 09 30 06 08 70 0f 01 18 09 30 06 08 ca 0f 01 18 09 30 06 08 ca 0f 01 18 09 30 06
2015-01-24 09:58:03 EST (1422111483) 03 07 76 0f 01 18 09 30 06 07 76 0f 01 18 09 30 06 08 8e 0f 01 17 0b 26 05 08 5c 0f 01 18 05 1f 06
2015-01-24 09:58:03 EST (1422111483) 03 aa 55 02 00 00 00 20 21 00 00 0a 0c 01 00 01 03 00 00 0a 0c 01 00 01 03 08 d4 0f 01 13 0b 3b 01
2015-01-24 09:58:03 EST (1422111483) 03 08 52 0f 01 12 04 1e 07 08 d4 0f 01 13 0b 3b 01 08 52 0f 01 11 03 0b 06 00 00 0a 0c 01 00 01 03
2015-01-24 09:58:03 EST (1422111483) 03 00 00 0a 0c 01 00 01 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2015-01-24 09:58:03 EST (1422111483) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 04 04 0f 01 11 09 24 06
2015-01-24 09:58:03 EST (1422111483) 03 03 e2 0f 01 12 16 24 07 08 e8 0f 01 13 15 19 01 08 66 0f 01 12 04 09 07 08 d4 0f 01 13 0b 3b 01
2015-01-24 09:58:03 EST (1422111483) 03 08 52 0f 01 11 03 0b 06 00 2c 0f 01 13 0e 2b 01 00 1a 0f 01 11 0d 0f 06 00 2d 0f 01 14 14 29 02
2015-01-24 09:58:03 EST (1422111483) 03 00 1a 0f 01 11 0c 12 06 08 d4 0f 01 13 0b 3b 01 08 52 0f 01 11 03 0b 06 08 de 0f 01 13 05 21 01
2015-01-24 09:58:03 EST (1422111483) 03 08 c0 0f 01 11 09 2c 06 07 da 0f 01 13 13 0c 01 07 26 0f 01 12 04 1e 07 ff ff ff ff ff ff ff ff
2015-01-24 09:58:03 EST (1422111483) 03 ff ff ff ff ff ff ff ff aa 55 03 00 00 00 01 03 00 00 0f 01 18 09 30 61 aa 55 04 00 00 00 00 03
2015-01-24 09:58:03 EST (1422111483) 03 aa 55 05 00 00 00 01 05 ff ff 0f 01 18 09 39 ff aa 55 06 00 00 00 04 09 20 41 ac 0d 1c 00 d0 02
and here is another one:
2015-01-24 14:47:39 EST (1422128859) 84 e2
2015-01-24 14:47:39 EST (1422128859) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2015-01-24 14:47:39 EST (1422128859) 03 00 28 00 28 00 28 00 28 00 28 00 28 01 40 08 03 00 00 0f 01 18 09 30 06 00 00 0f 01 18 09 30 06
2015-01-24 14:47:39 EST (1422128859) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2015-01-24 14:47:39 EST (1422128859) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 03 e7 0f 01 18 09 30 06 03 dd 0f 01 18 0e 00 06
2015-01-24 14:47:39 EST (1422128859) 03 08 8e 0f 01 18 09 31 06 08 7a 0f 01 18 0d 25 06 08 70 0f 01 18 09 30 06 08 66 0f 01 18 0c 28 06
2015-01-24 14:47:39 EST (1422128859) 03 00 27 0f 01 18 09 30 06 00 25 0f 01 18 0d 2e 06 00 28 0f 01 18 09 30 06 00 27 0f 01 18 0b 2d 06
2015-01-24 14:47:39 EST (1422128859) 03 08 70 0f 01 18 09 30 06 08 66 0f 01 18 0c 28 06 08 d4 0f 01 18 0c 28 06 08 ca 0f 01 18 09 30 06
2015-01-24 14:47:39 EST (1422128859) 03 07 76 0f 01 18 09 30 06 07 62 0f 01 18 0c 28 06 08 8e 0f 01 17 0b 26 05 08 5c 0f 01 18 05 1f 06
2015-01-24 14:47:39 EST (1422128859) 03 aa 55 02 00 00 00 20 21 00 00 0a 0c 01 00 01 03 00 00 0a 0c 01 00 01 03 08 d4 0f 01 13 0b 3b 01
2015-01-24 14:47:39 EST (1422128859) 03 08 52 0f 01 12 04 1e 07 08 d4 0f 01 13 0b 3b 01 08 52 0f 01 11 03 0b 06 00 00 0a 0c 01 00 01 03
2015-01-24 14:47:39 EST (1422128859) 03 00 00 0a 0c 01 00 01 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2015-01-24 14:47:39 EST (1422128859) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 04 04 0f 01 11 09 24 06
2015-01-24 14:47:39 EST (1422128859) 03 03 dd 0f 01 18 0e 00 06 08 e8 0f 01 13 15 19 01 08 66 0f 01 12 04 09 07 08 d4 0f 01 13 0b 3b 01
2015-01-24 14:47:39 EST (1422128859) 03 08 52 0f 01 11 03 0b 06 00 2c 0f 01 13 0e 2b 01 00 1a 0f 01 11 0d 0f 06 00 2d 0f 01 14 14 29 02
2015-01-24 14:47:39 EST (1422128859) 03 00 1a 0f 01 11 0c 12 06 08 d4 0f 01 13 0b 3b 01 08 52 0f 01 11 03 0b 06 08 de 0f 01 13 05 21 01
2015-01-24 14:47:39 EST (1422128859) 03 08 c0 0f 01 11 09 2c 06 07 da 0f 01 13 13 0c 01 07 26 0f 01 12 04 1e 07 ff ff ff ff ff ff ff ff
2015-01-24 14:47:39 EST (1422128859) 03 ff ff ff ff ff ff ff ff aa 55 03 00 00 00 01 03 00 03 0f 01 18 0e 24 5d aa 55 04 00 00 00 03 06
2015-01-24 14:47:39 EST (1422128859) 03 08 7a 08 66 00 26 00 28 08 66 08 d4 07 6c 03 dd 00 06 00 00 00 00 00 00 00 00 ff ff ff ff ff ff
2015-01-24 14:47:39 EST (1422128859) 03 08 7a 08 66 00 26 00 28 08 66 08 d4 07 6c 03 dd 00 06 00 00 00 00 00 00 00 00 ff ff ff ff ff ff
2015-01-24 14:47:39 EST (1422128859) 03 08 7a 08 66 00 25 00 28 08 66 08 d4 07 6c 03 dd 00 06 00 00 00 00 00 00 00 00 ff ff ff ff ff ff
2015-01-24 14:47:39 EST (1422128859) 03 aa 55 05 00 00 00 01 05 ff ff 0f 01 18 0e 22 ff aa 55 06 00 00 00 04 09 20 41 ac 0d 1c 00 d0 02
2015-01-24 14:47:39 EST (1422128859) error sending control message: Connection timed out
that is great sleuthing! nicely done!
i wonder if the acurite stations use some of the same components as the fine offset stations. it may be nothing, but the fine offset stations also have a pair of 'magic number' bytes: aa 55
do you have any sense of the volatility of the 17 33-byte readings? do yours change over the course of a day? hour? minutes? i'm wondering if the current value of the inside humidity sensor is hiding in there. if not then we can only get inside humidity by reading historical records.
i have seen the following values returned in the two-byte response to 0x0201:
84 e2
7c e2
here is a block of R3 data. does it match your hypothesis?
2015-01-24 09:58:03 EST (1422111483) 7c e2
2015-01-24 09:58:03 EST (1422111483) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2015-01-24 09:58:03 EST (1422111483) 03 00 28 00 28 00 28 00 28 00 28 00 28 01 e0 0c 03 00 00 0f 01 18 09 30 06 00 00 0f 01 18 09 30 06
2015-01-24 09:58:03 EST (1422111483) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2015-01-24 09:58:03 EST (1422111483) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 03 e7 0f 01 18 09 30 06 03 e7 0f 01 18 09 30 06
2015-01-24 09:58:03 EST (1422111483) 03 08 8e 0f 01 18 09 31 06 08 84 0f 01 18 09 30 06 08 70 0f 01 18 09 30 06 08 70 0f 01 18 09 30 06
2015-01-24 09:58:03 EST (1422111483) 03 00 27 0f 01 18 09 30 06 00 26 0f 01 18 09 33 06 00 28 0f 01 18 09 30 06 00 28 0f 01 18 09 30 06
2015-01-24 09:58:03 EST (1422111483) 03 08 70 0f 01 18 09 30 06 08 70 0f 01 18 09 30 06 08 ca 0f 01 18 09 30 06 08 ca 0f 01 18 09 30 06
2015-01-24 09:58:03 EST (1422111483) 03 07 76 0f 01 18 09 30 06 07 76 0f 01 18 09 30 06 08 8e 0f 01 17 0b 26 05 08 5c 0f 01 18 05 1f 06
2015-01-24 09:58:03 EST (1422111483) 03 aa 55 02 00 00 00 20 21 00 00 0a 0c 01 00 01 03 00 00 0a 0c 01 00 01 03 08 d4 0f 01 13 0b 3b 01
2015-01-24 09:58:03 EST (1422111483) 03 08 52 0f 01 12 04 1e 07 08 d4 0f 01 13 0b 3b 01 08 52 0f 01 11 03 0b 06 00 00 0a 0c 01 00 01 03
2015-01-24 09:58:03 EST (1422111483) 03 00 00 0a 0c 01 00 01 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2015-01-24 09:58:03 EST (1422111483) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 04 04 0f 01 11 09 24 06
2015-01-24 09:58:03 EST (1422111483) 03 03 e2 0f 01 12 16 24 07 08 e8 0f 01 13 15 19 01 08 66 0f 01 12 04 09 07 08 d4 0f 01 13 0b 3b 01
2015-01-24 09:58:03 EST (1422111483) 03 08 52 0f 01 11 03 0b 06 00 2c 0f 01 13 0e 2b 01 00 1a 0f 01 11 0d 0f 06 00 2d 0f 01 14 14 29 02
2015-01-24 09:58:03 EST (1422111483) 03 00 1a 0f 01 11 0c 12 06 08 d4 0f 01 13 0b 3b 01 08 52 0f 01 11 03 0b 06 08 de 0f 01 13 05 21 01
2015-01-24 09:58:03 EST (1422111483) 03 08 c0 0f 01 11 09 2c 06 07 da 0f 01 13 13 0c 01 07 26 0f 01 12 04 1e 07 ff ff ff ff ff ff ff ff
2015-01-24 09:58:03 EST (1422111483) 03 ff ff ff ff ff ff ff ff aa 55 03 00 00 00 01 03 00 00 0f 01 18 09 30 61 aa 55 04 00 00 00 00 03
2015-01-24 09:58:03 EST (1422111483) 03 aa 55 05 00 00 00 01 05 ff ff 0f 01 18 09 39 ff aa 55 06 00 00 00 04 09 20 41 ac 0d 1c 00 d0 02
and here is another one:
2015-01-24 14:47:39 EST (1422128859) 84 e2
2015-01-24 14:47:39 EST (1422128859) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2015-01-24 14:47:39 EST (1422128859) 03 00 28 00 28 00 28 00 28 00 28 00 28 01 40 08 03 00 00 0f 01 18 09 30 06 00 00 0f 01 18 09 30 06
2015-01-24 14:47:39 EST (1422128859) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2015-01-24 14:47:39 EST (1422128859) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 03 e7 0f 01 18 09 30 06 03 dd 0f 01 18 0e 00 06
2015-01-24 14:47:39 EST (1422128859) 03 08 8e 0f 01 18 09 31 06 08 7a 0f 01 18 0d 25 06 08 70 0f 01 18 09 30 06 08 66 0f 01 18 0c 28 06
2015-01-24 14:47:39 EST (1422128859) 03 00 27 0f 01 18 09 30 06 00 25 0f 01 18 0d 2e 06 00 28 0f 01 18 09 30 06 00 27 0f 01 18 0b 2d 06
2015-01-24 14:47:39 EST (1422128859) 03 08 70 0f 01 18 09 30 06 08 66 0f 01 18 0c 28 06 08 d4 0f 01 18 0c 28 06 08 ca 0f 01 18 09 30 06
2015-01-24 14:47:39 EST (1422128859) 03 07 76 0f 01 18 09 30 06 07 62 0f 01 18 0c 28 06 08 8e 0f 01 17 0b 26 05 08 5c 0f 01 18 05 1f 06
2015-01-24 14:47:39 EST (1422128859) 03 aa 55 02 00 00 00 20 21 00 00 0a 0c 01 00 01 03 00 00 0a 0c 01 00 01 03 08 d4 0f 01 13 0b 3b 01
2015-01-24 14:47:39 EST (1422128859) 03 08 52 0f 01 12 04 1e 07 08 d4 0f 01 13 0b 3b 01 08 52 0f 01 11 03 0b 06 00 00 0a 0c 01 00 01 03
2015-01-24 14:47:39 EST (1422128859) 03 00 00 0a 0c 01 00 01 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
2015-01-24 14:47:39 EST (1422128859) 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 04 04 0f 01 11 09 24 06
2015-01-24 14:47:39 EST (1422128859) 03 03 dd 0f 01 18 0e 00 06 08 e8 0f 01 13 15 19 01 08 66 0f 01 12 04 09 07 08 d4 0f 01 13 0b 3b 01
2015-01-24 14:47:39 EST (1422128859) 03 08 52 0f 01 11 03 0b 06 00 2c 0f 01 13 0e 2b 01 00 1a 0f 01 11 0d 0f 06 00 2d 0f 01 14 14 29 02
2015-01-24 14:47:39 EST (1422128859) 03 00 1a 0f 01 11 0c 12 06 08 d4 0f 01 13 0b 3b 01 08 52 0f 01 11 03 0b 06 08 de 0f 01 13 05 21 01
2015-01-24 14:47:39 EST (1422128859) 03 08 c0 0f 01 11 09 2c 06 07 da 0f 01 13 13 0c 01 07 26 0f 01 12 04 1e 07 ff ff ff ff ff ff ff ff
2015-01-24 14:47:39 EST (1422128859) 03 ff ff ff ff ff ff ff ff aa 55 03 00 00 00 01 03 00 03 0f 01 18 0e 24 5d aa 55 04 00 00 00 03 06
2015-01-24 14:47:39 EST (1422128859) 03 08 7a 08 66 00 26 00 28 08 66 08 d4 07 6c 03 dd 00 06 00 00 00 00 00 00 00 00 ff ff ff ff ff ff
2015-01-24 14:47:39 EST (1422128859) 03 08 7a 08 66 00 26 00 28 08 66 08 d4 07 6c 03 dd 00 06 00 00 00 00 00 00 00 00 ff ff ff ff ff ff
2015-01-24 14:47:39 EST (1422128859) 03 08 7a 08 66 00 25 00 28 08 66 08 d4 07 6c 03 dd 00 06 00 00 00 00 00 00 00 00 ff ff ff ff ff ff
2015-01-24 14:47:39 EST (1422128859) 03 aa 55 05 00 00 00 01 05 ff ff 0f 01 18 0e 22 ff aa 55 06 00 00 00 04 09 20 41 ac 0d 1c 00 d0 02
2015-01-24 14:47:39 EST (1422128859) error sending control message: Connection timed out
Andrew Daviel
Mar 23, 2015, 1:25:32 PM3/23/15
to weewx-de...@googlegroups.com
On Saturday, 21 March 2015 11:25:13 UTC-7, Andrew Daviel wrote:
Oops.
- new version marked "version 1.4". Previous version worked nicely for most files, but with the different offset got the alignment wrong for wind data that was now on the next line.
rd-tx-usb.pl - convert tshark output - oops that's the decimal output version. trivial to fix
In the R1 data, I think a bit or two of data[6] may be used - when I plot historical rain data against live-collected data I see jumps that correlate with changes in bits 0,1 but I haven't got it sorted out properly. It rains a lot here, but of course not when I want to test a rain sensor (I mounted it on the chimney to try and get sensible wind data instead of it just following vortices in the shade of my house, so pouring water in to test it is not practical)
Looks like I have the HP03S sensor - I would never have figured how to decode that from R2. Thanks!
I'll look at the other stuff tonight, or when I have time.
Andrew
Andrew Daviel
Mar 24, 2015, 1:05:54 PM3/24/15
to weewx-de...@googlegroups.com
On Sunday, 22 March 2015 10:25:55 UTC-7, mwall wrote:
andrew,
that is great sleuthing! nicely done!
i wonder if the acurite stations use some of the same components as the fine offset stations. it may be nothing, but the fine offset stations also have a pair of 'magic number' bytes: aa 55
do you have any sense of the volatility of the 17 33-byte readings? do yours change over the course of a day? hour? minutes? i'm wondering if the current value of the inside humidity sensor is hiding in there. if not then we can only get inside humidity by reading historical records.
i have seen the following values returned in the two-byte response to 0x0201:
84 e2
7c e2
here is a block of R3 data. does it match your hypothesis?
It's not quite the same as mine, and my script will not decode it out of the box. But it looks very close. One seems to have no actual historical data, but the other has about 3 lines. The timestamp in the last line looks right.
I've put a couple of my data files online at http://andrew.daviel.org/acurite/ - the older ones I was first able to match up. They aren't re-shifted to be one record per line, just the original captured data. The first bytes on each line don't seem volatile.
I have some later data that's supposed to match R2 data (at least, it's over the same period but the actual per-record collection times are different) but that computer's showing a disk error and needs rebooting. I'll try and post that later.
Andrew
I've put a couple of my data files online at http://andrew.daviel.org/acurite/ - the older ones I was first able to match up. They aren't re-shifted to be one record per line, just the original captured data. The first bytes on each line don't seem volatile.
I have some later data that's supposed to match R2 data (at least, it's over the same period but the actual per-record collection times are different) but that computer's showing a disk error and needs rebooting. I'll try and post that later.
Andrew
Andrew Daviel
Mar 25, 2015, 2:48:33 AM3/25/15
to weewx-de...@googlegroups.com
On Tuesday, 24 March 2015 10:05:54 UTC-7, Andrew Daviel wrote:
On Sunday, 22 March 2015 10:25:55 UTC-7, mwall wrote:
i have seen the following values returned in the two-byte response to 0x0201:
84 e2
7c e2
I haven't seen that, I don't think. Only 01ff.
here is a block of R3 data. does it match your hypothesis?
I found I was using the old script that did not compensate for shifted data.
This is the decode from the longer block: (there is no wind peak, that just matches the acu_link output)
#1DateTime,2Indoor Temperature C, 3Indoor Humidity %, 4Outdoor Temperature C ,5Outdoor Humidity % ,6Wind Chill F, 7Heat Index C ,8Dew Point C,9Pressure kPa ,10Wind direction,11Wind Current KPH, 12Wind Peak KPH, 13Wind Average KPH, 14Rainfall mmm
#1 2 3 4 5 6 7 8 9 10 11 12 13 14
2015-01-24T14:10:00 20.56 37.00 25.56 40.00 19.44 19.44 5.56 98.90 360.00 0.00 0.00 0.00 0.00 0.00
2015-01-24T14:22:00 20.56 38.00 25.56 40.00 19.44 19.44 5.56 98.90 360.00 0.00 0.00 0.00 0.00 0.00
2015-01-24T14:34:00 20.56 38.00 25.56 40.00 19.44 19.44 5.56 98.90 360.00 0.00 0.00 0.00 0.00 0.00
I've put more R3 files online at http://andrew.daviel.org/acurite/
Andrew
Weather Guy
Apr 11, 2015, 7:55:37 PM4/11/15
to weewx-de...@googlegroups.com
Andrew,
I've just posted some good information on this USB traffic on mwall's thread here:
https://groups.google.com/forum/#!topic/weewx-development/Pxv32Gxmb3U
It shows how some of the top-level header/command stuff is actually USB HID commands and what goes on makes a lot more sense now. Anyway, I hope you find this useful/enlightening -- it was for me.
Also, if you have any of the pcap files of the R3 reads I'd like to see those...could you post one or two of them on your web site?
Thanks!
I've just posted some good information on this USB traffic on mwall's thread here:
https://groups.google.com/forum/#!topic/weewx-development/Pxv32Gxmb3U
It shows how some of the top-level header/command stuff is actually USB HID commands and what goes on makes a lot more sense now. Anyway, I hope you find this useful/enlightening -- it was for me.
Also, if you have any of the pcap files of the R3 reads I'd like to see those...could you post one or two of them on your web site?
Thanks!
Andrew Daviel
Apr 13, 2015, 2:24:07 AM4/13/15
to weewx-de...@googlegroups.com
On Saturday, 11 April 2015 16:55:37 UTC-7, Weather Guy wrote:
Also, if you have any of the pcap files of the R3 reads I'd like to see those...could you post one or two of them on your web site?
I've just posted acu9.pcapng to andrew.daviel.org/acurite/ also WeatherData3 which is the CSV downloaded by VIS.
I've updated rd-acurite-log.R3.pl which is basically just a trivial change to handle a longer file. I had several data points (different length files) to determine a 16-bit value, but now just one point to determine a 24-bit value; it seems to be not regular big-endian but (bits[23-16],bits[0-7],bits[8-15]).
I've gotten myself a bit muddled with data and programs on 2 different computers and haven't consolidated the read-USB program and the decode-data program into one. I'm logging R1 and R2 hex data from cron every 12 minutes and was going to start logging R3 data once a week when I found the problem. I'm going to try and download R3 after 1,2,4,8 etc. days from cron to check the upper bits of length, then probably return to weekly downloads.
I've updated rd-acurite-log.R3.pl which is basically just a trivial change to handle a longer file. I had several data points (different length files) to determine a 16-bit value, but now just one point to determine a 24-bit value; it seems to be not regular big-endian but (bits[23-16],bits[0-7],bits[8-15]).
I've gotten myself a bit muddled with data and programs on 2 different computers and haven't consolidated the read-USB program and the decode-data program into one. I'm logging R1 and R2 hex data from cron every 12 minutes and was going to start logging R3 data once a week when I found the problem. I'm going to try and download R3 after 1,2,4,8 etc. days from cron to check the upper bits of length, then probably return to weekly downloads.
Reply all
Reply to author
Forward
0 new messages