Major rainfall accumulation error in both Meteobridge Pro and Nano SD
Posted: Sun Jun 05, 2022 7:32 am
Hi,
I have two Meteobridge devices described as follows. Both devices fail to correctly register the correct amount of accumulated rainfall experienced in their locations.
Both these devices have been commissioned for nearly a year.
Neither of these devices have ever correctly measured the amount of accumulated rainfall.
A brief description of each installation follows, with an analysis of a recent rain event incurred by the Meteobridge Pro system, illustrated with several screen shots which hopefully will illustrate the problem I have observed.
System A: A Meteobridge Pro which receives signals via wireless from a Davis Vantage Pro 2 sensor system.
The current firmware installed in this device is Meteobridge 5.4 (May 31 2022, build 14749), FW 1.4
This is designed as a stand alone data collection point. No data is pushed to external weather networks. No scripts or periodic functions are used. The storage system is the internal factory supplied SD card. No external USB memory is attached. Interface for the reading of internally stored data and user commands is via a locally provided WiFi network just for the Meteobridge Pro at the remote location.
The factory supplied antennas have been replaced with a fixed antenna system for the 900Mhz band used by the Davis system. The system is in a rural area, several kms from any buildings. The received signal level for the raw data is -70dB, as indicated on the setup screen and the receive threshold is set to -85dB. This is a fixed permanent system and no missing data due to RF signal fluctuations or interference has ever been observed. The distance for the data transmission from the Davis instrument cluster to the Meteobridge Pro is about 25 metres.
The Davis Vantage Pro 2 instrument cluster is less than a year old, is regularly cleaned and the rain tipping sensor is free from obstruction and operates correctly.
The rainfall for the month of June up to midnight 3rd June was registered as 1.8mm. This was after a reboot (explained below).
Rain occurred throughout the 4th June with a total of 10mm of rain until midnight.
Note however that the rain total for the 4th of June is in error. The rain total for the month increments very slowly during the day, both on the max/min table and also on the hour data as below. Note that the Hour Data and Max/Min data errors are different. The error becomes increasingly larger during the day as shown below.
Hour data at the end of the 4th June, just before midnight.
Max/Min data showing error in total rain for the month of June.
The actual rainfall for 4th June was 10mm. The max/min above registered the rainfall for the day of 4th June correctly as 10mm, as does "the all in one chart" in the Chart Generator section.
The system rolled over at midnight on 4th June and the errors persisted as below.
If however a reboot is performed via the command on the user interface (soft reboot), all the data errors appear to correct themselves. However, the correction is short lived and the next day as soon as any rain occurs the intrinsic issue becomes obvious and the problem persists.
Here are the photos showing the correct data immediately after a soft reboot (as described above ) is performed.
Hour data after reboot early on 5th June, showing corrected data.
Similarly for the max/min data.
System B: A Meteobridge Nano SD installed within the console of a Davis Vantage Pro 2.
The current firmware installed in this device is Meteobridge 5.4 (May 31 2022, build 4211), FW 1.4
This system experiences the same type of rainfall error which occurs with System A.
As in System A, this is also a stand alone system with no data pushed to external weather networks.
For simplicity, screenshots are not provided for this system.
This system also corrects itself after a soft reboot, with the errors recurring in the time following the reboot.
This system also appears to become sluggish to commands as the time interval since the last reboot increases.
Hopefully the above description is helpful in finding the issue. I must admit as this is a core function of these products I am concerned that maybe there is a setup that I may have missed.
Thank you.
Kind regards,
Emma
I have two Meteobridge devices described as follows. Both devices fail to correctly register the correct amount of accumulated rainfall experienced in their locations.
Both these devices have been commissioned for nearly a year.
Neither of these devices have ever correctly measured the amount of accumulated rainfall.
A brief description of each installation follows, with an analysis of a recent rain event incurred by the Meteobridge Pro system, illustrated with several screen shots which hopefully will illustrate the problem I have observed.
System A: A Meteobridge Pro which receives signals via wireless from a Davis Vantage Pro 2 sensor system.
The current firmware installed in this device is Meteobridge 5.4 (May 31 2022, build 14749), FW 1.4
This is designed as a stand alone data collection point. No data is pushed to external weather networks. No scripts or periodic functions are used. The storage system is the internal factory supplied SD card. No external USB memory is attached. Interface for the reading of internally stored data and user commands is via a locally provided WiFi network just for the Meteobridge Pro at the remote location.
The factory supplied antennas have been replaced with a fixed antenna system for the 900Mhz band used by the Davis system. The system is in a rural area, several kms from any buildings. The received signal level for the raw data is -70dB, as indicated on the setup screen and the receive threshold is set to -85dB. This is a fixed permanent system and no missing data due to RF signal fluctuations or interference has ever been observed. The distance for the data transmission from the Davis instrument cluster to the Meteobridge Pro is about 25 metres.
The Davis Vantage Pro 2 instrument cluster is less than a year old, is regularly cleaned and the rain tipping sensor is free from obstruction and operates correctly.
The rainfall for the month of June up to midnight 3rd June was registered as 1.8mm. This was after a reboot (explained below).
Rain occurred throughout the 4th June with a total of 10mm of rain until midnight.
Note however that the rain total for the 4th of June is in error. The rain total for the month increments very slowly during the day, both on the max/min table and also on the hour data as below. Note that the Hour Data and Max/Min data errors are different. The error becomes increasingly larger during the day as shown below.
Hour data at the end of the 4th June, just before midnight.
Max/Min data showing error in total rain for the month of June.
The actual rainfall for 4th June was 10mm. The max/min above registered the rainfall for the day of 4th June correctly as 10mm, as does "the all in one chart" in the Chart Generator section.
The system rolled over at midnight on 4th June and the errors persisted as below.
If however a reboot is performed via the command on the user interface (soft reboot), all the data errors appear to correct themselves. However, the correction is short lived and the next day as soon as any rain occurs the intrinsic issue becomes obvious and the problem persists.
Here are the photos showing the correct data immediately after a soft reboot (as described above ) is performed.
Hour data after reboot early on 5th June, showing corrected data.
Similarly for the max/min data.
System B: A Meteobridge Nano SD installed within the console of a Davis Vantage Pro 2.
The current firmware installed in this device is Meteobridge 5.4 (May 31 2022, build 4211), FW 1.4
This system experiences the same type of rainfall error which occurs with System A.
As in System A, this is also a stand alone system with no data pushed to external weather networks.
For simplicity, screenshots are not provided for this system.
This system also corrects itself after a soft reboot, with the errors recurring in the time following the reboot.
This system also appears to become sluggish to commands as the time interval since the last reboot increases.
Hopefully the above description is helpful in finding the issue. I must admit as this is a core function of these products I am concerned that maybe there is a setup that I may have missed.
Thank you.
Kind regards,
Emma