[danner]

OK, sorry folks, another stupid question time. Please bear with me as I am new to arduino.

I cannot complete my TX units because I am waiting on the correct size resistors to show up so I thought I would smoke test my Pro2+.

I downloaded the newest Pro2+ software a couple of hours ago. Changed some settings to match what I have and put it in test mode = True. Flashed it, and shazam, it works. Couple questions though.

To make a long story short the temperature displayed on the TFT display reads 153.1 degrees F, but the temp on the internal web page shows the correct temp of 67.1F.

One other thing. I did a search for this question as well. The clock initially showed the year 2000 and after it connected to my LAN the clock updated to the correct date but not the correct hour. My time zone is 4 hours behind UTC time but the displayed time is 3 hours ahead of UTC. I had planned to run this without a PC and software for a little while and just have it upload to wunderground, but if it needs to have Cumulus connected in order to have the correct time then how does that work with wunderground and the time difference.

An observation. The reported pressure (BME280) is spot on to my current weather station. Is it using my elevation and automatically providing a sea level correction? Can I view the raw uncorrected pressure?

[werk_ag]

Hi,

I downloaded the newest Pro2+ software a couple of hours ago. Changed some settings to match what I have and put it in test mode = True. Flashed it, and shazam, it works. Couple questions though.

To make a long story short the temperature displayed on the TFT display reads 153.1 degrees F, but the temp on the internal web page shows the correct temp of 67.1F.

Perhaps it is a bug when using F degrees. I will check it as soon as possible.

One other thing. I did a search for this question as well. The clock initially showed the year 2000 and after it connected to my LAN the clock updated to the correct date but not the correct hour. My time zone is 4 hours behind UTC time but the displayed time is 3 hours ahead of UTC.  I had planned to run this without a PC and software for a little while and just have it upload to wunderground, but if it needs to have Cumulus connected in order to have the correct time then how does that work with wunderground and the time difference.

You don't need to have the receiver unit connected to Cumulus to have the correct time. It just a matter of adjusting two parameters in the user configurable settings. Please check these settings and adjust according to your Time Zone and Summer Time rules

Code:

// --------------------------------------------------------------------------------------
//   Define rules for Auto Summer Time Display, and clock adjustment
// --------------------------------------------------------------------------------------
// Example for Australia Eastern Time Zone (Sydney, Melbourne)
// TimeChangeRule aEDT = {"AEDT", First, Sun, Oct, 2, 660};    //UTC + 11 hours
// TimeChangeRule aEST = {"AEST", First, Sun, Apr, 3, 600};    //UTC + 10 hours
// Timezone myTZ(aEDT, aEST);

TimeChangeRule PST = {"PST", Last, Sun, Mar, 1, 60};   //Portuguese Summer Time -  "UTC + 1" or GMT + 1
TimeChangeRule GMT = {"GMT", Last, Sun, Oct, 2, 0};    //Portuguese Winter Time -  "UTC + 0" or GMT
Timezone myTZ(PST, GMT);

Example for you, supposing your place doesn't use "Summer Time"

TimeChangeRule ST = {"ST", Last, Sun, Mar, 1, -240};   // My Summer Time -  UTC -4
TimeChangeRule WT = {"WT", Last, Sun, Oct, 2, -240};    //My Winter Time -  UTC -4
Timezone myTZ(ST, WT);[/code]

An observation. The reported pressure (BME280) is spot on to my current weather station. Is it using my elevation and automatically providing a sea level correction?

Yes, it uses the user defined elevation to calculate the equivalent sea level pressure. This is the value used by weather stations to report pressure.

Can I view the raw uncorrected pressure?

Changing the code, almost everything it's possible. I don't recommend, but if you wish, you can do it at your own risk.

[danner]

Thanks for the reply. This is the code I am using for the time.

// --------------------------------------------------------------------------------------
//   Define rules for Auto Summer Time Display, and clock adjustment
// --------------------------------------------------------------------------------------
// Example for Australia Eastern Time Zone (Sydney, Melbourne)
// TimeChangeRule aEDT = {"AEDT", First, Sun, Oct, 2, 660};    //UTC + 11 hours
// TimeChangeRule aEST = {"AEST", First, Sun, Apr, 3, 600};    //UTC + 10 hours
// Timezone myTZ(aEDT, aEST);

TimeChangeRule usEDT = {"USEDT", Second, Sat, Mar, 11, 200};   //UTC - 4 hours
TimeChangeRule usEST = {"USEST", First, Sun, Nov, 5, 200};    //UTC - 5 hours
Timezone myTZ(usEDT, usEST);

Right now the clock reads 0523 and the top green light is on. UTC time should be 0203. Local time is 2203.

[werk_ag]

Please try this:

Code:

TimeChangeRule usEDT = {"USEDT", Second, Sat, Mar, 11, -240};   //UTC - 4 hours
TimeChangeRule usEST = {"USEST", First, Sun, Nov, 5, -300};    //UTC - 5 hours
Timezone myTZ(usEDT, usEST);

[danner]

Here's the internal web page display.



And here's the TFT.

[danner]

Please try this:

Code:

TimeChangeRule usEDT = {"USEDT", Second, Sat, Mar, 11, -240};   //UTC - 4 hours
TimeChangeRule usEST = {"USEST", First, Sun, Nov, 5, -300};    //UTC - 5 hours
Timezone myTZ(usEDT, usEST);

That worked, thanks!

Now I understand. Those are minutes not AM or PM. So -240 minutes and -300 minutes.

[danner]

I have another question. Why is the displayed rain only available in mm on the TFT screen? I looked at the code and it says "no setting, always mm". Is there no way to display inches?

// --------------------------------------------------------------------------------------
// Define data display units
// --------------------------------------------------------------------------------------
#define Date_Time_Format 1 // 0 for dd-mm-yyyy, 1 for yyyy/mm/dd
byte Temp_Display_Unit = 1; // 0 for ºC, 1 for ºF
byte ATM_Display_Unit = 1; // 0 for mBar, 1 for inHg
byte Rain_Display_Unit = 0; // no setting, always mm
byte Wind_Display_Unit = 1; // 0 for Km/h, 1 for mph, 2 for m/s, 3 for Knots

[werk_ag]

... Is there no way to display inches?

// --------------------------------------------------------------------------------------
//   Define data display units
// --------------------------------------------------------------------------------------
#define Date_Time_Format 1     // 0 for dd-mm-yyyy, 1 for yyyy/mm/dd
byte Temp_Display_Unit = 1;    // 0 for ºC, 1 for ºF
byte ATM_Display_Unit  = 1;    // 0 for mBar, 1 for inHg
byte Rain_Display_Unit = 0;    // no setting, always mm
byte Wind_Display_Unit = 1;    // 0 for Km/h, 1 for mph, 2 for m/s, 3 for Knots

I know that commonly the rainfall in USA is expressed in inches. Unfortunately for USA users, the WeatherDuino can only display the rainfall (and rainfall rate) in mm. I don't remember where but there are a discussion on the forum about this matter. The main reason is about precision, to display 0.1mm of rain in inches, we need to use at least 4 decimal places.

[werk_ag]

Here's the internal web page display.



And here's the TFT.

I have just checked this issue, and I can confirm that its a bug. The issue occurs only when ºF is chosen as display unit.
It's strange that none of the users in USA have reported it before. Thank your for having done it.
This issue will be fixed on next software release. If you need a quick fix, please send me your email by PM, and I will send you a file which corrects the problem.

[werk_ag]

Please try this:

Code:

TimeChangeRule usEDT = {"USEDT", Second, Sat, Mar, 11, -240};   //UTC - 4 hours
TimeChangeRule usEST = {"USEST", First, Sun, Nov, 5, -300};    //UTC - 5 hours
Timezone myTZ(usEDT, usEST);

That worked, thanks!

Now I understand. Those are minutes not AM or PM. So -240 minutes and -300 minutes.

Yes, that's it!