WXforum.net
Weather Station Hardware => Davis Instruments Weather Stations => Topic started by: miraculon on January 13, 2018, 02:34:51 PM
-
There has been a lot of discussion in other threads about reception of the VP2 vs VUE hardware.
The Texas Instruments datasheet for the CC1021 has a red "Not Recommended for New Designs NRND" at the top of each page. (NRND is an abbreviation for the Not Recommended for New Designs, sounds kind of redundant...)
I was browsing through TI's RF transceiver offerings, to see what is newer. I noticed that the CC1021 is -109dBm and all of their other offerings are better than -116dBm. The CC1021 is also the lowest data rate. Obviously, TI still supplies the part but it appears that there are newer options.
I didn't do an exhaustive search in capabilities, but it seems that there are parts listed on this page (http://www.ti.com/product/CC1021/compare#p367=Sub-1%20GHz&p1694=Smart%20RF%20Transceiver&o4=ACTIVE) that could replace the CC1021. (the pin counts are lower on some of these newer parts, which is typical but precludes "drop in replacement")
Has anyone opened a recent Davis console or SIM and looked at the RF chip? Are they still using the CC1021 across the board? My consoles/Envoys/SIMs are getting "long in the tooth" and probably have the CC1021.
I was wondering if the VUE might have gone with one of the newer parts with better sensitivity.
Greg H.
-
There has been a lot of discussion in other threads about reception of the VP2 vs VUE hardware.
The Texas Instruments datasheet for the CC1021 has a red "Not Recommended for New Designs NRND" at the top of each page. (NRND is an abbreviation for the Not Recommended for New Designs, sounds kind of redundant...)
I was browsing through TI's RF transceiver offerings, to see what is newer. I noticed that the CC1021 is -109dBm and all of their other offerings are better than -116dBm. The CC1021 is also the lowest data rate. Obviously, TI still supplies the part but it appears that there are newer options.
I didn't do an exhaustive search in capabilities, but it seems that there are parts listed on this page (http://www.ti.com/product/CC1021/compare#p367=Sub-1%20GHz&p1694=Smart%20RF%20Transceiver&o4=ACTIVE) that could replace the CC1021. (the pin counts are lower on some of these newer parts, which is typical but precludes "drop in replacement")
Has anyone opened a recent Davis console or SIM and looked at the RF chip? Are they still using the CC1021 across the board? My consoles/Envoys/SIMs are getting "long in the tooth" and probably have the CC1021.
I was wondering if the VUE might have gone with one of the newer parts with better sensitivity.
Greg H.
Anybody got an open VUE pcb where its components can be viewed?
-
The VUE console uses the CC1101. Not sure about the VUE ISS.
-
The VUE console uses the CC1101. Not sure about the VUE ISS.
Q: On a VP2 ISS, is it U41 or U21?
-
So 109 dBm on VP2 vs 116 on Vue. If correct could be the cold weather mystery answer.
-
So 109 dBm on VP2 vs 116 on Vue. If correct could be the cold weather mystery answer.
Just chasing that potential pink herring, then that would imply that the ISS signal was getting weaker in very cold conditions, which should have been evident from the RSSI figure**. Maybe openvista could eyeball some relative RSSI values (from the 2nd diagnostic screen) from VP2 vs Vue console. Of course it's slightly complicated with the Vue and VP2 being on different but related scales.
Must admit that I always think better on the VP2 scale, preferring to see RSSI≥30 for decent reception. I once worked out that:
VP2 = [(Vue + 100) / 1.5] + 20
Hopefully that formula is correct. In other words, the Vue ought to be -85dBm or better (less negative). But maybe the Vue is a bit more tolerant then and -90 or even -95dBm might be adequate. (Edit: Yes, those RSSI figures are quite a bit stronger than the threshold sensitivity, but I've never seen a VP2 console reliably pick up an ISS at less than low 20's RSSI or eg -92dBm, so obviously there are other factors like background noise involved.
** Really should have thought to ask the RSSI question at an earlier stage in the troubleshooting - grey cells must be dying off quicker than I'd like to think. :-(
And, one other afterthought: What I'm thinking about is looking for differences in RSSI between 'normal-reception' and very cold conditions to see if the transmitter really is getting weaker.
-
Q: On a VP2 ISS, is it U41 or U21?
U41...
-
Anybody got an open VUE pcb where its components can be viewed?
A guy here is fixin' to change out a supercap on the Vue. http://www.wxforum.net/index.php?topic=33576.0
From the picture with the cap exposed I can't see how easy it would be to get to the other components.
-
Maybe openvista could eyeball some relative RSSI values (from the 2nd diagnostic screen) from VP2 vs Vue console.
Sorry, just saw this thread now.
Over in the other discussion on signal dropouts (https://www.wxforum.net/index.php?topic=33496.150 (https://www.wxforum.net/index.php?topic=33496.150)) I had noted that the average RSSI on my VP2 console for the ISS was upper 50s and for the wind was mid 40s. Given that 60 is the theoretical maximum value, that would equate to above average to near perfect signal strength for both transmitters.
On the Vue the ISS reception averages upper -60s (dBm) to low 70s and the wind transmitter averages mid to upper -70s when its 10F or colder. So the Vue would seem to indicate the overall signal quality is actually worse (scale from 0 to -100 where 0 is the strongest signal), but still well within the range of connectivity.
A complicating factor is that when it's really cold, and the VP2 console disconnects from, for example, the ISS transmitter (the closest, strongest signal), often it won't reconnect unless you manually throw the VP2 console into setup mode (or, according to ValentineWeather, use WeatherLink to reset). This is despite the fact that the console attempts to reconnect automatically every 15 minutes. Even stranger is that if you let the outage go long enough (several hours) eventually the console will reconnect. Yet, I've always been able to get it to reconnect immediately if I place it into setup mode.
One would assume that the wind transmitter would be subject to the longest outages since it's the furthest transmitter and measures weaker in both consoles. However, while its outages tend to be more frequent, they typically don't last nearly as long (minutes) as the ISS outages (hours).
Also, I've never lost both transmitters' signals simultaneously. If this problem is the result of poor signal strength in cold weather, why would one transmitter always stay connected regardless?
So, it would seem that the VP2 console outages aren't simply due to signal sensitivity. There would seem to be some firmware issues in play too.
-
Doubt it would be as simple as firmware when the hardware RF chips actually have different dB sensitivity with the Vue 116 vs 109 on VP2.
-
Doubt it would be as simple as firmware when the hardware RF chips actually have different dB sensitivity with the Vue 116 vs 109 on VP2.
I didn't say it's only firmware. But if it's purely signal sensitivity, why does throwing the console into setup mode so often fix it? And why doesn't the console find the signal when it goes to automatically reconnect every 15 minutes? Either way an "R" flashes in the lower right. Both actions are handled by the firmware.
Also why does the console drop the strongest signal while keeping the weakest signal online for hours at a time? Why does it never drop both?
-
Perhaps the VP2 is only compensating for one of the transmitter's frequency error. It keeps doing this until the other transmitter can no longer be received. Placing the console in Setup does away with the acquired frequency error data and allows it to reconnect with both transmitters.
-
Considering that the magnitude of this problem seems to only be coming to light fairly recently, while the VP2 has been in wide use for around a decade and a half, I wonder if any one can show if the problem has existed all along or when it appeared. Looking at the other thread, I see graphs showing the problem has been around since at least October 2015. The last firmware update appears to be March 2014.
-
Perhaps the VP2 is only compensating for one of the transmitter's frequency error. It keeps doing this until the other transmitter can no longer be received. Placing the console in Setup does away with the acquired frequency error data and allows it to reconnect with both transmitters.
Yes, but the firmware should do that automatically. Why require user intervention?
If it were the case that the console needs to clear all data from the display so it can dedicate its resources to reconnection, then why not set a limit like 3 failed resync attempts and then enter setup automatically?
Either way, our discussion is centering around firmware limitations.
-
Has anyone opened a recent Davis console or SIM and looked at the RF chip? Are they still using the CC1021 across the board? My consoles/Envoys/SIMs are getting "long in the tooth" and probably have the CC1021.
Looking over this thread again, I see where someone verified that the Vue is using a different chip, but unless I'm missing it, I don't see where anyone verified the newer VP2 consoles are still using the CC1021. Unless someone verifies, I'm not sure we can just assume that they are and that that's the problem. I suspect Davis tries to keep their component inventory and design differences between the different models as small as possible.
Who knows, maybe the problem became more noticeable when or if Davis switched to the new chips in the VP2.
-
If Davis changed RF chips in the VP2, they didn't notify the FCC.........
-
If Davis changed RF chips in the VP2, they didn't notify the FCC.........
Are they required to report changes in the RF chip if the approved specifications aren't exceeded, or does every component change require retesting?
I've found some docs like this: https://fccid.io/IR2DWW6312/Test-Report/Test-Report-474646, but I'm not finding where what RF chip is used is specified, and I'm not up on FCC requirements.
-
If Davis changed RF chips in the VP2, they didn't notify the FCC.........
Are they required to report changes in the RF chip if the approved specifications aren't exceeded, or does every component change require retesting?
I've found some docs like this: https://fccid.io/IR2DWW6312/Test-Report/Test-Report-474646, but I'm not finding where what RF chip is used is specified, and I'm not up on FCC requirements.
Title 47 CFR 2.1043(a) states in part:
changes to the basic frequency determining and stabilizing circuitry (including clock or data rates), frequency multiplication stages, basic modulator circuit or maximum power or field strength ratings shall not be performed without application for and authorization of a new grant of certification.
-
If Davis changed RF chips in the VP2, they didn't notify the FCC.........
Are they required to report changes in the RF chip if the approved specifications aren't exceeded, or does every component change require retesting?
I've found some docs like this: https://fccid.io/IR2DWW6312/Test-Report/Test-Report-474646, but I'm not finding where what RF chip is used is specified, and I'm not up on FCC requirements.
Title 47 CFR 2.1043(a) states in part:
changes to the basic frequency determining and stabilizing circuitry (including clock or data rates), frequency multiplication stages, basic modulator circuit or maximum power or field strength ratings shall not be performed without application for and authorization of a new grant of certification.
Thanks. I guess that's more or less definitive. Not being a lawyer and reading all the exclusions and such, I don't know if it can be argued that even though Davis changed a part (that I assume itself has an FCC ID, and could possibly be considered an acceptable replacement?), but all the ratings listed remain the same, that it doesn't require recertification. If they did change the chip, it would assumedly still have the basic characteristics of the old units to remain compatible, as long as it doesn't exceed power or such.
Anyway, I doubt this is a chip problem. The characteristics of the CC1021 didn't suddenly become inadequate when TI declared it NRND.
I could be wrong, the problem could have existed since the release of the VP2, and the correlation between the cold and dropouts just happened to be made fairly recently, as far as I can tell, despite the years in use and the popularity of the station. It is possible, unexplained dropouts have existed all along. Just seems that if that large of a percentage of units are affected as it would seem, it would have been apparent before now.
Just curious, has anyone compared the reception of an affected VP2 console from a Vue ISS?
-
I could be wrong, the problem could have existed since the release of the VP2, and the correlation between the cold and dropouts just happened to be made fairly recently, as far as I can tell, despite the years in use and the popularity of the station. It is possible, unexplained dropouts have existed all along. Just seems that if that large of a percentage of units are affected as it would seem, it would have been apparent before now.
Just curious, has anyone compared the reception of an affected VP2 console from a Vue ISS?
Yes, I made a detailed post on this very page (http://www.wxforum.net/index.php?topic=33638.msg341623#msg341623 (http://www.wxforum.net/index.php?topic=33638.msg341623#msg341623)) comparing the VP2 console reception to the Vue.
As far as how old this issue is, here's a thread dated January 2014: https://www.wxforum.net/index.php?topic=21526.msg211815;topicseen#msg211815 (https://www.wxforum.net/index.php?topic=21526.msg211815;topicseen#msg211815). Notice "cold" is only mentioned one time in that thread. It's framed as a battery problem even though the issue is occurring during a cold snap in the winter and he had replaced the CR123a battery just weeks before.
Mid-identifying the cause can be expected since the problem is counter-intuitive. Doubt is probably the most natural reaction to it. I doubted until I noticed I had received 2 out of 2 consoles 2.5yrs apart with the same issue). Searching for something people don't report or don't consistently describe is difficult.
Here are some other threads going back as far as 2009 that could be the same issue:
https://www.wxforum.net/index.php?topic=13811.msg134822#msg134822 (https://www.wxforum.net/index.php?topic=13811.msg134822#msg134822)
https://www.wxforum.net/index.php?topic=6115.25 (https://www.wxforum.net/index.php?topic=6115.25)
-
Just curious, has anyone compared the reception of an affected VP2 console from a Vue ISS?
Yes, I made a detailed post on this very page (http://www.wxforum.net/index.php?topic=33638.msg341623#msg341623 (http://www.wxforum.net/index.php?topic=33638.msg341623#msg341623)) comparing the VP2 console reception to the Vue.
Maybe I'm missing something on the other thread, but my question is if anyone who has a Vue ISS and a VP2 console notes the same problem with reception from the Vue ISS that they do from the VP2 ISS. I know you have a VP2 console, a Vue console and a VP2 ISS, are you saying you have a Vue ISS also? People with VUEs probably don't have much reason to buy a VP2 console. I'm not sure what it would prove, but as I say, I was just curious.
Thanks for the other links I'll have to go back and review the other threads and see if there's any new clues there, thought I doubt it. About the only way would be if everyone with a VP2 had records for the life it that showed what percentage of consoles have the problem, when it started or if had always been there to get some kind of an idea. Either that, or everyone who experiences the problem try to get an answer and a fix from Davis.
-
As far as how old this issue is, here's a thread dated January 2014: https://www.wxforum.net/index.php?topic=21526.msg211815;topicseen#msg211815 (https://www.wxforum.net/index.php?topic=21526.msg211815;topicseen#msg211815). Notice "cold" is only mentioned one time in that thread. It's framed as a battery problem even though the issue is occurring during a cold snap in the winter and he had replaced the CR123a battery just weeks before.
The problem here is that the thread continues on into March when The sky was blue, temp. 70, time 1:00PM, no excuse in solar panel not to carry the ISS.
which leads me to believe it's not the same problem, at least not entirely if at all.
Unfortunately, the thread ends soon after with no apparent resolution, unless maybe the station finally got over its frostbite. :-)
-
About the only way would be if everyone with a VP2 had records for the life it that showed what percentage of consoles have the problem, when it started or if had always been there to get some kind of an idea. Either that, or everyone who experiences the problem try to get an answer and a fix from Davis.
As zackdog and I pointed out several times in the other thread, most people DO have a complete record of signal strength. It's in their WeatherLink archives. They can graph temperature and signal strength and see when those two lines correspond.
The question then becomes how many people live in an area that gets cold enough often enough to notice the problem and/or how many will check WeatherLink in the fashion described above? zackdog issued the challenge to everyone to check their records. How many people responded even if just to prove him wrong? My count is 0.
I'd bet the majority of Davis' customers have never even heard of WxForum. How many farmers have you seen on this forum?
As for those that do come here perhaps they don't want to be told it's only them, or it's only been happening recently, or they set their ISS up wrong, or they can't expect batteries to operate at 10F or that Davis would have fixed it by now or any of the myriad excuses those of us who have reported this issue have been given.
Yes, it's more likely those affected contacted Davis rather than publicly make their case, especially if they were uncertain what was going on.
-
As zackdog and I pointed out several times in the other thread, most people DO have a complete record of signal strength.
Not really. They have a record of successful packet reception, which isn't quite the same thing as signal strength (RSSI). You can have a decent signal (say RSSI=30 or more for a VP2 or better than -85dBm for a Vue), but frequency or timing deviations that the receiver cannot lock on to or eg significant interference.
The RSSI information is available, just a shame that it's not logged.
Edit: Meant to add: This is pertinent to what I think may be happening with this low temperature issue. Your ISS signals look strong enough normally that I doubt they're weakening sufficiently to cause dropouts (though looking at the RSSI when dropouts are pending - but obviously before they actually happen - would help clarify that). I suspect that some other aspect of the signal profile is causing the problem, possibly that low temps are causing some drift in signal frequency or timing, which is outside the parameters that the VP2 console can cope with. Either the circuitry of the Vue is somehow more forgiving of the deviations or maybe it can recover much more quickly from any dropouts that do happen.
-
As zackdog and I pointed out several times in the other thread, most people DO have a complete record of signal strength.
Not really. They have a record of successful packet reception, which isn't quite the same thing as signal strength (RSSI). You can have a decent signal (say RSSI=30 or more for a VP2 or better than -85dBm for a Vue), but frequency or timing deviations that the receiver cannot lock on to or eg significant interference.
The RSSI information is available, just a shame that it's not logged.
Well, if you see packet reception drop to nothing for a period -- graphs that ValentineWeather and zackdog have posted several times -- it's safe to assume that there is no connection between receiver and transmitter. Those periods just happen to correspond to cold weather.
-
Here's what has been put together in two separate threads so far through a combination of first-hand testimony and statistical data:
1. We have graphs connecting total loss of signal to cold temperatures starting around 10F (give or take 5F).
2. We have visual confirmation of the outage on VP2 consoles during at least some of these periods (others occur in the wee hours of the night or when the owner is otherwise away).
3. We know it occurs across various vintages of transmitters and consoles (going back to at least mid 2013).
4. The issue is not limited to particular channels.
5. The issue persists with new transmitter batteries.
6. Consoles can be moved to more favorable spots (based on reception statistics) and still experience reception difficulties despite being well within range
7. The reception problems disappear once a Vue console is acquired and placed in the same spot
8. The Vue console appears to have a different receiving chip than the VP2 with greater signal sensitivity
9. There appear to be some software routines in the firmware that at least prolong outages in the VP2 console.
All signs point to design error even if it's mostly component tolerances (meaning some owners experience it and some owners don't despite having "identical" components). If it's truly reception based, as this thread would suggest, then it would follow that certain owners in favorable RF environments (combination of close proximity and lack of obstacles) might not experience it while others would.
For those who do, they also need to live in a qualifying climate, observe the issue, feel motivated to solve the issue (rather than let it go because it may happen infrequently), then have the confidence to go public with their problem. If any of those aren't true, we almost certainly won't know about it.
-
As zackdog and I pointed out several times in the other thread, most people DO have a complete record of signal strength. It's in their WeatherLink archives. They can graph temperature and signal strength and see when those two lines correspond.
The question then becomes how many people live in an area that gets cold enough often enough to notice the problem and/or how many will check WeatherLink in the fashion described above? zackdog issued the challenge to everyone to check their records. How many people responded even if just to prove him wrong? My count is 0.
I'd bet the majority of Davis' customers have never even heard of WxForum. How many farmers have you seen on this forum?
As for those that do come here perhaps they don't want to be told it's only them, or it's only been happening recently, or they set their ISS up wrong, or they can't expect batteries to operate at 10F or that Davis would have fixed it by now or any of the myriad excuses those of us who have reported this issue have been given.
Yes, it's more likely those affected contacted Davis rather than publicly make their case, especially if they were uncertain what was going on.
This forum has been a very active forum for many years, and I would think most people live where the temp at least periodically gets down to 10 degrees.
If people aren't reporting the problem, its probably because they're not experiencing the problem. The lack of response to Zackdog's challenge helps back that up. People, especially the less interested and involved, are less likely to follow and respond to a thread about a problem they aren't having. I recall at least one person saying they don't have the problem.
People don't necessarily even have to have WeatherLink. Most people do seem to connect to their computers and/or the internet, and do diligently check their data for any anomalies. Nightly winter lows are especially things people look for and would notice. Even if other software shows flatlines rather than blanks, they're still going check that out, especially as it would be happening to all weather variables and presumably would stick out.
People do try to help each other out here, and that often involves speculation, ideas like lithium batteries can't be expected to operate below 20 are considered and discounted. What you are calling "excuses" are people trying to make sure common errors aren't being committed. That is a reasonable, and even necessary, aspect of troubleshooting. When people suggest someone looking for help check certain things, I don't see it as being accusatory, or as definitively stating that that's what the problem is.
People are looking for evidence and correlation to try to figure things out. If I speculate that the problem seems to have become more apparent recent years, and no one presents any compelling evidence to the contrary, I don't see why that should offend anyone. Others have stated that they don't experience the problem, so however widespread it may be, it doesn't appear to be universal, despite however it may look to you. Of the links you gave earlier, I saw one case were there appeared to be direct evidence that there was a link to dropouts and the cold. Even then you need to consider whatever incidental factors there may be; such as cold happening to coincide with the longest nights, or such. Despite all that, I'm not trying to minimize or deny the problem to those who do experience it.
You came here looking for answers, yet don't seem to appreciate ideas and speculation of what the problem may be. You seem to believe that Davis knows about the problem, with no evidence, and even if they don't, they're still guilty, and that they're the only ones who can solve the problem. Well, you're most likely correct about the last point at least. But as someone else has said, you're unhappy with Davis, but won't tell them. So you've presented your evidence, and I think it is pretty conclusive and valuable. Unfortunately, at least so far, it doesn't tell exactly what is causing the problem, or how widespread it is.
-
Here's what has been put together in two separate threads so far through a combination of first-hand testimony and statistical data:
1. We have graphs connecting total loss of signal to cold temperatures starting around 10F (give or take 5F).
...
8. The Vue console appears to have a different receiving chip than the VP2 with greater signal sensitivity
I'm still going to quibble with [1]. I don't believe that there's evidence that it's a loss of signal strength, but a loss of signal lock/synch. You may think that it amounts to the same thing, but there's a different cause in each case and a loss of lock isn't explained by superior sensitivity of the Vue console (though a different receiver chip, if there is one, might have other benefits). OTOH there are other conceivable explanations, eg maybe the simpler transmitter spec of the Vue allows a simpler search pattern in the firmware for resynchs and hence quicker resynchs..
The question then becomes how many people live in an area that gets cold enough often enough to notice the problem...
Probably not many outside of the US (excluding much of the south) and Canada I'd have guessed. The main exception in Europe would be Scandinavia and around the Alps (and Eastern Europe too, but probably not too many Davis stations there). But here in the UK, for instance, which is hardly a warm climate, temperatures below -12C are pretty rare, certainly in all the main lowland areas where the great majority of the population live. So I'm unsurprised to have seen this rarely reported here.
-
OTOH there are other conceivable explanations, eg maybe the simpler transmitter spec of the Vue allows a simpler search pattern in the firmware for resynchs and hence quicker resynchs..
This was something I was thinking also. But the less sensitivity may also play some roll.
Davis techs need to know about the issue and look into it. Hope someone has taken it up with them.
-
But the less sensitivity may also play some roll.
But there's no evidence that I've seen cited anywhere that the signal was weak (on the contrary what openvista reports AIUI is that the signal was relatively strong prior to dropout) and so why would greater sensitivity at the margin make any difference?
But what I'm debating here is the technical cause of the apparent issue and not whether or not Davis should be engaged, if anyone should be motivated to do so.
-
Hell, I don't even have a dog in this fight, I'll call Brett Lane myself. Whether that helps or not....
-
Message sent.
-
The question then becomes how many people live in an area that gets cold enough often enough to notice the problem...
Probably not many outside of the US (excluding much of the south) and Canada I'd have guessed. The main exception in Europe would be Scandinavia and around the Alps (and Eastern Europe too, but probably not too many Davis stations there). But here in the UK, for instance, which is hardly a warm climate, temperatures below -12C are pretty rare, certainly in all the main lowland areas where the great majority of the population live. So I'm unsurprised to have seen this rarely reported here.
Yet there are many here, seems like a fair percentage actually, from northern US states, along with at least some from Canada and regions such as Norway. For every person commenting about their stations bottoming out or not at -40, you would think there would be at least a few others noting a problem that occurs at +10F. Plus, stations are said to be used in Antarctic research, I believe it's been claimed. While they don't post here, as far as I'm aware, you would think that such a problem with equipment being used by, I assume, scientists for scientific research would be noted by now.
[BTW, the quote you attributed to me was originally from OpenVista.]
-
I have one simple question:
The Vue has a Reception Diagnostic Screen (Screen 2) that shows the Current frequency correction factor. Does it do it for both of the transmitters or only one, or can you somehow choose which one to monitor?
-
The Vue has a Reception Diagnostic Screen (Screen 2) that shows the Current frequency correction factor. Does it do it for both of the transmitters or only one, or can you somehow choose which one to monitor?
Pretty sure you can choose - certainly you can on VP2 and it's usually the same on the Vue. Should be 2nd+Chill then left or right arrow to cycle through active transmitters (of which there will be 2 max on the Vue, but only when a 6332 Tx is being used).
-
The Vue has a Reception Diagnostic Screen (Screen 2) that shows the Current frequency correction factor. Does it do it for both of the transmitters or only one, or can you somehow choose which one to monitor?
Pretty sure you can choose - certainly you can on VP2 and it's usually the same on the Vue. Should be 2nd+Chill then left or right arrow to cycle through active transmitters (of which there will be 2 max on the Vue, but only when a 6332 Tx is being used).
Then my first test would be to see if the same frequency correction factor is being applied to both transmitters. Or is it distinctly different values as it should be.
Even TI's Design Note DN015 states:
Finally, note that in an RF network application each receiver should memorize the frequency offset value associated with each transmitting
node in order to apply the correct permanent offset when communicating with different nodes.
-
Here's what has been put together in two separate threads so far through a combination of first-hand testimony and statistical data:
1. We have graphs connecting total loss of signal to cold temperatures starting around 10F (give or take 5F).
...
8. The Vue console appears to have a different receiving chip than the VP2 with greater signal sensitivity
I'm still going to quibble with [1]. I don't believe that there's evidence that it's a loss of signal strength, but a loss of signal lock/synch. You may think that it amounts to the same thing, but there's a different cause in each case and a loss of lock isn't explained by superior sensitivity of the Vue console (though a different receiver chip, if there is one, might have other benefits). OTOH there are other conceivable explanations, eg maybe the simpler transmitter spec of the Vue allows a simpler search pattern in the firmware for resynchs and hence quicker resynchs..
OK, fair enough. We certainly appear to be having a syncing issue. I can see other possible benefits to the Vue console such as better processing and more complimentary, optimized firmware that prevents signal locks from breaking. Perhaps Davis learned from earlier failures.
Either way, we seem to have an issue that is baked into the console to one degree or another.
To the average affected VP2 user the solution is always going to be the same: get a Vue console. That is, of course, unless Davis spontaneously decides to redesign the RF section of their 13 yr old console. I'm not holding my breath.
-
Did you run the test that I inquired about?
-
Did you run the test that I inquired about?
I'm not sure if this question is directed at me, but I'll go ahead and answer. Yes, I ran the test. However, it's +31F (~0C) here now so this may or may not be the case at colder temps. I haven't really paid a lot of attention to this parameter other than to notice that it hops around on the VP2.
Indeed, there are discrete, navigable screens for each active channel. The frequency correction is 0 for both transmitters on the Vue console and holding steady. On the VP2, it vacillates between +1 and +2 for the ISS. The wind transmitter at one point was showing 1 and then later 3. The factors do not seem to correspond across channels.
-
Did you run the test that I inquired about?
I'm not sure if this question is directed at me, but I'll go ahead and answer. Yes, I ran the test. However, it's +31F (~0C) here now so this may or may not be the case at colder temps. I haven't really paid a lot of attention to this parameter other than to notice that it hops around on the VP2.
Indeed, there are discrete, navigable screens for each active channel. The frequency correction is 0 for both transmitters on the Vue console and holding steady. On the VP2, it vacillates between +1 and +2 for the ISS. The wind transmitter at one point was showing 1 and then later 3. The factors do not seem to correspond across channels.
Are you looking at item (2.) Radio frequency error of the last packet received successfully. Or item (3.) Current frequency correction factor. (Just checking.)
-
Did you run the test that I inquired about?
I'm not sure if this question is directed at me, but I'll go ahead and answer. Yes, I ran the test. However, it's +31F (~0C) here now so this may or may not be the case at colder temps. I haven't really paid a lot of attention to this parameter other than to notice that it hops around on the VP2.
Indeed, there are discrete, navigable screens for each active channel. The frequency correction is 0 for both transmitters on the Vue console and holding steady. On the VP2, it vacillates between +1 and +2 for the ISS. The wind transmitter at one point was showing 1 and then later 3. The factors do not seem to correspond across channels.
Are you looking at item (2.) Radio frequency error of the last packet received successfully. Or item (3.) Current frequency correction factor. (Just checking.)
Definitely frequency correction factor. Just re-checked both manuals and then both consoles. Those are the correct values.
-
Sorry, my bad. On the Vue console I was wrong. It's -4 for the ISS and -3 for the wind. The VP2 was correct.
-
Lets visualize this is a different manner. Below is the output of a CC1101 receiving packets from an ISS:
Index: 00 Packet: A0 00 A4 81 1B 00 1F 0E FF FF RSSI: -67 Correction: -22
Index: 01 Packet: E0 00 A4 80 01 00 AE 96 FF FF RSSI: -68 Correction: -20
Index: 02 Packet: 50 00 A4 FF 73 00 CF 38 FF FF RSSI: -68 Correction: -20
Index: 03 Packet: 80 00 A4 14 99 00 C4 35 FF FF RSSI: -70 Correction: -19
Index: 04 Packet: 20 00 A4 6D C1 80 75 1A FF FF RSSI: -66 Correction: -19
Index: 05 Packet: E0 00 A4 80 03 00 C8 F4 FF FF RSSI: -73 Correction: -20
Index: 06 Packet: 50 00 A4 FF 71 00 A9 5A FF FF RSSI: -70 Correction: -20
Index: 07 Packet: 80 00 A4 14 79 00 D4 87 FF FF RSSI: -66 Correction: -20
Index: 08 Packet: 70 00 A4 8F 01 80 DD 8B FF FF RSSI: -69 Correction: -20
Index: 09 Packet: E0 00 A4 80 01 00 AE 96 FF FF RSSI: -65 Correction: -19
Index: 10 Packet: 50 00 A4 FF 71 00 A9 5A FF FF RSSI: -66 Correction: -21
Shown above is the Rx Hop Index (Channel), the actual packet, RSSI and the accumulated frequency error correction being applied for that channel. This pretty much matches what my Vue console is showing. So in openvista's case, the Vue console should be keeping up with both transmitters on a per channel basis. A VP2 should be doing something similar.
-
Lets visualize this is a different manner. Below is the output of a CC1101 receiving packets from an ISS:
Index: 00 Packet: A0 00 A4 81 1B 00 1F 0E FF FF RSSI: -67 Correction: -22
Index: 01 Packet: E0 00 A4 80 01 00 AE 96 FF FF RSSI: -68 Correction: -20
Index: 02 Packet: 50 00 A4 FF 73 00 CF 38 FF FF RSSI: -68 Correction: -20
Index: 03 Packet: 80 00 A4 14 99 00 C4 35 FF FF RSSI: -70 Correction: -19
Index: 04 Packet: 20 00 A4 6D C1 80 75 1A FF FF RSSI: -66 Correction: -19
Index: 05 Packet: E0 00 A4 80 03 00 C8 F4 FF FF RSSI: -73 Correction: -20
Index: 06 Packet: 50 00 A4 FF 71 00 A9 5A FF FF RSSI: -70 Correction: -20
Index: 07 Packet: 80 00 A4 14 79 00 D4 87 FF FF RSSI: -66 Correction: -20
Index: 08 Packet: 70 00 A4 8F 01 80 DD 8B FF FF RSSI: -69 Correction: -20
Index: 09 Packet: E0 00 A4 80 01 00 AE 96 FF FF RSSI: -65 Correction: -19
Index: 10 Packet: 50 00 A4 FF 71 00 A9 5A FF FF RSSI: -66 Correction: -21
Shown above is the Rx Hop Index (Channel), the actual packet, RSSI and the accumulated frequency error correction being applied for that channel. This pretty much matches what my Vue console is showing. So in openvista's case, the Vue console should be keeping up with both transmitters on a per channel basis. A VP2 should be doing something similar.
I see a difference of between 3 and 6 comparing corresponding channels across receivers over time. So, for instance, currently on the Vue, the correction factor for the wind xmtr is -3 but on the VP2 it's +1. That's a difference of 4. For the ISS, the Vue reports -5 and the VP2 +1. That's a difference of 6. The receivers are right beside each other.
-
So the objective here is to somehow prove/disprove that the VP2 does in fact track both transmitters independently.......
-
So the objective here is to somehow prove/disprove that the VP2 does in fact track both transmitters independently.......
There can sometimes be a difference between the two channels' correction factors on the VP2 console. Usually it differs only by 1 but sometimes 2. So if the ISS is 1, the wind will be 2 or 3. Thus it would appear it is tracking them independently. Now, if you mean independently (a.k.a. differently) from the Vue, then yes, that, too, is true and might be a cause for concern.
It appears, if I understand this correctly, the Vue may do a better job finding the precise frequency of each transmitter which creates a better signal lock more resistant to being dropped when conditions deteriorate. The VP2, by virtue of less optimal frequency correction, has a fuzzier signal? I guess my question is why are the two devices correcting the frequency differently?
Does the CC1021 chip handle frequency correction or would that functionality be handled by a different chip and/or software?
-
So the objective here is to somehow prove/disprove that the VP2 does in fact track both transmitters independently.......
There can sometimes be a difference between the two channels' correction factors on the VP2 console. Usually it differs only by 1 but sometimes 2. So if the ISS is 1, the wind will be 2 or 3. Thus it would appear it is tracking them independently. Now, if you mean independently (a.k.a. differently) from the Vue, then yes, that, too, is true and might be a cause for concern.
It appears, if I understand this correctly, the Vue may do a better job finding the precise frequency of each transmitter which creates a better signal lock more resistant to being dropped when conditions deteriorate. The VP2, by virtue of less optimal frequency correction, has a fuzzier signal? I guess my question is why are the two devices correcting the frequency differently?
Does the CC1021 chip handle frequency correction or would that functionality be handled by a different chip and/or software?
So it does appear that the VP2 is tracking both transmitters. The frequency error compensation is done totally different for the two.
For the CC1021:
http://www.ti.com/lit/an/swra063/swra063.pdf
So for the CC1021, a new frequency must be calculated and written to the FREQ_A register by the
processor every time the AFC register value changes.
For the CC1101:
http://application-notes.digchip.com/001/1-2121.pdf
The CC1101 on the other hand supplies the frequency error direct (FREQEST) and the accumulated value is simply written to the FSCTRL0 register by the processor.
The frequency error is the total amount required to keep the receiver on track with the transmitter. It doesn't matter which one (or both) drifted. There is no reason to compare the comp values from the Vue to the values the VP2 is using. They have nothing to do with each other.
Maybe the CC1101 can track farther? (Resolution is FXTAL/2^14 (1.59kHz-1.65kHz); range is ±202 kHz to ±210 kHz, dependent of XTAL frequency.) Not readily spelled out for the CC1021....
-
One thought, temperature could affect more than just transmitter frequency, like the CPU clock frequency. If that drifts then the transmissions may fall outside the consoles reception window - I know as I had to add a correction factor to my Arduio transmission timing to prevent sync loss on the VP2 console.
I haven't read all the other threads, so apologies if this has been dismissed before.
-
One thought, temperature could affect more than just transmitter frequency, like the CPU clock frequency. If that drifts then the transmissions may fall outside the consoles reception window - I know as I had to add a correction factor to my Arduio transmission timing to prevent sync loss on the VP2 console.
Mark, yes, that was exactly my thought, as I tried to explain upthread. I'm no wireless engineer but seems to me that there are various parameters that could be affected by some clock or other reference frequency drifting off and then affecting timings of some other key parameter. I don't know how sensitive the channel time windows are, for instance.
-
OK, good to know rdsman. It would appear there is no direct evidence currently that this is a frequency issue.
As for timing (mccrossley and johnd), perhaps the Vue receiver has a more liberal window for receiving packets?
-
So, does, anybody know what "clock" chip the two consoles use? Same device or different? Is the same device used for internal timing, or are separate clocking sources used?
I raise this question because my experience has been that my VP2 console clock timing was terrible (always losing time) while the replacement VUE console clock seems to be quite accurate.
-
So, does, anybody know what "clock" chip the two consoles use? Same device or different? Is the same device used for internal timing, or are separate clocking sources used?
I raise this question because my experience has been that my VP2 console clock timing was terrible (always losing time) while the replacement VUE console clock seems to be quite accurate.
There isn't a real time "clock" chip in either console. The processor keeps time with a clock crystal.
-
So, does, anybody know what "clock" chip the two consoles use? Same device or different? Is the same device used for internal timing, or are separate clocking sources used?
I raise this question because my experience has been that my VP2 console clock timing was terrible (always losing time) while the replacement VUE console clock seems to be quite accurate.
There isn't a real time "clock" chip in either console. The processor keeps time with a clock crystal.
A raw crystal? Usually there's a divide-by-N "chip" used to derive the desired 'clock' timing.
-
So, does, anybody know what "clock" chip the two consoles use? Same device or different? Is the same device used for internal timing, or are separate clocking sources used?
I raise this question because my experience has been that my VP2 console clock timing was terrible (always losing time) while the replacement VUE console clock seems to be quite accurate.
There isn't a real time "clock" chip in either console. The processor keeps time with a clock crystal.
A raw crystal? Usually there's a divide-by-N "chip" used to derive the desired 'clock' timing.
See:
http://ww1.microchip.com/downloads/en/AppNotes/Atmel-1259-Real-Time-Clock-RTC-Using-the-Asynchronous-Timer_AP-Note_AVR134.pdf
-
So, does, anybody know what "clock" chip the two consoles use? Same device or different? Is the same device used for internal timing, or are separate clocking sources used?
I raise this question because my experience has been that my VP2 console clock timing was terrible (always losing time) while the replacement VUE console clock seems to be quite accurate.
There isn't a real time "clock" chip in either console. The processor keeps time with a clock crystal.
A raw crystal? Usually there's a divide-by-N "chip" used to derive the desired 'clock' timing.
See:
http://ww1.microchip.com/downloads/en/AppNotes/Atmel-1259-Real-Time-Clock-RTC-Using-the-Asynchronous-Timer_AP-Note_AVR134.pdf
Yep, that's what the industry calls a Real Time Clock (RTC) chip. The external "oscillator" is a crystal that is oscillating at many, many, many times faster than the end/desired "clock" output...typically about 10X faster but can vary. The greater the difference between the oscillator input and the clock output, the tighter the operating tolerance (less variance).
-
Yep, that's what the industry calls a Real Time Clock (RTC) chip. The external "oscillator" is a crystal that is oscillating at many, many, many times faster than the end/desired "clock" output...typically about 10X faster but can vary. The greater the difference between the oscillator input and the clock output, the tighter the operating tolerance (less variance).
Sorry to be a little OT, but is this why some clocks drift a couple of minutes a week vs. some that can drift less than a second per week? I've always figured that products with a super inaccurate clock were a sign of corner cutting on other electronic components as well.