WXforum.net
Weather Station Hardware => Davis Instruments Weather Stations => Topic started by: openvista on January 01, 2018, 12:41:29 PM
-
Since our cold spell began on Christmas (temps mostly below 10F with periods below zero), I've noticed an increasing amount of signal drop outs on my VP2 console.
At first, it was just the anemometer transmitter (6332), but as time went on my 1 month old ISS joined the show. FYI, the anemometer transmitter is about 2 years old. Batteries in both were replaced this past Spring (I moved the battery from the old ISS to the new ISS).
I've had occasional dropouts in the past but nothing like this. However, this is the first time since putting the station in service 2.5yrs ago that we've had a stretch of such low temperatures for so long.
Initially, I thought maybe there was something about the cold that lessened the range of the transmitters. This has been discussed here before in other threads (for example: https://www.wxforum.net/index.php?topic=24871.msg239377#msg239377 (https://www.wxforum.net/index.php?topic=24871.msg239377#msg239377)). Accordingly, I moved the console to be higher and closer by about 15ft to both transmitters (ISS is ~50ft away and Anemometer is ~60ft thru 2 walls - 1 drywall and another drywall/wood/siding). Console diagnostics shows that I now average mid 40s signal strength for the anemometer and upper 50s for the ISS (out of a max of 60). When I'm free of extended dropouts, I'm consistently around 98 or 99% for packet reception. So I don't think the issue in the new location is range.
I also changed channels on both transmitters thinking, perhaps, it wasn't weather related but something to do with a new source of interference. Nope.
In my mind that leaves either the console (which isn't even 2 yrs old) or the CR123a batteries.
I noticed that this issue never occurs during bright, sunny days even when temps are in the single digits or colder. It always occurs when light is low or non-existent. So that would suggest the batteries. But if the batteries (replacement OEM Duracells) are depleted after only 8 months in cold weather, I would think the two other VP2 station owners in town (not to mention other forum members in similar or colder climates) would also be experiencing this issue.
If it's the console, why does this issue always occur at night? And why doesn't it occur simultaneously? I've never had the ISS and anemometer drop out at the same time.
None of this makes sense to me, but it has gotten so bad I've had to pull my station off my own weather site and replace it with a neighboring station (via Wunderground) at night.
When I'm feeling up to it (currently down with the flu), I will buy a couple CR123 batteries and see if that does the trick.
Thoughts?
-
I am reasonably sure that this is due to the lithium battery out in the ISS having reduced output at cold temperatures. A quick Google search will find links explaining that the batteries are at about 50% of their room temperature "performance". I am supposing this means AH capability and perhaps voltage as a consequence.
I have been seeing this behavior as well. It seems that as soon as the super-cap runs out, and the temperature is single digits °F, it will happen. I have lost comms on my long-range repeater setup as well as my ISS (this 2nd issue seems to be isolated to one older console, though).
The Texas Instruments CC1021 used by Davis has programmable power output registers. I suspect that Davis might have some preservation strategy when the battery is low that reduces power. I keep check the Low Batt indication for my repeater and other SIM transmitters, but they have not toggled status. It might be due to the time (midnight?) of reading the battery status.
Greg H.
-
Thank you for the reply, Greg.
The Wikipedia article (https://en.wikipedia.org/wiki/Lithium_battery (https://en.wikipedia.org/wiki/Lithium_battery)) on the battery chemistry (actually called a "lithium metal" battery as distinguished from a "lithium ion" battery), shows that it's supposed to have an operational range down to -30C. But, as you say, output in all batteries reduces as temperatures plunge below freezing. So even if there is some kind of output at -30C (-22F), it's probably not enough to power the ISS transmitter. From experience, it would seem the threshold for the ISS is higher. -15C (+5F) or colder for several hours would seem to be a safe, if somewhat rough, set of conditions necessary to produce these drop outs. The colder it gets and the longer the conditions persist, the more frequent are the drop outs.
But that begs the question, if this is true, why isn't this discussed more frequently on this forum? Officially, the VP2 is advertised as operating in temperatures down to -40C (-40F). I recall thread(s) complaining about that particular specification being unrealistically warm for station owners in northern locations (northern Scandinavia, much of Canada, Alaska, ND, MN, ME, etc) and many believed that Davis should produce a product specifically for these climates. Others countered that no company could be reasonably expected to do so as the cost would be too high. I do not recall anyone in those discussions saying, essentially: "-40C? Ha! Try operating these stations consistently below -15C and see what happens!"
I guess I'm at a loss to explain something that would seem to expose Davis to class-action litigation. I'm sure I don't have to explain how much of the globe gets and stays below -15C for stretches every winter. And yet, I can find no other reasonable hypothesis at the moment.
-
I can't fault Davis for the known behavior of batteries. They specified the best available type.
If there is a better low temperature battery that fits the CR123 form factor, I would be interested in learning about it.
I am considering installing a 5V regulator for the repeater, since I already have 15VDC out there for my preamplifier. I am not going up there is this weather, though! :shock:
Greg H.
-
If, indeed, the wireless SIM cannot reliably transmit below about 10F, I would certainly fault Davis.
Real-world performance data of a proprietary device cannot be replaced by a handful of anonymous screen names on an internet forum making opposite, anecdotal claims or the results of a Google search for "lithium battery output in cold weather conditions". Davis alone has the information we seek, either way.
That is unless we believe that in the decade or so Davis has been selling wireless VP2s worldwide, they wouldn't have collected enough support inquiries to know if there's a transmission problem with those units. Extremely improbable. And yet that apparently hasn't stopped them from continuing to market it down to -40C has it?
Bottom line: if I had access to reliable information in 2015 that the station would start dropping offline below 10F, I would have purchased a wired version when I moved to this location at that time. Instead, since that time, I've purchased an additional wireless console and two wireless transmitters. And now I should just pony up for a wired console and 2 wired SIMs?
-
When I'm feeling up to it (currently down with the flu), I will buy a couple CR123 batteries and see if that does the trick.
Thoughts?
My thought is to get plenty of rest and drink lots of fluids. :-)
For your station, if you have a long enough extension cord, you can try powering the ISS with the power adapter you have for your console for a cold night or so, then if the problem persists it's likely more than just a battery problem.
For what it's worth, I have an original VP and live in a cold climate (-41.5 F was the low last year, and the VP did record it, despite -40 being the advertised lower limit), and don't seem to have cold related dropouts. However my ISS is less than 100 feet from the house, no metal or other major obstructions between the console and ISS, and a fairly rural area; so my signal could probably be somewhat weakened and I might not notice, even given the lesser range of the original VP.
-
I can't fault Davis for the known behavior of batteries. They specified the best available type.
If there is a better low temperature battery that fits the CR123 form factor, I would be interested in learning about it.
If I understand how the ISS operates correctly, it only transmits a few times per minute. Couldn't it trickle charge the supercap from the battery and the use the supercap to power the transmission? I'm sure there is a tradeoff involved as there always is in life and physics, but might it be worth it?
-
I can't fault Davis for the known behavior of batteries. They specified the best available type.
If there is a better low temperature battery that fits the CR123 form factor, I would be interested in learning about it.
If I understand how the ISS operates correctly, it only transmits a few times per minute. Couldn't it trickle charge the supercap from the battery and the use the supercap to power the transmission? I'm sure there is a tradeoff involved as there always is in life and physics, but might it be worth it?
I am almost certain that the super-cap runs the system until it is discharged. Then the battery takes over. I am not sure what you would gain by recharging the super-cap from the battery. I haven't reverse engineered the SIM transmitters, but I would guess that there is some diode steering that feeds the higher of the supplies (battery, super-cap & solar) to the circuitry.
The ISS (and Anemometer Transmitter) transmit wind data every 2.5 seconds. The other data is on a more leisurely schedule.
Greg H.
-
I am not sure what you would gain by recharging the super-cap from the battery.
You would gain having a lower current demand on the battery, which may increase the ability of the station to transmit in cold weather (depending on other system characteristics). Instantaneously drawing the energy necessary for a transmission directly from the battery requires far more power than drawing that same energy over a period of time and banking it in the supercap.
-
OK, I have just replaced the battery in the ISS. The old one tested at 2.98V after about 20 minutes inside. New CR123a battery tested at 3.22V. That's not much drain. Replacement would seem like a long shot.
I'll wait to replace the wind transmitter battery until I'm feeling better and the weather cooperates.
-
A timely thread indeed. Had a few dropouts with the recent subzero weather. I have 2 VP2 consoles and 1 Vue console. Both VP2 consoles had dropouts but not the Vue which was located further away and upstairs from the ISS. My (totally unscientific, unproven...etc) theory is that is that the (extreme) cold must affect the ISS transmission output signal strength, and the Vue console is a more sensitive receiver. Again, just my own theory. Counting the days 'til Spring. ;)
-
.... The old one tested at 2.98V after about 20 minutes inside. New CR123a battery tested at 3.22V. That's not much drain. Replacement would seem like a long shot.
Tested at 2.98V, then with a load would be close to be considered flat.
-
Tested at 2.98V, then with a load would be close to be considered flat.
Well, if the battery is flat at 2.98V at room temperature, then how does the SIM function when it's well below freezing and the battery can only produce some fraction of its rated power due to physical limitations? Seems a fresh battery would be insufficient.
-
Anyone know the exact voltage when Davis sends a "LOW" signal over the loop?
-
Tested at 2.98V, then with a load would be close to be considered flat.
Well, if the battery is flat at 2.98V at room temperature, then how does the SIM function when it's well below freezing and the battery can only produce some fraction of its rated power due to physical limitations? Seems a fresh battery would be insufficient.
It probably doesn't function real well at all. 2.85v is considered flat for a CR123a, 2.75v is considered totally dead
-
OK the battery I pulled out has an imprint on it that says "2010/04". Can I reasonably assume that's the manufacture date? I know the "guaranteed fresh" date is March 2019 which is not very far out. So, apparently, this battery, although purchased new and installed in April 2017, was sitting on a shelf somewhere for quite awhile.
The new Energizer I put in has a "07/17a" imprint and an expiration of 12/27. Get 'em while they're fresh, right?
I'll know whether the battery change corrects the dropouts as we have another blast of cold air coming with at least one night expected to get below 0F.
-
Anyone know the exact voltage when Davis sends a "LOW" signal over the loop?
A few years back I ran this test. This is when my Temp/Hum station was battery only before I added the solar panel. (they ship with solar these days)
"Flash" refers to the diagnostic LED. (which was normally kept off of course)
3.28 New
3.02 Run
2.87 OK
2.85 LOW
2.70 Flash-No Data
2.48 No Flashing
Has anyone had better results with more Farads in the super-cap for this? I wonder if more "F" would keep it going all night...
Greg H.
-
Anyone have an old ISS and really cold weather who's willing to test an RCR123A instead of a CR123A? The RCR123A is the same size but 3.7V instead of 3.0V. Even though rechargeables tend to perform more poorly in the cold capacity-wise, perhaps the higher nominal voltage would be enough to keep the ISS working at lower temps. Data for battery performance at temperature below -40° is hard to come by, but if the ISS can handle 3.7V (3.7V nominal, up to 4.2V fully charged no load) during warm weather I suspect the RCR123A would only sag to around 3.0V in extreme cold.
-
I've got an old SIM and an old 24hr FARS but not a spare console. Afraid I can't run that experiment.
Incidentally, I ordered a battery tester that will place the CR123a under load. The Davis voltage figures that Greg posted earlier, of course, are all determined under load. Simply putting a battery on a multimeter may return a deceiving value. So I should have a better idea of the health of the battery I removed yesterday by early next week (8th or 9th).
-
Even my $4 Harbor Freight multimeter puts a small load on batteries to test their "real" voltage.
-
Sure so does mine (so does holding a battery between your fingers), but does that load approach the nominal load the battery would be under in the SIM?
Here's a DIY version of what I'm talking: http://www.instructables.com/id/Add-Battery-Test-to-a-Multimeter/ (http://www.instructables.com/id/Add-Battery-Test-to-a-Multimeter/)
-
I'm using the Surefire 123A with success down to -36 last winter. This year between 12AM New Years and 9 am it was in the -25F range. Surefire claims batteries working range -76º to 176º F.
I did put new batteries in the night I knew it was going to get real cold.
-
The Sure Fire has 1550 mAH and is for "high drain devices". This should give it a better starting point vs. the temperature de-rating. I am going to order some.
Greg H.
-
At -37F is where it dropped out last winter so insulated the ISS this year just in case it went that low again.
-
If there's a Lowe's nearby, Greg, they have them. $5 for 2 pack (which is half the price of Duracell). I believe I may give them a try too.
Thanks, Randy, for the suggestion.
-
Surefire claims batteries working range -76º to 176º F.
Do they specify what "working range" means, like how many volts and how many mAh capacity at -76°F? I can't find specifications on their battery.
-
Welcome, I think it should fix the cold weather issues for most part. Amazon has them box of 12 for $20.
https://www.amazon.com/gp/product/B0035HB694/ref=od_aui_detailpages00?ie=UTF8&psc=1
-
I ordered them from Battery Junction. batteryjunction.com (http://batteryjunction.com) I needed some other batteries as well.
Greg H.
-
Thanks, Randy, for the suggestion.
Ditto this! \:D/
Greg H.
-
I don't like ordering batteries online because you never know how old they will be. These batteries lose approx 5% charge per year on a shelf (marketing claims to the contrary I have a hard time believing).
How I got into this mess (potentially, yet to be confirmed) is I ordered from a trusted weather retailer and I didn't really pay attention to the expiration date on the package. It was a few years out so no big deal, right? Well, it was 7 years old (approx 35% discharged) by the time I popped it into my ISS.
It's a crap shoot online. I like to walk into the store and see the dates on the packages.
-
I just inserted a new SureFire CR123a battery in both transmitters.
Temp was 9F and falling. Tomorrow's forecasted high is 7 and Friday's high is 3 with below zero temps possible both nights and Saturday won't leave the single digits. The old batteries would have conked out multiple times during a stretch like that. We'll see...
-
That didn't take long!
The anemometer 6332 transmitter dropped out 3 times last night starting around 8PM (just for a moment), again at ~12:30AM (just for a moment) and it disconnected completely from the console (with the dreaded dashes appearing in the wind field) at ~6:30AM lasting almost an hour until I put the console in setup mode.
The ISS seems to have had no issues.
Anybody have experience with anny transmitter drop outs during cold weather? This thing is barely 2 years old and hasn't given me any other trouble.
-
When I purchased my original anny transmitter, it immediately had issues keeping a connection with the console. After trying everything I could I contacted Davis and they had me send it back and sent me a new one. Upon arrival the new one worked great, and has had no issues for over 2 years now here in our harsh winter climate in western Maine.
It's usually a last resort option, but maybe give Davis a call or send them an email to see what they say. They should walk you through the process of how to figure out what's up.
Best of luck!
- Matt
-
Agree it could just be a bad unit, In the meantime I would relocate console and maybe boost strength.
-
Something else to try change transmitter on wind Iss to #6. Why because it works well for me. :lol:
-
It's on channel 8 (ISS is on 6). Previously it was on 2. Same diagnostic performance on either channel. Doesn't look to be an interference issue.
I've already relocated console to an optimum position where signal strength (RSSI) averages mid to upper 40s (out of 60) and packet completion (when its not super cold and drop outs occur) is 98% or 99%. I can't get it better than that. I've walked around with the console enough to know.
I don't believe it's a weak signal. It's something to do with sustained, extreme cold that shuts down the transmitter.
-
Anybody have experience with anny transmitter drop outs during cold weather?
Both of mine are fine. (currently 0°F here)
Greg H.
-
I don't believe it's a weak signal. It's something to do with sustained, extreme cold that shuts down the transmitter.
Bad transmitter could be solder losing contact somewhere when the cold restricts it slightly.
-
That’s what I’m thinking it is. We’ve been -15F to -25F since Christmas nearly each night here with no transmission issues so far. The station should have no issues under these conditions until the battery becomes worn out and you have a lack of sunlight due to shorter days/lower sun angle.
Even then, based off of your description I would agree with ValentineWeather that it’s probably a bad connection being amplified to the point of lost connection during cold temps.
-
Thanks everyone for the input.
Is it possible to use a spare ISS as a wind transmitter? I think I remember reading you can't do that, but just asking because I do have a spare ISS.
-
All the field ISS's are the same and will work. The restriction is with the console only using 1 as the primary station.
Primary is the only one you can plug rain gauge and solar/UV stuff into. Wind can use seperate ISS as long as its programmed on console like you've done.
-
If you have a spare ISS I'd say definitely try it out when you get a chance. At the very least if you notice it working well, it will point you towards knowing that the issue is in fact with your other ISS/anemometer transmitter and not with the console itself, even though we are pretty sure that isn't the case already. But it's always good to be sure.
Are you seeing dropouts with the ISS and anny transmitter, or just the anny transmitter now that batteries have been replaced in both. I would have a hard time believing you have two bad transmitters, but one is very believable. If its both, than testing things out with your spare ISS may lead you into the direction of believing that its actually not an issue with the transmitters but rather that there is in fact a reception issue with the console itself if you still see reception problems on your console with that ISS in use.
-
Looks like maybe Sunday or Monday will be my first shot at decent weather to perform "pole surgery". Bitter cold and blowing snow until then. Gotta take my gloves off to deal with the nuts/washers/locks. If they fall in the snow, they'll be there until spring as the drifts out there are no joke!
Also, I found out the fancy battery tester will be here Saturday, so I'll post back this weekend about the batteries I took out of each transmitter and their true state (after ~8 months of usage).
In the meantime, if anyone has anything new to share, please do. Thanks!
-
Are you seeing dropouts with the ISS and anny transmitter, or just the anny transmitter now that batteries have been replaced in both.
Since replacing both batteries yesterday, only the anemometer transmitter has dropped out. I'll post back if that changes.
-
Okay then that leads me to believe its most likely an issue with the anny transmitter itself.
You're doing everything right by trying all different options first. I would say do just that, give it a bit more time (at the same time while waiting for the weather to improve a bit so you can get out there!), and if you see solid transmission between the ISS and the console still, but continue to have issue with the anny transmitter, then definitely contact Davis about the issue, and let them know about all the diagnostic steps you've already taken on your own to try to resolve the problem, and they will be able to help you out from there.
-
ISS dropped out this morning for about half an hour until I threw the console in setup mode to re-establish connection. So both transmitters are acting up again.
What I don't understand is that before replacing the battery in the ISS, I was seeing half a dozen drop outs a day. This one waited 36 hours to manifest. Very weird. If it were the console, the pattern should have just continued on like normal. There's been no improvement in the weather. Also, if it were the console, I would think there would be as many drop outs during the day (relative to its 9 hr length) as there are at night. As it stands, I've only ever seen a couple drop outs during the day and that's on the anemometer, never on the ISS.
Going back to what we know: there's a correlation with temperature and transmission loss. But others in similar or worse conditions aren't necessarily seeing this. And the battery change produced an improvement (for the ISS) but not a total fix.
What if I order a Vue console to see if that can hold onto both signals? Are there any drawbacks to using that device like less frequent update intervals or any kind of gotchas compared to the VP2 console?
-
I use the Vue as my primary because it has altimeter correction. My VP2 console is in the bedroom used just for visual. Vue works just like VP2 for separate wind transmitter.
The downside is no UV/solar or additional sensor support like soil/leaf.
-
I use the Vue as my primary because it has altimeter correction. My VP2 console is in the bedroom used just for visual. Vue works just like VP2 for separate wind transmitter.
The downside is no UV/solar or additional sensor support like soil/leaf.
Don't care about the other sensors as long as I can put both wind and ISS on it.
-
Is anyone getting a "low battery" status on their problem transmitters associated with this low temperature issue? I am not, I keep checking and the batteries always come back as "OK" on the Weatherlink Alarm and Battery Status screen.
Greg H.
-
Something about this issue doesn't sit right with me. I have a hunch there's nothing "wrong" with my console other than it's reception is finicky under certain environmental conditions. If so that's design error considering the stated range of 200 to 400' through walls. I'm, at most, 60' feet through walls from either transmitter and I've got above average to perfect RSSI numbers on both. .
Having read through other threads on this issue, console reception in cold weather appears to be luck of the draw. Sometimes moving the console closer or further away or putting it higher or lower helps. Sometimes not. Notice the pattern? There is no pattern. The fact that a treasure hunt is even necessary to get a ~$300, 2 year old weather station console working simply because it got cold outside is beyond ridiculous to me.
Maybe I'm surly because in the last year while troubleshooting problems with my VP2 I've had to replace: multiple batteries (SIM, 6332, FARS), FARS fan, ISS transmitter, temp/humidity sensor suite, radiation shield, anemometer bearing, and now a console. So basically, I've got 2 weather stations, but I purchased in the most expensive way possible. Most of the equipment I replaced was well inside it's maintenance cycle or expected lifetime, and should NOT have needed replacement. Either I'm one unlucky dude or quality control at Davis is sorely lacking.
During this period, I contacted Davis support about an issue I discovered in the console firmware (that temperature offsets are not reflected in relative humidity or any derived variable using relative humidity such as dew point). They deftly and repeatedly kept stepping around the issue until, essentially, I forced the director of support to admit it (maybe a dozen emails later). And now you know why I don't want to contact Davis support. I don't trust them. I'd bet high that they know about this cold weather reception issue (with a separate issue being, perhaps, their insufficient OEM battery) but will lead people who contact support on a wild goose chase nonetheless. I don't need to have my time wasted too.
In any event, I've ordered a Vue console because they've got me by the short hairs. My website gets hundreds of visits per day and I've got hard core regulars who depend on it. I can't have the temperature reading "0" and the humidity "NaN" and so forth for extended periods.
You can bet that if this pattern continues, though, my next call won't be to Davis but to R.M. Young in Traverse City, Mich. They don't sell toys that break over there.
-
Just wondering -- is there any other electronic equipment that is placed near the console?
[Probably not, but it's worth asking]
-
I've tried it both ways - by itself and near other electronics. Either way, you get drop outs.
I've actually tried about 6 different spots in 2 different rooms while hunting for a trouble free zone.
The dropouts happen regardless of channel too. So if it were something in the room it would need to be broad spectrum 900mhz interference mostly during sleeping hours that only occurs when the outside temp is below 10F. Keep in mind, the reception strength is solid regardless of temperature. I've watched a drop out happen live on the console in statistical mode and saw the signal strength go from 59 (out of 60) to nothing when packets started dropping one after another. That's why initially it seemed the transmitter battery was the most likely culprit.
-
Here are a couple questions I don't think have been asked previously in this thread:
- You indicate you have data dropouts on your console. Does this include seeing the same data missing from your data feeds to your website?
- I am still not convinced you aren't having some kind of interference issue. Are there any other Davis weather stations in your neighborhood or that are being received by your console? Have you checked your console, in setup mode, to ensure that you don't have any other ISS's or Anemometers transmitting on the same channels you are trying to use? To test for the presence of any other transmitters in your area you MUST turn-off all of your ISS and Anemometer transmitters. Assuming you have all of your receiving channels turned-on, to begin this test, let the console run for several minutes to see if it detects any transmitters on any channel. If any transmitters are detected, make certain that specific channel is turned-off and that you do not use that channel for either your ISS or Anemometer. If they are, pick other channels to use. Refer to your VP2 Console Manual for instructions on how to use Setup Mode.
I had an issue some years ago where a neighbor installed a VP2 about 500 feet away from me. Suddenly, I began getting intermittent data being uploaded to my website. After some sleuthing, I discovered there was another VP2 signal being received on the same channel I was using. The data failure was not consistent but rather very intermittent. Once I discovered the second VP2 data signal, I merely changed channels and the issue disappeared. To minimize any other issues, I also disabled all other channels on the console so I was only open to receiving signals from my own ISS.
-
Here are a couple questions I don't think have been asked previously in this thread:
- You indicate you have data dropouts on your console. Does this include seeing the same data missing from your data feeds to your website?
- I am still not convinced you aren't having some kind of interference issue. Are there any other Davis weather stations in your neighborhood or that are being received by your console? Have you checked your console, in setup mode, to ensure that you don't have any other ISS's or Anemometers transmitting on the same channels you are trying to use? To test for the presence of any other transmitters in your area you MUST turn-off all of your ISS and Anemometer transmitters. Assuming you have all of your receiving channels turned-on, to begin this test, let the console run for several minutes to see if it detects any transmitters on any channel. If any transmitters are detected, make certain that specific channel is turned-off and that you do not use that channel for either your ISS or Anemometer. If they are, pick other channels to use. Refer to your VP2 Console Manual for instructions on how to use Setup Mode.
Yes, the data goes missing everywhere since the console has either no temp/humidity or wind data to transmit to my weather software (WeatherCat). The wind is particularly troublesome because as soon as it blinks it torches my 10 minute average which is what appears on the site for "wind". It reads 0 and the wind chill then equals the temperature for at least the next 5 minutes while the software computes the new average.
As for interference, I am not aware of any new stations in the area. There have always been 2 stations within about a mile or so since I've lived here. They've never presented problems. Although, just to be safe I don't use channel 1 on the ISS as it's the default and most likely used by either or both stations. While I have not tried turning both transmitters off, I have watched the console poll for all available stations and it only ever presents my station IDs. Keep in mind, I've tried 6 of the 8 channels while trying to solve this issue. So if other channels were occupied, I'd expect for them to have appeared in my console at some point while configuring the new channels.
I'll grant you that it has the appearance of an interference issue, but given what I've tried, for the issue to be interference it would have to be broad in spectrum, confined mostly to nighttime hours and particular temperatures (even if those temperatures occur during the daytime).
My working hypothesis at the moment is the console receiver is a bit flaky due to either design error (which is perhaps why others experience this sometimes too) or by malfunction (maybe both). Regardless, given the lower power output from the batteries in cold conditions, the issue surfaces once the transmitters have drained the supercap. During the day, the transmitters have full output because the solar panels keep the supercap going. Could be wrong and will know once the new console arrives. If so, then I will turn off both transmitters and precede as you suggested.
Appreciate the reply.
-
Regardless, given the lower power output from the batteries in cold conditions, the issue surfaces once the transmitters have drained the supercap. During the day, the transmitters have full output because the solar panels keep the supercap going.
Are you unable to temporarily power your ISS with the power adapter to see if the problem persists?
-
Couple of quick comments:
It always used to be the case that the channels were not created equal and that eg high channels like 8 were at least a little more prone to drop out and then took longer to resynch when they did. I don't know whether this was fixable in firmware and if any improvement was ever made. So I'd always try using the lowest channel number that you think may be free from potential interference. MAy well not cure the problem but may ameliorate it.
Second: Don't forget that the ISS SIM board has a jack via which the board can be powered via an (up to) 5v supply. So you could envisage using an external battery box fitted with some cells of a suitable size and chemistry that can deliver eg 3.5-4.0v (or even slightly more) even in very cold conditions, but don't over-volt in more comfortable temperatures. OK still a small project to develop and build but not too tricky and might be a fall-back option.
-
Second: Don't forget that the ISS SIM board has a jack via which the board can be powered via an (up to) 5v supply. So you could envisage using an external battery box fitted with some cells of a suitable size and chemistry that can deliver eg 3.5-4.0v (or even slightly more) even in very cold conditions, but don't over-volt in more comfortable temperatures. OK still a small project to develop and build but not too tricky and might be a fall-back option.
My understanding was that it was designed to be powered by the typical Davis power supply that the console uses. Is that incorrect?
-
My understanding was that it was designed to be powered by the typical Davis power supply that the console uses. Is that incorrect?
No, um, did I imply something different? :? The standard console supply is 5v and so anything up to 5v should be OK, but just thinking that an external battery pack might well use eg 3 cells and so around 4v (depending on the type/chemistry of the cells) in the cold might be what you'd expect. But given that the CR123 is a 3v battery then anything above that ought to give some extra margin.
-
No, um, did I imply something different? :?
No,um, I guess not. :? Just wanted to make sure I wasn't giving bad advice. Sounded like you were suggesting something more complicated than what someone may want to do as just a temporary test to try to verify the problem.
-
No,um, I guess not. :? Just wanted to make sure I wasn't giving bad advice. Sounded like you were suggesting something more complicated than what someone may want to do as just a temporary test to try to verify the problem.
No, your advice is good. But I was just thinking that the ISS might well be way beyond a convenient distance for a cabled power supply, so the battery idea was perhaps more general-purpose. But, sure, if it's feasible then a mains supply either as a temporary test or a long-term solution sounds good. (Ah, I hadn't seen your post before posting mine, so no attempt to supersede yours ;) )
-
johnd and snowhiker, thanks for the suggestions.
Not sure that adapter is made to withstand these kinds of conditions. Is it water tight and rated for at least -15C temps? We're in day 3 of 4 days straight of horizontal snow (30mph+ winds) and -15 to -20C weather. Anything that I put out there is going to get slammed.
We don't have anything that passes for an electronics part store in town (RIP Radio Shack). So I don't have the ability to go out and procure battery packs, other DC adapters and such. Everything I have on hand is for indoor use only.
-
No, your advice is good. But I was just thinking that the ISS might well be way beyond a convenient distance for a cabled power supply, so the battery idea was perhaps more general-purpose. But, sure, if it's feasible then a mains supply either as a temporary test or a long-term solution sounds good. (Ah, I hadn't seen your post before posting mine, so no attempt to supersede yours ;) )
No problem, makes sense! :grin: I had also asked many posts and/or days ago if it might be convenient to run an extension cord to test for a night or so. The lack of any response added to my paranoia that maybe my advice was off to begin with. :-)johnd and snowhiker, thanks for the suggestions.
Not sure that adapter is made to withstand these kinds of conditions. Is it water tight and rated for at least -15C temps? We're in day 3 of 4 days straight of horizontal snow (30mph+ winds) and -15 to -20C weather. Anything that I put out there is going to get slammed.
We don't have anything that passes for an electronics part store in town (RIP Radio Shack). So I don't have the ability to go out and procure battery packs, other DC adapters and such. Everything I have on hand is for indoor use only.
Myself, I would risk it for a night, at least, and wrap the adapter in plastic or something and keep it off the ground. At those temperatures the precip shouldn't melt and get things too wet. I don't believe the power supply should be affected much by the cold, it will continue to provide more than adequate voltage. I assume your outdoor outlets are GFI.
However, I'll add the legal type of disclaimer that I'm not responsible for damage if you follow my advice. ;)
-
Just repeating because we are several pages into this thread and some may have missed/forgotten it: I have a brand new ISS transmitter (30 days old). The likelihood that it along with my 2 yr old wind transmitter are both malfunctioning in the same fashion, under the same conditions and in the same general timeline is hard for me to accept.
I have changed xmtr batteries, frequencies (3 separate times starting with channels 1 and 2) and moved the console to several locations in search of the best reception (both xmtrs are currently averaging 45 RSSI or above). Still the dropouts persist (although admittedly less often in the ISS).
I think the best course of action is to await the arrival of the new Vue console next week. If the issue persists with a new console, then perhaps, with help, I can create some kind of MacGuyver-like device to power the anemometer transmitter (which is the most frequent offender at this point).
-
Couple of quick comments:
It always used to be the case that the channels were not created equal and that eg high channels like 8 were at least a little more prone to drop out and then took longer to resynch when they did. I don't know whether this was fixable in firmware and if any improvement was ever made. So I'd always try using the lowest channel number that you think may be free from potential interference. MAy well not cure the problem but may ameliorate it.
Second: Don't forget that the ISS SIM board has a jack via which the board can be powered via an (up to) 5v supply. So you could envisage using an external battery box fitted with some cells of a suitable size and chemistry that can deliver eg 3.5-4.0v (or even slightly more) even in very cold conditions, but don't over-volt in more comfortable temperatures. OK still a small project to develop and build but not too tricky and might be a fall-back option.
Excellent suggestion for applications where 110VAC FARS fan is already being used...
-
Re the voltage via the DC input jack on most Davis boards (ISS, Envoy/console, other transmitters etc) the nominal voltage is ideal in the 4-5 volt range but keep in mind the Davis solar kits runs around 6.8 volt and this causes no issues and one reason there is a 7v upper voltage clamp on the power jack. Also for this reason the input voltage is dropped by 0.7v via protection diode before the voltage regulators which makes the final lower voltage above 3 volts (3.3v for the IP logger) hence minimum voltage to keep an IP logger operational is 4+ volts
-
Re the voltage via the DC input jack on most Davis boards (ISS, Envoy/console, other transmitters etc) the nominal voltage is ideal in the 4-5 volt range but keep in mind the Davis solar kits runs around 6.8 volt and this causes no issues and one reason there is a 7v upper voltage clamp on the power jack. Also for this reason the input voltage is dropped by 0.7v via protection diode before the voltage regulators which makes the final lower voltage above 3 volts (3.3v for the IP logger) hence minimum voltage to keep an IP logger operational is 4+ volts
Good info, thanks. As the upper limit was said to 5VDC was one reason I wanted to verify with John that the standard Davis supply was okay, I was pretty sure that it had a nominal output of 5V, but often power supplies output are a few percent higher, depending on load. So you've further set my mind at ease that Davis isn't encouraging users to blow up the ISS by giving them adapters that will fit the jack but have too high voltage. :grin:
-
Just one more comment from me and then I'll shut-up and wait for the results with the new console.
I don't know about the Vue console and how it works but, the standard VP2 console has the ability to turn-off (disable) individual receiver channels. As I mentioned in my reply above, I only enable the channel I want to receive my ISS data from. All other channels are disabled. This does two things - 1) It prevents any interference from potential transmitters on other channels and 2) it speeds up the recovery of your ISS signal detection should the signals be lost for some reason. The console simply goes directly to only the enabled channels to look for incoming signals thus, resulting is finding the desired channel(s) more quickly. i was told that by a Davis tech many years ago when I had my problem with a close-by interfering station.
Forgot add- you certainly have the patience of Job! Many would have given-up long before this. I wish you the best of luck in resolving your issue.
-
I don't know about the Vue console and how it works but, the standard VP2 console has the ability to turn-off (disable) individual receiver channels. As I mentioned in my reply above, I only enable the channel I want to receive my ISS data from. All other channels are disabled.
The last time I changed IDs on the transmitters I went thru every other ID and saw their status listed as "off". Not sure if that's what you're referring to or if there's another step beyond that. I didn't actually have to change anything.
Forgot add- you certainly have the patience of Job! Many would have given-up long before this.
Appreciate it! Many locals visit my site where they can get the WU and NWS forecasts side by side, snowfall totals, 3 different radars and a real local almanac. At no point are they treated like rats in a maze where if only they click 4 times they get all the cheese just so advertisers can sufficiently feast on them in the process. I'm so old I remember when site owners dealt in good faith with their audience!
-
As promised, here are the results of my test of the CR123a batteries removed from both transmitters using the ZTS multi-battery tester (see attached image). This device has two patents related to pulse loading the battery which simulates an appropriate load. It has a 5 LED scale. Each light signifies 20% capacity.
The battery taken from the ISS came back with all 5 lights lit which means, essentially, it was full. Of course it may have been somewhere between 80% and 100%, and still lit all 5 lights. On my digital multimeter it read 3.02V. This was higher than the initial reading 20 minutes after removal (2.98V). That's probably because the internal portion of the battery was still cold at that time and subsequently warmed.
The 2nd battery which was removed from the wind transmitter came back at 80% or 4 out of 5 lights. However, it too tested at 3.02V on my multi-meter. 15 minutes after removal, though, it was at 2.92V.
Either way, I'm guessing that in extreme cold the OEM batteries have to be, essentially, full strength or there will be issues when the output drops with temperature. The SureFire replacement batteries claim to operate at lower temps (-76 vs -30). Indeed, ValentineWeather has used them in temps well below zero and had no issues.
Since installing the new batteries, I certainly have had fewer dropouts with the ISS (only one so far that lasted the better part of an hour before I caught it and put console in setup). Ironically, the wind transmitter, which had the weakest battery, has not improved. I'm seeing regular dropouts on a ~5hr interval lasting anywhere from 10 minutes (most common) to half an hour or longer. It does make sense that the anemometer battery would be drained faster because that transmitter is having to do calculations every couple seconds.
Anyway, the new Vue console should be here late next week and I will post back once it's had time to establish a track record. In the meantime, if you have anything to add to the thread that will enlighten those of us who experience signal dropouts in cold weather, please do! Thanks for reading and/or contributing!
-
I suspect that it's probably possible to speculate almost ad infinitum as to possible causes in the absence of being able to get more detailed diagnostics on ISS and console circuitry, which isn't going to be possible outside of an electronics lab.
But one other possibility that occurs to me is that wireless transmitter circuitry is also, to a degree :grin:, temperature sensitive. Maybe your particular example is on the tail of acceptable tolerances and in extreme cold something about the wireless protocol (frequency lock, channel timing, whatever) goes beyond the point at which the console can hold synch and it may take quite a while to regain synch. Just possibly another console would be better matched to the idiosyncrasies of that particualr SIM board.
-
I suspect that it's probably possible to speculate almost ad infinitum as to possible causes in the absence of being able to get more detailed diagnostics on ISS and console circuitry, which isn't going to be possible outside of an electronics lab.
But one other possibility that occurs to me is that wireless transmitter circuitry is also, to a degree :grin:, temperature sensitive. Maybe your particular example is on the tail of acceptable tolerances and in extreme cold something about the wireless protocol (frequency lock, channel timing, whatever) goes beyond the point at which the console can hold synch and it may take quite a while to regain synch. Just possibly another console would be better matched to the idiosyncrasies of that particualr SIM board.
Well, according to Davis, I am well inside the operational range of both transmitters as they are rated for -40F temperatures. If that's not true, Davis needs to change their specifications and marketing materials. The coldest I've gotten is -11F, but most of my dropouts were in the single digits (+5F). So, I don't really accept the premise that I'm an edge case.
Also we are talking about two transmitters, one of them ~1 month old, that are having the same issue. Both function perfectly well above 10F. I'm hoping the Vue has a better receiver, but that wouldn't negate the real possibility that both transmitters, with identical radio circuitry, might share the same inherent, unpublished shortcomings. If I were the only one to experience these symptoms under similar conditions, perhaps I would agree something strange is going on.
-
I had this problem about two years ago. I sent console in to Davis and it was repaired (supposedly). While it was in for repairs, I used a spare Vue console to collect the data. I also like the fact that the Vue allows you to set barometer to altimeter. So, when I got the repaired VP2 console back, I basically just use it to monitor the temperature in my Brew room. Here is the link to the thread I started on this problem. http://www.wxforum.net/index.php?topic=30972.msg308465#msg308465
After reading this thread, I checked The VP2 data vs the Vue and I have had the VP2 lose connection to the ISS four times since November. The Vue, which I use to collect my data and upload to CWOP, WU, Weathercloud, etc, has never lost connection. The lowest I found was in the 70% range. If the VP2 console were to die, I wouldn't replace it except I need it for the additional temperature sensor. If this wasn't the case, I would replace with the Vue console.
I will be interested to see how your troubles get resolved. Good luck.
Mark
-
I had this problem about two years ago. I sent console in to Davis and it was repaired (supposedly). While it was in for repairs, I used a spare Vue console to collect the data. I also like the fact that the Vue allows you to set barometer to altimeter. So, when I got the repaired VP2 console back, I basically just use it to monitor the temperature in my Brew room. Here is the link to the thread I started on this problem. http://www.wxforum.net/index.php?topic=30972.msg308465#msg308465
After reading this thread, I checked The VP2 data vs the Vue and I have had the VP2 lose connection to the ISS four times since November. The Vue, which I use to collect my data and upload to CWOP, WU, Weathercloud, etc, has never lost connection. The lowest I found was in the 70% range. If the VP2 console were to die, I wouldn't replace it except I need it for the additional temperature sensor. If this wasn't the case, I would replace with the Vue console.
I will be interested to see how your troubles get resolved. Good luck.
Mark
Switching from VP2 console to Vue console solved MY mysterious "dropouts" too!
-
Thanks zackdog and Old Tele man for your first hand accounts.
If the Vue console eliminates my dropouts as well, that doesn't say anything good about Davis. Upon learning years ago that the wireless kit experiences signal lock problems in cold weather, Davis could have done one or more of the following:
1) recommended buyers purchase the wired version and change the official specifications and promotional text to reflect an operational range above 10F (-15C)
2) recommended buyers swap a VP2 console for a Vue console if they anticipate being in 10F or colder weather
3) switched out the OEM Duracell with a SureFire battery (or at least recommend them during support calls)
4) fixed the console and/or transmitters so dropouts no longer occur within the original specifications
Instead, wireless users call support and are told to send in their VP2 consoles for "repair", the pretext being there MUST be something wrong with the console (couldn't be a design error). The unit Davis returns, however, is no more able to hold onto a signal in -15C or colder weather than before. I don't recall anyone ever being offered a refund.
Perhaps support, too, has been kept in the dark. Nevertheless, someone over at Davis must have put 2 and 2 together after all these years. If not, that's worse. It suggests no one at Davis is capable of or willing to recognize patterns in support calls and/or learn from their mistakes to prevent them from appearing in subsequent designs.
-
Perhaps support, too, has been kept in the dark. Nevertheless, someone over at Davis must have put 2 and 2 together after all these years. If not, that's worse. It suggests no one at Davis is capable of or willing to recognize patterns in support calls and/or learn from their mistakes to prevent them from appearing in subsequent designs.
I can't speak to whether this is true or not at Davis, but I have worked in technology companies with known hardware flaws. I can tell you that we were not allowed to disclose that we knew the hardware was flawed. We just had to tell the customers to send it in for warranty replacement/repair. The support team and hardware team repeatedly informed management that this one component was a huge source of RMAs, but management steadfastly refused to change suppliers because the other suppliers cost a little bit more. For some unknown reason the cost of repeated warranty returns and repairs, as well as damage to the brand's reputation, did not seem to factor into management's cost-benefit calculations.
-
Perhaps support, too, has been kept in the dark. Nevertheless, someone over at Davis must have put 2 and 2 together after all these years. If not, that's worse. It suggests no one at Davis is capable of or willing to recognize patterns in support calls and/or learn from their mistakes to prevent them from appearing in subsequent designs.
I can't speak to whether this is true or not at Davis, but I have worked in technology companies with known hardware flaws. I can tell you that we were not allowed to disclose that we knew the hardware was flawed. We just had to tell the customers to send it in for warranty replacement/repair. The support team and hardware team repeatedly informed management that this one component was a huge source of RMAs, but management steadfastly refused to change suppliers because the other suppliers cost a little bit more. For some unknown reason the cost of repeated warranty returns and repairs, as well as damage to the brand's reputation, did not seem to factor into management's cost-benefit calculations.
Those of us who have spent our careers in the IT field supporting end users (guilty), have heard such war stories. That's why I don't take seriously notions that Davis has no idea of what's happening, especially considering how long this product has been on the market and how many wireless units are out in the field.
In fact, as I mentioned earlier in the thread, I've caught Davis hiding another, unrelated issue with much lower stakes. It affected fewer users, but their first instinct was to deny repeatedly until they were backed into a corner, and then act like they always knew it, and it's no big deal. The only reason I got an admission of any sort was because I confronted the director of Technical Support with hard math and wouldn't back down. If I had been a less knowledgeable user who was quarantined in first tier support, you can bet my emails would have met the delete button (and did initially, hence my detective work).
-
I found a problem too. They denied also but eventually came out with console update that fixed issue. Funny thing they never admitted in update it fixed issue but it did. The issue was running Vue console and separate wireless anemometer, the large cup setting was wrong, wind speed reported would be low compared to VP2 console.
I came across it because I run both consoles using same anemometer. Others also chimed in confirming they were seeing same issue. So make sure you have latest Vue console update using the wireless anemometer.
-
This got me thinking, maybe it is something inherent in the VP2 console. I know a lot of people that have VP2s don't use the WeatherLink software, but I always shut down my Cumulous and download to WeatherLink for my records. I decided to look back at the data from when I upgraded from the WM II to the VP2. The graphs are pretty interesting. It appears that I had a reception problem from day one when the temperatures went down, and I never realized it because I never happened to be looking at the console when it occurred. Here are two years of data graphs. It is pretty obvious that the reception goes down during the cold months.
Can you guess when I switched to the Vue console? :lol:
Mark
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
-
I think issue is real with so many here experiencing same dropout problem in very cold conditions, now getting Davis to admit near impossible because many users never experience low enough temperatures. Plus I couldn't get them to admit issue with anemometer when it was so easily replicated.
Not all VP2's have issues either, if they do it's not as noticable.
Good graph also, shows issues with cold weather for sure and its very clear when you switched to the Vue console.
-
Wow, that is pretty solid evidence that something major changed in mid-February of 2015! Now, comes the question is WeatherLink the only software that captures this info? It's been so long since I did anything with WL or VWS, I don't remember what data elements get captured from the data logger. It would be really nice to be able to see these kinds of charts with WD or some other weather software.
-
Is the solder connection to the external antenna different on the Vue console? Just wondering if there's a design difference.
-
It would be really nice to be able to see these kinds of charts with WD or some other weather software.
Here's a screenshot of the wind dropouts in WeatherCat (with temperature included for reference).
In the first image you'll notice dropouts (which are indicated by the wind speed suddenly going to 0) came about every 5 hours or so when it was below 10F. You'll notice on the 2nd image that as the temp goes above 10F, the dropouts disappear. I haven't had a dropout since the temp has stayed above 10 early yesterday morning.
Jan 5-6:
[ You are not allowed to view attachments ]
Jan 7-8:
[ You are not allowed to view attachments ]
-
...many users never experience low enough temperatures...
Not all VP2's have issues either, if they do it's not as noticable.
I agree, Randy. Most wireless users won't get or stay below 10F for long. If you aren't checking the console (or your weather software or website) often, you might not notice, especially if the cold snap is brief. Most of my wind dropouts last about 6-10 minutes. Of course, it does get worse as it gets colder in my experience. The dropouts last longer and sometimes the console won't resync without help.
Regardless, for those of us who depend on the proper functioning of our stations, it's completely unacceptable for the thing to start quitting on us at 10F (-15C) or colder.
-
Is the solder connection to the external antenna different on the Vue console? Just wondering if there's a design difference.
I have a VUE, two VP2 consoles, an Envoy8x and a regular Envoy adjacent to each other. The antennas (and the mounting) appear to be identical. If I remember correctly from when I had both a VUE and a VP2 apart, the antenna coax and connection to the PCB seemed to be the same. (I didn't have these apart side-by-side or even at the same time, and I am relying on my sometimes sketchy memory :?)
Greg H.
-
Thanks zackdog and Old Tele man for your first hand accounts.
If the Vue console eliminates my dropouts as well, that doesn't say anything good about Davis. Upon learning years ago that the wireless kit experiences signal lock problems in cold weather, Davis could have done one or more of the following:
1) recommended buyers purchase the wired version and change the official specifications and promotional text to reflect an operational range above 10F (-15C)
2) recommended buyers swap a VP2 console for a Vue console if they anticipate being in 10F or colder weather
3) switched out the OEM Duracell with a SureFire battery (or at least recommend them during support calls)
4) fixed the console and/or transmitters so dropouts no longer occur within the original specifications
Instead, wireless users call support and are told to send in their VP2 consoles for "repair", the pretext being there MUST be something wrong with the console (couldn't be a design error). The unit Davis returns, however, is no more able to hold onto a signal in -15C or colder weather than before. I don't recall anyone ever being offered a refund.
Perhaps support, too, has been kept in the dark. Nevertheless, someone over at Davis must have put 2 and 2 together after all these years. If not, that's worse. It suggests no one at Davis is capable of or willing to recognize patterns in support calls and/or learn from their mistakes to prevent them from appearing in subsequent designs.
Having worked on automotive OEM products (now retired), we had to comply with fairly strict EMC and temperature requirements. These were never tested at the same time for any of our customers, which included well-known car companies, including Japanese and Korean. At least for automotive, I never heard of a combination RF and temperature-controlled test facility. I would be interested to know if such a test facility exists.
Testing RF performance at temperature would have to be field tested at the whim of Mother Nature. I know that there are some OATS (open area test site) that could conceivably be used for this if the weather conditions are right. Being California-based, this might be a bit difficult logistically for Davis.
Greg H.
-
Testing RF performance at temperature would have to be field tested at the whim of Mother Nature. I know that there are some OATS (open area test site) that could conceivably be used for this if the weather conditions are right. Being California-based, this might be a bit difficult logistically for Davis.
That would beg the question "what was the origin of the current environmental specifications?" Their rear end?
The bottom line is Davis sold these devices with the assurance they would do well in weather down to -40F. They left it to their users to discover that the true lower limit is actually 50 degrees warmer! And you want us to absolve them because they didn't/couldn't field test their units before selling them to people in cold climates?
You do realize there are commercial freezers that can go down to -40F and beyond, right? I have a platinum RTD device made for deep freeze applications that can read down to -199F.
-
You do realize there are commercial freezers that can go down to -40F and beyond, right?
We had a temperature chamber at work when we tested our product. It could test both hot and cold at any arbitrary temperature (within the chamber's capability) with the DUT inside. The customer's spec called out -40°C, but we would frequently take it much colder in order to test to failure.
My point was that there are RF test facilities, there are temperature test facilities, but are there any that can do both at the same time, i.e. test RF at cold temperatures? I am not trying to "absolve" anyone, just pointing out that this is a difficult thing to test.
Greg H.
-
Antarctic research facilities would be ideal for frequency hopping spread spectrum transmitter and receiver testing on the warmer days, for Davis inst. above -40C. :-)
-
You do realize there are commercial freezers that can go down to -40F and beyond, right?
We had a temperature chamber at work when we tested our product. It could test both hot and cold at any arbitrary temperature (within the chamber's capability) with the DUT inside. The customer's spec called out -40°C, but we would frequently take it much colder in order to test to failure.
My point was that there are RF test facilities, there are temperature test facilities, but are there any that can do both at the same time, i.e. test RF at cold temperatures? I am not trying to "absolve" anyone, just pointing out that this is a difficult thing to test.
Greg H.
Umm, unless I'm missing something, why not just put the station (or SIM) inside the temperature chamber and then put the console some distance away in room temperature? Problem solved. Yes, it may not conform to some off-the-shelf test spec, but it would at least give them an idea of what users would experience. It would be a field test, of sorts.
-
The temperature chamber we had was stainless steel lined. (as are all that I am familiar with)
Since this is a Faraday cage basically, it's a little difficult for any signal to get out...
Greg H.
-
If it is an RF problem, why is the Vue console not affected :?:
Mark
[ You are not allowed to view attachments ]
-
Good point what I read about FHSS to work correctly both transmitter and receiver need to stay in sync or packet loss increases so lets say the VP2 console is doing more work than the Vue so its not using as much resource collecting packets because of other duties but why only when temperatures are low?
-
The temperature chamber we had was stainless steel lined. (as are all that I am familiar with)
Since this is a Faraday cage basically, it's a little difficult for any signal to get out...
Greg H.
I would think with your professional background, you would appreciate that unless you are privy to industry, company and product-specific information about various capabilities, design decisions and test facilities, some of which would be protected almost certainly by a non-disclosure agreement, playing arm chair engineer is pointless.
If Davis knew they couldn't test their claim (of wireless capability to -40F) and continued making it when it became clear over time it wasn't true, then shame on them. That's the worst possible scenario.
-
If it is an RF problem, why is the Vue console not affected :?:
There might be more than one factor in play here. Could be the SIM transmitter design is a bit finicky but compensated for by an improved or better "mated" receiver in the Vue. Could be, as Randy suggested, that the Vue isn't multitasking as much. Who knows. I doubt we'll ever know.
-
You do realize there are commercial freezers that can go down to -40F and beyond, right?
We had a temperature chamber at work when we tested our product. It could test both hot and cold at any arbitrary temperature (within the chamber's capability) with the DUT inside. The customer's spec called out -40°C, but we would frequently take it much colder in order to test to failure.
My point was that there are RF test facilities, there are temperature test facilities, but are there any that can do both at the same time, i.e. test RF at cold temperatures? I am not trying to "absolve" anyone, just pointing out that this is a difficult thing to test.
Greg H.
ALL of the automotive manufacturers have/use 'combined' Climatic-RF Anechoic chambers to test/certify (for FCC compliance) their satellite-communication (and eaves-dropoping) GPS, XM-radio, and "On-Star"-like services (and slowly inching towards ultimate "BIG BROTHER" OBD-III).
-
I am beginning to wonder if Davis actually did anything to my console for the $80 when I sent it in. Been looking back over my records since I read this thread and put together a spread sheet. I will continue to monitor both consoles, at least until May.
Mark
[ You are not allowed to view attachments ]
-
Davis probably gave it the old "once over". If pressed, I'm sure they could say the fee was for a diagnostic. Did they send an invoice with any explicit notes?
Looking at your spreadsheet I see dropouts on the VP2 console starting at +20F!
Also it seems signal quality does degrade on the Vue console as temps go lower. What is the average Vue packet completion percentage in warmer periods? 98%? 99%?
My VP2 console seems to average 98% during >10F weather (for both transmitters).
-
... playing arm chair engineer is pointless.
Maybe so, yet I find the insights, and even speculations, of men like Greg and Tele man interesting. I'm still interested in what the problem is even if there is nothing we can do about it. Even if there are controlled environmental facilities, it seems they'll still miss things that turn up in real world circumstances.
BTW, sometime ago I posted a graph of my reception with my original VP with temps approaching -40 when someone here basically told me I didn't know what I was talking about when I said it didn't seem to be much affected by temperature:
[ You are not allowed to view attachments ]
So I think my case does show a VP console can in fact operate down to -40, any quality control issues or such aside. I don't know how the fancy spread spectrum frequency hopping may change things, but I think it is a little funny that the VP2 was supposed to solve things like connection problems, but my old VP(1) seems to have less problems than many VP2s many years newer. :-)
-
Maybe so, yet I find the insights, and even speculations, of men like Greg and Tele man interesting.
As do I. I get a little irritated when speculation turns into [paraphrasing]: "well, it might not be possible for Davis to run tests on their transmitters in cold weather". Combine that with an earlier statement of: "show me a better battery form factor" (in response to a discussion about possible low OEM battery output @ <10F). Greg appears to believe if we're going to point out problems, then somehow it's our responsibility to come up with a better solution or demonstrate reliable test procedures proven to work below 10F. That's not speculation; it's a subtle shifting of responsibility onto the consumer rather than the manufacturer (who alone possesses the resources to address the issue). Now, if there's a workaround, like the Vue console, I'm all ears. But let's keep clear on who's ultimately responsible for what and what is realistically possible for the end user.
...I think it is a little funny that the VP2 was supposed to solve things like connection problems, but my old VP(1) seems to have less problems than many VP2s many years newer.
This is spot on. Unfortunately, our society has fully embraced the religion of progress. The fundamental doctrine being if its newer, smaller and easier, it must be better. Above all, you are not allowed to pine for older, more reliable technology.
-
...I think it is a little funny that the VP2 was supposed to solve things like connection problems, but my old VP(1) seems to have less problems than many VP2s many years newer.
This is spot on. ..
I don't doubt the SnowHiker's observation for a second and it may be specially pertinent to very low temperatures. But overall I'd say that VP2 is incomparably better than VP1 in terms of wireless performance. VP1 (even in revised form) always had short range, substantial problems when asked to penetrate a wall, often refused to get to 100% in reception even under favourable circumstances, many units had short streak lengths whatever you did and there always seemed to be periodic brownouts and dropouts in reception. The only favourable thing I'd say about VP1 was that supercap faults were rare, probably because of the more mechanically robust component type used.
-
The only favourable thing I'd say about VP1 was that supercap faults were rare, probably because of the more mechanically robust component type used.
Maybe I should add, that from my experience with the VP1, you can expect five years or so for the lifespan of the supercap. I just accept that as routine maintenance. I don't know how it compares to the VP2.
Another favorable thing about the VP1 is that the temp does work at least down to -40 (the lowest I've recorded was -41.5, and it didn't appear to bottom out, despite the stated specs), the new temp sensors are guaranteed to stop working at -40. Maybe a relatively minor thing, but when we get a record low I like to have some idea of what it is. But maybe getting a little off topic. :-)
-
Here was my VP2 console plot this year at -27F. Signal looked good but same day toward sunset dropped out at -5F. This is longer distance at 370' console to ISS. New surfire battery also.
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
-
Regard ISS reception I would say that nobody should ever be expecting 100%, 100% of the time and there will be spikes by the very nature of signal and hardware and there will be some spikes be hot, cold or indifferent
-
Agreed. 100% reception isn't the standard, as far as I'm concerned. In fact, I have no issue with keeping temperature and wind active on the console and in my weather software (as opposed to dashes or zeros) when diagnostics show 96-98% packet completion.
I think the issue here is resyncs -- where the console loses a connection and has to poll for minutes or hours to regain a connection -- should not correlate positively to weather that half the country gets every winter (and that's a conservative estimate assuming 10F is the line; not the 20F figure that zackdog's graphs seems to suggest).
-
Sorry, people, but equipment designed to operate at 1,000 foot distance and -40ºF should be working at those conditions...or (per FCC regulations) it's fraudulent marketing.
That being said, experience tells me that WHILE it should work per the specs, one should LIKEWISE assume 'degradation' to increase as distance "approaches" those specs...thus, everything should be 100% reception up to about 50% range, then slowly go DOWN as the distance approaches the "spec" limit of 1,000-feet...or...the temperature falls DOWN toward -40ºF.
-
The ISS % reception is also only based on the Wind Samples received against the Wind Samples expected for the relative Arc Interval. Is this then indicative of the overall reception issue?
-
The ISS % reception is also only based on the Wind Samples received against the Wind Samples expected for the relative Arc Interval. Is this then indicative of the overall reception issue?
No, I doubt anyone is too overly concerned with percentage of completed packets as long as they can maintain a signal lock with the transmitter. A dropped packet here or there isn't going to matter. When loss of signal lock (and subsequent resynchronization) coincides with temps below 10-20F, there's a BIG problem. Especially when you are 50ft away from a transmitter and it indicates nearly full strength otherwise.
-
The ISS % reception is also only based on the Wind Samples received against the Wind Samples expected for the relative Arc Interval. Is this then indicative of the overall reception issue?
No, I doubt anyone is too overly concerned with percentage of completed packets as long as they can maintain a signal lock with the transmitter. A dropped packet here or there isn't going to matter. When loss of signal lock (and subsequent resynchronization) coincides with temps below 10-20F, there's a BIG problem. Especially when you are 50ft away from a transmitter and it indicates nearly full strength otherwise.
But that is what I am saying in regard the above ISS reception examples or are you obtaining signal lock/reception figures from another source? if so then the above ISS reception graphs are irrelevant then?
-
The ISS % reception is also only based on the Wind Samples received against the Wind Samples expected for the relative Arc Interval. Is this then indicative of the overall reception issue?
No, I doubt anyone is too overly concerned with percentage of completed packets as long as they can maintain a signal lock with the transmitter. A dropped packet here or there isn't going to matter. When loss of signal lock (and subsequent resynchronization) coincides with temps below 10-20F, there's a BIG problem. Especially when you are 50ft away from a transmitter and it indicates nearly full strength otherwise.
But that is what I am saying in regard the above ISS reception examples or are you obtaining signal lock/reception figures from another source? if so then the above ISS reception graphs are irrelevant then?
All I know is that when the ISS signal based on wind packets expected, or whatever, is down to zero I get absolutely no data from the ISS. I have basically lost connection. Maybe these show better what we are talking about.
Mark
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
-
Yes I have seen instances like that as well and that is probably based on a single ISS but take the example where there is a Wind transmitter then the ISS % reception is based on the Wind transmitter and maybe not the main ISS??
-
Yes I have seen instances like that as well and that is probably based on a single ISS but take the example where there is a Wind transmitter then the ISS % reception is based on the Wind transmitter and maybe not the main ISS??
You have seen this happen and you don't find it a little disturbing?
I can see that, but I do not have a separate wind transmitter.
Mark
-
Mattk, I think we're getting down in the weeds here. Earlier today I posted an example graph from WeatherCat (Mac weather software) showing what wind "dropouts" look like in real time -- how long they last, how often they occur, and in what temperatures they occur. Several others have posted graphs demonstrating complete loss of ISS reception at similar temperatures. We have all shown this doesn't happen in warmer temps. And Mark has shown that even when a signal is locked as temps begin to fall below 20, packet completion lessens. I think we have a pretty good picture of the problem at this point.
-
Ok then so is the ISS % based on the Wind Samples representative and what do Wind Spike samples justify? Like I can show you reception spikes based on transmitters 6" apart but honestly can anybody say wind sample statistics are representative?
-
I had to disable uploads to WeatherLink long ago because it was causing my weather software, WeatherCat, to lock up. So I don't have the same screens to post as others.
In WeatherCat, when the ISS loses a signal lock, the temperature and humidity flat line until a connection is re-established. It can last for hours. I have made a screen capture of an example of that. In addition, I get 0's and NaN's sent to my website. If I look over at the console when this is occurring, I see dashes appear in the temperature and humidity fields. I can then pop into diagnostic or statistical screens on the console and see the dropped packets accumulating and the resync count incremented.
It's essentially the same process as wind dropouts, but the way WeatherCat responds makes it is easier to see with wind (drops to zero) than temp/humidity (flat lines at last recorded value).
-
I forgot to add that in addition to the flatlining graphs, WeatherCat increments a "sensor error" count. That corresponds to each poll of the console in which it encounters a sensor error. This is useful to establish how long a given outage lasted.
-
Ok then so is the ISS % based on the Wind Samples representative and what do Wind Spike samples justify? Like I can show you reception spikes based on transmitters 6" apart but honestly can anybody say wind sample statistics are representative?
This dynamic is tiresome. Several people have already posted a variety of visual evidence demonstrating complete (as well as partial) signal loss correlating to <10F temperatures in both ISS and wind transmitters. That's the takeaway. Not individual packet completion rates, not whether someone was using a wind transmitter and an ISS, not whether a spike in a graph could mean something else under completely different conditions. There's ample first hand accounts in this thread to supplement the graphs and confirm the true extent of the problem.
If you're going to contribute, perhaps take the time to read and understand what's already been posted rather than spraying barely coherent, hypothetical questions at everyone as you drive by.
-
It's just a question focusing on is the signal reception based on wind samples relevant or not? There just appears to be a guilty verdict regardless of the evidence relevence
-
It's just a question focusing on is the signal reception based on wind samples relevant or not? There just appears to be a guilty verdict regardless of the evidence relevence
I guess your point is that ISS Reception according to the Weatherlink help file is The ISS Reception rate shows the percentage of wind data packets that have been successfully received by the Vnatage Vue, Vantage Pro or Vantage Pro2 console.
[The "Vnatage Vue" is Davis' typo.]
Someone can correct me if wrong, but I think they specify wind packets because they are updated and transmitted the most, every 2.5 seconds. As I understand, other variables aren't updated so often. However, as far as I can see, and apparently everyone else here seems to see, if wind packets aren't received, then no other packets are received either, and if a packet is received it will contain wind. In short; every data transmission contains a wind packet, and if a wind packet isn't received no other data is either.
If the question has to do with separate wind stations, I have no personal experience, but as far as I can tell the ISS reception in WL is based on the ISS and doesn't show for other stations, though on the console in diagnostic mode I can see the reception % for other stations by pressing the "Station" button.
If the question is about how extra stations can affect the ISS reception, it can lower it a bit. On the post where I posted my graph (post #97), you can see a slight decrease in ISS reception around the evening of January 17th, it corresponds to when I powered up an extra temp station I use to monitor water pipes when we get cold spells.
-
Someone can correct me if wrong, but I think they specify wind packets because they are updated and transmitted the most, every 2.5 seconds.
AIUI, it's actually a bit simpler than that. The wireless packets have essentially an identical format to one another and ALL contain wind speed data but the content of the rest of the 8-byte payload varies according to the sensor data being transmitted. So monitoring wind speed packets is actually the same as monitoring the complete packet stream from a given transmitter. Details are in DeKay's famous wiki:
https://github.com/dekay/DavisRFM69/wiki (https://github.com/dekay/DavisRFM69/wiki)
(And also, reading between the lines a little, supported by the information in the Meteostick documentation.)
-
AIUI, it's actually a bit simpler than that. The wireless packets have essentially an identical format to one another and ALL contain wind speed data but the content of the rest of the 8-byte payload varies according to the sensor data being transmitted. So monitoring wind speed packets is actually the same as monitoring the complete packet stream from a given transmitter. Details are in DeKay's famous wiki:
Thanks. :-) That's pretty much what I had in mind when I said In short; every data transmission contains a wind packet, and if a wind packet isn't received no other data is either.
but wasn't able to speak as clearly, thoroughly, and concisely.
-
On numerous occasions during very cold and dry weather, I've had a similar issue where the wind direction suddenly switches around to the south or SE and reports 0mph or occasionally a 1 or 2mph speed (even though it's blowing out of a N, NW or W direction and the wind cups are spinning at a decent clip). At the same time this happens, the humidity and dewpoint spike up quickly and the temperature drops. Has anyone else experienced this issue? It seems to happen when the temperature gets into the teens or lower during a dry arctic airmass (which we had up here in Massachusetts for the better part of a week). It has happened to me in previous winters too, the VP2 is about 6 years old now. Any thoughts?
-
New Vue console has arrived!
I'm already seeing improvement. The most consecutive good packets received on the VP2 console today: ~1000 and on the Vue ~5000. VP2 console started recording statistics at midnight and the Vue this afternoon. Not bad.
I have 5 days coming up starting Friday with highs around 10 and lows near 0. So I should know more then.
-
So far so good on the Vue console. It's been below 10F since approximately 5:30AM EST (over 8 hours now). No outages for either transmitter. Not even a re-synchronization. I'm at 99% packet completion for both since midnight (and it's been 15F or colder that whole time).
However, the VP2 console, which is right beside the Vue console, lost connection with the ISS at 10:08AM and has tried 15 times to resync and been unsuccessful. That's an almost 4 hour outage, folks! In all probability, if I put it in setup mode, it would connect successfully (as it has in the past). The point is, though, that if I were away during that time, my website and all the data providers I upload to would be fed garbage until I returned and discovered it (best case scenario).
The next 24 hours should be spent at or under 10F. By Sunday early AM, it should be near/below 0F. I will report back later this weekend.
-
However, the VP2 console, which is right beside the Vue console, lost connection with the ISS at 10:08AM and has tried 15 times to resync and been unsuccessful.
Perhaps it's somewhere in this thread - but what is the firmware version of your VP2 console? And it's age?
-
The point is, though, that if I were away during that time, my website and all the data providers I upload to would be fed garbage until I returned and discovered it (best case scenario).
Why aren't you using the Vue for online?
-
However, the VP2 console, which is right beside the Vue console, lost connection with the ISS at 10:08AM and has tried 15 times to resync and been unsuccessful.
Perhaps it's somewhere in this thread - but what is the firmware version of your VP2 console? And it's age?
The VP2 console was purchased in early 2016. Serial number starts with AP. It has the latest firmware.
-
The point is, though, that if I were away during that time, my website and all the data providers I upload to would be fed garbage until I returned and discovered it (best case scenario).
Why aren't you using the Vue for online?
Sorry, should have clarified. I am using the Vue console to connect to my weather software (which feeds my website, WU, CWOP, etc). I was attempting to make the point that if I hadn't purchased the Vue console, I'd be toast because the VP2 console is hosed in cold weather.
-
That seems like a clear result thus far. So the provisional conclusion presumably is that the ISS is continuing to transmit on schedule despite the low temperatures, but that there's likely some drift in timing or frequency of the packets as the temperature drops, which your original VP2 console struggles to keep synch with.
What I'm not clear about though is whether there's any intrinsic difference between Vue and VP2 console circuitry, which I'd find a little surprising (expecting them to be almost identical); or if it's more a question that ISS and console (of whatever flavour) are never perfectly matched because of component tolerances and that your original VP2 console was simply less exactly matched than the new Vue console. In other words, a new VP2 console might have given an equally good result. No easy way of telling of course, just musing.
-
However, the VP2 console, which is right beside the Vue console, lost connection with the ISS at 10:08AM and has tried 15 times to resync and been unsuccessful.
OK, you have a Vue console that works OK with your ISS, and a VP2 console that does not.
If I had this situation, I would call Davis support, to report the difficulty.
Perhaps it's somewhere in this thread - but what is the firmware version of your VP2 console? And it's age?
The VP2 console was purchased in early 2016. Serial number starts with AP. It has the latest firmware.
-
That seems like a clear result thus far. So the provisional conclusion presumably is that the ISS is continuing to transmit on schedule despite the low temperatures, but that there's likely some drift in timing or frequency of the packets as the temperature drops, which your original VP2 console struggles to keep synch with.
What I'm not clear about though is whether there's any intrinsic difference between Vue and VP2 console circuitry, which I'd find a little surprising (expecting them to be almost identical); or if it's more a question that ISS and console (of whatever flavour) are never perfectly matched because of component tolerances and that your original VP2 console was simply less exactly matched than the new Vue console. In other words, a new VP2 console might have given an equally good result. No easy way of telling of course, just musing.
It seems others have reported getting better synch with their Vue consoles than the VP, and don't recall anyone reporting the converse. Unless there are some people reporting better with the VP console, it seems that tolerances must be wider on the Vue. If I'm not mistaken, the Vue was designed sometime later than the VP2, and unless they use identical circuit boards in the Vue and VP, then I have to think something must be different.
Assuming Davis is aware of the improved reception of the Vue, they must not have found it cost effective, or thought the problem was widespread enough, to redesign the VP2 circuitry.
Dalecoy asked about firmware; that made me think to look at the firmware updates for the consoles, and it appears that the Vue and VP use different firmware (the latest available for the Vue appears to be 4.18, the latest for the wireless VP2 appears to be 3.15 ), that leads me to believe that they aren't identical, or the firmware wouldn't be different.
Also, I don't remember if there have been many reports in the past, if not then it could indicate that there has been some change to the VP console, such as maybe a bad batch of components from a supplier for the VP boards or something? If I'm reading correctly, it appears the last firmware update for the VP console came out in March 2014, so it it was a firmware issue it seems problems would have started appearing the winter after that, or tolerances change over time, but if I recall correctly the OP had a fairly new VP console which would discount that. But then, I'm also just musing.
-
That seems like a clear result thus far. So the provisional conclusion presumably is that the ISS is continuing to transmit on schedule despite the low temperatures, but that there's likely some drift in timing or frequency of the packets as the temperature drops, which your original VP2 console struggles to keep synch with.
What I'm not clear about though is whether there's any intrinsic difference between Vue and VP2 console circuitry, which I'd find a little surprising (expecting them to be almost identical); or if it's more a question that ISS and console (of whatever flavour) are never perfectly matched because of component tolerances and that your original VP2 console was simply less exactly matched than the new Vue console. In other words, a new VP2 console might have given an equally good result. No easy way of telling of course, just musing.
Looking back through my records, I've had this cold weather issue with 2 separate VP2 consoles across 2 different ISS transmitters and a 6332 wind transmitter. That's 2 consoles and 3 SIMS that just happen not to play with each other in cold weather. No problems at all in weather above 20F. What are the odds?
If my console were still under warranty, I'd swap it out for a new one. And I'd happily take wagers as to the likelihood of repeated problems from anyone who thinks the handful of us who have spoken up are somehow just very unlucky. I'd even give 3 to 1 odds.
Given that I'm being forced to purchase an additional device for what appears to be a Davis design error, it makes no sense to pay the ~$100 USD premium for a VP2 receiver since I don't have sensors the Vue doesn't support.
-
If planning on being away I found best friend was free product called Teamviewer, gives ability to check in with everything connected into computer and reset if needed.
Can't do hard reboot but in most cases not necessary.
Before I moved to Nebraska was using Teamviewer to control both cameras and weather station while still in Arizona.
-
OK, you have a Vue console that works OK with your ISS, and a VP2 console that does not.
If I had this situation, I would call Davis support, to report the difficulty.
I'd encourage you, if you have time, to read this entire thread which contains documented evidence that this issue is not limited to any one person or siting. If you do so, I doubt you'll conclude that this, or any issue that could expose Davis to legal or publicity problems, can be properly addressed by Davis support. I refer specifically to the post where I list out all the parts I've had to replace in the past year because of Davis "quality" control as well as the posts where I and at least one other person catch Davis support, including leadership, being less than forthright. Yet another person in this thread will attest that on this very issue they will take your money and give you nothing in return. No thanks.
-
If planning on being away I found best friend was free product called Teamviewer, gives ability to check in with everything connected into computer and reset if needed.
Can't do hard reboot but in most cases not necessary.
Before I moved to Nebraska was using Teamviewer to control both cameras and weather station while still in Arizona.
Unfortunately, the issue here isn't my computer. It's the VP2 console. Can Teamviewer put my console in setup mode? :lol:
-
I'd encourage you, if you have time, to read this entire thread which contains documented evidence that this issue is not limited to any one person or siting. If you do so, I doubt you'll conclude that this, or any issue that could expose Davis to legal or publicity problems, can be properly addressed by Davis support. I refer specifically to the post where I list out all the parts I've had to replace in the past year because of Davis "quality" control as well as the posts where I and at least one other person catch Davis support, including leadership, being less than forthright. Yet another person in this thread will attest that on this very issue they will take your money and give you nothing in return. No thanks.
There is also the possibility that Davis is not aware of the problem, or understand how widespread it may be. If there are only a few reports then support may just resort to their first instinct that everything is operator error and blow it off.
Also it seems to me that if there was a legal issue, then your rights may be mitigated if you're unable to show that you addressed the issue adequately with Davis.
In any case, you gain nothing if you don't raise the issue with them any further than you've already done. Davis has been known to work with people in some other cases, though I agree in your case your not likely to get the satisfaction you desire.
-
Looking back through my records, I've had this cold weather issue with 2 separate VP2 consoles across 2 different ISS transmitters and a 6332 wind transmitter. That's 2 consoles and 3 SIMS that just happen not to play with each other in cold weather. No problems at all in weather above 20F. What are the odds?
Don't disagree with the conclusion, just a little surprised. The Vue was launched 2009 IIRC and the VP2 2005 effectively, so I'd have thought that Davis have had plenty of opportunity to change the detail of the VP2 console board, even if changes are only made occasionally. Wonder if it's possible that cheaper (greater tolerance) components in the Vue actually allow it to be more tolerant to drift in the transmitter parameters, but maybe less good in other respects (lower sensitivity?). But I guess it's probably too late now in the VP2 product cycle to expect any significant design changes.
-
OK, you have a Vue console that works OK with your ISS, and a VP2 console that does not.
If I had this situation, I would call Davis support, to report the difficulty.
I'd encourage you, if you have time, to read this entire thread which contains documented evidence that this issue is not limited to any one person or siting. If you do so, I doubt you'll conclude that this, or any issue that could expose Davis to legal or publicity problems, can be properly addressed by Davis support. I refer specifically to the post where I list out all the parts I've had to replace in the past year because of Davis "quality" control as well as the posts where I and at least one other person catch Davis support, including leadership, being less than forthright. Yet another person in this thread will attest that on this very issue they will take your money and give you nothing in return. No thanks.
Excuse me? I have, indeed, read the entire thread (several times).
You are unhappy with Davis, but won't tell them.
Thanks.
-
I wouldn't be so bold as to say that the Davis VP2 console is poorly engineered as you seem to be inferring. I have a VP2 console that works fine at all temperatures from well over 100°F to -17°F and below. I've NEVER experienced the issue you are describing. I'm not saying you aren't having an issue with yours. However, these same consoles are used by scientific teams in both Arctic and Antarctic. If there was an engineering issue with the units, it would have been discovered long before this and most likely fixed by now.
-
Look, folks, I'm not saying everyone who contacts Davis support will have a negative experience. I'm sure if the question is sufficiently straightforward or an honest answer wouldn't reflect poorly on the company, Davis support is helpful. Indeed, in such circumstances, I've had good luck with them in the past.
If, however, you're Davis and one of the following is true:
1) you're just now discovering that VP2 consoles lose connection to wireless transmitters in cold weather (but probably should have known long ago)
2) you've been aware of this issue for years because this is a ubiquitous product installed over the last 13 years in most every climate on Earth
3) you're aware to some degree there's a subset of consoles that do this, but you don't know how large the problem is, and it could be larger than you think
are you, in this increasingly lawsuit-stricken age, going to admit to this problem? Extremely doubtful. This pattern would generally hold true with any company offering product support. That's the world in which we live.
-
If planning on being away I found best friend was free product called Teamviewer, gives ability to check in with everything connected into computer and reset if needed.
Can't do hard reboot but in most cases not necessary.
Before I moved to Nebraska was using Teamviewer to control both cameras and weather station while still in Arizona.
Unfortunately, the issue here isn't my computer. It's the VP2 console. Can Teamviewer put my console in setup mode? :lol:
Doesn't need to just open and close WL couple times along with dashboard (bulletin) and it will start receiving again. Takes about 15 minutes max to regain connection. If you do nothing yes it might take hours that's why having Teamviewer is nice.
Just did it on my remote station and it started communicating again. I've never had to go into setup mode before and I've managed remotely for 5 years now.
-
3) you're aware to some degree there's a subset of consoles that do this, but you don't know how large the problem is, and it could be larger than you think
That was part of my point, that's a good reason to contact Davis. If Davis has no reason to believe a significant number of consoles are affected because people aren't reporting the problem, and their testing in sunny California doesn't tell them otherwise, what action would you expect them to take?
are you, in this increasingly lawsuit-stricken age, going to admit to this problem? Extremely doubtful. This pattern would generally hold true with any company offering product support. That's the world in which we live.
So you've already determined what the problem is and what Davis' reaction would be?
It seems as if I've heard of companies being sued because they've denied and tried to cover up known problems. But I guess you're more of a lawyer than I am.
-
If planning on being away I found best friend was free product called Teamviewer, gives ability to check in with everything connected into computer and reset if needed.
Can't do hard reboot but in most cases not necessary.
Before I moved to Nebraska was using Teamviewer to control both cameras and weather station while still in Arizona.
Unfortunately, the issue here isn't my computer. It's the VP2 console. Can Teamviewer put my console in setup mode? :lol:
Doesn't need to just open and close WL couple times along with dashboard (bulletin) and it will start receiving again. Takes about 15 minutes max to regain connection. If you do nothing yes it might take hours that's why having Teamviewer is nice.
Merely devil's advocate here; why should that even be necessary?
-
Merely devil's advocate here; why should that even be necessary?
It shouldn't be necessary its messed up. I'm just giving some tips on making live easier because I've done it. Ideally it should just reconnect but sometimes it won't and someone 1000 miles away can remotely get it going again. .
-
Merely devil's advocate here; why should that even be necessary?
It shouldn't be necessary its messed up. I'm just giving some tips on making live easier because I've done it. Ideally it should just reconnect but sometimes it won't and someone 1000 miles away can remotely get it going again. .
Got it.
-
I wouldn't be so bold as to say that the Davis VP2 console is poorly engineered as you seem to be inferring. I have a VP2 console that works fine at all temperatures from well over 100°F to -17°F and below. I've NEVER experienced the issue you are describing. I'm not saying you aren't having an issue with yours. However, these same consoles are used by scientific teams in both Arctic and Antarctic. If there was an engineering issue with the units, it would have been discovered long before this and most likely fixed by now.
This is what I know. Both the VP2 consoles I purchased (2.5 years apart) have the issue. My first console was used in Phoenix up to 119F. Never had a problem until I brought it north. How many does it affect? Who knows. Obviously, Randy, Mark and others have experienced problems in cold weather too.
The problem doesn't have to affect every VP2 console ever made to qualify as an "engineering issue". It could be, as others have pointed out, a matter of poorly spec'd or matched components that sometimes behave and sometimes don't.
It's important to note, however, that many of us had the problem even before we were aware of it. I, for one, am extremely vigilant. So that was a surprise. Once we discovered it, though, a look back at the software revealed it had been there all along. In my case, it became unavoidable during the polar vortex (which I had not experienced in my previous 2 winters).
-
If planning on being away I found best friend was free product called Teamviewer, gives ability to check in with everything connected into computer and reset if needed.
Can't do hard reboot but in most cases not necessary.
Before I moved to Nebraska was using Teamviewer to control both cameras and weather station while still in Arizona.
Unfortunately, the issue here isn't my computer. It's the VP2 console. Can Teamviewer put my console in setup mode? :lol:
Doesn't need to just open and close WL couple times along with dashboard (bulletin) and it will start receiving again. Takes about 15 minutes max to regain connection. If you do nothing yes it might take hours that's why having Teamviewer is nice.
Just did it on my remote station and it started communicating again. I've never had to go into setup mode before and I've managed remotely for 5 years now.
Well, I'm sure that advice will help many. However, not all of us have WeatherLink installed or available. In my case, I use a Mac and have WeatherLink IP. They don't make a WeatherLink app for Mac that supports WLIP.
-
Well, I'm sure that advice will help many. However, not all of us have WeatherLink installed or available. In my case, I use a Mac and have WeatherLink IP. They don't make a WeatherLink app for Mac that supports WLIP.
Yikes! no wonder. I would say most do use WL or at least like me have it available when needed. I use Cumulus as the primary software but when things don't work fix it with WL.
-
Based on my experience, I would bet there are a lot of VP2 owners that don't even realize they have this problem. So many people complain about the "dated" look of the WeatherLink software, so the first thing they do after setting up the console is install new software. I did it because I liked the look of Cumulous, but I really prefer the WL graphs and data files so I make it a point to shut down Cumulous at least weekly and open WL to download the logger.
I installed my VP2 in late April of 2014 and immediately started using Cumulous as my main software. Everything appeared to be going along fine until February of 2016 , when I happened to notice on my console that it had lost connection. I wondered why Cumulous did not show gaps in data. When I looked in the dayfile text files, for that time period that the connection to the ISS was lost, they had the same values as the period before the connection was lost. These values were also sent to WU, so my graphs never had any gaps in data. With the WL graphs it is very obvious, there were gaps in the graphs. Most of the lost connections were at night or early morning. Had I not noticed the outdoor data dashed out, I would never have known there was a problem. Looking at WL graphs from November 2014 to April 2015 I had four lost connections. May to October of 2015 zero lost connections, then in November it went south, fifteen lost connections by the middle of February.
Maybe now would be a good time for all you non-believers that live in a cold climate to fire up WL and do a test to prove that I just have a bad console and it is not something inherent to the VP2 console.
End of rant.
Mark
-
3) you're aware to some degree there's a subset of consoles that do this, but you don't know how large the problem is, and it could be larger than you think
That was part of my point, that's a good reason to contact Davis. If Davis has no reason to believe a significant number of consoles are affected because people aren't reporting the problem, and their testing in sunny California doesn't tell them otherwise, what action would you expect them to take?
are you, in this increasingly lawsuit-stricken age, going to admit to this problem? Extremely doubtful. This pattern would generally hold true with any company offering product support. That's the world in which we live.
So you've already determined what the problem is and what Davis' reaction would be?
It seems as if I've heard of companies being sued because they've denied and tried to cover up known problems. But I guess you're more of a lawyer than I am.
Oh, good Lord, I'm not a lawyer. I'm stating the obvious. Companies don't knowingly admit to truths that could make them liable.
I suppose I could call Davis like Mark did and have them spin my wheels and charge me $$ to return the same console with the same problem. Even if they were to offer me a free VP2 console, that does me no good. I have a website to run that people depend on and I need a console that works now. Hence, why I purchased the Vue console. So far, so good.
-
Oh, good Lord, I'm not a lawyer. I'm stating the obvious. Companies don't knowingly admit to truths that could make them liable.
:lol:
Still seems somewhat counter intuitive to me that you seem to believe that a company will not be willing to work with and please their customers because they're afraid of getting sued, especially if there is little or no evidence that they're aware of a widespread problem, and how would they be aware it's a widespread problem if no one reports it? You have details and experience that most others, if they have noticed the problem at all, probably don't. But somehow, even though you're not a lawyer, you know how Davis would handle the matter if you did talk to them. I understand that might take a little of your time and effort, and as is clear from all your posts on this thread, you must not have much time. But maybe if you did, and as a result Davis found and rectified the problem, it would help others.
-
Just for heck of it, let's game out a Davis support interaction. After summarizing the problem and offering corroboration, I would insist Davis cut me a check for my Vue console. Why? Because I'm not sticking Ryan @ Scaled Instruments with the return just so Davis can send me the same product for free. This one works fine so far. And I'm not going to pay Davis to fix what appears to be a design error. What's more, I'm not performing free labor for Davis by testing out a 3rd VP2 console only to, quite likely, return it. So the only successful scenario ends with an apology, a check and a promise by Davis to reach out to their users and make this right (which I would expect to hear about from actual users on this forum). Since none of that is going to happen, I just skipped to the part where I solved my own problem (even if it involved an unjust expense to me).
This thread, unlike the pointless exercise above, is an effort to help others with this problem. If after reading it they wish to contact Davis support, that is their right, especially if their product is under warranty.
Assuming Davis were interested in visiting the most likely place on the internet their users would describe problems with their products, maybe they already know? There I go making assumptions.... ;)
-
Appears like some have lost the plot with this one, this thread isn't going anywhere at the moment expect downhill.
-
As of this morning, after 30 hours spent below 10F, I have not experienced any loss of connection with my transmitters on the Vue console (0 resyncs and 0 sensor errors in my software). I've never had a 24 hour period on any of my VP2 consoles at these temperatures without issues.
Over the same period the VP2 console had 5 resyncs with the ISS and 4 resyncs with the wind transmitter. Yesterday I observed a ~6 hour ISS outage on the VP2.
I think I know what I need to know at this point.
-
Openvista, I am glad your new Vue console is working for you and the signal-drop issue appears to be resolved. As you said, hopefully others will read this thread and gain some knowledge about the issue so they can make their own rational decision on the matter.
Good luck with the new Vue console!
-
As I hinted at earlier, switching to a VUE console seemed (for whatever reasons) to SOLVE my ISS-to-console "drop-out" problems, which were NOT solved by changing ISS unit (I bought a spare), ISS CR123A batteries (replaced a LOT of them), or ISS-cover solar panel (also a spare).
Bluntly, the VUE console *receiver* seems to operate better...although the original VP2 Console worked fine during its initial 4-years of service, then began to suddenly experience periodic "low battery on #1" notices regardless of CR123A battery life/replacements.
-
As I hinted at earlier, switching to a VUE console seemed (for whatever reasons) to SOLVE my ISS-to-console "drop-out" problems, which were NOT solved by changing ISS unit (I bought a spare), ISS CR123A batteries (replaced a LOT of them), or ISS-cover solar panel (also a spare).
Bluntly, the VUE console *receiver* seems to operate better...although the original VP2 Console worked fine during its initial 4-years of service, then suddenly began to experience periodic "low battery on #1" notices regardless of CR123A battery life/replacements.
I never received low battery warnings even though my software, WeatherCat, checks battery strength daily. Although that error could be an idiosyncracy of a particular weather application (WeatherLink?).
In my case, both receivers experienced signal problems in cold weather *as soon as they were placed in those conditions*. For my first console, that was the first winter in Michigan (it lived in AZ before that for 2 yrs). For my 2nd console, issues occurred immediately after being placed into service in January 2016.
-
I still wonder if a 16340 (rechargeable CR123A) might perform better in this scenario. I can't find data on the 16340 size, but the better 18650 batteries (https://www.orbtronic.com/content/Datasheet-specs-Sanyo-Panasonic-NCR18650GA-3500mah.pdf) still have 3.5V at 14°F (as low as the published data go). Even if I assume a steep voltage drop off from there, we're looking at staying above 3V until somewhere around -25°F.
When I first proposed the idea I was worried that the 4.2V maximum of these batteries might be an issue, but since then have realized that the power adapter supplies 5V. It seems like these batteries shouldn't be an issue.
-
This thread explains why the Vue has better reception. RF chip in Vue is better.
http://www.wxforum.net/index.php?topic=33638.msg341444#msg341444
-
Put the console antenna in the up position, if you don't already do, to see if that helps prevent signal dropouts.
-
In my case, both receivers experienced signal problems in cold weather *as soon as they were placed in those conditions*. For my first console, that was the first winter in Michigan (it lived in AZ before that for 2 yrs). For my 2nd console, issues occurred immediately after being placed into service in January 2016.
A question for those who have studied the available data in detail:
Is this (dropouts with receiving from transmitters in very low temperature) - more prevalent for installations that have multiple transmitters being received by the console?
-
In my case, both receivers experienced signal problems in cold weather *as soon as they were placed in those conditions*. For my first console, that was the first winter in Michigan (it lived in AZ before that for 2 yrs). For my 2nd console, issues occurred immediately after being placed into service in January 2016.
A question for those who have studied the available data in detail:
Is this (dropouts with receiving from transmitters in very low temperature) - more prevalent for installations that have multiple transmitters being received by the console?
ValentineWeather and I both have multiple transmitters, but zackdog does not and he had the issue. Beyond that I can't say as there is incomplete information.
Good question, though. Will anyone else with the issue please report how many xmtrs you use?
-
Evidently the phone call I made to Davis has fallen on deaf ears, or they're "researching" it. Oh well...
-
In my case, both receivers experienced signal problems in cold weather *as soon as they were placed in those conditions*. For my first console, that was the first winter in Michigan (it lived in AZ before that for 2 yrs). For my 2nd console, issues occurred immediately after being placed into service in January 2016.
A question for those who have studied the available data in detail:
Is this (dropouts with receiving from transmitters in very low temperature) - more prevalent for installations that have multiple transmitters being received by the console?
ValentineWeather and I both have multiple transmitters, but zackdog does not and he had the issue. Beyond that I can't say as there is incomplete information.
Good question, though. Will anyone else with the issue please report how many xmtrs you use?
Perhaps zackdog will confirm. I don't quite understand what zackdog said
December 17, 2016
This morning my console lost connection for half an hour, but my additional temperature sensor remained connected. Got ISS to reconnect and then the temperature sensor lost connection.
http://www.wxforum.net/index.php?topic=30972.msg308465#msg308465
-
Also, from:
November 06, 2017, 11:27:50 AM
http://www.wxforum.net/index.php?topic=24211.msg335789#msg335789
I looked closer and noticed I was receiving from ISS #2. I had forgotten that ISS #4 was my wireless temperature station
-
Well, I know earlier in the thread zackdog said he didn't have a wind transmitter (http://www.wxforum.net/index.php?topic=33496.msg340824#msg340824 (http://www.wxforum.net/index.php?topic=33496.msg340824#msg340824)). The graphs he posted were of his ISS. It's possible he wasn't always using a separate temp station when he was experiencing outages. Hopefully, he'll clarify.
Another person who reported this issue is miraculon, and I'm pretty sure he has multiple transmitters. Again, he'll have confirm.
MonumentHillWeather said that when he first got his wind transmitter he had issues (http://www.wxforum.net/index.php?topic=33496.msg340146#msg340146 (http://www.wxforum.net/index.php?topic=33496.msg340146#msg340146)). Although I'm not sure if his issue was strictly cold related or not.
Assuming all 3 members mentioned above receive multiple channels and no one with a single transmitter is reporting cold weather drop outs, then we may have a new working hypothesis. However, it still wouldn't be iron clad because MonumentHillWeather's situation cleared up with a replacement console. Nevertheless, that new stipulation would go a long way to explaining why there aren't more people seeing the problem.
-
So, just to summarise what has been a long thread, your working hypothesis AIUI is that:
1. Very cold conditions cause some change in the profile or character of the VP2 transmitter signal, but probably to some aspect other than signal strength (RSSI), which seems to look good right up until contact is dropped;
2. The changes in [1] make it increasingly difficult for the VP2 console to retain lock on the signal, an issue that is exacerbated when there are multiple transmitters in use. But Vue consoles appear more tolerant to the degraded signal than VP2 consoles.
-
So, just to summarise what has been a long thread, your working hypothesis AIUI is that:
1. Very cold conditions cause some change in the profile or character of the VP2 transmitter signal, but probably to some aspect other than signal strength (RSSI), which seems to look good right up until contact is dropped;
2. The changes in [1] make it increasingly difficult for the VP2 console to retain lock on the signal, an issue that is exacerbated when there are multiple transmitters in use. But Vue consoles appear more tolerant to the degraded signal than VP2 consoles.
Yes, however, I'd tweak #2 to say that, until we hear differently, it may be fair to say that multiple transmitters are a prerequisite to experiencing signal lock problems. I have yet to confirm a case where the person involved has only 1 transmitter being received.
-
Another person who reported this issue is miraculon, and I'm pretty sure he has multiple transmitters. Again, he'll have confirm.
I have a total of six transmitters and one long-range repeater.
Transmitters consist of 2 anemometer transmitters, a VP2 ISS, a Temp/Hum station, another "rain station"/temp station, and a temp station. (I have a mish-mash of stations configured as "ISS" for the Envoy8x and MBPro that do double duty)
The only LOS that has occurred is a very old "eBay special" VP2 console and the Marina VUE/Repeater setup. The "Marina VUE" only looks at the Marina data on Station #1/Repeater A. I suspect that the Marina's ISS actually experienced the "low temp issue" (whatever it is) because the signal from the Marina's Weatherlink page was also lost coincidentally with my repeater signal. I suspect that the long range repeater takes a long time to synch back up and do its FHSS dance.
The last time I checked the ISS and Temp/Hum batteries (November?) the voltages were just around 3V. I have all "OK" on the Weatherlink (PC SW) battery status page.
The signals from my own sensors have not been lost on two VP2 consoles, two VUE consoles, two Envoys and an Envoy8x. Only the old "eBay" console lost signal and went to dashes.
Greg H.
-
Another person who reported this issue is miraculon, and I'm pretty sure he has multiple transmitters. Again, he'll have confirm.
I have a total of six transmitters and one long-range repeater.
Transmitters consist of 2 anemometer transmitters, a VP2 ISS, a Temp/Hum station, another "rain station"/temp station, and a temp station. (I have a mish-mash of stations configured as "ISS" for the Envoy8x and MBPro that do double duty)
The only LOS that has occurred is a very old "eBay special" VP2 console and the Marina VUE/Repeater setup. The "Marina VUE" only looks at the Marina data on Station #1/Repeater A. I suspect that the Marina's ISS actually experienced the "low temp issue" (whatever it is) because the signal from the Marina's Weatherlink page was also lost coincidentally with my repeater signal. I suspect that the long range repeater takes a long time to synch back up and do its FHSS dance.
The last time I checked the ISS and Temp/Hum batteries (November?) the voltages were just around 3V. I have all "OK" on the Weatherlink (PC SW) battery status page.
The signals from my own sensors have not been lost on two VP2 consoles, two VUE consoles, two Envoys and an Envoy8x. Only the old "eBay" console lost signal and went to dashes.
Greg H.
This is interesting. On one hand, it lends credence to the idea that this is a timing issue of some sort. Perhaps we should refine the hypothesis to including "VP2 consoles receiving repeater(s) or multiple transmitters in approximately 10F (-12C) or colder conditions". That's still far from a guaranteed formula, of course, as Greg points out. But if you accept the idea of component tolerances varying just enough for some to experience it and others not, and combined with all the other prereqs, that could make sense.
On the other hand, someone else had earlier claimed that this issue seems "new" in that it only was observed recently. They went on to speculate that it was, perhaps, limited to newer equipment and/or firmware. But miraculon is observing this on a "very old" VP2 console. Does it have the original firmware on it, Greg? What is its approximate vintage?
-
Does it have the original firmware on it, Greg? What is its approximate vintage?
I believe that is is circa 2006, and was able to accept the latest (current) firmware. It takes significantly longer to sync up than the newer consoles. (one 2011 and another about a year old)
G
-
Does it have the original firmware on it, Greg? What is its approximate vintage?
I believe that is is circa 2006, and was able to accept the latest (current) firmware. It takes significantly longer to sync up than the newer consoles. (one 2011 and another about a year old)
G
OK, good to know. My 2013 console had the original, shipped firmware (never updated) and still exhibited the drop outs, so the issue is not limited to the latest firmware. Now we know it can happen on an early console too.
-
A question for those who have studied the available data in detail:
Is this (dropouts with receiving from transmitters in very low temperature) - more prevalent for installations that have multiple transmitters being received by the console?
I'm glad I asked that question.
Candidate for Postulate #3: VP2 stations meet the stated temperature specifications, when only one transmitter is involved.
[johnd, what would be the percentage of installations with more than one transmitter - and the percentage within areas that experience cold conditions (and owners who would notice dropouts)]
-
Candidate for Postulate #3: VP2 stations meet the stated temperature specifications, when only one transmitter is involved.
My only reservation is that someone was reporting something like this issue back in 2009 (see: https://www.wxforum.net/index.php?topic=6115.25 (https://www.wxforum.net/index.php?topic=6115.25)) on a new VP2 station with only 1 transmitter. He was told by Davis support it was due to his trailer having an aluminum frame (not cladding, just the framing). I don't really buy that explanation, but I cannot confirm any further details nor what the resolution was, if any. He replaced the console, ISS transmitter SIM, xmtr batteries, changed channels and the issue still persisted.
Key quote:
...as night comes start getting really low signals/dash outs and show 1157 bad packets 360 CRCs and 10 reconnects for one night. The trend I'm seeing is the colder it is the worse it gets. Now if that's normal I'm not impressed. I also don't think its normal to be standing within 20 feet of the ISS and get bad connections.
-
Sorry I haven't checked in here for a while. I am doing a little digging into my records to gather some more information on the problems I have had. One thing I do know is that I did not get the additional temp/hum transmitter until 12/2/2016, long after I had problems with console.
Mark
-
Sorry I haven't checked in here for a while. I am doing a little digging into my records to gather some more information on the problems I have had. One thing I do know is that I did not get the additional temp/hum transmitter until 12/2/2016, long after I had problems with console.
Mark
Alright, well that would tell us this can happen with only 1 transmitter ID selected for reception. So, yes, johnd, the issue is, perhaps, "exacerbated" by extra transmitters/repeaters.
Also, I sent a PM to MarkWX who reported similar issues in 2009 requesting he join us here, if he's up to it.
-
[johnd, what would be the percentage of installations with more than one transmitter - and the percentage within areas that experience cold conditions (and owners who would notice dropouts)]
I don't have any exact figures but I'd guess 15-20% of VP2 owners and maybe 10% of Vue owners here have one or more supplementary transmitters. Most of our Davis sales are in the UK and very few of those would experience temperatures below -10C (say 14F) except on very rare occasions. So I'm not surprised about the lack of reports here.
-
Okay, condensed version of my time line.
1. Purchased and installed VP2 Plus April of 2014. ISS is on #2.
2. First became aware that I was losing signal in Feb of 2016. Went back in WL records and discovered I had the same problem during winter of 2014-2015, just not as bad. Contacted Davis and sent in the console for repair. Got console back and did not hook to a computer, since I was having excellent results with the Vue console. They replaced the console board for a cost of $82 including shipping.
3. In June of 2016 I tried hooking console to a computer via usb cable, but was unable to get the computer to find the console. Called Davis and was told to send console and logger to them under warranty. According to the slip, they again replaced the console board. I am now on third console board. Now have unit hooked to a netbook and I thought it was working fine.
4. In Dec of 2016 I purchased a remote temperature sensor and installed it as #4. Have had no drop outs on it.
5. After seeing this thread, I went back and checked my WL data for the winter of 2016-2017 and discovered I am still getting drop outs during the winter with the third console board. I intended to continue on with this spread sheet, but decided it is pretty obvious I have a problem, no need to continue. I am now going to install my Vantage Vue ISS as #1 and try receiving signals from it on the VP2 console as Snowhiker had suggested while the weather is still cold. Stay tuned.
[ You are not allowed to view attachments ]
Mark
-
That's a lot of helpful info, zackdog. Thanks!
Three console boards (essentially 3 consoles) and yet the ISS troubles persist! That's certainly not helping to make the case that this issue is confined to a handful of consoles.
-
Three console boards (essentially 3 consoles) and yet the ISS troubles persist! That's certainly not helping to make the case that this issue is confined to a handful of consoles.
I didn't ever think that was the case. However, a handful of reported cases from locations with relatively low temperatures where the operator noticed the problem, and perhaps most likely where multiple transmitters are involved.
The frequency-hopping technology being used by the VP2 requires the receiver (console) to adjust to the exact set of frequencies being transmitted, and those exact frequencies will "drift" with temperature changes at the transmitter. With multiple transmitters, that's multiple sets of frequencies, and each set "drifts" differently. Firmware algorithms to handle that situation are not simple - and the smaller available memory in the VP2 console undoubtedly required compromises.
Apparently (based on evidence demonstrated in this thread), the firmware algorithms in the Vue console are better at handling the situation.
-
With multiple transmitters, that's multiple sets of frequencies, and each set "drifts" differently
It may well be that the frequency drift with temperature is the main fly in the ointment here, but let's not forget that there's another parameter too, which is the limits of the timing window in which each wireless channel sits. Maybe any timing drift also correlates with frequency drift (as presumably it might do if there was some master clock).
Also, I don't know whether each transmitter synchronises to use the same sequence of frequencies in the FHSS pattern or not. It would be quite interesting to see an explanatory post from someone who actually knows and understands how the FHSS, channel timings etc all work together for multiple VP2/Vue transmitters.
-
With multiple transmitters, that's multiple sets of frequencies, and each set "drifts" differently
It may well be that the frequency drift with temperature is the main fly in the ointment here, but let's not forget that there's another parameter too, which is the limits of the timing window in which each wireless channel sits. Maybe any timing drift also correlates with frequency drift (as presumably it might do if there was some master clock).
Also, I don't know whether each transmitter synchronises to use the same sequence of frequencies in the FHSS pattern or not. It would be quite interesting to see an explanatory post from someone who actually knows and understands how the FHSS, channel timings etc all work together for multiple VP2/Vue transmitters.
I'm not sure I understand the question. Each transmitter is totally independent. They don't "talk to each other", because they don't have any receiving capability.
Being independent, and each having it's own "clock", yes the timing window also drifts with temperature, at the same "percentage" as the frequency drift.
But perhaps I'm not understanding the question.
-
Also, I don't know whether each transmitter synchronises to use the same sequence of frequencies in the FHSS pattern or not. It would be quite interesting to see an explanatory post from someone who actually knows and understands how the FHSS, channel timings etc all work together for multiple VP2/Vue transmitters.
A simple test:
There are people with multiple transmitters and multiple consoles out there. Put two consoles side by side and into the Reception Diagnostic Screen. Monitor a different transmitter with each console and see
if the "Frequency index of the next packet to be received" is the same on both consoles. This test will tell if the console is just waiting the appropriate amount of time for the last transmitter (by ID) or if it is
tracking individual transmitters on a per frequency basis.
-
I'm not sure I understand the question. Each transmitter is totally independent. They don't "talk to each other", because they don't have any receiving capability.
That's not my picture, but admittedly I'm at the edge of my knowledge in understanding how the wireless chips work. Maybe the transmitters don't talk to each other, but surely they listen to each other (fsvo listen at least). Otherwise how does a new transmitter in a set-up that already has eg an ISS know how to time its packet transmissions and to sequence its frequencies? Surely the console only listens to one frequency at a time (before it hops to the next one I mean)? Maybe some one can explain?
-
Also, I don't know whether each transmitter synchronises to use the same sequence of frequencies in the FHSS pattern or not. It would be quite interesting to see an explanatory post from someone who actually knows and understands how the FHSS, channel timings etc all work together for multiple VP2/Vue transmitters.
A simple test:
There are people with multiple transmitters and multiple consoles out there. Put two consoles side by side and into the Reception Diagnostic Screen. Monitor a different transmitter with each console and see
if the "Frequency index of the next packet to be received" is the same on both consoles. This test will tell if the console is just waiting the appropriate amount of time for the last transmitter (by ID) or if it is
tracking individual transmitters on a per frequency basis.
I have a Vue console and a VP2 console; however, the frequency index function appears the same on both. First, I put both on the same channel ID in the reception diagnostic screen. They were tracking perfectly (same indices changing at the same time on both consoles). Then, as instructed, I changed the channel ID on the VP2 console and saw different indices updating out of sync with the other channel ID. After awhile, I changed the Vue to the same channel ID as the VP2 and, again, it was tracking the VP2 in timing and indices.
Confirmed: the IDs channels are indexed independently.
Test was conducted at +23F.
[Updated to correct the term "channel" with "ID"]
-
Also, I don't know whether each transmitter synchronises to use the same sequence of frequencies in the FHSS pattern or not. It would be quite interesting to see an explanatory post from someone who actually knows and understands how the FHSS, channel timings etc all work together for multiple VP2/Vue transmitters.
A simple test:
There are people with multiple transmitters and multiple consoles out there. Put two consoles side by side and into the Reception Diagnostic Screen. Monitor a different transmitter with each console and see
if the "Frequency index of the next packet to be received" is the same on both consoles. This test will tell if the console is just waiting the appropriate amount of time for the last transmitter (by ID) or if it is
tracking individual transmitters on a per frequency basis.
I have a Vue console and a VP2 console; however, the frequency index function appears the same on both. First, I put both on the same channel in the reception diagnostic screen. They were tracking perfectly (same indices changing at the same time on both consoles). Then, as instructed, I changed the channel on the VP2 console and saw different indices updating out of sync with the other channel. After awhile, I changed the Vue to the same channel as the VP2 and, again, it was tracking the VP2 in timing and indices.
Confirmed: the channels are indexed independently. (Test was conducted at 23F)
When you state "channel" are you referring to "Transmitter ID"?
-
When you state "channel" are you referring to "Transmitter ID"?
Yes, I use "channel" and "ID" synonymously. Perhaps I shouldn't since each transmitter can broadcast on multiple frequencies. Sorry about the confusion.
-
I'm not sure I understand the question. Each transmitter is totally independent. They don't "talk to each other", because they don't have any receiving capability.
Maybe the transmitters don't talk to each other, but surely they listen to each other (fsvo listen at least).
fsvo? No, they don't listen. They just transmit on a frequency schedule that is "hard wired" (based on the selection of ID).
Otherwise how does a new transmitter in a set-up that already has eg an ISS know how to time its packet transmissions and to sequence its frequencies? Surely the console only listens to one frequency at a time (before it hops to the next one I mean)? Maybe some one can explain?
The transmitter just starts when it's "turned on". And yes, the console only listens to one frequency at a time. I'll try to find the time/energy to provide an explanation, when I get a few more minutes.
-
The diagnostics screen on the console shows1 the frequency correction being applied to each received packet, so it should be *fairly* easy to see if the frequency is drifting.
Again with my home brew Arduino transmitter I added a "calibration factor" to the transmitted frequencies to bring that statistic as close to zero as I could.
1 Number 2 - Radio frequency error.
-
Otherwise how does a new transmitter in a set-up that already has eg an ISS know how to time its packet transmissions and to sequence its frequencies? Surely the console only listens to one frequency at a time (before it hops to the next one I mean)? Maybe some one can explain?
OK. The following is based on work by dekay and several others: And the actual Davis algorithm might be slightly different (we have no way of knowing), but generally has to work this way:
In the US version, 51 frequencies in the 915 MHz band are used. There is a set sequence for these (hopping around in the band), used by every Davis transmitter. A short example would be 911.5, 902.35, 912.00, 923.00, 915.00, 906.50, etc. etc. for 51 different frequencies. Those are nominal, specific frequencies and at any given time, and any given temperature, any transmitter might (for example) actually transmit on 911.41375 or 911.58625 when it was "specified" to be transmitting on 911.50000. That frequency correction factor would be the same for any specified frequency of that particular transmitter, near that time, but would vary with temperature, etc. But another Davis transmitter, sitting at the same place, same temperature, etc, would have a different specific frequency correction factor (i.e., a different offset from the specified nominal frequency).
But just think of 51 frequencies on a specified non-linear sequence. [Footnote: Europe only uses 4 frequencies]
The transmitter steps (hops) through and transmits on that sequence of frequencies at an interval specified by the "Transmitter ID". There are 8 of those IDs. ID #1 specifies an interval of 2.5 seconds. ID #2 an interval of 2.5625 seconds, and so forth by steps of 1/16 second (.0625) until ID #8 is 2.9375 seconds between transmissions on successive frequency "hops".
Refer to the short example of frequency sequence above:
911.5, 902.35, 912.00, 923.00, 915.00, 906.50
Now, start up the receiver (Console). Pick a frequency to listen on (911.5), and listen for perhaps a long time. [Doing the math, 50 x 2.9375 ~~ 2 minutes 27 seconds] If you don't receive anything, assume there's no transmitter out there, and keep listening.
If you receive something (a valid packet) on 911.5, then quickly start listening on 902.35. You should receive a packet within 2.9375 seconds (ID #8). For purposes of this tale, assume you receive it at 2.5 seconds - so there's a transmitter on ID #1. Now, you can set up to receive (in the sequence of the next 49 frequencies, at 2.5 second intervals) from that transmitter.
MEANWHILE you have to ALSO keep listening, to see if there is a transmitter on any or all of the other 7 IDs. That requires listening on the same frequency (902.35) at 2.5625 seconds, 2.625, 2.6875, etc. And if you receive a packet, you know there's another transmitter on the associated ID - up to a total of 8 of them. So, set up to also receive (in the sequence of the next 49 frequencies, at the appropriate interval different from 2.5 seconds) from that transmitter.
Remember: Those packets you receive from different transmitters, may have different frequency offsets from the nominal specified frequency. So, you have to arrange to measure the frequency offsets (a topic for a different discussion), and keep track of them -- and they change with changing temperature.
Now, throw in that the operator may suddenly remove the transmitter with ID #1. Or change it's ID. Or reboot the console...............
I hope I got that right. Questions?
-
Excellent explanation, dalecoy. I knew each transmitter was broadcasting on multiple frequencies but wasn't certain exactly how this was accomplished.
So, if I understand this correctly, since my ISS is on ID #6 it should broadcast a packet every 2.8125 seconds. The console listens for that exact interval and if, for some reason, nothing is there within 2.8125 seconds, the packet is missed (dropped) and the console tunes into the next frequency (which is stored in an array and the index tells the console which array key to request). If too many packets are dropped sequentially, a re-sync is attempted. If the re-sync operation fails after 10 minutes then the console indicates a lost signal with an "L" flashing in the lower right and will attempt to re-sync with the transmitter at that ID in 15 minutes. Correct?
How does cold weather affect the timing of the packet? Is it that the clock in the transmitter drifts and sends packets slightly late?
-
There are actually TWO different CLOCKs, one in the ISS transmitter and one in the Console receiver and they are NOT truly "synched" because there is no feedback between them.
-
There are actually TWO different CLOCKs, one in the ISS transmitter and one in the Console receiver and they are NOT truly "synched" because there is no feedback between them.
Yes, but it would seem that only the clock in the transmitter is affected by cold. How would a clock inside a console in a climate-controlled room drift only in cold weather? My guess is that it expects the packet within a certain time window and doesn't get it because the transmitter's clock is slightly off. Perhaps the Vue is more lenient and waits longer (along with possibly applying the observed difference to future packet reception timing)?
-
How does cold weather affect the timing of the packet? Is it that the clock in the transmitter drifts and sends packets slightly late?
The console is actually listening slightly before (and after) the 2.8125 timing mark. Note that how much is "slightly" depends on how many transmitters, and on what IDs, it's listening. [So, more transmitters means less time that the console can spend on each transmitter, within the 2.x second windows]
Both the timing and the frequency are affected (equally %) by the cold. But because the timing is relatively broad (there's lots of time in 1/16th of a second), the actual critical effect is likely on the frequency.
So, the console loses packets (it's listening on a frequency slightly different from the transmitter's drifted frequency). Then decides it has to spend additional time trying to figure out the new frequency offset (for that transmitter). Or, ultimately, declare it "lost" and try to re-acquire.
-
Perhaps the Vue is more lenient and waits longer (along with possibly applying the observed difference to future packet reception timing)?
If your head hurts from thinking about all of this....
Consider that the VP2 console has a smaller memory than the Vue console. That memory is used to store data and instructions (firmware). It's well known that the VP2 console is so memory-constrained that any addition to it's instructions are limited to the minimum possible things. The instructions must be the most simple ones to do the job. And any additions are essentially impossible.
My best guess is that the Vue memory allows a lot more instructions to handle this transmitter reception stuff. That is, the Vue is simply smarter about what to do, etc.
As a forinstance - maybe the Vue console can start the difficult process of looking for transmitter frequency drift after seeing just one or two missed packets - where the VP2 console must take the easier approach of just declaring that lock has been lost, and starting over with that transmitter sync. Please note that this is a speculative example, and I don't know what the firmware actually does.
-
Surely the console only listens to one frequency at a time (before it hops to the next one I mean)?
That's correct - but it can very rapidly change the frequency it's listening to.
Maybe the transmitters don't talk to each other, but surely they listen to each other (fsvo listen at least). Otherwise how does a new transmitter in a set-up that already has eg an ISS know how to time its packet transmissions and to sequence its frequencies?
Still wondering about "fsvo", but...
Note that the transmitter doesn't have to know anything about anything, except for the setting of the dip switches.
Also, I'm told that European systems (in the 868 MHz band) use only four frequencies. That wouldn't require much change in the firmware, and would speed things up a bit - but be more susceptible to outside interference.
-
Here is some food for thought:
According to the FCC fillings for both consoles (internal Pictures);
Both consoles use the same processor - ATMEGA128L. The VP2 processor uses an external crystal (shown in the pictures), the Vue apparently uses the internal RC oscillator of the processor (no external crystal shown in the pictures). Along with keeping up with transmitter frequency drift, both would have to somehow timestamp the packets in order to implement a PLL or PID algorithm to keep up with timing errors. The VP2 would have to determine the frequency error, calculate a new receive frequency (for each transmitter) and save it into an array. For the Vue, it can read the frequency error direct and save it into an array (for each transmitter) and simply write the accumulated value back to one register to be applied next time around. No matter how you look at it, the Vue would be faster at doing this than the VP2 in the case of frequency error. They would require the same amount of time for timestamping packets assuming they both run at the same processor speed.
I'll go back to sleep now........
-
dalecoy,
So, on one hand, we have the older and slower VP2 that struggles keeping up in cold conditions, particularly making frequency corrections in real time across multiple IDs. On the other we have the Vue -- a more capable unit with, perhaps, better firmware (something I posited awhile back in the CC1021 thread).
That still doesn't explain why some VP2 consoles experience this issue and others do not in identical weather conditions. Care to speculate?
-
That still doesn't explain why some VP2 consoles experience this issue and others do not in identical weather conditions. Care to speculate?
Do we have information on VP2 consoles having this issue when only receiving from one transmitter?
Assuming you are talking about VP2 consoles receiving from two transmitters, and situations with the same received-at-the-console signal strengths:
1. It turns out that the exact combination of Transmit IDs has some effect on the complexity of the situation (due to the timing). So, what were those choices? [I don't know what combinations are better than others, but I know there is an effect - how often does the console have to choose between 2 frequencies scheduled for the same exact time]
2. If the two transmitters react similarly to weather (~~equal frequency drift), that situation would be easier for the console to handle than if the two transmitters have different drift. [That might be due to different models, housing, location, mounting, or even just the fact that electronic components like resistors can typically vary by 5%]. And there's no easy way to tell if that is the case.
3. Do we know what else the console is continually doing, in addition to receiving? Feeding data to some kind of logger? Responding to software requests? Those things all take processor resources (cpu cycles), that are not available for the receiving-and-adjusting tasks.
Obviously, if a mild form of the problem occurs, but the console recovers and the operator doesn't notice, then "everything's OK".
And clearly, more than 2 transmitters......
-
Do we have information on VP2 consoles having this issue when only receiving from one transmitter?
Yes, zackdog said he had issues with a single ISS. He later added a temperature station, but not before experiencing cold related outages with 1 ID.
3. Do we know what else the console is continually doing, in addition to receiving? Feeding data to some kind of logger? Responding to software requests? Those things all take processor resources (cpu cycles), that are not available for the receiving-and-adjusting tasks.
I've actually experienced the "lost signal" status on the console both ways: with a logger (WeatherLink IP) polled by WeatherCat software and as a standalone console with no logger connected. I was receiving 2 transmitters in both instances.
And clearly, more than 2 transmitters......
miraculon, who lives in northern Michigan, has 6 transmitters and 2 VP2 consoles he says do NOT experience dropouts. He would have to confirm how many of those transmitters each console receives, but I think it's pretty safe to assume at least one of those consoles has more than 2 IDs selected.
Not trying to be a pain in the rear. Just trying to refine the most repeatable aspects of the problem which I would guess to be some combination of component tolerances, a poor QC/QA process, and hardware/firmware already at the limits of its capabilities.
-
Not trying to be a pain in the rear. Just trying to refine the most repeatable aspects of the problem which I would guess to be some combination of component tolerances, a poor QC/QA process, and hardware/firmware already at the limits of its capabilities.
Understood. You asked for speculation about some factors, and I provided some.
I agree with your speculation about component tolerances and hardware/firmware at the limits, and would add individual siting factors, local RF environment, and peopleware.
I'm a bit skeptical about the role of QC/QA - I would not expect the individual products to be tested at the temperature limits.
-
I'm a bit skeptical about the role of QC/QA - I would not expect the individual products to be tested at the temperature limits.
I was thinking strictly of the components themselves and/or the assembly process. Usually there is a control process to weed out substandard units.
-
This has been an interesting topic.
I'm a bit skeptical about the role of QC/QA - I would not expect the individual products to be tested at the temperature limits.
I was thinking strictly of the components themselves and/or the assembly process. Usually there is a control process to weed out substandard units.
So, what's your estimate of the number of reports that Davis has received, regarding cold-weather signal dropouts?
And how many VP2 systems do you suppose that Davis has manufactured?
-
miraculon, who lives in northern Michigan, has 6 transmitters and 2 VP2 consoles he says do NOT experience dropouts. He would have to confirm how many of those transmitters each console receives, but I think it's pretty safe to assume at least one of those consoles has more than 2 IDs selected.
I would think even if each console isn't set up to receive all the transmitters, the extra signals would provide a certain amount of interference, thus befuddling* the console to some extent.
*Sorry for my lack of technical jargon.
-
So, what's your estimate of the number of reports that Davis has received, regarding cold-weather signal dropouts?
And how many VP2 systems do you suppose that Davis has manufactured?
The total units produced question is probably better directed toward johnd. But my guess would be in the 10-25 thousand range. That wouldn't include supplemental consoles or transmitters, just base systems.
Given the qualifiers necessary to experience the problem, I'd say dozens have reached out for support to Davis. But for every one that is willing to do so, there's got to be at least 10, 50, maybe even 100 that don't, especially since the problem may not happen during the warranty period. I live just a few blocks from Lake Superior and didn't really notice the problem until this year. 2 warm winters previous to that didn't consistently expose it.
-
Maybe I should revise the total VP2 stations produced to 50-100k given we're talking worldwide. But, I'm just spit balling here.
-
I'd say dozens have reached out for support to Davis.
I'd guess fewer than that, but - if we say TWO dozen, then...
That's roughly an average of two reports per year.
If we assume 100,000 units, then that's 0.024%
In a non-life-safety product..........
-
Has anybody with the problem actually checked on their VP2 console to see if the frequency correction being applied is getting larger in cold weather? And if it is showing a larger value than usual, warming a transmitter to see if it comes back to a smaller value?
-
....to see if the frequency correction being applied is getting larger in cold weather?
Note that it could actually be getting smaller. It's the change that's a factor here.
-
I'd say dozens have reached out for support to Davis.
I'd guess fewer than that, but - if we say TWO dozen, then...
That's roughly an average of two reports per year.
If we assume 100,000 units, then that's 0.024%
In a non-life-safety product..........
Well, if we're talking 100k units, then I'd up my report estimate to the low hundreds.
In your initial calculations, you forgot to multiply the reported cases. I'm guessing you don't believe that the quantity of support interactions == the quantity of VP2 owners affected. Let's assume that a "high friction" issue such as this one would be 1 report per 50 customers affected (1:50 ratio) which is a middle range estimate between 1:10 and 1:100. So, at 200 support touches (again middle of the range "low hundreds"), that would be 10,000 people potentially affected or 10% of the customer base. That's somewhere in the ballpark I would think. Hard to say.
Here's a follow up question for you: what percentage of owners would contact Davis if the solder joints connecting the battery terminals to the board in every VP2 console came loose within 2 years?
I'd bet 5% (tops!) for an issue that affects 100% of consoles eventually. And just like in the case of cold weather drop outs, there are going to be some owners who never notice for one reason or another. Regardless, that's a 1:20 ratio for a higher profile, easier to comprehend, lower friction issue.
For something immediately obvious, like a cracked display out of the box, I'd expect closer to 1:10 or less. Most people would just return it to the dealer though.
So, no, I don't think support requests potentially representing 10% of the customer base, give or take, is a vanishingly small issue.
Full disclosure: I've spent the last 20 years in the IT support field, including consulting for businesses.
-
Full disclosure: I've spent the last 20 years in the IT support field, including consulting for businesses.
We have somewhat similar backgrounds.
Of course, I was talking about reported instances, and you are talking about affected installations. Quite different topics.
And reports of IT system problems are almost always easily reproducible, while the problem under discussion here is not so easily reproduced - particularly based on a few user reports that are short on details.
I know you understand that, if users experience a problem but nobody reports it, it doesn't get fixed. And that problem-investigation-and-fix resources get allocated based on the number and severity of reports.
What's your evaluation of the severity of this signal dropout issue? [Compared to solder joints connecting the battery terminals to the board in the same number of VP2 consoles.]
And did you significantly increase the number and details of signal-dropout support calls to Davis?
Yes, this is an interesting problem, and (perhaps) indicates that the VP2 system does not completely meet the advertised specifications under the entire range of conditions and combinations of accessories.
If you were hired as a consultant to Davis, what would you advise them to do?
-
We have somewhat similar backgrounds.
Of course, I was talking about reported instances, and you are talking about affected installations. Quite different topics.
And reports of IT system problems are almost always easily reproducible, while the problem under discussion here is not so easily reproduced - particularly based on a few user reports that are short on details.
I know you understand that, if users experience a problem but nobody reports it, it doesn't get fixed. And that problem-investigation-and-fix resources get allocated based on the number and severity of reports.
What's your evaluation of the severity of this signal dropout issue? [Compared to solder joints connecting the battery terminals to the board in the same number of VP2 consoles.]
And did you significantly increase the number and details of signal-dropout support calls to Davis?
Yes, this is an interesting problem, and (perhaps) indicates that the VP2 system does not completely meet the advertised specifications under the entire range of conditions and combinations of accessories.
If you were hired as a consultant to Davis, what would you advise them to do?
Posing speculative questions like "What's your evaluation of the severity of this signal dropout issue?" or "how many VP2 systems do you suppose that Davis has manufactured?" only to cleverly attempt to falsify any answer (which is non-falsifiable by nature since the facts are clearly unknown or the answer can only be subjective) isn't helping to clarify matters.
And, no, IT support issues are not "almost always" reproducible any more than car troubles are almost always reproducible. There's a fair number that are all around vexing.
Let's simplify this. In the end, it doesn't matter how many users are aware or have reported it or even whether Davis is aware. If a product owner cannot operate their device normally according to the instructions and stated limitations in the manual without repeatable failures, the product is defective. Period.
I agree with your speculation about component tolerances and hardware/firmware at the limits, and would add individual siting factors, local RF environment, and peopleware.
Let's examine your list of possible confounding factors (reasons why the operator or environment could be at fault).
First up, the idea that there may be an unfavorable "RF environment". Not only has no evidence has been presented to support this contention, but, in fact, the available evidence goes the other way. We know that signal strength is acceptable even under the conditions in which failure is likely. Background noise has also been shown to be low. The Vue console's 0 resync count compared to an adjacent VP2's console's positive resync count is further evidence that the issue is not external.
You mentioned siting. Is placing an ISS 60' away from the console through normal residential wood-frame construction considered poor siting? This would seem especially dubious given the reception statistics mentioned above.
Up next we have "peopleware" (a vague, elastic term). This "peopleware" is active when the same person fires up their new Vue console and it operates normally under identical conditions causing failure in the VP2 console. Curious.
No reasonable or supportable alternative hypothesis has been forwarded to date as to why certain VP2 consoles fail in cold weather. We can speculate on the exact nature of the error(s) or exacerbating factors, but we have sufficient first-hand accounts, statistical data and expertise to conclude the responsibility primarily rests with the manufacturer.
-
we have sufficient first-hand accounts, statistical data and expertise to conclude the responsibility primarily rests with the manufacturer.
I agree.
Full disclosure: I've spent the last 20 years in the IT support field, including consulting for businesses.
If you were hired as a consultant to Davis, what would you advise them to do?
-
If you were hired as a consultant to Davis, what would you advise them to do?
Your question deliberately confuses roles. I'm a consumer of a defective product. Why should I offer the manufacturer free consultation, especially when they've shown not the slightest interest in understanding this issue (or other, less consequential issues)? Or was your thinly-disguised, patronizing point that I should take a moment to consider Davis' perspective? I assure you I've already carefully reviewed Davis' position on this matter.
If johnd, who's livelihood is connected to selling Davis equipment, can remain fair and impartial, why can't others who presumably lack a conflict of interest refrain from reflexively minimizing and blame shifting?
-
If you were hired as a consultant to Davis, what would you advise them to do?
... I'm a consumer of a defective product....
.... I assure you I've already carefully reviewed Davis' position on this matter....
I believe I understand.
I'm happy to have answered some questions.
-
DEVILS ADVOCATE: Opinions do not equal facts.
-
DEVILS ADVOCATE: Opinions do not equal facts.
I'm not sure what that means. You'll need to clarify.
I'll point out, though, there are sufficient facts in this thread to make a prima facie case for design failure. Of course, there are plenty of opinions too!
-
OK. The following is based on work by dekay and several others: And the actual Davis algorithm might be slightly different (we have no way of knowing), but generally has to work this way:
OK, many thanks for the explanation. That's broadly the picture I had, but it's at the next level of detail that I start getting more lost.
So, just starting off thinking about a single transmitter on #1: AIUI, data is transmitted in eg 20-byte packets with 8-10-byte payload & some of those bytes used for comms overhead, ie start/stop bytes etc. Also AIUI/BICBW there's a trade-off of baud rate and sensitivity which, within limits, is up to the developer to decide on. But if eg 38.4K baud was being used and assuming in this case that bps = baud (not sure whether that's true or not, but if...) then each packet takes ~4ms to transmit.
Then do we think that each complete packet is transmitted on a single frequency, which I'm guessing would simplify the design? And then the transmitter sleeps for a relatively long period, which I thought was how it manages to use so little battery/supercap power. At what point will it hop to the next frequency? Maybe after 62.5ms? So the next packet arriving would arrive on the next frequency in the sequence? And so on? If this isn't the correct picture then how often do the frequencies change?
Now if there are multiple transmitters in play: My previous picture, which I know may well be wrong was that when a new transmitter starts up, it first listens on the primary frequency in the sequence and if it hears another active Tx then synchronises with that signal. Otherwise surely the console has to be listening on 50-odd (US) frequencies simultaneously, which sounds like a clever trick.
Sorry, I know that this is rather OT for this thread, but it would simply be interesting to learn in more detail just how the data comms actually work.
-
Each transmitter just round robins the set frequencies for the geography.
Each packet from a transmitter is sent on a different channel.
There is no link between transmitters, the id set determining the gap between transmissions. Because you have no control over when each transmitter starts it's sequence the gap variation between channels assures that the transmission collisions are minimised.
-
The baud rate is 19.2
The packet is transmitted on a single frequency.
The transmitter then sleeps for 2.5 seconds (if it's on ID #1) - and then transmits the new packet on the next frequency in order. [The frequency order is the same for all transmitters]
when a new transmitter starts up, it first listens on the primary frequency in the sequence
No, the transmitter doesn't listen. And there is no "primary frequency".
It transmits a packet on a frequency, sleeps for 2.5(+) seconds, and transmits a new packet on the next frequency in order.
That greatly simplifies the job of the transmitter - and complicates the job of the receiver.
Let me know what's confusing here.
-
Sorry, I know that this is rather OT for this thread, but it would simply be interesting to learn in more detail just how the data comms actually work.
Nope, not OT at all. I find it illuminating as well and applicable to this issue.
-
Now if there are multiple transmitters in play: My previous picture, which I know may well be wrong was that when a new transmitter starts up, it first listens on the primary frequency in the sequence and if it hears another active Tx then synchronises with that signal. Otherwise surely the console has to be listening on 50-odd (US) frequencies simultaneously, which sounds like a clever trick.
The way it is implemented on my transceiver, is that it:
1. Listens on a frequency for the transmission id you expect to hear.
2. If nothing is heard after a period of time, switch to the next frequency and listen again (there may be interference on the first frequency you pick).
3 Repeat 2. until you receive the transmission you want.
4. When you get that first packet, store the expected time for that channels next transmission, and..
5. Just before the next transmission is due, set to the expected frequency and switch on the receiver.
6. If the packet is received, repeat 4 & 5. If it is missed, then skip that channel on to the next frequency and expected time anyway.
You set the time for the next packet from the received time of the last, however if you miss one then you have to set the time to the last 'expected' time plus the interval - so you can see a timing error can accumulate from a missed or sequence of missed packets.
Of course the above is duplicated for each channel you want to receive. I set a timer interrupt for the next expected transmission from any channel, as soon as you receive a packet the receiver is switched off and an interrupt set for the next expected packet - that way you can receive packets on different frequencies quite close together in time.
-
Thanks, Mark. As I said earlier:
.... the actual Davis algorithm might be slightly different (we have no way of knowing), but generally has to work this way:
There's certainly a lot of ways for increased "smarts" in the firmware, with corresponding better performance in normal and off-normal conditions. Limited by the amount of firmware memory space available. The Vue console seems to be smarter than the VP2.