Results from tests of Sensor Contact Lost alarm

[Dave Walker]

THESE TESTS WERE CARRIED OUT TO TRY AND FURTHER UNDERSTAND THE SENSOR ALARM ISSUE.

Test 1 - Prove that RG11 connectors do not cause Lost Sensor Alarm.[/b]
Wind and rain cables unplugged from transmitter
Wind direction display on console direction goes blank. Wind speed = 0.0
No alarm generated even after 30 minutes

Test 2 - Prevent weather station transmission being received at console (but the transmitter remains working) to see how the console receiver indication behaves. Then restore reception after the Lost Sensor Contact alarm occurs to see if the data link is restored.
Transmitter screened with foil.
Console outside figures freeze at last figures received.
Console Receiver switches on 8 times at 48 sec intervals for 2 seconds (no data received)
After another 45s receiver switches on solidly for 2min 30sec
After this 2min 30secs all outside figures go to dashes and Lost Sensor Contact alarm is generated
Receiver then resumes the previous cycle and is on for 2 secs every 48 secs
Transmitter screen removed – data now being received at console
On next ‘receiver on cycle’ console readings restore and all normal

Test 3 – Prevent weather station transmission being received at console (but the transmitter remains working) then restore reception before Lost Sensor Contact alarm occurs to see if the data link is restored.
Transmitter screened with foil.
Waited until the receiver entered ‘On for 2min 30sec’ state
Transmitter screen removed during this receiver on phase
On next transmission the console display returns to normal

Test 4– To test how the console responds to another data system on the same frequency.
Transmitter screened with foil.
When receiver entered the ‘On for 2min 30sec’ state, an electric consumption monitor on 433.9Mhz (transmitting a data burst every 5 secs) switched on next to console – no effect
After 2min 30sec all outside figures go to dashes, Lost Sensor Contact alarm generated and receiver resumed 48 sec cycle with 2 sec on-time
Transmitter screen removed – (electric monitor still on). On next receiver cycle console readings restore and all normal

Test 5 – To see what happens if the transmitter suffers some problem that changes the timing of its transmission, putting it out of sync with the console receiver – eg an intermittent battery contact.
At 1207 Transmitter battery removed for 2 mins then replaced
At 1209 Transmitter resumes operation but is now out of sync with the receiver
At 1214 (approx) the receiver entered the ‘On for 2min 30sec’ state. I assumed this was intended to re-synchronise in case the transmitter timing had changed but despite the fact that the transmissions were being received on the radio next to the console, the console did not respond to the transmissions and at 1216 & 25secs the Lost Sensor Contact alarm was generated
Receiver now resumed 48 sec cycle, on for 2 secs each time but still out of sync with transmitter
The time difference between data transmission (received on a portable radio) and the console ‘receiver on’ indication was measured with a stopwatch to see if the difference might be changing, leading to an eventual matching up again between transmitter and receiver.
At 1220 was 6 secs
1230 6
1300 6
1400 6
1500 6
1600 6
1700 6
1800 6

Gave up at 1800 and restarted the console to allow it to synchronise, which it did straight away and all displays were then normal.

Since doing these trials I have experienced a Lost Sensor Contact alarm twice:
The first time was for about 10 minutes. The error log showed just 1 line of “Lost Sensor Conatct” alarm. From the above tests this would indicate that the loss lasted for about 10 minutes (long enough for the alarm flag to be generated by the FO console), but then re-establshed on the next transmission from the weather station.

The second time the alarm lasted for something like 3 hours but the exact length of time could not be determined because Cumulus logs Lost Sensor Contact alarm every 10 seconds BUT if the event goes for a long time then the earlier alarm times are lost. There is obviously a limit on the number of lines in the error display. This is somewhat confusing as looking back will not necessarily show the time that the alarm was first generated if it has lasted for a long time. Would be more useful if only the first ‘alarm’ was shown and then a different text line (eg “Sensor Contact regained at date/time” – or similar)

Why these alarms occur is still unknown and the station has had no further loss of sensor contact for over a week. The distance between transmitter and console is only 10 metres and line of sight. There are no other transmissions on the frequency of the wireless link and from the above test 5 the alarm lasting for about 10 minutes was not due to a transmitter timing issue or the system would not have recovered so quickly.

I appreciate that there is no definite answer to these alarms but felt that this post may help to shed some more light on this issue.

Dave

[AllyCat]

Hi Dave,

Thanks for those detailed test reports.

Test 4– To test how the console responds to another data system on the same frequency.
Transmitter screened with foil...... electric consumption monitor on 433.9Mhz (transmitting a data burst every 5 secs) switched on next to console – no effect

The FO receiver seems well designed to ignore data from another transmitter (as it should, since it is using the "shared" ISM band). It not only looks for the correct "protocol" (message structure) but I believe also the "address" (better called a signature) of the appropriate transmitter.

Test 5 – To see what happens if the transmitter suffers some problem that changes the timing of its transmission, putting it out of sync with the console receiver – eg an intermittent battery contact.

Receiver now resumed 48 sec cycle, on for 2 secs each time but still out of sync with transmitter

The User Manual for the 308x models implies that the receiver starts a "search" for the transmitter if the signal is "lost", but I don't think that this actually happens. Just as well because it's a bad idea. If the receiver starts a search that soon, it may well lock onto somebody else's transmitter! There was a recent thread here where several users of Davis stations (which have far greater wireless range) had found their Consoles locked onto the wrong transmitter.

Also, I believe that the FO transmitters actually change (increment) their address each time the batteries are replaced, so it is essential to also reset the Console.

Cheers, Alan.

[jim-easterbrook]

Also, I believe that the FO transmitters actually change (increment) their address each time the batteries are replaced, so it is essential to also reset the Console.

I've managed to change the batteries without any reset - the transmitter carries on transmitting in the same "phase" and retains the accumulated rain value. I think the trick is to swap batteries during the 48 second gap between transmissions.

(I'm not disagreeing with what you wrote, but not every battery change will reset the transmitter.)

[AllyCat]

Hi Jim,

Yes, you're absolutely correct; I'd (temporarily) forgotten that I've recommended (and used) that trick myself. The power consumption of the microcontroller during the "sleep" period between transmissions is obviously so low that the supply decoupling (reservoir) capacitor keeps the "clock" running. Then when the micro attempts to transmit (or more probably run the A/D converter a few seconds before) without a battery present, it knocks down the rail, and the micro resets when the battery is replaced.

Cheers, Alan.

[Dave Walker]

Thanks Alan and Jim. Useful information re changing of the Tx batteries.

I'm now waiting for the next Lost Sensor alarm (during a time when I'm within earshot of Cumulus) so I can have a listen on 433.9Mhz to see if the Tx is still sending data. If it is, and the Rx indication is still coincident with the transmission then, as we don't have anything else on that frequency and have no neigbours, being out in the country, then perhaps it would suggest that either the data from the Tx is corrupt or that the console isn't 'decoding' the data correctly. I don't have any way of looking at the actual data so that may be as far as I can go.

As ever, when you are wanting something to happen it of course doesn't!!!

Very strange that the system recovers after a number of hours in the lost sensor contact alarm condition.

Does the FO console do an automatic re-sync ever?

Is there a way of actually forcing a re-sync on the 1081 without taking out the USB/batteries, thus being able to keep the memory contents?

On the subject of cumulus alarms, there is a definate correspondence on my PC running Vista between some "station doesn't seem to be responding" alarms on cumulus and my free AVG doing a weekly (night-time) scan, even though the AVG is set to use minimum resources during the scan.

Dave

[KarlS]

The "lost contact" problem is definitively on the console side. I use a Raspberry Pi and RFM01 receiver module to read the TX data, and while the console reports “lost contact”, the Raspberry happily records a new data packet every 48 seconds.

[AllyCat]

Hi Dave,

Very strange that the system recovers after a number of hours in the lost sensor contact alarm condition.

Does the FO console do an automatic re-sync ever?

Is there a way of actually forcing a re-sync on the 1081 without taking out the USB/batteries, thus being able to keep the memory contents?

Both the Console and Transmitter use "Watch Crystals" which should be accurate to better than a second per day. Therefore, "drift" of the timing shouldn't be a problem even if "contact" is lost for many hours.

The 308x (Solar, non-touchscreen) models can be instructed to resynchronise by pressing the <down arrow> button, but I don't know of any way of doing it on any of the touchscreen versions. Similarly, I don't believe that any of the models automatically resynchronise, despite this extract from page 4 of the 3080 User manual:

"RF (Radio Frequency) Receiving Mode
1. After power-on, the weather station enters RF receiving state for 144s.
2. Base station receive the temperature, humidity, wind speed and rain data each
48s, receive illuminance date each 60s. If there is no new effective signal from
the sensor in constance receiption failure 8 times, the outdoor temperature and
humidity will display “----”. The base station will start search the new remote sensor
signal for 144s.
3. Hold the “▼” key for 4s to enter manual RF receiving state.."

On occasions, I've reset/resynchronised the Console without the data log being erased (I think by very briefly interrupting the power). However, the "data pointer" was then incorrect (the console memory is arranged as a circular buffer), so it needed a tedious comparison with previously logged data to recover any additional data.

The radio receiver is very low-cost (at least in the 434 MHz OOK versions), so it's probably responsible for most of the "lost contacts". Perhaps you have some "out of band" interference that your monitor doesn't hear. And have you seen the "antenna" (red wire) in a typical console?

Cheers, Alan.

[jim-easterbrook]

Both the Console and Transmitter use "Watch Crystals" which should be accurate to better than a second per day.

My measurements of drift vs network time (NTP) show both console and transmitter drift by 1 to 3 seconds per day, depending on temperature.

[Dave Walker]

I rather suspected that the console may be more likely the guilty party rather than the transmitter.
If the receiver is so simple then it's selectivity (rejection of unwanted frequencies) is probably not very good. Having said that, the only other things in the house are wi-fi and DECT cordless phone which are so far away from the 433Mhz band that the console receiver would need to be 'wide open' to be hearing them I think.

If there is a drift of 1 to 3 secs due to temperature on both Tx and Console (and given that they are not at the same temperature of course) could that not occasionally cause loss of contact, since the receiver appears to be switched on for no more that about 2 secs?

[jim-easterbrook]

If there is a drift of 1 to 3 secs due to temperature on both Tx and Console (and given that they are not at the same temperature of course) could that not occasionally cause loss of contact, since the receiver appears to be switched on for no more that about 2 secs?

I shouldn't think so. It's not a step change, and I expect the console updates its "expected arrival of next reading" time each time it receives one, so it should follow the drift OK.

[AllyCat]

Hi Jim,

Yes, perhaps I should have said "could" not "should"; I'd overlooked that we're discussing a FO product.

However, my own Console is currently only 100 seconds "slow", yet the clock/date hasn't been adjusted for at least 200 days. I know that to be the case, because I haven't adjusted it since the FO software decided that 2013 is a leap year (so the date is still one day out).

@Dave: Yes, I guess the "Reception Window" might eventually drift out of range after perhaps half or one day of continuous lost contacts. As Jim says, the software should continuously "centralise" the window when signals are being received. Of course if the Console software were really clever, it could "calibrate" its own clock against the received signal.

FO-Leap Year.jpg

Cheers, Alan.

[Dave Walker]

OK. Thanks Alan and Jim for all the info which further helps in understanding what is going on.

The fact that the FO software thinks 2013 was a leap year tells a lot about the rest of it I think

I've had no loss of sensor contact now for about 10 days bit I'm sure that it will pop up again in due course. If I glean any further clues I'll post on the forum.

Cheers

Dave

[MartinHJ]

I would agree with some of the other posts in this thread that it is the console that is the problem with lost sensor contacts.

I have two fine-offset consoles receiving the data from my single outdoor station and when one console was showing "--" for some of the values on the display (indicating and coupled with cumulus reporting lost sensor contact) the other would show a full display (and vice versa)!

My second console was a replacement for the first having had so much trouble. I did look at the wire antenna and trimmed it down slightly to a proper fraction of a wavelength which helped on that console but positioning is still key.

I ended up with my console that is connected to the PC connected by a screened USB lead (with ferrites built in) and an additional ferrite on there as well....cable routing away from other PC cables and also careful positioning of the console seems to make a difference. I have found a position that works and periodically I get the occasional 1 lost sensor contact reported.

On other occasions I get long periods of lost sensor contact which is because something has been knocked and moved or an object placed near the console. Re-adjusting things fixes the problem

Martin

[jefL]

Interesting this. My recently purchased N96 from Maplin initially showed lost sensor contact with no outside readings for several periods of up to three hours during the first week of use. Correspondence with Maplins help desk diagnosed a faulty transmitter. During the delay caused by arguments over the guarantee (even though it was only a month old) meant that by the time the new transmitter arrived it had settled down and hasn't missed a beat (crosses fingers) for nearly a month now.
From this thread it would appear that my problem was more likely to have been the console then.

Still, I have a spare transmitter if mine ever packs up completely.

Note to self, look out for a suitable radio receiver to listen in for transmissions to check if the fault recurs.

[AllyCat]

Hi,

From this thread it would appear that my problem was more likely to have been the console then.

Welcome to the forum. Certainly the location of the Console (specifically its internal antenna) can be very important (as with most high frequency radio systems).

Or perhaps you had an "issue" with radio interference, since the band used is very congested now.

Cheers, Alan.