I noticed a30 minute gap in the data on Weather Underground, but only on data from the ISS. I looked in the Meteobridge logs and found this:
The first three are included for information, and don't look like error messages.
logger (16.01.2016 21:00:51): bandwidth narrow
logger (16.01.2016 21:00:51): chip authentication ok: 14
logger (16.01.2016 21:00:51): frequency band 915MHz (US)
logger (17.01.2016 21:44:31): suspicious (blocked) temp 63.9(14.1)C, (f8 7f bd 5b ff ff 0b ae) -83db
logger (17.01.2016 21:44:34): suspicious (blocked) temp 14.0(63.9)C, (80 0b 5d 23 cb 00 61 5a) -50db
logger (18.01.2016 19:09:24): suspicious windspeeds (detected): gust/avg 87.4/0.0 m/s (60 b8 2b 45 92 64 47 b2) -88db
logger (19.01.2016 04:09:08): restart meteostick (304 secs no valid rf signal)
logger (19.01.2016 04:14:09): restart meteostick (302 secs no valid rf signal)
logger (19.01.2016 04:19:10): restart meteostick (301 secs no valid rf signal)
logger (19.01.2016 04:24:11): restart meteostick (301 secs no valid rf signal)
What is causing this dropout, and what can I do to avoid it?
This dropout appears to have caused an error in the rainfall totals. Data from the ISS is for this day is less than a rain bucket rain guage (nothing mechanical or electronic to fail).
Signal strength typically shows -50 dB. Distance is about 50' through a ceiling and a composition shingle roof.
Signal strength before and after the event was uniform (now decay at all).
Weather Underground page is here: http://www.wunderground.com/personal-we ... CASANJO507
Nothing unusual was happening at 4 AM.
Both the meteobridge and my networking are on an uninterrupted power supply.
Iss is solar powered Davis Vantage Pro 2.
MB Pro: Please explain these error messages...
Moderator: Mattk
Re: MB Pro: Please explain these error messages...
I did a bit of research and found the data protocol of a different Davis ISS: https://github.com/dekay/im-me/blob/mas ... otocol.txt
It looks like the rain gauge data is sent as a continuously incrementing unsigned byte that increments once per bucket tip. This is a good design as it would require contiguous missing packets for at least 2.55" of rain before the rain value became wrong.
So the only way to account for the 0.03" measurement difference in 0.46" of rain between the bucket rain gauge and the Davis is the 50 yd distance between the two gauges. (I had previously had 1.13" of rain with only 0.01" difference).
I'd still like an explanation of those error messages though. It looks suspiciously like the meteostick built into the Meteobridge Pro crashed repeatedly for 20 minutes.
It looks like the rain gauge data is sent as a continuously incrementing unsigned byte that increments once per bucket tip. This is a good design as it would require contiguous missing packets for at least 2.55" of rain before the rain value became wrong.
So the only way to account for the 0.03" measurement difference in 0.46" of rain between the bucket rain gauge and the Davis is the 50 yd distance between the two gauges. (I had previously had 1.13" of rain with only 0.01" difference).
I'd still like an explanation of those error messages though. It looks suspiciously like the meteostick built into the Meteobridge Pro crashed repeatedly for 20 minutes.
Re: MB Pro: Please explain these error messages...
Suspicious data readings are usually a symptom of too high RF sensitivity where it
picks up lots of RF noise and some of those look from the CRC like proper packets
but content is not in line with previous data received, therefore Meteobridge blocks that.
When your sensors data is coming in with -50db, something like -70db is as
reasonable RF threshold. What value do you have defined?
Is your MB PRO located outside your IT cabinet? Sitting next to other IT makes
RF reception an unnecessary hard job, even when signal level is good.
I cannot confirm that the RF unit resets/crashed every 20 minutes. That is not happening here
and it is also not reported in your messages snippet.
picks up lots of RF noise and some of those look from the CRC like proper packets
but content is not in line with previous data received, therefore Meteobridge blocks that.
When your sensors data is coming in with -50db, something like -70db is as
reasonable RF threshold. What value do you have defined?
Is your MB PRO located outside your IT cabinet? Sitting next to other IT makes
RF reception an unnecessary hard job, even when signal level is good.
I cannot confirm that the RF unit resets/crashed every 20 minutes. That is not happening here
and it is also not reported in your messages snippet.
Re: MB Pro: Please explain these error messages...
I have a couple of other temperature sensors that operate at 900 MHz, any possibility that they have the same data packet type & check sum with a different data format?admin wrote:Suspicious data readings are usually a symptom of too high RF sensitivity where it
picks up lots of RF noise and some of those look from the CRC like proper packets
but content is not in line with previous data received, therefore Meteobridge blocks that.
Also two of those packets have spuriously low signal strengths. I have not seen any neighbours with Davis ISS anywhere, but could I be picking up another ISS?
I was following the instructions that came with the device, not to mess with those numbers unless told to by you guys.When your sensors data is coming in with -50db, something like -70db is as
reasonable RF threshold. What value do you have defined?
Currently it is still at -90.
I will adjust to -70.
Yes, it is outside the wiring closet. It is sitting about 4' from my wifi box and above two monitors (it is in a location with the fewest layers of roofing/walls to the ISS, and access to the UPS).Is your MB PRO located outside your IT cabinet? Sitting next to other IT makes
RF reception an unnecessary hard job, even when signal level is good.
Misunderstanding here. I did not say it failed every 20 minutes, I said in failed repeatedly for 20 minutes. I have not had a repeat of that 20 minute sequence of restarts.I cannot confirm that the RF unit resets/crashed every 20 minutes. That is not happening here
and it is also not reported in your messages snippet.