Blind scan finds transponders but shows 0 channels

Pittsville

SatelliteGuys Pro
Original poster
Jul 4, 2006
164
3
38N 75W
Something I noticed is that sometimes the Azbox will indicate that it found new transponders, but at the end of the scan it shows 0 channels found. I was saying NO when it asked if I really wanted to save channels because there weren't any. I noticed if I tell it to save anyway it saves the transponders, and I can sometimes do a transponder scan on the transponers it found, and then it will find the channels.
 
Pittsville,

This is a problem that I have observed, too.

I can only guess as to the reason why, but I think that when it completes the blind scan and logs the TPs, it goes immediately to the channel scan but doesn't wait for the tuner to lock in to the TP signals. Sometimes it does and sometimes it misses that first TP lock. I think that if it misses the first TP lock, it misses all the TPs for the entire scan duration and just zips through with nothing found.

When this happens, I select "SAVE ALL CHANNELS" even though none were shown as being logged in and then perform a "SATELLITE SCAN" which picks up the channels.

I think that the system gets "slow" or busy with what it was initially doing with the blind scan and doesn't wait for the tuner to LOCK onto the first TP signal, so then it just breezes through the scan for channels before it can ever lock onto a signal. i.e. "Didn't detect a signal, move on to the next TP, didn't see any signal, move on to the next and so on and so forth."

Since it doesn't always respond this way, I have tried to determine what might be different from one blind scan to the next. I think it might have something to do with the first TP found during the blind scan. If it is a weak signal because it is a fringe beam or because the dish/motor isn't optimally aligned or if it is an S2 signal that demands a strong signal quality for the tuner to lock it may just foul the whole scan process.

I have also observed that even when doing a TP scan or even when fooling around with my motor alignment, it takes a few seconds for the signal to lock. If the delay to LOCK onto a signal is too long, then it will pass it by. So this could be another reason why it does not pick up the channels.

I do believe that the above reasons, if they are indeed the root of the problem, can be overcome with firmware upgrades. Of course, that is if OpenSat would address them.

Since the firmware is open source, anyone with the Linux programming knowledge can write codes for these boxes (one of the advantages that brought me to the AZBox). Possibly, in the future, someone will write a better firmware that befits our use and resolves some of these conflicts.

RADAR
 
Pittsville,

This is a problem that I have observed, too.

I can only guess as to the reason why, but I think that when it completes the blind scan and logs the TPs, it goes immediately to the channel scan but doesn't wait for the tuner to lock in to the TP signals. Sometimes it does and sometimes it misses that first TP lock. I think that if it misses the first TP lock, it misses all the TPs for the entire scan duration and just zips through with nothing found.

When this happens, I select "SAVE ALL CHANNELS" even though none were shown as being logged in and then perform a "SATELLITE SCAN" which picks up the channels.

I think that the system gets "slow" or busy with what it was initially doing with the blind scan and doesn't wait for the tuner to LOCK onto the first TP signal, so then it just breezes through the scan for channels before it can ever lock onto a signal. i.e. "Didn't detect a signal, move on to the next TP, didn't see any signal, move on to the next and so on and so forth."

Since it doesn't always respond this way, I have tried to determine what might be different from one blind scan to the next. I think it might have something to do with the first TP found during the blind scan. If it is a weak signal because it is a fringe beam or because the dish/motor isn't optimally aligned or if it is an S2 signal that demands a strong signal quality for the tuner to lock it may just foul the whole scan process.

I have also observed that even when doing a TP scan or even when fooling around with my motor alignment, it takes a few seconds for the signal to lock. If the delay to LOCK onto a signal is too long, then it will pass it by. So this could be another reason why it does not pick up the channels.

I do believe that the above reasons, if they are indeed the root of the problem, can be overcome with firmware upgrades. Of course, that is if OpenSat would address them.

Since the firmware is open source, anyone with the Linux programming knowledge can write codes for these boxes (one of the advantages that brought me to the AZBox). Possibly, in the future, someone will write a better firmware that befits our use and resolves some of these conflicts.

RADAR

Good info Radar, I've had this experience many times, when this happens again I'll try "Save All Channels" and see what occurs, instead of Not Saving.
 
I've definitely experienced the same thing and often wondered about the cause. At one point I thought it might have something to do with the total number of transponders or possibly transponders at too close of a frequency although I really don't know. My solution has generally been to go back and manually select and scan those transponders with signal after the blindscan which usually works.
 
I have noticed the odd transponder missing channels in the blind scan, but for the most part it gets them. My Pansat scans the horizontal found frequencies for channels first, and then switches to the vertical. With the AZBox method of scan, from lowest to highest frequency, regardless of polarity, I wonder whether the constant voltage switching for horizontal/vertical as it progresses through the frequencies could contribute to missing channels, as any slight hesitation in switching polarities might cause it not to remain checking the frequency quite long enough (and we all know that when just changing channels, the AZBox certainly isn't the fastest).
 
Pittsville,

This is a problem that I have observed, too.

I can only guess as to the reason why, but I think that when it completes the blind scan and logs the TPs, it goes immediately to the channel scan but doesn't wait for the tuner to lock in to the TP signals. Sometimes it does and sometimes it misses that first TP lock. I think that if it misses the first TP lock, it misses all the TPs for the entire scan duration and just zips through with nothing found.

When this happens, I select "SAVE ALL CHANNELS" even though none were shown as being logged in and then perform a "SATELLITE SCAN" which picks up the channels.

I think that the system gets "slow" or busy with what it was initially doing with the blind scan and doesn't wait for the tuner to LOCK onto the first TP signal, so then it just breezes through the scan for channels before it can ever lock onto a signal. i.e. "Didn't detect a signal, move on to the next TP, didn't see any signal, move on to the next and so on and so forth."

Since it doesn't always respond this way, I have tried to determine what might be different from one blind scan to the next. I think it might have something to do with the first TP found during the blind scan. If it is a weak signal because it is a fringe beam or because the dish/motor isn't optimally aligned or if it is an S2 signal that demands a strong signal quality for the tuner to lock it may just foul the whole scan process.

I have also observed that even when doing a TP scan or even when fooling around with my motor alignment, it takes a few seconds for the signal to lock. If the delay to LOCK onto a signal is too long, then it will pass it by. So this could be another reason why it does not pick up the channels.

I do believe that the above reasons, if they are indeed the root of the problem, can be overcome with firmware upgrades. Of course, that is if OpenSat would address them.

Since the firmware is open source, anyone with the Linux programming knowledge can write codes for these boxes (one of the advantages that brought me to the AZBox). Possibly, in the future, someone will write a better firmware that befits our use and resolves some of these conflicts.

RADAR

Efectively, there is an open source project (Open Pli) at the moment. I have tried thier first image and find it very good. Lots of people have expressed similar opinions. The good thing is that they have nightly builds with correct bugs as they are reported.
2.OpenPLi - Open Source Set-Top Box Software
 

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

Who Read This Thread (Total Members: 1)

Latest posts