Using pass-thru when not locked.

Status
Please reply by conversation.

B.J.

SatelliteGuys Pro
Original poster
Oct 15, 2008
2,029
1
Western Maine
I have observed the following several times in the past, when using my Fortec receivers (Lifetime, Ultra, Mercury), and posted about it in other forums, however I just observed it happening with my Diamond for the first time, and I figured out a way to bypass the "problem".

Well, what I've observed, is that with some receivers, when a satellite is set up to have a DiseqC port number, that if I am on a transponder that isn't strong enough to lock well, or a transponder that doesn't exist anymore, that the receivers seem to go into some un-documented search mode, whereby it will try different DiseqC port numbers trying to find the port that might have the transponder you've selected.
I know that this sounds absurd, but I first discovered this when I had 3 different dishes all tuned to the same PBS transponder, all connected to different ports of a DiseqC switch. I was trying to aim one of the dishes at the time, but was unable to get a good signal. So I decided to go outside and play with the alignment a bit. I connected a meter, and started playing with the aim of the dish a bit. After a bit of playing, I completely lost signal on the meter. Completely gone, like it wasn't getting any voltage. I went inside to see if somehow the receiver had gotten into some lockup mode or something. To my surprise, I had a solid lock on the channel I was trying to tune. Went outside.... no voltage. Confused, I disconnected the coax from the LNB. Went inside, still receiving the channel. Switched channels, and then back.... NOTHING..... then after a while...... BLINK... and the channel popped in.
I eventually verified that after not being able to lock the transponder with the parameters I had entered, the receiver was switching ports randomly on my DiseqC switch, which just happened to be on the same channel, and when it got a lock, it just stayed there. !?#$%#^@
I later found that if I used my Channel master meter that has a little indicator light that lights when it senses a 22KHz DiseqC signal, and if I lifted up on the dish enough to pull the dish off a transponder it was locked to, that as soon as it lost lock, that it would try sending out DiseqC signals, perhaps thinking that the switch had gotten a spurious signal and gone to another port. Stop lifting the dish, the DiseqC signal stopped. I think in this case, it was sending out the right DiseqC signal. But apparently the receivers would eventually try other port numbers if it wasn't able to find the signal on the right port. Really weird behavior. I eventually discovered that this was a way of telling if I was on the correct satellite while out at the dish with no TV. Ie if the little 22KHz light stopped blinking on the meter, I knew that I was on the right satellite, because when it stopped blinking I knew the receiver inside was LOCKED.

Anyway, as mentioned, yesterday I noticed my Diamond 9000 doing something similar. What I was doing, was trying to tune a transponder using a receiver that was slaved to my Diamond through the passthru. I didn't have any current channels saved on the Diamond on the sat in question on the polarity I was trying to tune, so I tuned the Diamond to a non-existant channel with the proper polarity selected. Went to the slaved receiver, and tuned in the transponder I was looking for. The problem, however, was that the transponder would lock, but with bunches of errors. I went back to the Diamond, and tried to adjust the dish position a bit. While I was adjusting the dish, my reception on the slaved receiver was rock solid.... no errors. As soon as I'd save and exit out of the adjust page, I'd start getting all sorts of errors on the slaved receiver.
Finally, it dawned on me that when I was in the setup page adjusting the dish position, etc, it wasn't trying to change the DiseqC settings, but as soon as I'd exit the dish position adjust page, it would start sending out DiseqC port signals, which were apparently messing up the reception on my slaved receiver. I don't know if the DiseqC signals were affecting the signal coming from the LNB, affecting the signals getting through the switch, or somehow getting into the slaved receiver, or perhaps the Diamond somehow shuts off the slaved port when it's sending diseq or something, but whatever the reason, I was losing reception on the slaved receiver every time the Diamond would send DiseqC signals.
Anyway, I found that the simple solution was to tune to the non-existant channel, then go in and turn off the DiseqC port selection to the OFF state, so that it wasn't selecting a port anymore. This may have worked only because I was on port 1, and off was right next to 1, so it just stayed on 1. If I had been on port 2, it might not have worked, because I would have had to go through 1 to get to OFF.
Anyway, if anyone ever tries using the passthru of a DVB receiver hooked up to a DiseqC, and you have trouble on the slaved receiver, you might check to see if the master receiver is on a transponder with a solid lock.
 
Most samples that we test have an auto switch set-up feature. We have chosen to disable this function on GEOSATpro receivers, but see this function on several FTA units.

Three years ago we hosted Fortec Star Engineering team for the Mercury II receiver to develop a firmware "FIX" for the DiSEqC and 22 KHz switch control.

We had discovered a similar issue while transitioning to the Mercury II for Glorystar systems. When we attempted to locate AMC4 on DiSEqC port one or with 22KHz off, but satellite was located on DiSEqC port 2 or 22KHz ON, the receiver would indicate a Signal Lock overriding the preprogrammed port commands and resulting in the dish being incorrectly aimed. We developed an installation step requiring installers to direct connect to a specific LNBF to first identify the correct satellite aiming then install the switch. Unfortunately, many installers were neglecting to power OFF the master power switch when inserting the DiSEqC switch and we were experiencing an unacceptable switch failure rate.

At first the engineers insisted that we were programming the receiver incorrectly, then they insisted that it was manufacturing error by our switch manufacturer... after multiple days of test we were able to provide conclusive data to support or findings. A chipset auto switch detection routine was taking place even though the feature had been disabled in the firmware. We implemented a port reset / resend switch command if no signal was detected overriding the manufacturer chipset instructions (NEC 61114). We immediately included this fix in the Glorystar firmware and Fortec Star included in subsequent factory firmware releases. If my memory serves me correctly, the fix was included in the same release as the reduced SQ readings (early 07?).

Could be that the Diamond 9000 has a similar "FEATURE"....
 
To avoid this sort of problems, I usually position a motorized dish on a proper sat with a master receiver, then put it into Standby, set all dish setup options on a slave receiver, save the sat's motor position, and scan required channels of the same sat. It works great for FTA sats, except for some of their clear channels that have tweens on DBS sats. In last scenario, if DBS sats positions were previously memorized to watch clear channels they offer, these only sat positions may be messed up or lost in the master receiver, once memorized in the slave receiver.
 
Last edited:
Most samples that we test have an auto switch set-up feature. We have chosen to disable this function on GEOSATpro receivers, but see this function on several FTA units.
.....
Could be that the Diamond 9000 has a similar "FEATURE"....

Thanks for the interesting info. Good to know the reason for the strange behavior I've been seeing.
 
Status
Please reply by conversation.

Users Who Are Viewing This Thread (Total: 0, Members: 0, Guests: 0)

Who Read This Thread (Total Members: 2)