Separate names with a comma.
Discussion in 'DIRECTV HD DVR/Receiver Discussion' started by Stevies3, May 19, 2013.
actually, DVR - Linux could help you read all files include logs
Ah OK, so not something you can do on a regular receiver then?
Only if it has FW with debug output enabled, then you will need RS232 TTL converter to watch debug messages. Practically if you 're working for SW dept.
Well thanks for that, Captain Obvious, but in the interests of KISS, I think we all can use the colloquial terms "signal level" and "signal strength" to represent that, because that is how consumer/lay folks converse when speaking about this. We don't need to parse what is really going on in this type of application of technique, because a fine understanding of that doesn't change the technique needed to get the most reliable reception.
And it is especially useless to parse the fine understanding of that if you are going to be incorrect in the first place.
Speaking as someone who has performed hundreds of digital sat uplinks from mobile platforms and thousands of professional downlinks over the years I think I can safely go out on a limb here and state that it is rare for digital sat or DVB return signals to be monitored by BER. Usually what is used is MER, or Modulation Error Ratio, or professionally, by Eb/NO, both of which take into account other factors at the antenna other than the sheer number of raw uncorrupted bits, which would vary by bit rate and which can change irrespective of receive "strength", making BER unreliable as an indexed measurement just for that single reason alone,
MER is much easier to use to approximate a simulated analog scale, so it lends itself well to what we view on our test screen as "signal strength". We want the bits, but we also want them without time smear (time smear raises the threshold for decoding), which MER takes into account while BER does not. BER is also only accurate if you use the same bandwidth all of the time, which DVB does not, also maklng it inaccurate for an indexed measurement. A measurement such as Eb/NO is not related to the bandwidth because it is measuring a S/N ratio of the energy per bit against noise power spectral density, making it much more reliable than BER.
And there is absolutely a way to accurately correlate MER or Eb/NO readings to RF signal, which is exactly what is suposed to be what is happening when simulating the analog-scale-based "digital quality" meter in a consumer IRD. The only thing we don't really know as consumers is how tightly the scale is calibrated from DVR to DVR, or how similarly the readings are indexed from DVR model to DVR model. That is a slop factor only DTV can be responsible for, meaning I might get exactly the same readings as you with the exact same delivered signal level at the antenna, or due to the slop factor, I might not.
Ok, Captain UN-obvious. . . I swear, I re-read your post 3 times or more and I still don't have a clue what you said other than you might get the same signal that I do, but maybe not?
That's good reading for techno-geeks, but definitely you missed post#36.
Once again: signal level reading on screen provided by DTV receivers/DVRs is SS=f(SNR).
[Perhaps one day I would sit close to the dish with a wet blanket and play the numbers ... but who need the table ?! ]
Thank you for the detailed explanation, it does make sense. I think you could have offered it without the leading snide remark, it would have been a more pleasant learning experience. I see though that you do agree with the basic points I was trying to make. The signal level you see displayed is not a true RF signal strength indicator, and you cannot compare the signal levels between different IRDs due to whatever reason you care to attribute, including "slop factor".
No one needs it, but some of us would be interested in it. I'd be pretty surprised if it isn't something like SS = SNR*x.
It would be more interesting to see what correlation, if any, there is between additional wet sheets attenuating the signal by x db and changes in the SNR. That may be not be a linear relationship, you may see very little movement in SNR as you drop the dbm output from the LNB until you hit an inflection point where little additional attenuation causes large drops in SNR.
you're right about a level and SNR manipulation with wet blanket - it was just little thinking time for write the note ... really I would move the dish to get mixed DTV signal from adjusted sats
Well, here is ... no that linear, but perhaps middle part it is
(a note: in files "/viewer/messages.log[.xx]" the value mistakenly named as "CNR" while BCM450x chip reporting actual SNR values; that logs taken from HR22-100 model)
I pretty much expected very little slope at the top end, but once it gets to 11db or so it is a lot more linear than I would have thought. Thanks for the taking the time to do this, it is quite interesting!
Did you happen to notice at exactly what levels the picture started breaking up? Always been sort of curious what the minimum signal strength reading is where you can expect to have a perfect picture. Since I've only seen really low readings when I had a LNB going bad (when it would flake out, transponders would jump from 95 all the way down to 0 in a split second, then back again, or to any random number in between) or during a heavy storm. You need poor but consistently poor readings to tell where the lower limit is
35+ MPH wind is a Tropical Storm as per the NWS and Gale Force Winds begin at 39 MPH. As noted, periods of gusts well over 35 mph is very common multiple times per year here - and there have been plenty of substained winds much higher than 35 MPH.
At substained 80mph - 90mph, you dish will leave the J frame, as witnessed by many storms, regardless of the lnb type.
This time I was lucky to find old system logs on external HDDs from HR20 and HR22; so I did plot the graph by taking numbers from tpn's scans made last years.
I should warn those ppl (who want to verify my result) about a SW bug:
- the FW versions in both models [HR20-700 and HR22-100] has a bug - SNR [named as CNR] values has same digits after decimal point as at front of it, so you will see all values looks like 2.2/5.5/9.9/11.11/17.17; that means fraction values after decimal point are bogus. It does produce weird points on a plot, when for same SNR [ say 11.11] you will find multiple SS values like 91/92/93/94.
I hope someone with latest models HR23/24/etc will check if the bug eradicated and SNR values come correctly, then we would get more pleasant curve of the "SNRtoSS" conversion.
To obtain the log files from DVR's drive, I'm using Windows based PC and easy to use program UFS Explorer what allow you to read system files from second XFS partition of the drive without mounting the partition.
Seems like a good time to put the old AT9 to rest and have moved this year's posts here: http://www.dbstalk.com/topic/211491-snrcnr-to-the-receivers-reported-signal-strength/