Hello all,
My first post here, hope everything will go well.
I don't know what are the procedures to insert changes into the releases, so I'll just describe the fixes, hope someone will find it useful and explain how should I merge the changes into releases.
I had a Twinhan 1027 card for a while using Twinhan's Linux drivers with many of my changes inside to make it work properly. The results were not perfect and there was no support in linuxtv community, so I've decided to buy Twinhan 1041 card with hope that its experimental support will work better than what I had (and to advance to DVB-S2 format ofcause).
With latest mantis drivers I had some locking and scanning problems (using Manu's scan utility).
Following are the description of changes I did to the driver and scan utility to solve all those problems
First of all I'd like to thank the people who maintain the mantis driver. I found the code very well organized and easy to follow.
Th major lock problem with this card is that it behaves differently every time it tries to lock.
Sometimes the STATUS register reports END_LOOPVIT flag on first time the register is checked, sometimes it shows a lock after about 20-30 checks. My guess is that the card is not reset properly every time its used.
Since I don't have any document describing the registers in that card I did a workaround - scan the same frequency several times (I do it 3 times, I think 2 will be enough). I've added an internal loop counter to functions that search for timing, carrier and data. Only when that loop on the same frequency is finished, the derotator zigzag is set to next frequency.
Another issue is the stepping of the derotator frequency. I didn't really understood the units of those steps since it's divided by "mclk" variable (that has 1647 value in my machine), but the stepping was too coarse. With the limits used in the code in most of that cases it allowed one-two steps back and forward from the base frequency. I've used derot_step calculated in stb0899_dvbs_algo function:
internal->derot_step = internal->derot_percent * (params->srate / 1000L) / internal->mclk; /* DerotStep/1000 * Fsymbol */
That value was used only in carrier search function, while in timing serach the calculation was:
derot_step = (params->srate / 2L) / internal->mclk; --> which gives value large by 16.666 than 30% calculation.
and in data search the calculation was:
derot_step = (params->srate / 4L) / internal->mclk; --> which gives value large by 8.333 than 30% calculation.
In short there is incosistency in used steps. First I've changed the 30% value to 10%, but after that set it to 20% and had the same results, I don't think that change is needed. All my steps calculations are based on stb0899_dvbs_algo function step calculation based on 20%.
I've used 4x that step for timing search, 2x that step for carrier search and 1x that step for data search.
Another change is the limit of derotator frequency in search functions. The frequency found in timing serach is used as base frequency in carrier search, but the limit is absolute and not related to the base frequency.
I've changed the functions to check limit around frequency found in previous step.
For example, I had a transponder that is constantly found in timing search with derotator frequency value around 4500, the limit is set to something around 5200. When the limit is checked as:
if (ABS(derot_freq) > derot_limit)
The actual limit will be 700 instead of 5200. I've changed the check in carrier and data search functions to:
if(derot_freq > base_freq + derot_limit || derot_freq < base_freq - derot_limit)
In timing search function the change has no meaning since base_freq is always zero.
Theese are the major changes that allow me to lock on all the transponders comparing to 1027 card.
I've also added 1 mSec sleep to loop in stb0899_check_data function, open loops are not a good idea and the card need some time to lock anyway.
After all those changes I still saw that randomly some channels are not appearing in the results list, while the card locked on them successfuly. It turns out that the card or the driver has a buffer that is not resetted after tunning to another channel, so scan utility got some descriptors from previosly locked channel.
I dindn't had time to look for a good solution since I'm not familiar with IOCTL commands to the card so another workaround solved that problem: ignore first 3 messages arrived to a filter set in the scan utility.
That's all. Hope it help someone here.
My next task is to find out why DVB-S2 channels are not locked. Will write if I'll find something interesting.
I'd really like to see those changes in formal release so I won't have to merge the changes when I upgrade the driver.
Cheers,
Alex.
My first post here, hope everything will go well.
I don't know what are the procedures to insert changes into the releases, so I'll just describe the fixes, hope someone will find it useful and explain how should I merge the changes into releases.
I had a Twinhan 1027 card for a while using Twinhan's Linux drivers with many of my changes inside to make it work properly. The results were not perfect and there was no support in linuxtv community, so I've decided to buy Twinhan 1041 card with hope that its experimental support will work better than what I had (and to advance to DVB-S2 format ofcause).
With latest mantis drivers I had some locking and scanning problems (using Manu's scan utility).
Following are the description of changes I did to the driver and scan utility to solve all those problems
First of all I'd like to thank the people who maintain the mantis driver. I found the code very well organized and easy to follow.
Th major lock problem with this card is that it behaves differently every time it tries to lock.
Sometimes the STATUS register reports END_LOOPVIT flag on first time the register is checked, sometimes it shows a lock after about 20-30 checks. My guess is that the card is not reset properly every time its used.
Since I don't have any document describing the registers in that card I did a workaround - scan the same frequency several times (I do it 3 times, I think 2 will be enough). I've added an internal loop counter to functions that search for timing, carrier and data. Only when that loop on the same frequency is finished, the derotator zigzag is set to next frequency.
Another issue is the stepping of the derotator frequency. I didn't really understood the units of those steps since it's divided by "mclk" variable (that has 1647 value in my machine), but the stepping was too coarse. With the limits used in the code in most of that cases it allowed one-two steps back and forward from the base frequency. I've used derot_step calculated in stb0899_dvbs_algo function:
internal->derot_step = internal->derot_percent * (params->srate / 1000L) / internal->mclk; /* DerotStep/1000 * Fsymbol */
That value was used only in carrier search function, while in timing serach the calculation was:
derot_step = (params->srate / 2L) / internal->mclk; --> which gives value large by 16.666 than 30% calculation.
and in data search the calculation was:
derot_step = (params->srate / 4L) / internal->mclk; --> which gives value large by 8.333 than 30% calculation.
In short there is incosistency in used steps. First I've changed the 30% value to 10%, but after that set it to 20% and had the same results, I don't think that change is needed. All my steps calculations are based on stb0899_dvbs_algo function step calculation based on 20%.
I've used 4x that step for timing search, 2x that step for carrier search and 1x that step for data search.
Another change is the limit of derotator frequency in search functions. The frequency found in timing serach is used as base frequency in carrier search, but the limit is absolute and not related to the base frequency.
I've changed the functions to check limit around frequency found in previous step.
For example, I had a transponder that is constantly found in timing search with derotator frequency value around 4500, the limit is set to something around 5200. When the limit is checked as:
if (ABS(derot_freq) > derot_limit)
The actual limit will be 700 instead of 5200. I've changed the check in carrier and data search functions to:
if(derot_freq > base_freq + derot_limit || derot_freq < base_freq - derot_limit)
In timing search function the change has no meaning since base_freq is always zero.
Theese are the major changes that allow me to lock on all the transponders comparing to 1027 card.
I've also added 1 mSec sleep to loop in stb0899_check_data function, open loops are not a good idea and the card need some time to lock anyway.
After all those changes I still saw that randomly some channels are not appearing in the results list, while the card locked on them successfuly. It turns out that the card or the driver has a buffer that is not resetted after tunning to another channel, so scan utility got some descriptors from previosly locked channel.
I dindn't had time to look for a good solution since I'm not familiar with IOCTL commands to the card so another workaround solved that problem: ignore first 3 messages arrived to a filter set in the scan utility.
That's all. Hope it help someone here.
My next task is to find out why DVB-S2 channels are not locked. Will write if I'll find something interesting.
I'd really like to see those changes in formal release so I won't have to merge the changes when I upgrade the driver.
Cheers,
Alex.
_______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
