Tvheadend

Thanks crazycat, but with the ts220.patch applied on top of a git checkout of media_tree, this is actually worse now.

while zap is tuned to a DVB-T2 mux, dvbtraffic is reporting only 23Mbits/sec where previously it showed 38Mbits/sec - but in all cases the PIDs dvbtraffic reports are junk.

I was just thinking, maybe it'd make things easier if I set up my system so somebody can login remotely. If you don't have access to a high bitrate dvb-t2 mux it might speed things up.

Looking at the bus sniffs from Linux & windows again, the last thing before the mpeg data starts coming in is the 36 03 00 command - stream start. In the Linux USB sniffs I've seen it's earlier. Could this be important?

I've been following this thread with interest for the last week or so. I have both a PCTV 290e and the August T220. However, the driver software I'm using is stuff I've written myself, based on the Linux source code as I don't have access to most of the device data sheets. The driver software is 'user space' (i.e. not a kernel driver, so it's easier to debug) and doesn't even target Linux.

The software for the 290e works perfectly. However, and unsurprisingly, the T220 only works with a DVB-T mux. The transport stream from a T2 mux is garbled and sometimes even VLC crashes when attempting to play it.

I've looked over CrazyCat's latest patch for the T220 and also the 'usblyzer' CSV file provided by Jukka Pirinen. On a hunch that the 'ts_mode' is wrong, I checked Jukka's CSV file and sure enough, I can see a I2C write sequence:

08 6C 02 71 E4

which CrazyCat has added to his latest patch. However, a little further down in the file is:

08 6C 02 71 BC

So, instead of setting register 70 to 0x38 or 0xE4, I've tried it with 0xBC.

For the first time I've been able to record the transport stream for a DVB-T2 mux (about 150Mb in 30 seconds - I'm in UK, so these are the Freeview HD channels).

The original Linux source for the Sony CXD2028R has in it's header:

#define CXD2820R_TS_SERIAL 0x08
#define CXD2820R_TS_SERIAL_MSB 0x28
#define CXD2820R_TS_PARALLEL 0x30
#define CXD2820R_TS_PARALLEL_MSB 0x70

for 'ts_mode' settings. I've no idea what 0xBC means. Anyone else want to give this 'ts_mode' a go? Anyone know the meaning of these settings?

Hi Gavin.

I probably won't have a chance to test this register change right away, but believe me I'll get onto it as soon as I can (problems with my HTPC in the lounge) !

Cheers very much - I've been poring over those logs for ages - I suppose I went number blind after a while

reg 0x70
bit 4 - parallel or serial TS bus
bit 5 - bit order for serial mode
bit 3 - bit order for parallel mode

reg 0x71
bit 4 - TS clock inversion setting (0: Falling/Negative edge, 1: Rising/Positive edge)

Hi CrazyCat,

Thanks for describing these registers.

I've copied what the Windows driver appears to be doing from the CSV log - not setting register 70 at all and setting 71 to 0xBC.

Perhaps I need to experiment with setting register 70 also - unless you know what the power-on default is for this register?

Cheers,

Gavin

Default parallel mode, so driver not touch it.
Look like important only TS clock inversion bit (must be 0, but default is 1).
And 0x71 reg diffrent for DVB-T/C and T2.
TS clock inversion is 0x71 bit 4 for T/C, and bit 6 for T2.
So need add bool config option for cxd2820r and clear only this bits on demod init.

Second edition patch ready Please test in DVB-T and T2 mode. And DVB-C, if possible.

IT WORKS! IT WORKS! IT WORKS!

Did I mention that it now works? ;-)

Brilliant - tunes dvb-t & dvb-t2 just fine. BER seems to wander a little, but in my earlier register poking I managed to get a zap to lock with a solid 0 BER on the same frequency.. I'll do more testing & then see if I can reproduce the improvement.

Thanks crazycat :-D

Thanks for explaining what these registers actually do, CrazyCat.

I've applied similar changes to my driver source and it works for T and T2 (I can't check C as I don't have it).

Gavin, so you had a working driver already (ok not in DVB-T2 mode) ? Why was this thread the first I'd heard of it? ;-)

For future reference, none of my windows bus sniffs had any TS mode registers in them. Is there a knack to getting USB inits captured with USBlyzer? (yes, I tried enabling the hot-plugged devices tickbox)

Justin, check my init csv for windows. Init is not much different until 0x51.
It is done with usblyzer.

Edit: Sorry I did not notice the patch was already sent by crazycat, I'll test that right away

Edit2: Yes, it works, WOW thank you a lot CrazyCat for the fix and others who helped to find root cause for the problem!!

Hi Justin. I found this post when I realised that my own driver code for the T220 only worked with DVB-T. I thought that Linux support for this device had been available for some time and was surprised to discover that it had only just been released in kernel 3.14. It was just a happy coincidence that when I was looking for a solution on this, I found you guys on this thread were also looking for it.

As in my first post, my driver is not a Linux kernel driver but is derived from information in the source. I began working on this 'project' when I realised that there were no DVB-T2 based digital TV tuners that were supported on the Mac (my personal 'weapon of choice'…). I then made two 'stupid' decisions - and no, I don't include buying a Mac one of them !!

Stupid decision 1: How hard can it be to write a driver? I'll write one myself...

Stupid decision 2: As there were (at the time) only 3 or 4 (USB based) DVB-T2 devices, I decided I might as well write drivers for all of them…

Unfortunately, it's going a lot slower than I would like, and is definitely a 'work in progress'…

I've not begun to look into getting usb sniffs with stuff like 'usblyzer' yet - but I do need to at some point soon.

Cheers!

Hi Gavin.

No need to defend your decision to buy a Mac.. I'd be tempted to try one if I wasn't always wasting my money on nearly working TV tuners & the like ;-)

I gather that USB sniffing is only part of the 'fun'. The more accomplished driver hacker also speeds things along with i2c bus sniffers etc.. see here if you've not already: http://blog.palosaari.fi/2014/04/naked-hardware-15-pctv-triplestick-292e.html

See, as much as some people despise Windows, we still all need it - if only to get gear like this working properly. Oh, and unless you buy USBlyzer, it's only a 30 day trial so you'd be better off with usbsnoop on Windows XP (but who still has THAT lying around? Dad? LOL)

BTW I finally managed to find a 0x71 write from my Windows machine in a USB sniff this morning - exactly the way I expected it to work.

All the detective work has been kinda fun, and I'm sorry if I tried anybody's patience along the way.. I'm tempted to have a go helping to get this going in DVB-T2 mode... and I think there might be an I2C sniffer at work I can borrow.. http://www.ebay.co.uk/itm/USB-DIGITAL-DVB-T2-HDTV-TV-STICK-REMOTE-RECORDER-RECEIVER-DVB-C-DV-FM-DAB-ESY1-/201075991259?pt=UK_Computing_Video_Capture_TV_Tuner_Cards&hash=item2ed11022db

Crazy Cat wrote:

Default parallel mode, so driver not touch it.
Look like important only TS clock inversion bit (must be 0, but default is 1).
And 0x71 reg diffrent for DVB-T/C and T2.
TS clock inversion is 0x71 bit 4 for T/C, and bit 6 for T2.
So need add bool config option for cxd2820r and clear only this bits on demod init.

Second edition patch ready Please test in DVB-T and T2 mode. And DVB-C, if possible.

Can you advise how to apply this patch? Am happy with the Basic V4L build instructions here : http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers and assume I need to apply the patch between the git clone and media build bits (well there isn't much option is there? )

Would love to test.

Hi Stephen,

Apply the patch to the git clone - the patch file contains a 'diff' for each file that needs changes applied to it (take a look at the patch file with 'vi' and you'll see them). Or do 'man patch' for further info.

Justin H wrote:

I gather that USB sniffing is only part of the 'fun'. The more accomplished driver hacker also speeds things along with i2c bus sniffers etc.. see here if you've not already: http://blog.palosaari.fi/2014/04/naked-hardware-15-pctv-triplestick-292e.html

Yeah, I read Antti's blog and saw that he has started on this one. Haven't got a triplestick yet, but it's the next one to buy (shame the 290e is obsolete - I rather like it…)

See, as much as some people despise Windows, we still all need it - if only to get gear like this working properly. Oh, and unless you buy USBlyzer, it's only a 30 day trial so you'd be better off with usbsnoop on Windows XP (but who still has THAT lying around? Dad? LOL)

Only realised that 'usblyzer' was 'pay-ware' yesterday - so I've started looking at other options. I only have a little windows machine running 7, so snoop is out for me too! If anyone has any recommendations for a win7 USB analyser, please let me know.

All the detective work has been kinda fun, and I'm sorry if I tried anybody's patience along the way.. I'm tempted to have a go helping to get this going in DVB-T2 mode... and I think there might be an I2C sniffer at work I can borrow.. http://www.ebay.co.uk/itm/USB-DIGITAL-DVB-T2-HDTV-TV-STICK-REMOTE-RECORDER-RECEIVER-DVB-C-DV-FM-DAB-ESY1-/201075991259?pt=UK_Computing_Video_Capture_TV_Tuner_Cards&hash=item2ed11022db

I'll need to look into I2C sniffers - I guess you can see all the data going over the usb interface but you've gotta understand what it actually means!
Yep, getting these things working is challenging and rewarding. I got one of these 'astrometa' devices at the start of last week (took 3 weeks to arrive from China)! It's currently last on my list to work on - there is someone looking at the T2 panasonic demod - I have links to the git repo somewhere but it can be found in the discussion threads via that entry in Antti's blog.

Cheers,

Gavin

Stephen Neal wrote:

Can you advise how to apply this patch? Am happy with the Basic V4L build instructions here : http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers and assume I need to apply the patch between the git clone and media build bits (well there isn't much option is there? )

Would love to test.

I had the same question and figured out how to do it last night. I saved the patch file into the backports dir, added a reference to it in the backports.txt file under [3.255.255] and then just did the build as normal

Gavin, there's http://freeusbanalyzer.com/ ... I've not tried it yet but it might be a good bet. Oh and FWIW I've tried debugging USB in a virtual environment without any luck whatsoever.

Gavin, would you care to share your Mac driver for the August DVB-T2 stick please? I'd find it very useful!

And is Crazy Cat's patch going to appear in an upcoming Linux kernel release or will we be forced to compile our own Linux drivers for the foreseeable future?

Ross, I expect crazycat will submit the new code to linuxtv fairly soon, and it'll find its way into a kernel release from there.

Somebody can test DVB-T2 VHF ?

P.S. I commit latest my fixes for T220 in anoyher my V4L repo's:
linux-tbs-drivers - https://bitbucket.org/CrazyCat/linux-tbs-drivers
s2-liplianin-v39 - https://bitbucket.org/CrazyCat/s2-liplianin-v39

I can confirm that DVB-T2 VHF is working. I have already run it several days in my VDR and it has been stable.
I have patched media_build only with your latest patch. Also nanostick is still working with the patched driver.

Ross Collins wrote:

Gavin, would you care to share your Mac driver for the August DVB-T2 stick please? I'd find it very useful!

Sure, that was always the plan, but I don't think this thread is the place to discuss it.

Your profile doesn't include an email, so send me one off-thread if you're still interested.

Crazy Cat wrote:

reg 0x70
bit 4 - parallel or serial TS bus
bit 5 - bit order for serial mode
bit 3 - bit order for parallel mode

reg 0x71
bit 4 - TS clock inversion setting (0: Falling/Negative edge, 1: Rising/Positive edge)

Hi Crazy Cat,

Do you have any information on what bit 1 of register 0x71 does?

I have some simple code that demultiplexes MPEG-TS (works fine with 290e), but fails to find sync bytes with August T210. If I set bit 1, it finds sync. Does this control sync byte inversion?

Cheers,

Gavin

bit 0 or bit 1 ? DVB-T or T2 ?