Skip to contentSkip to conversation

usb-dvb and endpoints question

linux-dvb Dennis Noordsij 2 participants 5 messages May 31, 2008 Media (V4L/DVB)

lore
Share & tools
lore

Dennis Noordsij

author
#0 lore raw

Hi list,

I am writing a driver for the TerraTec Piranha DVB-T USB stick (actually the Sanio SMS-1000 chipset). From reading USB logs I have a working libusb prototype which can tune and receive the transport stream, and use the hardware PID filter.

Porting it to a proper linux DVB driver I have the following question:

This device has exactly 2 bulk endpoints, as follows:

Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0

All control messages go out over EP2. All responses, as well as the transport stream, come in over EP1.

All incoming packets have a small header which allows it to be mapped back to the corresponding request (excepting TS data which can be read spontaneously, but which is still marked with an additional header).

Does this mean that I can not really use the dvb-usb framework ? (since there is no generic_bulk_ctrl_endpoint, and since the TS stream also does not come on its own endpoint and even needs additional depackatizing).

Since incoming data is mixed with TS packets, you can no longer just write a command and read the next response. TS data will be streaming in and every time you make some request you will probably get some TS data first, and only then your response. How to solve?

Any pointers in the right direction? :-)

Cheers,
Dennis

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#1 lore raw
Quoted 32 lines · Dennis Noordsij

Hi list,

I am writing a driver for the TerraTec Piranha DVB-T USB stick (actually the Sanio SMS-1000 chipset). From reading USB logs I have a working libusb prototype which can tune and receive the transport stream, and use the hardware PID filter.

Porting it to a proper linux DVB driver I have the following question:

This device has exactly 2 bulk endpoints, as follows:

Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0

Quoted 2 lines

All control messages go out over EP2. All responses, as well as the transport stream, come in over EP1.

uh, very crazy solution :o

Quoted 7 lines

All incoming packets have a small header which allows it to be mapped back to the corresponding request (excepting TS data which can be read spontaneously, but which is still marked with an additional header).

Does this mean that I can not really use the dvb-usb framework ? (since there is no generic_bulk_ctrl_endpoint, and since the TS stream also does not come on its own endpoint and even needs additional depackatizing).

Looks like it is not possible to use dvb-framework very much...

...But you can use generic_bulk_ctrl_endpoint & generic_write to write data if you can use dvb-framework partially. But reading data could be very hard to implement.

Quoted 6 lines

Since incoming data is mixed with TS packets, you can no longer just write a command and read the next response. TS data will be streaming in and every time you make some request you will probably get some TS data first, and only then your response. How to solve?

Any pointers in the right direction? :-)

Other thoughts, wMaxPacketSize 0x0040 1x 64 bytes looks rather small for TS.

Can you provide sample usb-sniff from windows? Parsed with usb-replay parser.pl -script would be enough if whole sniff is very large.

Quoted 2 lines

Cheers,
Dennis

regards
Antti

Signature · 6 lines
http://palosaari.fi/

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
author
#2 lore raw

Hi Antti,

Thank you for your reply!

Quoted 2 lines

Other thoughts, wMaxPacketSize 0x0040 1x 64 bytes looks rather small for TS.

Yeah it would be, but somehow this seems to just be ignored. A tyical response would be a single USB packet containing exactly 21 TS packets, and 8 bytes of header (for a total of 3956 bytes)

See example below where it seems to interrupt the request-response with TS data.

As for reading-writing, I've got a specific version of the usb_dvb_generic_rw (using 2 endpoints) and it works fine by itself. But I haven't got around to how the the TS streaming is going work.

What is the read-loop going to be like ? :-)

Quoted 2 lines

Can you provide sample usb-sniff from windows? Parsed with usb-replay parser.pl -script would be enough if whole sniff is very large.

I've used different programs, but some example:

000820: Bulk or Interrupt Transfer (UP), 30.05.2008 14:06:09.336 +0.125.
Status: 0x00000000
Pipe Handle: 0xffad2bec (Endpoint Address: 0x81)
Get 0xf74 bytes from the device

 B5 02 14 01 74 0F 05 00 47 00 12 1B 67 65 72 05   ....t...G...ger.
 05 52 65 62 61 0C 05 56 6F 6C 6C 65 73 20 48 61   .Reba..Volles Ha
 75 73 54 02 15 00 4E FA 02 67 65 72 00 F4 05 55   usT...N..ger...U
 6E 74 65 72 68 61 6C 74 75 6E 67 73 73 65 72 69   nterhaltungsseri

... etc

Note that this contains TS data, "74 0F" is the length of the USB packet (0xF74 = 3956), after 8 bytes of header the TS sync 0x47 can be seen. Exactly 21 TS packets are contained.

Since the packets are so large, and I can't get the TerraTec software to do too much in terms of sending commands in between, I don't really have
many good logs of the mixing of TS and responses.

But one example:

000392: Bulk or Interrupt Transfer (DOWN), 30.05.2008 18:31:14.919 +0.0 Pipe Handle: 0x8118b66c (Endpoint Address: 0x2)
Send 0xc bytes to the device
67 02 C9 0B 0C 00 00 00 20 00 20 81 g.�..... . �

000393: Bulk or Interrupt Transfer (UP), 30.05.2008 18:31:14.919 +0.0.
Status: 0x00000000
Pipe Handle: 0x8118b66c (Endpoint Address: 0x2)
Send 0xc bytes to the device
000394: Bulk or Interrupt Transfer (UP), 30.05.2008 18:31:14.919 +0.0.
Status: 0x00000000
Pipe Handle: 0x8118b64c (Endpoint Address: 0x81)
Get 0xf74 bytes from the device
B5 02 14 01 74 0F 05 00 47 0F B4 1B 27 0B BA C2 �...t...G.�.'.��
... TS data follows ..

000395: Bulk or Interrupt Transfer (DOWN), 30.05.2008 18:31:14.919 +0.0 Pipe Handle: 0x8118b64c (Endpoint Address: 0x81)
Get 0x1000 bytes from the device
000396: Bulk or Interrupt Transfer (UP), 30.05.2008 18:31:14.935 +0.015.
Status: 0x00000000
Pipe Handle: 0x8118b64c (Endpoint Address: 0x81)
Get 0xe0 bytes from the device

 68 02 0B C9 E0 00 00 00 00 00 00 00 00 00 00 00   h..��...........
 01 00 00 00 01 00 00 00 00 00 00 00 1B 00 00 00   ................
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 1D 00 00 00 D2 FF FF FF 2D C5 FF FF 70 CE 34 1D   ....����-���p�4.
 00 00 00 00 01 00 00 00 0D 00 00 00 03 00 00 00   ................
 02 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00   ................
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

1) What data was sent in 393 ?
2) The response came after the TS packet (396 is the response to 392).
3) What data was received in 395 ?

Note that I've basically ignored the 395-type responses, they're shown also in the firmware initialization but if I just look at logs which actually show data then everything works correctly, so 395 and 393 would be noise ?

Hope I am not missing some basic USB thing that makes you slap your forehead and say "aha it's just the device telling you to do X!" :-)

Cheers,
Dennis

Quoted 5 lines
Quoted 2 lines

Cheers,
Dennis

regards
Antti

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

author
#3 lore raw
In reply to Antti Palosaari
Quoted 3 lines

Other thoughts, wMaxPacketSize 0x0040 1x 64 bytes looks rather small for TS.

Incidentally, usb-sniff reports the following:

ConfigurationDescriptor = 0xffb6adf8 (configure)

  ConfigurationDescriptor : bLength             = 9
  ConfigurationDescriptor : bDescriptorType     = 0x00000002
  ConfigurationDescriptor : wTotalLength        = 0x00000020
  ConfigurationDescriptor : bNumInterfaces      = 0x00000001
  ConfigurationDescriptor : bConfigurationValue = 0x00000001
  ConfigurationDescriptor : iConfiguration      = 0x00000000
  ConfigurationDescriptor : bmAttributes        = 0x00000080
  ConfigurationDescriptor : MaxPower            = 0x00000032
  ConfigurationHandle     = 0x811fa720
  Interface[0]: Length            = 56
  Interface[0]: InterfaceNumber   = 0
  Interface[0]: AlternateSetting  = 0
  Interface[0]: Class             = 0x000000ff
  Interface[0]: SubClass          = 0x00000002
  Interface[0]: Protocol          = 0x00000000
  Interface[0]: InterfaceHandle   = 0xffb7efa0
  Interface[0]: NumberOfPipes     = 2
  Interface[0]: Pipes[0] : MaximumPacketSize = 0x00000040
  Interface[0]: Pipes[0] : EndpointAddress   = 0x00000081
  Interface[0]: Pipes[0] : Interval          = 0x00000000
  Interface[0]: Pipes[0] : PipeType          = 0x00000002 (UsbdPipeTypeBulk)
  Interface[0]: Pipes[0] : PipeHandle        = 0xffb7efbc
  Interface[0]: Pipes[0] : MaxTransferSize   = 0x00010000
  Interface[0]: Pipes[0] : PipeFlags         = 0x00000000
  Interface[0]: Pipes[1] : MaximumPacketSize = 0x00000040
  Interface[0]: Pipes[1] : EndpointAddress   = 0x00000002
  Interface[0]: Pipes[1] : Interval          = 0x00000000
  Interface[0]: Pipes[1] : PipeType          = 0x00000002 (UsbdPipeTypeBulk)
  Interface[0]: Pipes[1] : PipeHandle        = 0xffb7efdc
  Interface[0]: Pipes[1] : MaxTransferSize   = 0x00010000  <<<<<<<<
  Interface[0]: Pipes[1] : PipeFlags         = 0x00000000

which makes more sense ?

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb