Topic: Anemometer Transmitter 6332 malfunction

[jbastos]

I bought recently from a official reseller (https://www.weathershop.co.uk/)

- anemometer #6410
- transmitter #6332
- weatherlink live #6100

After only 17 days of normal use,  wind speed data received from anemometer is wrong ( 2~3 times less than real) and wind direction is always between 20 and 30 degrees

Again, without any intervention, transmitter #6332 is now sending correct wind data, but stopped sending temperature and humidity ("temp":null, "hum":null)

I stress that temperature and humidity must come from internal sensors in the transmitter, because I do not have a temperature probe nor a humidity probe...

Anyone has experienced this weird behaviour? And how to to avoid this malfunction?

 [ You are not allowed to view attachments ]

[mcrossley]

The transmitter does not have any internal sensors, you have to add them. The WLL does have internal T/H and pressure.

[jbastos]

Thanks for your answer, no internal sensors in the transmitter makes sense and indeed I could not find any reference on internal sensors in the transmitter manual.

However, during the entire interval the transmitter was send wrong wind data, it was sending coherent temperature and humidity values that I could correlate with those sent by the WLL device...

Integrity of data received by the WLL from the transmitter is guaranteed by cyclic checksum, so either the transmitter is sending data from "virtual" temperature and humidity sensors or the WLL messes with the data it receives from the transmitter before sending it to weatherlink.com...

I do not have access to the local data at the WLL (I am still working on programming a raspberryPi implementing the localAPI that will allow to have access to the data), but if indeed it is the WLL that is messing the data it can as well send wrong data locally... 

[mcrossley]

Or your were picking up another nearby transmitter from a neighbour?

You could just put Cumulus MX on your pi to do full data access using the local API until you code your own solution.

[jbastos]

Or your were picking up another nearby transmitter from a neighbour?

It is a possibility, though remote.

The transmitter is only 16 feet from the WLL while the nearest Davis station displayed in weatherlink.com is 1/2 mile away (but there could be one hidden closer).

In the past I had a La Crosse wireless station and, if I remember well, during the setup phase the transmitter had to authenticate with/be accepted by the console receiver. Are Davis devices doing the same?

If not, what happens if two transmitters use the same radio channel in the proximity of the WLL? Will the data be intermixed? It seems not to be the case because then I would see bad data mixed with good data...

[davidmc36]

There is nothing to prevent one Davis Rx from picking up from any Tx on that channel.

I have a buddy that is getting data from ISS at 900 meters so you may be surprised if the Tx were up high like his.

[mcrossley]

The receiver locks on via timing (no identity info) to the first transmitter it sees on the configured channel. If the reception is weak and it loses a few transmissions then it goes back into listening mode and repeats the process.

[johnd]

I agree 100% with Mark and others. The most likely explanation is picking up an alternative ISS or 6332 transmitter. This does sometimes seem to happen even when the signal strengths from your own transmitter and the 'intruder' are theoretically quite different. In fact, it's difficult to think of an alternative explanation for your observations.

Which transmitter ID is your 6332 on? It would be worth switching to an alternative ID, but try to keep to the lower numbers if possible (eg leave say 6-8 alone unless you have no other option.

[davidefa]

I do not have access to the local data at the WLL (I am still working on programming a raspberryPi implementing the localAPI that will allow to have access to the data), but if indeed it is the WLL that is messing the data it can as well send wrong data locally...

You can access your data on weatherlink.com  via the v2 api ( I have written a small script if needed ).
Think ( hope ) the 'lsid' could be used to identify the sensor ( if your own or from the neighbourhood )

[mcrossley]

The lsid may or may not be different in this case - afaik it's not in inherent property of the transmitter, just a unique id allocated by Davis on first detection.

[jbastos]

Marc, John, David

Thank you all for your comments, I was frying my brain with this! I am a hobbyist familiar with the #7911 and #7410 Davis anemometers but no previous experience with Davis transmitters and receivers because I use my own custom data logger.

This time only I installed a weather station for a commercial client so I decided to go for the complete "professional" Davis version... I was feeling very embarrassed when the whole thing stopped working correctly after a few days!

I was inclined to believe there was something wrong in the electronics of the transmitter not getting enough power/voltage to correctly power the anemometer interface but still enough to send the data to the WLL...I am now completely convinced with your explanation why I was getting good temp and humidity values when there are no internal sensors in the #6332 transmitter and I don't have those probes.

I will change the transmitter ID from 1 to 2 to get rid of the "rogue" transmitter!

Jose

[jbastos]

The lsid may or may not be different in this case - afaik it's not in inherent property of the transmitter, just a unique id allocated by Davis on first detection.

"lsid":527410

Thanks, I will start logging the lsid referencing the transmitter data to see if there is any change

[jbastos]

The lsid may or may not be different in this case - afaik it's not in inherent property of the transmitter, just a unique id allocated by Davis on first detection.

I changed channel ID of my transmitter to #2.
I confirm that a different lsid is allocated to a transmitter and remains the same even if one changes the channel ID of the transmitter...
 
Playing with adding the "intruder" transmitter (on channel ID #1) to the WLL there is something that puzzles me:

The WLL is on a local network (with private IPs) but using the WeatherLink app from the Internet I can add and delete transmitters to the WLL. How is this possible?! How can I control a device that is on a local network without having control of the router to allow port forwarding? Is Davis using some king of tunnel protocol to communicate bidirectionally with the WLL?

[Mattk]

Transmitter ID#'s are relative to the 900mhz RF band and have no connection to WiFi or the Internet IP's. Every user/station has the availability to use any of the same 8 Tx/Rx ID's

[johnd]

Is Davis using some king of tunnel protocol to communicate bidirectionally with the WLL?

Yes, presumably so. I don't know the precise technical/protocol details, but it is certainly the case that there is some mechanism by which the wl.com platform can 'talk back' to a WLL unit without port forwarding being explicitly set up and thereby alter some details of the WLL configuration. I don't think this is unique to the Davis WLL unit and presumably involves some aspect of trust for the port that WLL is using. Mark may well know better than me how this sort of interaction works in principle?

It is one of the distinguishing features of WLL that this 2-way communication is possible, and is in contrast to the Davis legacy loggers where no comms back to the logger were possible.