Kenneth Aafløy wrote:I think you are mistaken.On Wednesday 14 July 2004 04:16, Peter Henderson wrote:I think I've fixed it. There is an integer underflow bug in mt352.c need to change line 517 (based on rev 1.7 in cvs) from tmp = 6 * freq + IF_FREQUENCYx6; to tmp = ((param->frequency*6)/1000000) + IF_FREQUENCYx6; This affects any multiplex which is on a Positive or Negative offset. (So 4978333330Hz fails but 690000000Hz would be fine) So Ben this should fix your problem as Crystal Palace is all Pos/Neg offsets.According to the datasheet (* p.44), this calulation is wrong. I've attached a patch which corrects this and also adds the requested change below. Please test a clean CVS with this patch, as I don't have this card/frontend/dvb-t. Using the example on p44. (and ignoring the IF_FREQUENCYx6 const for the moment) Your code does.. param->frequency = 630166667 so freq = param->frequency/1000000 = 630 <--- oops630*6 = 3780 And the example is 3781 Where the change I made gives (param->frequency*6)/1000000 = 3781 As a side note. Can FEC_NONE be added as a case to the LP code rate switch statements (and probably the HP as well) as this was the original reason I couldnt tune anything and had to comment out the default error return.It will then default to FEC_1_2, is this okay? Kenneth * http://assets.zarlink.com/DM/MT352_Design_Manual_Nov03.pdf |