Tvheadend

Ingmar Nurmiste wrote:

I can see a DVB-T2 HD channel with August DVB-T210 with OE 4.0 beta 4 and 5. There is only one upscaled test channel in that MUX, that is all we have in Estonia with DVB-T2 :(
Tried Finnish Digita HD MUX, but no luck. Works in Windows, so not an reception issue.
EDIT: Finnish channels did not work even in Windows in that location to be correct. (But with the same antenna Samsung receiver works well).

I've contacted the related kerenl developer and he notified me about an issue with high bitrate muxes (more than 40Mbps) so this might be the reason of your success (although it may be not related).

I've sent this thread link to that developer and I hopes he could join the disscussion.

As I said I can't help debugging as [maybe] only at June DVB-T2 service will be up here so I recommend anyone know enough Linux voodoo (at least compiling v4l-dvb and patching files) to try contact him through the linuxtv mailing list (or directly, not sure if appropriate).

dhead 666 wrote:

I've contacted the related kerenl developer and he notified me about an issue with high bitrate muxes (more than 40Mbps) so this might be the reason of your success (although it may be not related).

I've sent this thread link to that developer and I hopes he could join the disscussion.

As I said I can't help debugging as [maybe] only at June DVB-T2 service will be up here so I recommend anyone know enough Linux voodoo (at least compiling v4l-dvb and patching files) to try contact him through the linuxtv mailing list (or directly, not sure if appropriate).

That might explain the corruption issue i'm seeing when performing a w_scan of the DVB-T2 transmissions here - the bitrate is 40.2Mbit/sec.

I received an answer from the kernel developer.

• DVB-T2 servie details: country, frequency, bandwidth, modulation params (mod, fec, guard interval, trans mode).
• Logs: dmesg on init and scan/lock.

I'll add that you should keep all the info in one post.

Edit:
The the following error occurs when the device is connected to USB 3.0 port, when I connected to USB 2.0 port I didn't saw this error.

dvb-usb: recv bulk message failed: -110
dw2102: i2c transfer failed.

Err, I ran the Beta 5 off a new SD card but just get 'Connection lost' continually. Am I missing something obvious? Will try a reboot but this is very weird.

EDIT That wasn't very descriptive, apologies. I've got the TVHeadend enabled, Live TV enabled and the August 210 connected, however TVHeadEnd just reports "connection lost" every 10 seconds. Can't open the webpage which would usually list any connected tuners - page doesn't exist, so something's missing...

I've been following this thread with interest because I also bought one of these 'cheap' DVB-T2 tuners under the assumption that the linuxtv wiki page was correct. Two days after I placed the order, information emerged that it's a bit wonky on dvb-t2 in linux.

Anyway, at the risk of sounding unhelpful there's very little point in switching between versions of any distro in the hope the tuner will just start working. It's not going to work until the person debugging the linux driver has made more headway - and then tvheadend will need to incorporate the changes he eventually comes up with :-)

What everybody needs to do is (eek!) get on the commandline - SSH is great for this - and grab the output of the dmesg command upon plugging the tuner in, then grab the same output again when attempting to get a signal lock (i.e. during a w_scan or tzap command). The more information the developer has to work with, the better.

I'm starting to suspect (though I hope I'm completely wrong) that maybe this tuner's hardware just isn't up to the job. Maybe under Windows (especially with the junk software it comes with) the PID filtering is done on the tuner, meaning only one channel's bandwidth goes across the USB bridge at a time. Under Linux, the kernel driver is expecting to put the whole transport over USB & it will do any PID filtering. So, 10-15Mbps.. works fine.. but 40+Mbps doesn't. As I've already said I hope I'm wrong, and that tweaking the driver will fix this.

I've had a go at translating a USB analyser capture of the tuner running in Windows to see what's going on - and then comparing that with what the linux driver is doing, but it's tough going. Those linuxtv guys make it sound so easy!

This device not have any hw PID filtering. Used well-known Cypress FX2 family usb controller.

Justin Hornsby wrote:

I'm starting to suspect (though I hope I'm completely wrong) that maybe this tuner's hardware just isn't up to the job. Maybe under Windows (especially with the junk software it comes with) the PID filtering is done on the tuner, meaning only one channel's bandwidth goes across the USB bridge at a time. Under Linux, the kernel driver is expecting to put the whole transport over USB & it will do any PID filtering. So, 10-15Mbps.. works fine.. but 40+Mbps doesn't. As I've already said I hope I'm wrong, and that tweaking the driver will fix this.

I don't know how windows drivers works but you could dissmiss this easily if you try to save (or stream) the whole TS with VLC, it should be easy to achieve by VLC menus (so no command line) but I don't got windows running ATM to guide you through.

Crazy Cat wrote:

This device not have any hw PID filtering. Used well-known Cypress FX2 family usb controller.

Ah cool, that's very good to know. I've been told hardware PID filtering is a very rare thing in TV tuners these days.

Is there anything else I can do for you in terms of testing things? I'm currently working blind trying to get some kind of result from tzap in linux etc but I don't have any PID info for the transport I want to try zapping.

dhead 666 wrote:

I don't know how windows drivers works but you could dissmiss this easily if you try to save (or stream) the whole TS with VLC, it should be easy to achieve by VLC menus (so no command line) but I don't got windows running ATM to guide you through.

I've hooked up my one to my Windows PC to see if I could receive a DVB-T2 stream. Unfortunately, i'm not connected to the roof aerial, but I can pick up muxes no problem with an internal aerial (i'm not that far from Crystal Palace). Interestingly, when selecting a capture device with VLC, selecting DVB-T2 resulted in an error, but if I selected DVB-T and input the DVB-T2 mux frequency, I could tune and receive the HD channels without issue. Luckily, the DVB-T2 signals are just about strong enough to be picked up on the internal aerial without issue.

I've used VLC to save the mux, and it recorded flawlessly. I've got a 30 second recording which if I re-open in VLC I can still switch between channels.

So I guess that means that the adaptor is able to stream a full DVB-T2 mux over USB at over 40Mbit/sec (it was a 42Mbit/sec mux).

Edit: I can supply this mux recording if it'll help. It was recorded raw, no transcoding, so it comes to 145MB for 30 seconds of recording.

I make some changes in streaming mode for this device in dw2102 driver. See attached patch.
Maybe this resolve this issue.

Another patch for alternative support based on generic cxusb driver. This code from some Geniatech developer (old media_build published on russian ixbt forum). Use same tuner/demod drivers. Load dvb-usb-cxusb module instead dvb-usb-dw2102 (or disable before compiling).

P.S. look like this code used in Geniatech Android-based media-players for own usb tuners.

Thankyou very much Crazycat :-) I'll try both of these patches tonight, starting with the first.

Quickly tested both and still not working Max bandwidth I get is about 28Mbit/s while the stream is about 38Mbit/s.

Here usb traffic for both linux and windows.

Linux with Wireshark :
cxusb driver
http://koti.kapsi.fi/~bogey/august_dvb-t210/august_210_init_linux-cxusb.pcapng.gz
dw2102 driver
http://koti.kapsi.fi/~bogey/august_dvb-t210/august_210_init_linux-dw2102.pcapng.gz

Windows with usblyzer in csv format:
http://koti.kapsi.fi/~bogey/august_dvb-t210/august_210_init_windows.csv

if you see the raw data, the bytes are often doubled (e.g. 3e 3e 73 73 5c 5c ff ff 65 65 43 43 e0 e0 58 58 ..)
See for example below screenshot. There is is some garbage text from EPG or from subtitles, and every char is twice. Duplication of the bytes is visible everywhere in the stream.
http://koti.kapsi.fi/~bogey/august_dvb-t210/ts_data.png

Or see this raw data with hex editor (37MB)
http://koti.kapsi.fi/~bogey/august_dvb-t210/raw.ts

Under Windows 8.1 with the drivers downloaded from August website and the Arcsoft Totalmedia software I can find all the channels, including the HD channels that are in the 586 MHz frequency band here. However, when I try to view any of those HD channels the picture is horribly pixelated. In Linux I cannot find any channels at all at @586 MHz (my w_scan result was attached to this thread already earlier). Jukka, does the thing work ok for you even in Windows for the Finnish HD channels?

Here in Southern Finland all the HD channels are put in the mux that's at 586000kHz. Maybe the bandwidth of that MUX is too much for the HW or the driver. All the SD channels (at other frequencies) work ok under Linux and Windows for me. The PCTV NanoStick 290e works for all SD and HD channels in Linux and Windows using the same software and same antenna. Signal strength indicators show a good signal on both tuners in the Windows software.

Yes in Windows it works fine, heres example stream recorded with VLC (31s, 37Mbit/s, 132MB)
http://koti.kapsi.fi/~bogey/august_dvb-t210/raw_windows.ts

Operator is DNA, only YLE TV1 HD and YLE TV2 HD are free view.

Ah, so you have the VHF frequency DNA channels. From Digita UHF frequencies you get also YLE Fem HD btw I wonder if there's a difference how these work. Unfortunately I don't have a VHF antenna to test the DNA channels...

I've been looking in the Windows & Linux USB capture logs for patterns & even in just the first 5 URB transfers I can see what look like big differences in register accesses. I don't know what these registers do, or if they're going to make any difference - some might, some might not.

Windows           Linux
08 6c 02 00 00    08 6c 02 00 00    -- Reset?
09 01 01 6c d3    09 01 01 6c fd    
08 6c 02 d3 00    09 01 01 6c db
08 6c 02 00 04    08 6c 02 db 01
09 01 01 6c 10    09 01 10 60 00

Going through my windows capture log, I find things like

000072:  OUT: 0000000 us 0544414 ms BULK[00001] >>> 08 6c 02 ad 00

but cannot find 08 6c 02 ad XX in the linux USB log anywhere.

I think the sequences starting 0x08 are I2C writes, and 0x09 are I2C reads. Presumably the CXD2820 device is I2C master, and anything going to address 6c (0x08 0x6c) is the TDA18122 tuner.

Whatever is happening I think the setup of the tuner & demod chips is close enough to allow DVB-T to work but not close enough for DVB-T2.

NOTE: I am not a linux driver hacking expert by any means, so take all this as a pet theory ;-)

Hello,
I tried to take some logs for the August DVB-T210.

Country: Finland
Frequency: E35 586MHz

I got this info from the broadcasting company (Digita.fi):

Capacity: SD - MPEG2 2,5Mb/s, HD - MPEG4 7Mb/s
Bandwidth: 8MHz
Modulation: 64 - QAM
FFT: 8K extended
G/I: 1/8
FEC: 4/5

Not sure if this can be trusted as the mux contains 3 HD channels and 1 SD channel, can 64QAM really carry that data rate?

I will attach dmesg from attaching the dongle and during scanning, w_scan log and its output file. Also VLC messages when tuned to HD channel (got static grey screen) + dvbtune output. I used Linux Mint with daily kernel 3.14.0-999-generic from 10th of April.

Hope it helps.

Ingmar

What is that setting ts_mode?

        .i2c_address = 0x6c, /* (0xd8 >> 1) */
        .ts_mode = 0x38,

08 6C 02 70 38

but that is not seen anywhere in windows sniff logs..

Also in windows it also sends many times to

08 6E 02 00 XX

that's not happening in Linux.

I can't find any TS mode setting from windows either. Maybe they're relying on the default TS mode when the chip powers up. Crope says to try commenting out the cxd 2820r init which sets it

I commented ts_mode out and now it sets it
08 6c 02 70 00

URB data in stream is now having only 0 and 1

I think to try not writing anything at all to register 0x70 is what crope means :-)

That is, do not call cxd 2820 init at all

CrazyCat, I see in the code that the TS mode is set to 0x38 .. is this done to engage a certain mode in the FX2 controller?

I'm trying to put USB analyzer dumps of register settings from Windows into Linux code now to see if I can kick this tuner into working for our 38Mb+ DVB-T2 transports, but not having much luck so far (no lock)

tsmode is ok, default parallel mode (i think 0x30 is same).

check new patch - some additional tsconfig register initialization in cxd2820r driver and changed initial fx2 firmware cmds in dw2102.