[linux-dvb] Additional tuning status values req'd for tda10048
The TDA10048 (channel decoder) has some status registers that are helpful for fast scanning and accurate tuning. AUTO_OFFSET/OFFSET_F and FREQERR_R/TIMERR_R - for offset detection and tuning sampling clock correction How would features such as these fit into the existing frontend API ? I could imagine a FE_CAN_OFFSET_AUTO, FE_CAN_FREQ_CORRECT and FE_CAN_SAMP_CLOCK_CORRECT, in fe_caps, and an FE_HAS_OFFSET in fe_status, but can't see how you could read or set any of the other values without extending ioctls. Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Additional tuning status values req'd for tda10048
MikeW mw_phil at x.xx.xx writes: The TDA10048 (channel decoder) has some status registers that are helpful for fast scanning and accurate tuning. AUTO_OFFSET/OFFSET_F and FREQERR_R/TIMERR_R - for offset detection and tuning sampling clock correction How would features such as these fit into the existing frontend API ? I could imagine a FE_CAN_OFFSET_AUTO, FE_CAN_FREQ_CORRECT and FE_CAN_SAMP_CLOCK_CORRECT, in fe_caps, and an FE_HAS_OFFSET in fe_status, but can't see how you could read or set any of the other values without extending ioctls. Regards, MikeW I guess they could be additional dvb_frontend_parameters: __u32 channel_offset, freq_offset, samp_clk_error; MikeW gmane_padding ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] I2C NAKs and fails to respond during init o f TDA18211
Michael Krufky mkrufky at linuxtv.org writes: You might want to take a look at the tda18271 driver recently merged into the master branch, located under dvb/frontends ... Perhaps this driver might be enough to bring up the tda18211-- I don't have the spec for the 18211, so I cannot say that for sure, but I was under the impression that the tda18211 is exactly a tda18271, but DVB only. Let me know if there's anything that I can do to help you. Regards, Mike Krufky Also note in your tda18271_set_params() sgIF gets set for ATSC mode but is left at zero for OFDM mode - this is incorrect I believe, and the datasheet gives the required IFs as 3.3, 3.8 and 4.3 MHz Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] dvb-s encryption - how to capture a stream
Patrick Bulteel linuxtv at bulteel.org writes: Hi, I have a dvb-s card with a CAM and my subscription card. I get the message in syslog that shows the CAM is detected and initialized. However... I'm not sure how to get the encrypted video. Since it's a DVB-S card I thought szap would work, but although I get something, I can't view it, probably because it's the encrypted stream. What tool would I use? I have seem mention of ca_zap or something similar, but, I can't find the binary or source anywhere. Any pointers would be appreciated. Also would it be possible to decrypt an entire mux if I have a subscription for all the channels in the mux? -- Patrick Bulteel Reading the do drivers support Nagravision CA post suggests that your CAM + subscription card combination needs to be registered in some way with the broadcaster, so that the appropriate 'entitlement message' can be sent out over the data stream to allow the card to generate the decryption code word sequence for the streams you have subscribed to. Depends on the broadcaster's encoding whether decryption would work across a mux. Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] I2C NAKs and fails to respond during init o f TDA18211
Michael Krufky mkrufky at linuxtv.org writes: It's not wrong -- it's just missing. I said it before -- the driver is not tested with DVB-T -- I need a test case for it first. Feel free to send in a patch, since you DO have that test case. Cheers, Mike Krufky Sadly I have not yet achieved FE_HAS_SIGNAL (TDA10048 reg 1A: FREQ_LOCK) with _any_ code, though I /have/ had FE_HAS_CARRIER, FE_HAS_SYNC FE_HAS_VITERBI. Hence do not get FE_HAS_LOCK (TDA10048 reg 1A: FEL) Possibly need to get a spectrum analyser onto the IFOUT pins to see why the 10048 is not achieving proper lock. May be a 10048 setup mismatch ... On that basis I am not willing to submit patches, until I have demonstrably working tuning ! Regards MikeW PS. One of the RF techies said that silicon tuners were _much_ harder work than can tuners, hence the increase in s/w needed to work them ... ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] I2C NAKs and fails to respond during init o f TDA18211
Michael Krufky mkrufky at linuxtv.org writes: You might want to take a look at the tda18271 driver recently merged into the master branch, located under dvb/frontends ... Perhaps this driver might be enough to bring up the tda18211-- I don't have the spec for the 18211, so I cannot say that for sure, but I was under the impression that the tda18211 is exactly a tda18271, but DVB only. Let me know if there's anything that I can do to help you. Regards, Mike Krufky Thanks. I also note in your repository code that there is no account taken of whether the chip is in Master or Slave mode - the 18211 needs different frequency setting depending on whether it is running the 16MHz crystal (Master), or whether it just has the 16MHz input (Slave). This is relevant if you have a dual-tuner configuration, increasingly common to allow PVR and viewing on different channels. In Master mode you set the required frequency on the Main PLL, in Slave mode you have to use the Cal PLL. Also set CALVCO_forLOn: EB1[2] and a few other bits ! Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] I2C NAKs and fails to respond during init of TDA18211
Michael Krufky mkrufky at linuxtv.org writes: On 11/1/07, MikeW mw_phil at yahoo.co.uk wrote: Using the OM5776 eval board, and using the algorithm published in the rev 1.1.0 datasheet, I find I am getting an I2C NAK, which does not go away and requires a chip reset to restore any I2C communication, after successfully writing EP4 (r06) in the 'image rejection cal pt I, wanted signal measurement' section where registers are written back. (NAK occurs on write to EP5) While in calibration mode, the bytes of sub addresses 0x03 thru 0x0f must be written in one single i2c sequence. Thanks, I sorted this out and it got me past _this_ impediment, but get hangup elsewhere now :( Are you sure that you're using the exact algorithm from the datasheet? You're better off storing the values that you plan to write, then write them all at once in a single transaction. Am doing this as per datasheet - annoyingly since the two datasheet versions give one more complex, and one less complex algorithm respectively. (This has got to be the most complex setup for a tuner chip!) You might want to take a look at the tda18271 driver recently merged into the master branch, located under dvb/frontends ... Had a quick look - looks like the 'less complex' algorithm (which I am having little success with) My code is more 'factored out' rather than being one big(gish) function. TWEAK SUGGESTION - rather than copying your register map in order to prefix with the required register number prior to I2C write :- since you will never write r0 (assert this !), if you are about to write bytes from your 'register map' starting at rN, save the contents of the map byte at [N-1], write value N into that location, then do I2C block write from that position, then replace the byte at [N-1]. Perhaps this driver might be enough to bring up the tda18211-- I don't have the spec for the 18211, so I cannot say that for sure, but I was under the impression that the tda18211 is exactly a tda18271, but DVB only. Might try it out if I come to a brick wall ! Let me know if there's anything that I can do to help you. Regards, Mike Krufky Cheers, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] I2C NAKs and fails to respond during init of TDA18211
Using the OM5776 eval board, and using the algorithm published in the rev 1.1.0 datasheet, I find I am getting an I2C NAK, which does not go away and requires a chip reset to restore any I2C communication, after successfully writing EP4 (r06) in the 'image rejection cal pt I, wanted signal measurement' section where registers are written back. (NAK occurs on write to EP5) Anyone with better experience ? Thanks, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] I2C NAKs and fails to respond during init o f TDA18211
Michael Krufky mkrufky at linuxtv.org writes: On 11/1/07, MikeW xx_ at yahoo.co.uk wrote: Using the OM5776 eval board, and using the algorithm published in the rev 1.1.0 datasheet, I find I am getting an I2C NAK, which does not go away and requires a chip reset to restore any I2C communication, after successfully writing EP4 (r06) in the 'image rejection cal pt I, wanted signal measurement' section where registers are written back. (NAK occurs on write to EP5) While in calibration mode, the bytes of sub addresses 0x03 thru 0x0f must be written in one single i2c sequence. Yes, I did consider this, but, annoyingly, the kernel I2C primitives do not allow chaining of I2C buffers except as a 'repeated START' transaction, hence you need to copy the register address into a buffer followed by the data bytes, then send all as one transaction. (Could implement by saving content of previous byte in the reg map, replace with reg sddress value, sending bytes, then restoring original value ...) The data sheet flowchart actually says: SubAddr(hex): 03 to 0F suggesting that separate writes would be permissible. However, it's worth trying the single transfer approach. The version 1.0.1 document is actually a little more explicit in some cases, but I thought that since its version was earlier, it had been superceded. Will have another look at the sequence there since it's rather more prescriptive. Are you sure that you're using the exact algorithm from the datasheet? You're better off storing the values that you plan to write, then write them all at once in a single transaction. You might want to take a look at the tda18271 driver recently merged into the master branch, located under dvb/frontends ... Perhaps this driver might be enough to bring up the tda18211-- I don't have the spec for the 18211, so I cannot say that for sure, but I was under the impression that the tda18211 is exactly a tda18271, but DVB only. Let me know if there's anything that I can do to help you. Regards, Mike Krufky Thanks for the suggestion ! Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] improving the quality of DVB signal - PS
MikeW mw_phil at yahoo.co.uk writes: ngocminh_bk_nd at yahoo.com writes: Hi all I have 2 cards DVB-T DVB-S of TWINHAN but i can't use the kaffeine to watch TV channels because the level of signal approxiate 33%. when i use modules #modprobe : bttv bt878 dst dvb_core dvb-bt8xx the commands # scan asiat3 channels.conf #szap -c channels.conf bloomberg -r # cat dev/dvb/adapter0/dvr0 /home/ron/file.ts the signal of file.ts is very bad, not continuous. But when i try these card on Window the signal is good, about 88% How can I improve the signal? please help me. Thank you! Are you sure that the two numbers quoted are calculated in the same way ? Are they peak or average or windowed-average ? Or even refer to the same signal quality indicator ? Assuming you are comparing like with like, since some frontends with silicon tuners have adaptive/tracking filtering, it's possible that the Linux driver does not use the manufacturer's best algorithm for tuning. Regards, MikeW The usual signal quality 'number' for DVB is BER (bit error rate), hence you should check this figure for both your Win and Lin setups. Lower BER = better signal, it is NOT a percentage. But there might still be a difference in averaging calculations. MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1
Michael Krufky mkrufky at linuxtv.org writes: For the past few months, I've been working on refactoring the analog tuner.ko module, such that all hardware-specific code can be separated into dvb_frontend style tuner modules. ...snip... If there are any other questions, comments or concerns, I would love to hear them. Please don't be shy -- feel free to let me know if you like or dislike this approach. I'd like to have this merged as soon as possible, so that I may continue to work on the items mentioned about in the What comes next? section. Now, it's time to go out and party! I will be able to respond to any comments tomorrow afternoon. Regards, Michael Krufky Thanks Michael. I for one would very much appreciate a document detailing the implementation requirements for new drivers, and the necessary interconnections between tuner/demod/demux modules. The existing codebase has apparent duplication, redundancies and maybe obsolete/deprecated bits that make a 'clean sheet' implementation difficult to realise from a reverse-engineered view of existing drivers. Such a canonical driver doc would also help new drivers to better conform to standards thus easing maintenance and upgrades and assisting code reuse. Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] source example for non-pci/non-usb dvb card
Gery gxkahn at gmail.com writes: i am trying to implement dvb-s card which uses only i2c and neither based pci, nor usb. To make it clear it is based on proprietary bus, where only management by i2c. is there an example of such card in dvb or other open source project? If you are using the standard readb()/writeb() etc. accessor functions to talk to your device memory I can't see that there's much if any difference between that and talking to a PCI device. PCI hardware IIRC spots the address range that corresponds to the bus and does the required transfers, but if it's just 'standard' device memory things should pretty much work as-is - apart from not getting loaded by the PCI probe framework and a few details of that sort. If your device chip types are already supported, the existing drivers should be 99% of what you need, the only difference being they will need loading by a separate method from a PCI device. Or am I forgetting something ? Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HowTo for new tuner ... avail of 18271 code
MikeW mw_phil at yahoo.co.uk writes: On 8/2/07, Michael Krufky mkrufky at linuxtv.org wrote: Mike, I have already written a completely functional driver for the TDA18271 silicon. ...snip... Regards, Michael Krufky You are right - the devices are compatible except for the featureset restriction; I believe the IF_notch bit is also omitted. I look forward to giving your 18271 driver a spin when it becomes available. Regards, MikeW ... which might be when ?! Thanks, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HowTo for new tuner ... avail of 18271 code
Michael Krufky mkrufky at linuxtv.org writes: ...snip... What device do you have that uses the tda18211? So far, I am only aware of one device available on retail shelves that use the tda18271 -- I'm curious what you're working with. Regards, Mike Krufky Basically, the eval board I linked to before, with 10048/18211. MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HowTo for new tuner
Michael Krufky mkrufky at linuxtv.org writes: Mike, I have already written a completely functional driver for the TDA18271 silicon. DVB-T has not yet been tested on it, but I doubt it will be any problem. I understand that you are working with the TDA18211 -- do you know how similar it is to the 18271? I haven't google'd the 18211 yet, but I'll take a look. I am currently working to refactor the tuning api between the dvb and v4l subsystems -- this is my reasoning for not having released my tda18271 code publicly, as of yet. It does work, however, and I have only tested it so far using analog broadcasts. The difference for tuning DVB-T is only some small changes to certain registers. Based on what I see in the pdf that you linked above, I wouldn't be surprised if the tda18211 featureset is merely a small subset of the tda18271, meant specifically for DVB-T. How much progress have you already made with your driver? I'd be happy to help you if you have any further questions... If the 18211 is indeed program compatible with the 18271, except for the limited featureset, then I'd hate to see somebody do double-work. Regards, Michael Krufky You are right - the devices are compatible except for the featureset restriction; I believe the IF_notch bit is also omitted. I look forward to giving your 18271 driver a spin when it becomes available. Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
Michael Krufky mkrufky at linuxtv.org writes: ...snip... That's fine with me... except I just don't see why we shouldn't just have the demod drivers that have the integrated tuning functionality just fill tuner_ops.info.frequency_max|min anyway. The point is, the structures will be present regardless of whether any tuner_ops are actually filled. This is an opportunity to remove the frequency_min|max from the demod ops.info structure, as we all agree that it is inappropriate there anyhow. If we do this, then we will have a standard across the board. Regards, Mike Having looked around for such information myself, it would possibly help consistency of tuner/demod/demux drivers if there was a standard/'best practice' for implementing such software, giving the decision points based on the actual device(s) features, reflecting into implemented code. e.g. if the device is a tuner: - create this file (from a template ?) - fill in these structure fields based on xxx values - write these functions - add these Kconfig settings ... This would ensure in the current case that there is no misunderstanding about the roles of different, possibly duplicated, fields, and which has precedence. Also when to specifically use a tuner or frontend structure. Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] HowTo for new tuner
I have explored the 2.6.19.1 drivers source and checked out LinuxTv.org, plus plenty of other searching, in the hope of finding a step-by-step/HowTo guide or documentation for adding/implementing a new frontend tuner device, but in vain. Can anyone recommend a link ? Additionally what is the best way to represent a tuner that has several frequency bands - the dvb_tuner_info and dvb_tuner_ops structs don't appear to be able to deal with this easily. Thanks, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HowTo for new tuner
Markus Rechberger mrechberger at gmail.com writes: Hi Mike, Can you shed some more light about the capabilities of the tuner you intend to add support for? regards, Markus I guess that the bands are really an internal device programming concept and the driver should hide those anyway; fairly standard silicon tuner. MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HowTo for new tuner
Markus Rechberger mrechberger at gmail.com writes: Hi Mike, Can you shed some more light about the capabilities of the tuner you intend to add support for? regards, Markus Example: http://www.nxp.com/acrobat_download/literature/9397/75015475.pdf Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HowTo for new tuner
Manu Abraham abraham.manu at gmail.com writes: On 8/2/07, MikeW mw_phil at yahoo.co.uk wrote: I have explored the 2.6.19.1 drivers source and checked out LinuxTv.org, plus plenty of other searching, in the hope of finding a step-by-step/HowTo guide or documentation for adding/implementing a new frontend tuner device, but in vain. Can anyone recommend a link ? What kind of a tuner are you looking at ? Or better, which tuner is it ? Sorry, the bit about 'bands' was a bit of a red herring ... I take it there is no high-level documentation apart from the source files ! I can understand the existing code at the 'micro' level, but in terms of creating a new functional driver from the ground up, i.e. necessary structures, function pointers, arrays etc to be filled in ?! I guess just a lifecycle model for the components of a 'complete but empty' [i.e. all structure fields active, but no 'device code' apart from comments] frontend demux would be useful. If I make progress on this I will feed it back ... Regards, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] HowTo for new tuner -182x1
Michael Krufky mkrufky at linuxtv.org writes: On 8/2/07, Michael Krufky mkrufky at linuxtv.org wrote: Mike, I have already written a completely functional driver for the TDA18271 silicon. DVB-T has not yet been tested on it, but I doubt it will be any problem. I understand that you are working with the TDA18211 -- do you know how similar it is to the 18271? I haven't google'd the 18211 yet, but I'll take a look. I am currently working to refactor the tuning api between the dvb and v4l subsystems -- this is my reasoning for not having released my tda18271 code publicly, as of yet. It does work, however, and I have only tested it so far using analog broadcasts. The difference for tuning DVB-T is only some small changes to certain registers. Based on what I see in the pdf that you linked above, I wouldn't be surprised if the tda18211 featureset is merely a small subset of the tda18271, meant specifically for DVB-T. How much progress have you already made with your driver? I'd be happy to help you if you have any further questions... If the 18211 is indeed program compatible with the 18271, except for the limited featureset, then I'd hate to see somebody do double-work. Regards, Michael Krufky ...snip... LOL, cool, Markus. For the record, to other readers, I emailed Markus privately asking him not to top-quote. I dont have much to say about Markus' new method -- I haven't had time to look into it yet, but it sounds like a nice idea. Meanwhile, i think that Mike, working on the 18211, might be better off working with me, as I have high suspicions that his silicon is a subset of the one I've already worked on. We'll see what happens. Cheers, Michael Krufky Rumours suggest they are indeed similar devices ... I am investigating. (But I would still like to read a 'how it all fits together' doc ;) Might be able to refactor into a more comprehensible framework !) Thanks, MikeW ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
