Ecowitt stations

Well there is yet one other thing and that is negative temperatures. I have it figured out in the API but Brian now needs to update the code in his program. But I hardly ever see negative temperatures here in Florida. :smiley:

I got the negative temperatures sorted (by putting the sensor in the freezer)
it will mean though it will only read down to -25.6 C ?

Working range is -40

Here is another way to think of it…

A 16 bit integer is 16 ones or zeros. Here is the largest binary number representing that.
11111111 11111111

(for readability we separate it into two 8 bit integers…but it’s really together)

That largest 16 bit integer is easier to represent with hex notation.
FF FF

A signed integer is where that first bit is a 1 if negative. So that first bit is the negative flag.
15 ones is the largest possible possitve number.
01111111 1111111 binary
7F FF hex
Which equals 32767 (the last possible positive number using 15 ones, the limit of a 16 bit signed integer). You can’t use that first bit (currently 0) because that is used to indicate negative numbers. A zero in the first bit indicates a positive number.

You only take the 2’s compliment if that first bit is a 1. The 2’s complement is just flipping all the ones to zero and all the zeros to one…but lastly you have to add 1 to the total. Therefore you only take the 2’s compliment if in hex the integer is greater than 7F FF…(or greater than 32767 decimal.)

Therefore if we see anything starting with a 1 in a 16 bit integer we know this is a negative number.
11111111 11111111
FF FF hex
The 2’s compliment says to flip all the bits and add 1.
00000000 00000001
00 01 hex
Then convert to decimal and set the sign to negative if you did the 2’s complement.

But in programming you don’t need to do so much work. Nor do you need to know how all this works. Nor how to do 2’s compliments. For example in C programming it is this simple and easy.


#include <stdio.h>

int main() {
    int myInt;
    myInt = 0xFFE4;
    printf("%d\n",myInt);

    return 0;
}

That returns -28 decimal because we feed the program 0xFFE4 as a value. Which you then divide by 10 and in the case of temperature then it represents -2.8

ah, OK, yes, treat it like how the solar data works, instead of byte encoded
I will try that

I have updated WD to now use this new method for the temperature data

I have added support now to the GW1000 “hub” to the Linux and Mac versions and also the latest raspberry pi consolewd version :slight_smile:

Excellent job Brian. I enjoyed working with you for what little part I played. I had fun with a few eureka moments.

I want everyone to know that Brian has spent several days troubleshooting and developing his software to fully support the GW1000 and the different sensors. Every station sends data in its own language and in the case of the GW1000 it does not talk with immediately legible data. The data is encoded in special notation and all of it, commands to send and responses to receive were all in hex code…even the values returned. It all needs to be made sense of, tagged and converted. There was a good bit (pun intended) to figure out.

oh and I forgot to say I added option now to use the station rain totals
Thanks for your help Galfert
Q: so someone relying on the slow updating ambientdata.net, could use a GW1000 and get 2x faster update rate?

Yes, in many regards those now using Ambientweather.net would greatly benefit from adding a GW1000 to their station hardware (and it is very cost effective and easy to set up). Weather data would be more than 2x faster update rate. The GW1000 updates data every 16 seconds (receives every 14 seconds from sensors). Getting data from Ambientweather.net is 1 or 2 minutes delayed. So that is 3.75x to 7.5x faster update rate.

Not only is it faster than data from Ambientweather.net but also more reliable because it doesn’t need the Internet to be up nor for Ambientweather.net to be up (as it does go down sometimes), because getting data directly from the GW1000 all happens over the local network. Therefore there is less chance of missed data in WD.

Just upgraded to ver 103 and noticed that something is not right. It’s 28deg F outside and my display and website says it’s -10 out. I upgraded from ver 102 to try to fix the problem of it staying at 32deg f when it was below that and found this problem.

Steve

The new version should fix the problem below
Freezing
But is not working correct still?

That is correct. It is below freezing here right now (24.6 Deg F) according to the Ecowitt app https://www.ecowitt.net/home/index?id=4915 and my web site which is driven by WD and the WD program says (-9.2 Deg F) https://weather.athelstanewi.com/. The indoor temp looks fine. It looks like it’s just the outdoor temp that is messed up. I am using a GW1002 station.

Steve

I will check /test with the raw data you sent me and get back to you

Hi
if you could email me your data when its below 32f and what the actual temperature is
(or at least let me know what the actual temperature was when you did email me that raw data)

Brian,
Are you looking for the clientraw file in WD? I will send it to you via email when it returns below freezing again this evening as well as the outdoor temp as shown on ecowitt. Maybe I can do a screen shot of the Cron GW1000 also.

Steve

Hi
no, not the clientraw data
but the actual raw data that shows in the cronecowitt program

Hi Brian,
I sent you a screen shot of everything up showing as much info as I could. I did note that the outdoor temp and the indoor temp were displayed the same but outdoor reading had a - sign in front of it so it appears when the outdoor temp falls below freezing it takes the indoor temp and shows it as a minus for the outdoor temp.

Steve

yeah, that was a silly bug
I have sent you a email