Hauppauge HVR-900 HD and HVR 930C-HD with si2165

Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Ulf]

Hi,

I know the topic Hauppauge HVR-900 HD and HVR 930C-HD with si2165 demodulator was already discussed http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/40982 and http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266.
Just for me as a confirmation nobody plans to work on a driver for si2165.
Is there any chance how to push the development?

Ulf

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Antti Palosaari]

On 08/17/2013 02:30 PM, Ulf wrote:
> Hi,
>
> I know the topic Hauppauge HVR-900 HD and HVR 930C-HD with si2165 demodulator was already discussed http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/40982 and http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266.
> Just for me as a confirmation nobody plans to work on a driver for si2165.
> Is there any chance how to push the development?

comment mode
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266

As far as I know there is none working with si2165 Linux driver.

Last week I dumped out simple sniff from initial tuning to DVB-T channel 
and parsed log - it was 1.1 MB after parsing - wow. I haven't analyzed 
if it yet, but if it appears it is si2165 which generates that much 
control I/O it could be big task to write driver.

Anyone has the idea if that amount of USB I/O traffic is caused by cx231xx ?

regards
Antti

-- 
http://palosaari.fi/

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Hans Petter Selasky]

On 08/17/13 13:53, Antti Palosaari wrote:
> On 08/17/2013 02:30 PM, Ulf wrote:
>> Hi,
>>
>> I know the topic Hauppauge HVR-900 HD and HVR 930C-HD with si2165
>> demodulator was already discussed
>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/40982
>> and
>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266.
>>
>> Just for me as a confirmation nobody plans to work on a driver for
>> si2165.
>> Is there any chance how to push the development?
>
> comment mode
> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266
>
>
> As far as I know there is none working with si2165 Linux driver.
>
> Last week I dumped out simple sniff from initial tuning to DVB-T channel
> and parsed log - it was 1.1 MB after parsing - wow. I haven't analyzed
> if it yet, but if it appears it is si2165 which generates that much
> control I/O it could be big task to write driver.
>
> Anyone has the idea if that amount of USB I/O traffic is caused by
> cx231xx ?
>
> regards
> Antti
>

Hi,

FYI: The Si2168 driver is available from "dvbsky-linux-3.9-hps-v2.diff" 
inside. Maybe the Si2165 is similar?

http://www.selasky.org/hans_petter/distfiles/webcamd-3.10.0.7.tar.bz2

--HPS

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Antti Palosaari]

On 08/18/2013 02:54 PM, Hans Petter Selasky wrote:
> On 08/17/13 13:53, Antti Palosaari wrote:
>> On 08/17/2013 02:30 PM, Ulf wrote:
>>> Hi,
>>>
>>> I know the topic Hauppauge HVR-900 HD and HVR 930C-HD with si2165
>>> demodulator was already discussed
>>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/40982
>>>
>>> and
>>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266.
>>>
>>>
>>> Just for me as a confirmation nobody plans to work on a driver for
>>> si2165.
>>> Is there any chance how to push the development?
>>
>> comment mode
>> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266
>>
>>
>>
>> As far as I know there is none working with si2165 Linux driver.
>>
>> Last week I dumped out simple sniff from initial tuning to DVB-T channel
>> and parsed log - it was 1.1 MB after parsing - wow. I haven't analyzed
>> if it yet, but if it appears it is si2165 which generates that much
>> control I/O it could be big task to write driver.
>>
>> Anyone has the idea if that amount of USB I/O traffic is caused by
>> cx231xx ?
>>
>> regards
>> Antti
>>
>
> Hi,
>
> FYI: The Si2168 driver is available from "dvbsky-linux-3.9-hps-v2.diff"
> inside. Maybe the Si2165 is similar?
>
> http://www.selasky.org/hans_petter/distfiles/webcamd-3.10.0.7.tar.bz2

It is DVB-S driver. HVR-900 is DVB-T and DVB-C.

regards
Antti

-- 
http://palosaari.fi/

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Steven Toth]

> FYI: The Si2168 driver is available from "dvbsky-linux-3.9-hps-v2.diff"
> inside. Maybe the Si2165 is similar?

Excellent.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Hans Petter Selasky]

On 08/18/13 21:02, Steven Toth wrote:
>> FYI: The Si2168 driver is available from "dvbsky-linux-3.9-hps-v2.diff"
>> inside. Maybe the Si2165 is similar?
>
> Excellent.
>

Hi Guys,

I was contacted by someone claiming to be from "RSD" ??, named Danny 
Griegs, off-list, claiming I have the source code for sit2.c and cannot 
distribute it.

I want to make clear to everyone that the tarball I've provided only 
contains the C-equivalent of the "objdump -dx" output from the 
media_build-bst/v4l/sit2.o.x86 which is distributed officially by DVBSKY.

He claimed I had to pull the tarball off my site right away or face 
legal actions. I cannot understand this, and would like to ask you guys 
what you think. Obviously my sit2.c is too similar to their "licensed" 
sit2.c. And now these guys want to send a lawyer after me. What a mess. 
Should I laugh or cry. Any advice from you guys about this?

BTW: The hexdump of the sit2.o.x86 contains the string "license=GPL". 
Does that give me any rights to redistribute the re-assembled C-code ?

>
>> 00002460  63 28 29 20 66 61 69 6c  65 64 0a 00 01 36 73 69  |c() failed...6si|
>> 00002470  74 32 3a 20 25 73 2c 20  70 6f 77 65 72 20 75 70  |t2: %s, power up|
>> 00002480  0a 00 01 36 73 69 74 32  3a 20 25 73 2c 20 70 6f  |...6sit2: %s, po|
>> 00002490  77 65 72 20 75 70 5b 25  64 5d 0a 00 76 65 72 73  |wer up[%d]..vers|
>> 000024a0  69 6f 6e 3d 31 2e 30 30  00 6c 69 63 65 6e 73 65  |ion=1.00.license|
>> 000024b0  3d 47 50 4c 00 61 75 74  68 6f 72 3d 4d 61 78 20  |=GPL.author=Max |
>> 000024c0  4e 69 62 62 6c 65 20 3c  6e 69 62 62 6c 65 2e 6d  |Nibble <nibble.m|
>> 000024d0  61 78 40 67 6d 61 69 6c  2e 63 6f 6d 3e 00 64 65  |ax@gmail.com>.de|
>> 000024e0  73 63 72 69 70 74 69 6f  6e 3d 73 69 74 32 20 64  |scription=sit2 d|
>> 000024f0  65 6d 6f 64 75 6c 61 74  6f 72 20 64 72 69 76 65  |emodulator drive|
>> 00002500  72 00 70 61 72 6d 3d 73  69 74 32 5f 64 65 62 75  |r.parm=sit2_debu|
>> 00002510  67 3a 41 63 74 69 76 61  74 65 73 20 66 72 6f 6e  |g:Activates fron|
>> 00002520  74 65 6e 64 20 64 65 62  75 67 67 69 6e 67 20 28  |tend debugging (|
>> 00002530  64 65 66 61 75 6c 74 3a  30 29 00 70 61 72 6d 74  |default:0).parmt|
>> 00002540  79 70 65 3d 73 69 74 32  5f 64 65 62 75 67 3a 69  |ype=sit2_debug:i|

Thank you.

--HPS

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Antti Palosaari]

On 08/19/2013 10:47 PM, Hans Petter Selasky wrote:
> On 08/18/13 21:02, Steven Toth wrote:
>>> FYI: The Si2168 driver is available from "dvbsky-linux-3.9-hps-v2.diff"
>>> inside. Maybe the Si2165 is similar?
>>
>> Excellent.
>>
>
> Hi Guys,
>
> I was contacted by someone claiming to be from "RSD" ??, named Danny
> Griegs, off-list, claiming I have the source code for sit2.c and cannot
> distribute it.
>
> I want to make clear to everyone that the tarball I've provided only
> contains the C-equivalent of the "objdump -dx" output from the
> media_build-bst/v4l/sit2.o.x86 which is distributed officially by DVBSKY.
>
> He claimed I had to pull the tarball off my site right away or face
> legal actions. I cannot understand this, and would like to ask you guys
> what you think. Obviously my sit2.c is too similar to their "licensed"
> sit2.c. And now these guys want to send a lawyer after me. What a mess.
> Should I laugh or cry. Any advice from you guys about this?

Mabbe better to take off and develop clean room reverse-engineered one 
from the sniffs. It should not be mission impossible, but took a much 
more time. Also, it could be possible to get datasheets from the chipset 
vendor in order to develop totally new driver.

> BTW: The hexdump of the sit2.o.x86 contains the string "license=GPL".
> Does that give me any rights to redistribute the re-assembled C-code ?

I think that is grey area. There is a lot of binary modules having GPL 
license symbol whilst code is never shared...


>>> 00002460  63 28 29 20 66 61 69 6c  65 64 0a 00 01 36 73 69  |c()
>>> failed...6si|
>>> 00002470  74 32 3a 20 25 73 2c 20  70 6f 77 65 72 20 75 70  |t2: %s,
>>> power up|
>>> 00002480  0a 00 01 36 73 69 74 32  3a 20 25 73 2c 20 70 6f
>>> |...6sit2: %s, po|
>>> 00002490  77 65 72 20 75 70 5b 25  64 5d 0a 00 76 65 72 73  |wer
>>> up[%d]..vers|
>>> 000024a0  69 6f 6e 3d 31 2e 30 30  00 6c 69 63 65 6e 73 65
>>> |ion=1.00.license|
>>> 000024b0  3d 47 50 4c 00 61 75 74  68 6f 72 3d 4d 61 78 20
>>> |=GPL.author=Max |
>>> 000024c0  4e 69 62 62 6c 65 20 3c  6e 69 62 62 6c 65 2e 6d  |Nibble
>>> <nibble.m|
>>> 000024d0  61 78 40 67 6d 61 69 6c  2e 63 6f 6d 3e 00 64 65
>>> |ax@gmail.com>.de|
>>> 000024e0  73 63 72 69 70 74 69 6f  6e 3d 73 69 74 32 20 64
>>> |scription=sit2 d|
>>> 000024f0  65 6d 6f 64 75 6c 61 74  6f 72 20 64 72 69 76 65
>>> |emodulator drive|
>>> 00002500  72 00 70 61 72 6d 3d 73  69 74 32 5f 64 65 62 75
>>> |r.parm=sit2_debu|
>>> 00002510  67 3a 41 63 74 69 76 61  74 65 73 20 66 72 6f 6e
>>> |g:Activates fron|
>>> 00002520  74 65 6e 64 20 64 65 62  75 67 67 69 6e 67 20 28  |tend
>>> debugging (|
>>> 00002530  64 65 66 61 75 6c 74 3a  30 29 00 70 61 72 6d 74
>>> |default:0).parmt|
>>> 00002540  79 70 65 3d 73 69 74 32  5f 64 65 62 75 67 3a 69
>>> |ype=sit2_debug:i|
>
> Thank you.
>
> --HPS

regards
Antti


-- 
http://palosaari.fi/

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Konstantin Dimitrov]

hi Hans,

On Mon, Aug 19, 2013 at 10:47 PM, Hans Petter Selasky <hps@bitfrost.no> wrote:
> On 08/18/13 21:02, Steven Toth wrote:
>>>
>>> FYI: The Si2168 driver is available from "dvbsky-linux-3.9-hps-v2.diff"
>>> inside. Maybe the Si2165 is similar?
>>
>>
>> Excellent.
>>
>
> Hi Guys,
>
> I was contacted by someone claiming to be from "RSD" ??, named Danny Griegs,
> off-list, claiming I have the source code for sit2.c and cannot distribute
> it.
>

there is www.rsd.de, which is abbreviation for rohde-schwarz-something
and to where that side is actually redirecting. so, they are
German-based company making DVB equipment and maybe if that's the same
RSD that Danny Griegs guy could be legit. however, nothing in the
binary you used proves they have any ownership over the binary or the
code compiled in it. so, you can ask them to show you their NDA with
Silicon Labs - after all they can't have access to that information in
the code without valid NDA with Silicon Labs.

> I want to make clear to everyone that the tarball I've provided only
> contains the C-equivalent of the "objdump -dx" output from the
> media_build-bst/v4l/sit2.o.x86 which is distributed officially by DVBSKY.
>

so, there is no any guarantee that the code Max Nibble packed in that
binary is really his creation - he had a history of copy-left
practices - for example some time ago he tried to change the copyright
notice of code i released under GPL:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg41135.html

as its main architecture was based on 'cx24116.c' made by Steven Toth
and others, even the work of 'ds3000' demodulator is quite different
and i made a lot of changes in the code leaving almost no resemblance
with 'cx24116.c'.

so, if you search the list there are few discussions about 'ds3000',
which i made and what Max Nibble did with it. also, Max Nibble is most
likely not his real name - those DVBsky-brand products are made by
Chinese company with the notorious name of "BestTunar" (yes, i didn't
make spelling error here). in any case that's issue between RSD/Danny
Griegs and Max Nibble, not between you and them. also, you can check
the originating IP of the email from RSD/Danny Griegs and ensure it's
not some of the many personalities of Max Nibble - he writes from IP
addresses located at Shenzhen, China.

> He claimed I had to pull the tarball off my site right away or face legal
> actions. I cannot understand this, and would like to ask you guys what you
> think. Obviously my sit2.c is too similar to their "licensed" sit2.c. And
> now these guys want to send a lawyer after me. What a mess. Should I laugh
> or cry. Any advice from you guys about this?
>
> BTW: The hexdump of the sit2.o.x86 contains the string "license=GPL". Does
> that give me any rights to redistribute the re-assembled C-code ?
>

i'm not an intellectual property lawyer, but what you did is at least
honest, i mean add notice:

"Max Nibble wrote the initial code, but only released it in binary
form. Assembly to C conversion done by HP Selasky."

and as far as you can tell the license of the code in the binary
module is GPL, because recently similar as what you did with that
driver happened with close-source driver made by me - that driver
included both open-source patches to GPL code and thus GPL and not
open-source module - all the code for it was submitted as several
patches to V4L and the submitter when i confronted:

http://www.spinics.net/lists/linux-media/msg65888.html

just said - i didn't know you made that:

http://www.spinics.net/lists/linux-media/msg65889.html

how convenient even thought 'modinfo' of the not-open-source module of
the initial driver lists the license as not-GPL and my name and email
as author and thus all changes that are made as part of that driver
are clearly why and who made them. anyway, i just move one, because it
seems even open-source community like V4L is no longer supportive of
the real authorship and don't care the things to be open-sourced in
some proper way, which is damaging for the community if you ask me.

so, as i mentioned on one of the links above, i don't see anything
wrong with clean-room reverse-engineering, even if that includes
disassembling of some binary as you did (a lot of open-source drivers
are made that way, when there is no publicly available datasheets), as
far as that is mentioned as note, which you did - i mean if you have
full understanding of the driver work then it's fine and you can even
maintain it and make no any notes, but otherwise it's just a bunch of
magic numbers that are reversed from the binary and nothing more, i.e.
you can't maintain and extent its functionality beyond what's in the
binary and totally ignore and give no credit to the one that made the
binary - let's say some of the chip initialization values needs to be
changed due to a bug. so, in the last case i guess that has more
negative impact than it helps, because even like my case that NDAs are
preventing the driver to become open-source that doesn't mean at some
point it wouldn't be open-sourced in a proper way, i.e. with
permission from those which intellectual property prevents being
open-sourced. however, net results of the whole story i told is that i
can't commit and contribute even to the code that was open-sourced
based on my work. so, anyway, what i'm saying is that your case is not
precedent for V4L and so even for my case if some of the parties
decides i guess have grounds for that and can take legal actions, but
that didn't stop anyone and the code to be submitted to V4L.

best regards,
konstantin

>>
>>> 00002460  63 28 29 20 66 61 69 6c  65 64 0a 00 01 36 73 69  |c()
>>> failed...6si|
>>> 00002470  74 32 3a 20 25 73 2c 20  70 6f 77 65 72 20 75 70  |t2: %s,
>>> power up|
>>> 00002480  0a 00 01 36 73 69 74 32  3a 20 25 73 2c 20 70 6f  |...6sit2:
>>> %s, po|
>>> 00002490  77 65 72 20 75 70 5b 25  64 5d 0a 00 76 65 72 73  |wer
>>> up[%d]..vers|
>>> 000024a0  69 6f 6e 3d 31 2e 30 30  00 6c 69 63 65 6e 73 65
>>> |ion=1.00.license|
>>> 000024b0  3d 47 50 4c 00 61 75 74  68 6f 72 3d 4d 61 78 20
>>> |=GPL.author=Max |
>>> 000024c0  4e 69 62 62 6c 65 20 3c  6e 69 62 62 6c 65 2e 6d  |Nibble
>>> <nibble.m|
>>> 000024d0  61 78 40 67 6d 61 69 6c  2e 63 6f 6d 3e 00 64 65
>>> |ax@gmail.com>.de|
>>> 000024e0  73 63 72 69 70 74 69 6f  6e 3d 73 69 74 32 20 64
>>> |scription=sit2 d|
>>> 000024f0  65 6d 6f 64 75 6c 61 74  6f 72 20 64 72 69 76 65  |emodulator
>>> drive|
>>> 00002500  72 00 70 61 72 6d 3d 73  69 74 32 5f 64 65 62 75
>>> |r.parm=sit2_debu|
>>> 00002510  67 3a 41 63 74 69 76 61  74 65 73 20 66 72 6f 6e  |g:Activates
>>> fron|
>>> 00002520  74 65 6e 64 20 64 65 62  75 67 67 69 6e 67 20 28  |tend
>>> debugging (|
>>> 00002530  64 65 66 61 75 6c 74 3a  30 29 00 70 61 72 6d 74
>>> |default:0).parmt|
>>> 00002540  79 70 65 3d 73 69 74 32  5f 64 65 62 75 67 3a 69
>>> |ype=sit2_debug:i|
>
>
> Thank you.
>
> --HPS
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Hans Petter Selasky]

On 08/20/13 00:43, Konstantin Dimitrov wrote:
> German-based company making DVB equipment and maybe if that's the same
> RSD that Danny Griegs guy could be legit. however, nothing in the

Hi,

I've asked Danny to confirm his identity. The @googlemail.com e-mail 
transcript was quite empty :-(

According to Skype he is located in the GB. That's all I've got.

Hope this matter will resolve soon.

--HPS

Re: Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[nibble.max]

Hello Hans,

I am the original author of sit2 source code based on the reference code from silabs.
And we have signed NDA with silabs, it does not allow us to release the source code to the public.
I donot know it is permited or not when you do decompiling the binary code.

What happened between Konstantin Dimitrov and me, I think there is something misunderstand before.
But it looks it is not simple thing as I know he works for the competitor company.
I have some respect before, but now I think he is ridiculous and hostile.
As soon s his rumor release, we know our products really beat him.
What I want to tell him, please improve your products and make them stable.
The rumor just hurt him, not us. 
The customer start to do not believe him as they know the truth someday.

Finally, I have no relationship with Danny Griegs. He does not work for us and pay nothing to him.

BR,
Max
>On 08/20/13 00:43, Konstantin Dimitrov wrote:
>> German-based company making DVB equipment and maybe if that's the same
>> RSD that Danny Griegs guy could be legit. however, nothing in the
>
>Hi,
>
>I've asked Danny to confirm his identity. The @googlemail.com e-mail 
>transcript was quite empty :-(
>
>According to Skype he is located in the GB. That's all I've got.
>
>Hope this matter will resolve soon.
>
>--HPS
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Hans Petter Selasky]

On 08/20/13 10:26, nibble.max wrote:
> Hello Hans,
>
> I am the original author of sit2 source code based on the reference code from silabs.
> And we have signed NDA with silabs, it does not allow us to release the source code to the public.
> I donot know it is permited or not when you do decompiling the binary code.
>

Thank you Max for clearing this up a bit,

I can tell you that the decompiled driver works like expected with the 
product I bought and lets me use this product under FreeBSD like I was 
expecting after reading the Linux-commercial's from the Vendor.

Maybe an idea for the future. Abstract binaries a bit more so that they 
are independent of the Linux header files and other kernel functions. 
Then I wouldn't have to do the decompile.

The other DVB-T adapter I had before outputted somtimes corrupted or too 
long USB packets on the isochronous endpoint when the bitrate was going 
too high. I do no longer see this problem with the adapter supported by 
Max's driver. And I am satisfied. Regarding you and "Konstantin 
Dimitrov" I don't want to have any opinion about what product is best.

--HPS

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Matthias Schwarzott]

On 26.09.2013 16:54, Antti Palosaari wrote:
> On 25.09.2013 07:50, Matthias Schwarzott wrote:
>> On 17.08.2013 13:30, Ulf wrote:
>>> Hi,
>>>
>>> I know the topic Hauppauge HVR-900 HD and HVR 930C-HD with si2165
>>> demodulator was already discussed
>>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/40982 
>>>
>>> and
>>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266. 
>>>
>>>
>>> Just for me as a confirmation nobody plans to work on a driver for
>>> si2165.
>>> Is there any chance how to push the development?
>>>
>>> Ulf
>> Hi!
>>
>> I also bought one of these to find out it is not supported.
>> But my plan is to try to write a driver for this.
>> I want to get DVB-C working, but I also have DVB-T and analog reception
>> available.
>>
>> My current status is I got it working in windows in qemu and did a usb
>> snoop.
>> I also have a second system to test it in windows vista directly on the
>> hardware.
>>
>> Current status is documented here.
>> http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-930C-HD
>>
>> Until now I only have a component list summarized from this list.
>>
>>   * Conexant <http://www.linuxtv.org/wiki/index.php/Conexant> CX231xx
>> <http://www.linuxtv.org/wiki/index.php/Conexant_CX2310x>
>>   * Silicon Labs
>>
>> <http://www.linuxtv.org/wiki/index.php?title=Silicon_Labs&action=edit&redlink=1> 
>>
>>
>>     si2165 <http://www.linuxtv.org/wiki/index.php/Silicon_Labs_si2165>
>>     (Multi-Standard DVB-T and DVB-C Demodulator)
>>   * NXP TDA18271
>> <http://www.linuxtv.org/wiki/index.php/NXP/Philips_TDA182xx>
>>     (silicon tuner IC, most likely i2c-addr: 0x60)
>>   * eeprom (windows driver reads 1kb, i2c-addr: 0x50)
>>
>>
>> Is this correct?
>> Did anyone open his device and can show pictures?
>>
>> I now need to know which component is at which i2c address.
>> Windows driver does upload file hcw10mlD.rom of 16kb to device 0x44.
>
> I have opened it. There was similar sandwich PCB than used by rev1 
> too. So you cannot see all the chip unless you use metal saw to 
> separate PCBs.
>
> PCB side A:
> TDA18271HDC2
> 16.000 MHz
>
> Si2165-GM
> 16.000 MHz
>
>
> PCB side B:
> 24C02H
>
> regards
> Antti
>
Hi Antti,

thanks for that information.
The only real new information for me is the 16.000MHz xtal value.

Sad to know that the other chips are hidden.
I assigned more i2c addresses to functions, but not yet all (no idea if 
more addresses are real, or bad interpretations of snooped data).

I now try to check what already works:
- This is video via composite input.
- Next is to try video via analog input - see I see if the tuner in 
general works in this device.

In parallel I try to capture usb in different setups.
1. kvm+tcpdump (using usbmon)
2. usbsnoop on windows vista

Only setup 1 does provide a real list of usb packets.

Regards
Matthias

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Antti Palosaari]

On 01.10.2013 08:34, Matthias Schwarzott wrote:
> On 26.09.2013 16:54, Antti Palosaari wrote:
>> On 25.09.2013 07:50, Matthias Schwarzott wrote:
>>> On 17.08.2013 13:30, Ulf wrote:
>>>> Hi,
>>>>
>>>> I know the topic Hauppauge HVR-900 HD and HVR 930C-HD with si2165
>>>> demodulator was already discussed
>>>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/40982
>>>>
>>>> and
>>>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266.
>>>>
>>>>
>>>> Just for me as a confirmation nobody plans to work on a driver for
>>>> si2165.
>>>> Is there any chance how to push the development?
>>>>
>>>> Ulf
>>> Hi!
>>>
>>> I also bought one of these to find out it is not supported.
>>> But my plan is to try to write a driver for this.
>>> I want to get DVB-C working, but I also have DVB-T and analog reception
>>> available.
>>>
>>> My current status is I got it working in windows in qemu and did a usb
>>> snoop.
>>> I also have a second system to test it in windows vista directly on the
>>> hardware.
>>>
>>> Current status is documented here.
>>> http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-930C-HD
>>>
>>> Until now I only have a component list summarized from this list.
>>>
>>>   * Conexant <http://www.linuxtv.org/wiki/index.php/Conexant> CX231xx
>>> <http://www.linuxtv.org/wiki/index.php/Conexant_CX2310x>
>>>   * Silicon Labs
>>>
>>> <http://www.linuxtv.org/wiki/index.php?title=Silicon_Labs&action=edit&redlink=1>
>>>
>>>
>>>     si2165 <http://www.linuxtv.org/wiki/index.php/Silicon_Labs_si2165>
>>>     (Multi-Standard DVB-T and DVB-C Demodulator)
>>>   * NXP TDA18271
>>> <http://www.linuxtv.org/wiki/index.php/NXP/Philips_TDA182xx>
>>>     (silicon tuner IC, most likely i2c-addr: 0x60)
>>>   * eeprom (windows driver reads 1kb, i2c-addr: 0x50)
>>>
>>>
>>> Is this correct?
>>> Did anyone open his device and can show pictures?
>>>
>>> I now need to know which component is at which i2c address.
>>> Windows driver does upload file hcw10mlD.rom of 16kb to device 0x44.
>>
>> I have opened it. There was similar sandwich PCB than used by rev1
>> too. So you cannot see all the chip unless you use metal saw to
>> separate PCBs.
>>
>> PCB side A:
>> TDA18271HDC2
>> 16.000 MHz
>>
>> Si2165-GM
>> 16.000 MHz
>>
>>
>> PCB side B:
>> 24C02H
>>
>> regards
>> Antti
>>
> Hi Antti,
>
> thanks for that information.
> The only real new information for me is the 16.000MHz xtal value.
>
> Sad to know that the other chips are hidden.
> I assigned more i2c addresses to functions, but not yet all (no idea if
> more addresses are real, or bad interpretations of snooped data).
>
> I now try to check what already works:
> - This is video via composite input.
> - Next is to try video via analog input - see I see if the tuner in
> general works in this device.
>
> In parallel I try to capture usb in different setups.
> 1. kvm+tcpdump (using usbmon)
> 2. usbsnoop on windows vista
>
> Only setup 1 does provide a real list of usb packets.

Matthias, you likely try to do things too complex :) I am not going to 
comment analog side as I simply has no experience. Missing piece of code 
from the DTV point of view is only si2165 demod driver.

My technique is to make successful tune one channel and take sniffs. 
 From sniffs I generate C-code register writes (and sometimes reads too) 
using scripts. Reading that "C-code" is much more visual and easier than 
looking correct bytes from the raw sniffs. It is essential to find out 
from the sniffs what are tuner register writes, what are demod register 
writes and what are for USB-bridge itself. There may be some other chips 
which are needed to init in order to operate, like in cases I2C bus is 
connected through analog demodulator to digital demodulator.

Usually it is rather trivial to make skeleton driver from the code 
generated from sniffs which just shows that single channel sniffs were 
taken.

I have been looking simple example for "reverse-engineer demodulator 
driver how-to" blog post, but I haven't found suitable device yet. That 
was one device I looked, but I given-up as simplest sniff after parsing 
was over 1MB. Looks like there is multiple firmwares to download and 
also CX231xx usb protocol generates a lot of I/O => not very good 
example for simple how-to.

Take a look of that post to see some practical example about sniffing 
and code generation.
http://blog.palosaari.fi/2013/07/generating-rtl2832u-driver-code.html

regards
Antti

-- 
http://palosaari.fi/

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Matthias Schwarzott]

On 01.10.2013 16:45, Antti Palosaari wrote:
> On 01.10.2013 08:34, Matthias Schwarzott wrote:
>> On 26.09.2013 16:54, Antti Palosaari wrote:
>>> On 25.09.2013 07:50, Matthias Schwarzott wrote:
>>>> On 17.08.2013 13:30, Ulf wrote:
>>>>> Hi,
>>>>>
>>>>> I know the topic Hauppauge HVR-900 HD and HVR 930C-HD with si2165
>>>>> demodulator was already discussed
>>>>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/40982 
>>>>>
>>>>>
>>>>> and
>>>>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266. 
>>>>>
>>>>>
>>>>>
>>>>> Just for me as a confirmation nobody plans to work on a driver for
>>>>> si2165.
>>>>> Is there any chance how to push the development?
>>>>>
>>>>> Ulf
>>>> Hi!
>>>>
>>>> I also bought one of these to find out it is not supported.
>>>> But my plan is to try to write a driver for this.
>>>> I want to get DVB-C working, but I also have DVB-T and analog 
>>>> reception
>>>> available.
>>>>
>>>> My current status is I got it working in windows in qemu and did a usb
>>>> snoop.
>>>> I also have a second system to test it in windows vista directly on 
>>>> the
>>>> hardware.
>>>>
>>>> Current status is documented here.
>>>> http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-930C-HD
>>>>
>>>> Until now I only have a component list summarized from this list.
>>>>
>>>>   * Conexant <http://www.linuxtv.org/wiki/index.php/Conexant> CX231xx
>>>> <http://www.linuxtv.org/wiki/index.php/Conexant_CX2310x>
>>>>   * Silicon Labs
>>>>
>>>> <http://www.linuxtv.org/wiki/index.php?title=Silicon_Labs&action=edit&redlink=1> 
>>>>
>>>>
>>>>
>>>>     si2165 <http://www.linuxtv.org/wiki/index.php/Silicon_Labs_si2165>
>>>>     (Multi-Standard DVB-T and DVB-C Demodulator)
>>>>   * NXP TDA18271
>>>> <http://www.linuxtv.org/wiki/index.php/NXP/Philips_TDA182xx>
>>>>     (silicon tuner IC, most likely i2c-addr: 0x60)
>>>>   * eeprom (windows driver reads 1kb, i2c-addr: 0x50)
>>>>
>>>>
>>>> Is this correct?
>>>> Did anyone open his device and can show pictures?
>>>>
>>>> I now need to know which component is at which i2c address.
>>>> Windows driver does upload file hcw10mlD.rom of 16kb to device 0x44.
>>>
>>> I have opened it. There was similar sandwich PCB than used by rev1
>>> too. So you cannot see all the chip unless you use metal saw to
>>> separate PCBs.
>>>
>>> PCB side A:
>>> TDA18271HDC2
>>> 16.000 MHz
>>>
>>> Si2165-GM
>>> 16.000 MHz
>>>
>>>
>>> PCB side B:
>>> 24C02H
>>>
>>> regards
>>> Antti
>>>
>> Hi Antti,
>>
>> thanks for that information.
>> The only real new information for me is the 16.000MHz xtal value.
>>
>> Sad to know that the other chips are hidden.
>> I assigned more i2c addresses to functions, but not yet all (no idea if
>> more addresses are real, or bad interpretations of snooped data).
>>
>> I now try to check what already works:
>> - This is video via composite input.
>> - Next is to try video via analog input - see I see if the tuner in
>> general works in this device.
>>
>> In parallel I try to capture usb in different setups.
>> 1. kvm+tcpdump (using usbmon)
>> 2. usbsnoop on windows vista
>>
>> Only setup 1 does provide a real list of usb packets.
>
> Matthias, you likely try to do things too complex :) I am not going to 
> comment analog side as I simply has no experience. Missing piece of 
> code from the DTV point of view is only si2165 demod driver.
>
> My technique is to make successful tune one channel and take sniffs. 
> From sniffs I generate C-code register writes (and sometimes reads 
> too) using scripts. Reading that "C-code" is much more visual and 
> easier than looking correct bytes from the raw sniffs. It is essential 
> to find out from the sniffs what are tuner register writes, what are 
> demod register writes and what are for USB-bridge itself. There may be 
> some other chips which are needed to init in order to operate, like in 
> cases I2C bus is connected through analog demodulator to digital 
> demodulator.
>
> Usually it is rather trivial to make skeleton driver from the code 
> generated from sniffs which just shows that single channel sniffs were 
> taken.
>
> I have been looking simple example for "reverse-engineer demodulator 
> driver how-to" blog post, but I haven't found suitable device yet. 
> That was one device I looked, but I given-up as simplest sniff after 
> parsing was over 1MB. Looks like there is multiple firmwares to 
> download and also CX231xx usb protocol generates a lot of I/O => not 
> very good example for simple how-to.
>
> Take a look of that post to see some practical example about sniffing 
> and code generation.
> http://blog.palosaari.fi/2013/07/generating-rtl2832u-driver-code.html
>
> regards
> Antti
>
Hi Antti,

my real problem currently is, that I cannot get a good usb dump:
1. In virtual machine (win xp under kvm) it finds one transponder when 
scanning DVB-T, but does not get a picture.
2. On real machine with vista I can tune perfectly, but usb snooping 
does not work (at least not the ones I tried).
3. The only sniffer that seemed to produce enough data on vista was 
usblyzer.
But there is not script to convert the output to usbsnoop format.

Should I install windows xp on real hardware to try usbsnoop there? What 
hw/sw/os are you using?

At least I found out something that is working.
By adding the correct ids to the mceusb driver,
the ir part works correctly and all keys of the remote are correctly 
recognized with the existing Hauppauge keymap.

Regards
Matthias

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Antti Palosaari]

On 07.10.2013 22:30, Matthias Schwarzott wrote:
> On 01.10.2013 16:45, Antti Palosaari wrote:
>> On 01.10.2013 08:34, Matthias Schwarzott wrote:
>>> On 26.09.2013 16:54, Antti Palosaari wrote:
>>>> On 25.09.2013 07:50, Matthias Schwarzott wrote:
>>>>> On 17.08.2013 13:30, Ulf wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I know the topic Hauppauge HVR-900 HD and HVR 930C-HD with si2165
>>>>>> demodulator was already discussed
>>>>>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/40982
>>>>>>
>>>>>>
>>>>>> and
>>>>>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Just for me as a confirmation nobody plans to work on a driver for
>>>>>> si2165.
>>>>>> Is there any chance how to push the development?
>>>>>>
>>>>>> Ulf
>>>>> Hi!
>>>>>
>>>>> I also bought one of these to find out it is not supported.
>>>>> But my plan is to try to write a driver for this.
>>>>> I want to get DVB-C working, but I also have DVB-T and analog
>>>>> reception
>>>>> available.
>>>>>
>>>>> My current status is I got it working in windows in qemu and did a usb
>>>>> snoop.
>>>>> I also have a second system to test it in windows vista directly on
>>>>> the
>>>>> hardware.
>>>>>
>>>>> Current status is documented here.
>>>>> http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-930C-HD
>>>>>
>>>>> Until now I only have a component list summarized from this list.
>>>>>
>>>>>   * Conexant <http://www.linuxtv.org/wiki/index.php/Conexant> CX231xx
>>>>> <http://www.linuxtv.org/wiki/index.php/Conexant_CX2310x>
>>>>>   * Silicon Labs
>>>>>
>>>>> <http://www.linuxtv.org/wiki/index.php?title=Silicon_Labs&action=edit&redlink=1>
>>>>>
>>>>>
>>>>>
>>>>>     si2165 <http://www.linuxtv.org/wiki/index.php/Silicon_Labs_si2165>
>>>>>     (Multi-Standard DVB-T and DVB-C Demodulator)
>>>>>   * NXP TDA18271
>>>>> <http://www.linuxtv.org/wiki/index.php/NXP/Philips_TDA182xx>
>>>>>     (silicon tuner IC, most likely i2c-addr: 0x60)
>>>>>   * eeprom (windows driver reads 1kb, i2c-addr: 0x50)
>>>>>
>>>>>
>>>>> Is this correct?
>>>>> Did anyone open his device and can show pictures?
>>>>>
>>>>> I now need to know which component is at which i2c address.
>>>>> Windows driver does upload file hcw10mlD.rom of 16kb to device 0x44.
>>>>
>>>> I have opened it. There was similar sandwich PCB than used by rev1
>>>> too. So you cannot see all the chip unless you use metal saw to
>>>> separate PCBs.
>>>>
>>>> PCB side A:
>>>> TDA18271HDC2
>>>> 16.000 MHz
>>>>
>>>> Si2165-GM
>>>> 16.000 MHz
>>>>
>>>>
>>>> PCB side B:
>>>> 24C02H
>>>>
>>>> regards
>>>> Antti
>>>>
>>> Hi Antti,
>>>
>>> thanks for that information.
>>> The only real new information for me is the 16.000MHz xtal value.
>>>
>>> Sad to know that the other chips are hidden.
>>> I assigned more i2c addresses to functions, but not yet all (no idea if
>>> more addresses are real, or bad interpretations of snooped data).
>>>
>>> I now try to check what already works:
>>> - This is video via composite input.
>>> - Next is to try video via analog input - see I see if the tuner in
>>> general works in this device.
>>>
>>> In parallel I try to capture usb in different setups.
>>> 1. kvm+tcpdump (using usbmon)
>>> 2. usbsnoop on windows vista
>>>
>>> Only setup 1 does provide a real list of usb packets.
>>
>> Matthias, you likely try to do things too complex :) I am not going to
>> comment analog side as I simply has no experience. Missing piece of
>> code from the DTV point of view is only si2165 demod driver.
>>
>> My technique is to make successful tune one channel and take sniffs.
>> From sniffs I generate C-code register writes (and sometimes reads
>> too) using scripts. Reading that "C-code" is much more visual and
>> easier than looking correct bytes from the raw sniffs. It is essential
>> to find out from the sniffs what are tuner register writes, what are
>> demod register writes and what are for USB-bridge itself. There may be
>> some other chips which are needed to init in order to operate, like in
>> cases I2C bus is connected through analog demodulator to digital
>> demodulator.
>>
>> Usually it is rather trivial to make skeleton driver from the code
>> generated from sniffs which just shows that single channel sniffs were
>> taken.
>>
>> I have been looking simple example for "reverse-engineer demodulator
>> driver how-to" blog post, but I haven't found suitable device yet.
>> That was one device I looked, but I given-up as simplest sniff after
>> parsing was over 1MB. Looks like there is multiple firmwares to
>> download and also CX231xx usb protocol generates a lot of I/O => not
>> very good example for simple how-to.
>>
>> Take a look of that post to see some practical example about sniffing
>> and code generation.
>> http://blog.palosaari.fi/2013/07/generating-rtl2832u-driver-code.html
>>
>> regards
>> Antti
>>
> Hi Antti,
>
> my real problem currently is, that I cannot get a good usb dump:
> 1. In virtual machine (win xp under kvm) it finds one transponder when
> scanning DVB-T, but does not get a picture.

I think demod locks (== means signal is OK and demod streams data), but 
stream got lost somewhere on kvm. I have had similar experiences many 
years back when I tested some virtual machines.

> 2. On real machine with vista I can tune perfectly, but usb snooping
> does not work (at least not the ones I tried).

SniffUSB2.0 does not support any newer than XP :/ Thats really bad. We 
have to find out new solution...

> 3. The only sniffer that seemed to produce enough data on vista was
> usblyzer.
> But there is not script to convert the output to usbsnoop format.

There is actually script and it is quite simple. I have got it someone 
when we discussed AF9035 driver earlier. I just sent mail to that person 
and asked if he could share that script.

> Should I install windows xp on real hardware to try usbsnoop there? What
> hw/sw/os are you using?

I use native XP on my laptop and SniffUSB2.0.

Lets wait day or two if we can get that conversion script.

>
> At least I found out something that is working.
> By adding the correct ids to the mceusb driver,
> the ir part works correctly and all keys of the remote are correctly
> recognized with the existing Hauppauge keymap.

regards
Antti

-- 
http://palosaari.fi/

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Matthias Schwarzott]

On 07.10.2013 22:16, Antti Palosaari wrote:
> On 07.10.2013 22:30, Matthias Schwarzott wrote:
>> my real problem currently is, that I cannot get a good usb dump:
>> 1. In virtual machine (win xp under kvm) it finds one transponder when
>> scanning DVB-T, but does not get a picture.
>
> I think demod locks (== means signal is OK and demod streams data), 
> but stream got lost somewhere on kvm. I have had similar experiences 
> many years back when I tested some virtual machines.
Hi Antti,

You were absolutely right here. Using the USB sniffs from the virtual 
machine, I got a picture. So only the stream seems to get lost.
I did this by using these steps:

* Record data: tcpdump -i usbmon1 -w win-tune.tcpdump
* Start virtual machine and tune

* Convert to usbsniff format: parse_tcpdump_log.pl win-tune.tcpdump
* Run parse_cx231xx.pl on it (so i2c transfers can be seen)
* Format it by my own parse-si2165.py

With this I get code of 4700 i2c sends/receives.
When adding a msleep(1) into my si2165_read function, I get a picture 
most of the tries.
This is for DVB-T with fixed set of parameters.

Regards
Matthias

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Antti Palosaari]

On 16.10.2013 07:50, Matthias Schwarzott wrote:
> On 07.10.2013 22:16, Antti Palosaari wrote:
>> On 07.10.2013 22:30, Matthias Schwarzott wrote:
>>> my real problem currently is, that I cannot get a good usb dump:
>>> 1. In virtual machine (win xp under kvm) it finds one transponder when
>>> scanning DVB-T, but does not get a picture.
>>
>> I think demod locks (== means signal is OK and demod streams data),
>> but stream got lost somewhere on kvm. I have had similar experiences
>> many years back when I tested some virtual machines.
> Hi Antti,
>
> You were absolutely right here. Using the USB sniffs from the virtual
> machine, I got a picture. So only the stream seems to get lost.
> I did this by using these steps:
>
> * Record data: tcpdump -i usbmon1 -w win-tune.tcpdump
> * Start virtual machine and tune
>
> * Convert to usbsniff format: parse_tcpdump_log.pl win-tune.tcpdump
> * Run parse_cx231xx.pl on it (so i2c transfers can be seen)
> * Format it by my own parse-si2165.py
>
> With this I get code of 4700 i2c sends/receives.
> When adding a msleep(1) into my si2165_read function, I get a picture
> most of the tries.
> This is for DVB-T with fixed set of parameters.

Nice! Thats very good starting point =) Now start implementing things 
correctly.

* proper I2C routines / register write / read
* firmware download
* demod lock flags (that could be found easily by looking sniffs, it is 
reg(s) that is read very often and almost never written)

In a case of demod most registers has just hard coded values. Only case 
where you will likely see different register values is bandwidth 
settings. Unfortunately it is hard to find without modulator where you 
could test easily all 6/7/8 MHz, sniff and diff. Fortunately though, 8 
MHz is used almost everywhere in the world...

regards
Antti

-- 
http://palosaari.fi/

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[pierigno]

[-- Attachment #1: Type: text/plain, Size: 6152 bytes --]

Hi Matthias,

I went through a similar path in the past, using USBLyzer on a
virtualized windows environment, and developed this simple awk script
to adapt the csv output of USBLyzer to usbsnoop format. Hope it helps
:)





2013/10/7 Matthias Schwarzott <zzam@gentoo.org>:
> On 01.10.2013 16:45, Antti Palosaari wrote:
>>
>> On 01.10.2013 08:34, Matthias Schwarzott wrote:
>>>
>>> On 26.09.2013 16:54, Antti Palosaari wrote:
>>>>
>>>> On 25.09.2013 07:50, Matthias Schwarzott wrote:
>>>>>
>>>>> On 17.08.2013 13:30, Ulf wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I know the topic Hauppauge HVR-900 HD and HVR 930C-HD with si2165
>>>>>> demodulator was already discussed
>>>>>>
>>>>>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/40982
>>>>>>
>>>>>> and
>>>>>>
>>>>>> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/46266.
>>>>>>
>>>>>>
>>>>>> Just for me as a confirmation nobody plans to work on a driver for
>>>>>> si2165.
>>>>>> Is there any chance how to push the development?
>>>>>>
>>>>>> Ulf
>>>>>
>>>>> Hi!
>>>>>
>>>>> I also bought one of these to find out it is not supported.
>>>>> But my plan is to try to write a driver for this.
>>>>> I want to get DVB-C working, but I also have DVB-T and analog reception
>>>>> available.
>>>>>
>>>>> My current status is I got it working in windows in qemu and did a usb
>>>>> snoop.
>>>>> I also have a second system to test it in windows vista directly on the
>>>>> hardware.
>>>>>
>>>>> Current status is documented here.
>>>>> http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-930C-HD
>>>>>
>>>>> Until now I only have a component list summarized from this list.
>>>>>
>>>>>   * Conexant <http://www.linuxtv.org/wiki/index.php/Conexant> CX231xx
>>>>> <http://www.linuxtv.org/wiki/index.php/Conexant_CX2310x>
>>>>>   * Silicon Labs
>>>>>
>>>>>
>>>>> <http://www.linuxtv.org/wiki/index.php?title=Silicon_Labs&action=edit&redlink=1>
>>>>>
>>>>>
>>>>>     si2165 <http://www.linuxtv.org/wiki/index.php/Silicon_Labs_si2165>
>>>>>     (Multi-Standard DVB-T and DVB-C Demodulator)
>>>>>   * NXP TDA18271
>>>>> <http://www.linuxtv.org/wiki/index.php/NXP/Philips_TDA182xx>
>>>>>     (silicon tuner IC, most likely i2c-addr: 0x60)
>>>>>   * eeprom (windows driver reads 1kb, i2c-addr: 0x50)
>>>>>
>>>>>
>>>>> Is this correct?
>>>>> Did anyone open his device and can show pictures?
>>>>>
>>>>> I now need to know which component is at which i2c address.
>>>>> Windows driver does upload file hcw10mlD.rom of 16kb to device 0x44.
>>>>
>>>>
>>>> I have opened it. There was similar sandwich PCB than used by rev1
>>>> too. So you cannot see all the chip unless you use metal saw to
>>>> separate PCBs.
>>>>
>>>> PCB side A:
>>>> TDA18271HDC2
>>>> 16.000 MHz
>>>>
>>>> Si2165-GM
>>>> 16.000 MHz
>>>>
>>>>
>>>> PCB side B:
>>>> 24C02H
>>>>
>>>> regards
>>>> Antti
>>>>
>>> Hi Antti,
>>>
>>> thanks for that information.
>>> The only real new information for me is the 16.000MHz xtal value.
>>>
>>> Sad to know that the other chips are hidden.
>>> I assigned more i2c addresses to functions, but not yet all (no idea if
>>> more addresses are real, or bad interpretations of snooped data).
>>>
>>> I now try to check what already works:
>>> - This is video via composite input.
>>> - Next is to try video via analog input - see I see if the tuner in
>>> general works in this device.
>>>
>>> In parallel I try to capture usb in different setups.
>>> 1. kvm+tcpdump (using usbmon)
>>> 2. usbsnoop on windows vista
>>>
>>> Only setup 1 does provide a real list of usb packets.
>>
>>
>> Matthias, you likely try to do things too complex :) I am not going to
>> comment analog side as I simply has no experience. Missing piece of code
>> from the DTV point of view is only si2165 demod driver.
>>
>> My technique is to make successful tune one channel and take sniffs. From
>> sniffs I generate C-code register writes (and sometimes reads too) using
>> scripts. Reading that "C-code" is much more visual and easier than looking
>> correct bytes from the raw sniffs. It is essential to find out from the
>> sniffs what are tuner register writes, what are demod register writes and
>> what are for USB-bridge itself. There may be some other chips which are
>> needed to init in order to operate, like in cases I2C bus is connected
>> through analog demodulator to digital demodulator.
>>
>> Usually it is rather trivial to make skeleton driver from the code
>> generated from sniffs which just shows that single channel sniffs were
>> taken.
>>
>> I have been looking simple example for "reverse-engineer demodulator
>> driver how-to" blog post, but I haven't found suitable device yet. That was
>> one device I looked, but I given-up as simplest sniff after parsing was over
>> 1MB. Looks like there is multiple firmwares to download and also CX231xx usb
>> protocol generates a lot of I/O => not very good example for simple how-to.
>>
>> Take a look of that post to see some practical example about sniffing and
>> code generation.
>> http://blog.palosaari.fi/2013/07/generating-rtl2832u-driver-code.html
>>
>> regards
>> Antti
>>
> Hi Antti,
>
> my real problem currently is, that I cannot get a good usb dump:
> 1. In virtual machine (win xp under kvm) it finds one transponder when
> scanning DVB-T, but does not get a picture.
> 2. On real machine with vista I can tune perfectly, but usb snooping does
> not work (at least not the ones I tried).
> 3. The only sniffer that seemed to produce enough data on vista was
> usblyzer.
> But there is not script to convert the output to usbsnoop format.
>
> Should I install windows xp on real hardware to try usbsnoop there? What
> hw/sw/os are you using?
>
> At least I found out something that is working.
> By adding the correct ids to the mceusb driver,
> the ir part works correctly and all keys of the remote are correctly
> recognized with the existing Hauppauge keymap.
>
> Regards
> Matthias
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: usblyzer2usbsnoop.awk --]
[-- Type: application/octet-stream, Size: 1631 bytes --]

#!/usr/bin/awk -f

function get_type(field) {
	switch(field) {
		case /Control Transfer/:
			return "ControlTransfer";
		case /Bulk/:
			return "BULK";
		default:
			return;
	}
}


function get_direction(field) {
	switch(field) {
		case "in": 	return "<<<";
		case "out": return ">>>";
		default: return "---";
	}
}

# USBLyzer C:I:E field
function get_cie(field) {
	ret = split(field,element,":",seps);
	if(ret==3)
		return strtonum(element[3]);
}


function get_elapsed(field) {
	return strtonum(field)*1000;
}


function get_duration(field) {
	if(field!="") {
		split(field,element," ",seps);
		num = strtonum(element[1]);
		switch(element[2]) {
			case "us": num*1;
			case "ms": num*1000;
			default: break;
			
		}
		return num;
	}
	else return 0;
}


function get_bytes(field) {
	ret = split(field,element," ",seps);
	if(ret==3)
		return strtonum(element[1]);
}

BEGIN {
	FS=",";
	myNR=0;
	flip_header=1;
}

{
	if($6 ~ /Control Transfer/ || ($6 ~ /Bulk/ && $7 ~ /data/))
		myNR++;
}


($6 ~ /Control Transfer/ || ($6 ~ /Bulk/ && $7 ~ /data/)) {
 
		type = get_type($6);
		direction = get_direction($9);
		cie = get_cie($10);
		elapsed = get_elapsed($4);
		duration = get_duration($5);
		bytes = get_bytes($7);

		if(type == "BULK") {
			if(flip_header) {
				flip_header=0;
				printf("%06d:  URB_FUNCTION_SELECT_CONFIGURATION\n",myNR++);
			}
			# (%02d bytes)
			printf("%06d:  OUT: %07d us %07d ms BULK[%05d] %s %s\n",myNR,duration,elapsed,cie,direction,tolower($16));
		}

		if(type == "ControlTransfer")
			printf("%06d:  OUT: %07d us %07d ms ControlTransfer %s %s\n",myNR,duration,elapsed,direction,tolower($16)); 
}

Re: Hauppauge HVR-900 HD and HVR 930C-HD with si2165

[Matthias Schwarzott]

On 07.10.2013 22:21, pierigno wrote:
> Hi Matthias,
>
> I went through a similar path in the past, using USBLyzer on a
> virtualized windows environment, and developed this simple awk script
> to adapt the csv output of USBLyzer to usbsnoop format. Hope it helps
> :)
>
Hi pierigno,
thank you.
Yes, your script worked as far as it is possible.
But it turned out, usblyzer does not write the setup packet information 
to csv nor to xml output.
And only seeing it in the gui is not helpful for a few thousand register 
writes.

Regards
Matthias