Friday, December 19, 2014

AcuRite Weather Station, Barometric Pressure Part 6

Part 5 of this interminable series is here <link>

Way back in part 1 of this project I mentioned that I got into a little spat with a software developer about bringing up a linux version of his code <link>?  Well, I prowled around (a lot) in his forum and discovered that he really likes to talk.  That's a good thing, a very good thing, and I certainly can't say anything bad, I've got what? 200 or so posts on various technical items on this blog, and a trail a mile wide across the internet, so something about glass houses comes to mind.

At any rate, I ran across this post of his where he discusses the barometric pressure reading from the AcuRite console <link>.  The sensor is inexpensive, but it's a high sensitivity device and capable of measuring altitude to within 20cm if it is properly used.  What does altitude have to do with barometric pressure?  Everything.

I'm not going to go into the ins and outs of altitude vs temperature vs air pressure because there's entire sites devoted to this that will do a much better job of explaining it, except where it involves getting a reading worth using from the Acurite sensor in the console of my weather station.  It's the last piece of weather information I want to grab from the station; I want battery level from the weather head, but that's not weather info.  The rest of the stuff like rainfall this week, highest recorded temperature, those things can all be derived from the other data, and is a big piece of why I broke into the unit.

But, the barometric pressure still eludes me.  So, here's what I've learned so far and I'm quite open to suggestions.  The barometric sensor is: Measurement Specialities MS5607-02BA03 and here's its spec sheet PDF file <link> and the manufacturer's web page <link>.  It's a very nice device that uses a piezo crystal to sense pressure.  Since it's subject to temperature variance, it's read in the factory and calibration parameters are stored inside the chip.  The idea is that the developer resets the chip, reads the calibration parameters and then applies them to the reading from the chip and comes out with an extremely accurate measurement for altitude.  For a device in a fixed location, the altitude reading can be directly translated to atmospheric pressure.  That would give you an extremely accurate barometer.

Getting back to the forum post above, it's pretty clear that AcuRite doesn't do this.  They have some secret algorithm that is supposed to take the need for reading the calibration out by sampling readings for about a month to derive a value that will allow them to predict the weather more accurately for the console's location.  Pardon me if I'm a bit skeptical about that.  Weather forecasters have been trying to do that for centuries, and I hardly think AcuRite achieved the 'Holy Grail' of atmospheric science.  I think they couldn't figure out how to work the chip and gave up and called marketing in for a story to cover up the problem.

Who wants to buy a barometer that you have to wait a month before the readings start making sense?

We don't need accuracy in the absolute reading, we need accuracy in the changing of the reading, and a linear response that we can calibrate and forget for a while.  Remember the old physical barometers that our farmer grandparents had in the front room where you could check it on the way out the door to the barn?  Those devices worked well.  When you got them, you checked the local weather and set the reading to be the same by turning a screw on the back.  Then you set a movable needle (ours was red) to point to the same reading.  Then if the pressure went up (clear weather) you could tell because the needle moved up from the red one.  Simple, and did the job nicely.

I logged the data from the R2 message (where the barometer is supposed to show up) for quite a while, but still haven't figured it out.  In a fit of pique, I pulled the console apart to see if I could read the chip's markings:

Tearing open the AcuRite Console


Above is an over all view of the guts of the thing.  Circled on the left near the middle is the USB port and power input; above it is the board for the local temperature and humidity sensor; and way on the right is the radio receiver.  The antenna is a wire that runs up and to the left along the top.  Yes, they covered the logic chips to try and keep us from reverse engineering the hardware.


Here's the local temperature sensor (black) and local humidity sensor (white) next to an air vent. Simple setup and should work well.


The lower logic board with the reset and radio channel select switches.


The upper logic board.  The arrow points to the pressure sensor and I'm sorry it's hard to see, but you already know what it looks like from the data sheet.  This tiny little thing was hard to read and took my best magnifying glass and a good flashlight to see the markings.

All in all, it looks like a reasonable device, it makes me wonder why they took the path they chose for the barometric sensor; they seem to have enough horsepower in there to get a really good reading.

I went back to prowling through the website above, looking specifically for hints on how to derive the pressure reading from the data the device sends and came across this explanation:
In fact, the sensors used in these consoles aren't accurate; you can't expect to get an "accurate" barometric sensor for anything less than about $1,600.  That's the reason your sensor is reporting over 40 inches of mercury; we adjust for the variations between sensors using the adjustment you were asked to do.
But I don't buy that explanation.  I've seen a bunch of gauges that cost far less than $1600, with specs that are pretty impressive, and this device claims accuracy to mere centimeters.  Nope, it's simply that the data is not corrected using the burned in parameters that should be used.

So, given the various graphs provided by the manufacturer the device is relatively linear, just way off because the calibration hasn't been done, so how the heck do I find the pressure in the data?  If I can get the pressure, then rely on the temperature inside a house to be relatively stable, we should be able to derive an offset that gives us a pretty reasonable value.  Here's a small sample of the data sent in the R2 message.

02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 07 47 E0
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 05 47 E0
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 05 47 DC
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 05 47 D9
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 03 47 D9
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 03 47 D6
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 05 47 D6
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 07 47 D6
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 09 47 D6
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 09 47 D1

The reading on the console for the last line was 77 F and 30.09 in/Hg.  Notice how only the last three bytes change?  Actually though the last four bytes change.  Heres the highest and lowest values sorted from the file I'm logging to:

02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F DF 47 B0
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 3B 47 BB

Yes, the other values in the data do not change.  It was reported on the forum that the calibration values were being sent, but this isn't the case I my examination.  If these are calibration values, they don't resemble the items described by the manufacturer, nor do they make sense. So, we're left with the last four 8 bit values.  The data supplied by the sensor is in 24 bit values, so these last bytes could not be all of the temperature and pressure.  Since this is made in Europe, it's likely the data is in degrees C and mbar, and just looking at the four bytes as pressure, temperature, the last line of the first block could be, 0x9009 = 38873 which doesn't seem to be reasonable.  It might be somewhat reasonable for in/Hg though as in 38.8 in/Hg; a bit high, but sort of there.  I don't get much sense out of the other number 0x47d1 = 18385 either.

But notice that the second 16 bit number is roughly half the first number; it might be that the first number is a higher conversion from the A/D convertor than the second and both of them represent the same thing, just different settings on the A/D convertor.  The chip supports this, so it's possible.

And remember, I can't compare the numbers to the reading on the front of the display since AcuRite is using some secret algorithm to compute that because their way is more accurate, meaningful, whatever...

The low pressure for the last 24 hours was 952 mbar (28.11 in/Hg) and the high was 956 (28.23) and from the graph I looked at the average was 954 (28.17), so suppose the first 16 bit number was the pressure reading (uncompensated) and I just took a 24 hour average to see what came up, a change of 23 in the number would be a 1 millibar change in pressure.  If I just go with the average of 954 and consider the mean of my high and low reading 36877 and bump it up by one tenth for every 2.3  change in the number, to see what happens:

36831 to 36923 avg 36877  difference = 92
952 to 956 avg is 954  difference = 4
That would make each milibar increase equal to a change of 23 in the reading.

So, if I set 954 as being the same as 36877 and a reading of 8fe7 (right this second) would be 36839, subtract 36877 to get -38 divide by 23 to get -1.65 and the pressure would be 952.4 mbar.  Which is more reasonable than the display which says 1017 mbar, which would put me below seal level and a bunch higher than all the stations around me.  Also, remember that what I'm really interested in is the change over time as a forecast indicator.

All told, it looks to me like the barometric pressure is a total waste of time to continue trying to decode and make sense of beyond this.  It appears that AcuRite ignores the correction factors in favor of some secret technique, and we all know how I feel about 'secrets'.  I'll try this for a few days to see how it goes, but my big inclination is to get a pressure sensor and use some of the example code out there to read it and properly apply the compensation factors to get a really good reading.  I may not use the same chip, because there's a lot of breakout boards for the BMP180 and they're cheap.

Hmm, I could hook a BMP180 up to an Arduino, get both the temperature and barometric pressure from it, send it through an XBee to my Pi controller and replace the configuration I have outside in the Stephenson screen.  That would actually be a cool project.

If you notice something I overlooked, misunderstood, or messed up, let me know.

The next part to this project is here <link>.
Also, I've made progress on a barometric sensor that actually works <link>
With help from one of my readers the console barometer has been conquered <link>

21 comments:

  1. What happens when you manually change the calibration for barometric pressure on the console? Does that change what is output on the USB, or does it keep it for itself for display purposes?

    Also, thanks for the new code. Taking out the bootcmd.txt entry has fixed the issues I was having as well.

    ReplyDelete
    Replies
    1. I don't know. I can't change mine. Give it a try and let me know.

      Delete
  2. dave,

    thank you for publishing your work. here are a few more data points to (hopefully) help decode R2:

    data reported by the vis data reader (v3.4):
    - battery status
    - rf signal
    - usb mode (1,2,3,4)
    - outdoor X X X%
    - wind X X X
    - barometer inHg hPa psi
    - indoor F C ?
    - rainfall today, this month, this year
    - total records 0
    - last data saved (timestamp)

    apparently it is possible to apply offsets:
    - pressure
    - inside temperature (but not noted as offsets)
    - inside humidity?
    - outside temperature
    - outside humidity
    but it looks like pressure is the only one retained by the hardware?

    apparently console does not save when no external data? my 'total records' is always 0, but the 'last data saved' increments every 12 minutes.

    the console display changes much more often than R2 data

    what are the units of raw data?
    pressure: inHg
    indoor temp: C
    indoor humidity: ?
    outdoor temp: ?
    outdoor humidity: %
    wind: ?

    when no 5in1 connected, R1 is 01 CF FF FF FF FF FF FF 00 00

    R1 reads every 18 seconds
    R2 reads every 60 seconds

    and here are some raw data that might help with decoding:

    (time)
    R2 raw bytes
    values from data reader
    values from console

    ?
    02 00 00 4c be 0d ec 01 52 03 62 7e 38 18 ee 09 c4 08 22 06 07 7b 71 8a 4d
    25.065inhg 848.8hpa 12.311psi 65.3F 18.5C -
    66F 30% 30.18

    ?
    02 00 00 4c be 0d ec 01 52 03 62 7e 38 18 ee 09 c4 08 22 06 07 7b 71 8a 4d
    25.065inhg 848.8hpa 12.311psi 65.3F 18.5C -
    66F 34% 30.18

    ?
    02 00 00 4C BE 0D EC 01 52 03 62 7E 38 18 EE 09 C4 08 22 06 07 7B 8E 8A 40
    25.067inhg 848.9hpa 12.312psi 65.8F 18.8C -
    67F 37% 30.18

    ?
    02 00 00 4C BE 0D EC 01 52 03 62 7E 38 18 EE 09 C4 08 22 06 07 7B 8E 8A 40
    25.067inhg 848.9hpa 12.312psi 65.8F 18.8C -
    68F 37% 30.18

    ?
    02 00 00 4C BE 0D EC 01 52 03 62 7E 38 18 EE 09 C4 08 22 06 07 7B 8E 8A 40
    25.067inhg 848.9hpa 12.312psi 65.8F 18.8C -
    68F 38% 30.18

    ?
    02 00 00 4C BE 0D EC 01 52 03 62 7E 38 18 EE 09 C4 08 22 06 07 7B 8E 8A 40
    25.067inhg 848.9hpa 12.312psi 65.8F 18.8C -
    68F 30% 30.18

    ?
    02 00 00 4C BE 0D EC 01 52 03 62 7E 38 18 EE 09 C4 08 22 06 07 7B AB 8A 34
    25.071inhg 849.0hpa 12.314psi 66.2F 19.0C -
    68F 29% 30.18

    ?
    02 00 00 4C BE 0D EC 01 52 03 62 7E 38 18 EE 09 C4 08 22 06 07 7B AB 8A 34
    25.071inhg 849.0hpa 12.314psi 66.2F 19.0C -
    67F 30% 30.18

    ?
    02 00 00 4C BE 0D EC 01 52 03 62 7E 38 18 EE 09 C4 08 22 06 07 7B AB 8A 34
    25.071inhg 849.0hpa 12.314psi 66.2F 19.0C -
    67F 37% 30.18

    11:56
    02 00 00 4C BE 0D EC 01 52 03 62 7E 38 18 EE 09 C4 08 22 06 07 7B AB 8A 34
    25.071inhg 849.0hpa 12.314psi 66.2F 19.0C -
    68F 38% 30.18

    11:58
    02 00 00 4C BE 0D EC 01 52 03 62 7E 38 18 EE 09 C4 08 22 06 07 7B D2 8A 26
    25.079inhg 849.3hpa 12.317psi 66.9F 19.4C -
    69F 39% 30.18

    12:01
    02 00 00 4C BE 0D EC 01 52 03 62 7E 38 18 EE 09 C4 08 22 06 07 7B D2 8A 26
    25.079inhg 849.3hpa 12.317psi 66.9F 19.4C -
    70F 41% 30.18

    12:03
    02 00 00 4C BE 0D EC 01 52 03 62 7E 38 18 EE 09 C4 08 22 06 07 7B D2 8A 26
    25.079inhg 849.3hpa 12.317psi 66.9F 19.4C -
    70F 42% 30.18

    12:10
    02 00 00 4C BE 0D EC 01 52 03 62 7E 38 18 EE 09 C4 08 22 06 07 7B D2 8A 26
    25.079inhg 849.3hpa 12.317psi 66.9F 19.4C -
    71F 44% 30.18

    12:10
    02 00 00 4C BE 0D EC 01 52 03 62 7E 38 18 EE 09 C4 08 22 06 07 7C 50 89 E8
    25.084inhg 849.4hpa 12.320psi 69.0F 20.6C -
    71F 44% 30.18

    hope this helps!

    m

    matthew wall
    weewx developer

    ReplyDelete
    Replies
    1. Your R2 readings are completely different from mine, although they are similar in that most of the data stays the same all the time except the last 4 bytes. It could be that they are sending the correction bytes, but that doesn't explain why mine are mostly zeros and ones.

      I'll have to think about this a bit. Remember though, the console doesn't show the 'real' pressure, it shows the result of some algorithm that Acurite came up with. It's part of the month long 'learning' period they advertise as a good thing.

      How waiting a month before a meter works can be a good thing I don't know.

      And, yes, it isn't saving data in USB mode 4. In mode 4 all the data goes out the port and you're responsible for saving what you want. If you use any mode that saves data, you'll run into the bug that starts reporting that it can't hold any more data. I had that happen and got around it by pulling the batteries. Of course, that put it right back in 'learning' mode as well.

      Delete
    2. From my 2032, R2 matches Dave's:

      02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F C7 4C D3
      02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F C7 4C D4
      02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F C9 4C D3
      02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F C9 4C D4


      I'm wondering if they switched sensors in a board revision or something. I'm going to instrument Matthew's acurite.py to compute with algorithms for both chips (ignoring C7, A, B, C, and D for the MS5607), and see how the results compare. Using Matthew's implementation, my indoor temperature reports in the 40s when it actually drops to the low 60s. I'll follow up with my results.

      Delete
    3. I think there are at least two versions of output for the R2 message. I've seen only the zeros and ones version, but have heard from folk that get messages like Mathew's.

      However, I don't trust either of them a bit. There's just too much that they can do to the readings from the barometer. Give me a couple of weeks and I'll have a real barometer running and it won't matter any more.

      I've also managed to actually catch the RF data coming from the weather head itself. I may reach a point where the console is not even needed except as a display to impress visitors.

      Delete
  3. I got this via email. One of the readers, Play Kube, did a bunch of research on the barometric pressure and came up with this that tracks his local weather stations very well. This could well be the solution to the console barometer. I may just have to test this over a few days to see if he found it for us (if he's a he, he may be a she).

    I think the pressure data is in the last two bytes [23-24] of R2
    I got a linear fit to pressure data in pascals from acurite's windows app and [23-24] of R2 but with huge negative offset. I did not find any correlation between temperature and [21-22]
    pascals = 6.23*counts - 20402


    P(pascal) | T(F) | R2
    99470 55.? 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 88 4B 2B
    99450 55.? 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 88 4B 28
    99450 55.? 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 8A 4B 28
    99430 55.? 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 8A 4B 24
    99440 55.3 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 8D 4B 26
    99430 55.3 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 8D 4B 24
    99390 55.3 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 8D 4B 1E
    99400 55.3 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 8F 4B 20
    99400 55.3 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 8D 4B 20
    99400 55.4 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 8F 4B 20
    99380 55.4 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 8F 4B 1C
    99380 55.4 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 91 4B 1C
    99390 55.3 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 91 4B 1E
    99350 55.3 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 92 4B 18
    99350 55.1 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 92 4B 18
    99330 55.1 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 94 4B 14
    99320 55.1 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F A1 4B 13
    99320 54.9 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F A5 4B 13
    99280 54.9 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F A5 4B 0C
    99270 54.9 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F A3 4B 0B
    99260 54.7 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 9C 4B 09
    99250 54.5 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 94 4B 08
    99240 54.4 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 99 4B 06
    99220 54.5 02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F 9B 4B 03


    Later I verified pressure data form the sensor over 12 hours with local noaa and it fits very well. See attached.
    I will keep visiting you blog for more interesting stuff.

    ReplyDelete
  4. This comment has been removed by the author.

    ReplyDelete
  5. I have Baro data working. I uncommitted the "for" look to output the hex bytes for R1 & R2 and noticed that when I calibrated temps/hum/baro the R2-23/24 changed. I did some web searching and found a entry for different Acurite unit where it listed:
    bar = ((data[23] << 8) + data[24]) / 10 -364. I changed it to: return (float)(((data[23] << 8) + data[24]) / 519.00); and it seems to be track quite nicely. I'm at 7630 ft so 519 works for me. I added: (in getit() under if (whichOne == 1 else weatherData.baro = getBaro(data);

    ReplyDelete
    Replies
    1. So ... question(s): right now the sender is mounted on the deck railing (snow on roof etc + testing) rain = 1.50, 1.50, 3.00, 3.00, 1.50.... from where I was playing when first powered up. I assume there is/are command(s) to "Reset" which are _______? I'm also looking for windGust. My orig unit is a LaCrosse 2315 and SW is open2300 - my wind-speed/dir -> Fubar'ed'ed'ed... Costco/Acurite/DHome and here I R.
      Thanks

      Delete
    2. I have NOT found a reset command. I'm just waiting for it to roll over to zero. When that happens I can just adjust the code to allow for it. You can probably take the batteries out of the weather head and reset it though. I haven't tried that; it's too cold on the roof.

      Wind gusts are going to be a problem. The device doesn't seem to react well and measure the higher gusts properly. Here in the desert I don't worry about that much since there's only noticeable gusting when there's a thunder storm or dirt storm. Other folk have contacted me and indicated that it seems to respond non-linearly to wind gusts over 15 mph or so. It's difficult to tell what is going on because everyone that has looked into it has the thing mounted outside in an inconvenient place.

      Delete
  6. Correct me if you think differently but .... I think the RainCount never resets but just counts bucket tips: 0, 1, 2, 3, ... 126, 127, 0, 1, 2...
    So if I want to feed Wunderground... rain/hr & rain/day I'm going to be forced to keep a tally on the side before I Curl to Wunderground. (mutter mutter mutter...)

    ReplyDelete
    Replies
    1. I agree. It's not hard to do in code though; just think of it like a clock that rolls over the hour.

      Delete
    2. OK, I slept on it (rain problem) and have decided to go this route:
      getit1, getit2 and showit run every 30 seconds. In 'showit' I built a "insert into weadata values ('2016.... and insert it into a MysqlDb and select * from... gives
      2016-01-16 19:00:00 22.8 10.8 38 2 292.5 3.5 95 0 29.43
      Then in Cron every 5 minutes I can select the data I need for Wunderground and Curl it out.

      Delete
    3. I use a separate process that runs all the time to forward data to Cosm. That way I have a little more control and don't have to use curl. I never quite mastered curl well enough to trust my use of it.

      Delete
    4. So "separate process" is _________?? (ftp)
      Curl is simple. On the command line # curl "http://google.com"
      You will be told "moved..."
      curl https://www.google.com/search?q=desert+home&ie=utf-8&oe=utf-8#q=desert+home
      Now in PHP etc it's been decided to make it soooooooo freeeeeeek'n convoluted'ed'ed'ed'ed. But if you kiss it....

      Anyhow back to the main subject. So I've modified the code to mysql_query ("insert into.... every 30 seconds. Then every 5 minutes a php script to pull the last 5min/24hrs for the rain. Then create the string "http://wunderground...&temp=17.2&dewptf=...
      and curl it off to WU. At least that's where I'm at now - tomorrow???

      Delete
    5. It's one I wrote in python to read the database and forward the data to cosm.

      Delete
    6. This comment has been removed by the author.

      Delete
  7. http://www.wunderground.com/personal-weather-station/dashboard?ID=KCOBLACK1#history/tgraphs/s20160117/e20160117/mdaily

    ReplyDelete