SmiUsbGrabber3E.sys

[Dave Satterfield]

Hi,
My driver did not come with SmiUsbGrabber3C.sys. Instead, I have
SmiUsbGrabber3E.sys. Are there instructions on how to extract the
firmware from this version of the driver?
Thanks,
David Satterfield

[Pedro Martos]

Hi,

It's possible that the size of the new firmware is different. You could try using current instrucctions, but if this doesn't work, you should extract the firmware from the usbsnoop log as described in the kernel section.

best regards,

Pedro 

2012/2/18 Dave Satterfield <davi...@gmail.com>

--
cordiales saludos,

Pedro Ignacio Martos

pma...@fi.uba.ar / pima...@gmail.com

http://web.fi.uba.ar/~pmartos

[Jon Arne Jørgensen]

The 3E is the version with 3 CVBS inputs, right?
This driver is not written for that version of the hardware, but i think we should be able to make it work.

There is another thread in the mailinglist with a guy who made the device work by using the firmware for the 3C. But It would be better if we can make it work with the correct firmware :)

[Dave Satterfield]

The device I have has 4 composite video inputs and one audio input.
Linux sees it like this:

[ 1.921141] usb 1-3: New USB device found, idVendor=1c88,
idProduct=0007
[ 1.921151] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 1.921158] usb 1-3: Product: SM-USB 007
[ 1.921161] usb 1-3: Manufacturer: Somagic, Inc.
[ 1.921164] usb 1-3: SerialNumber: SMBL007



On Feb 18, 9:10 am, Jon Arne Jørgensen <jonjon.arnea...@gmail.com>
wrote:

> The 3E is the version with 3 CVBS inputs, right?
> This driver is not written for that version of the hardware, but i think we should be able to make it work.
>
> There is another thread in the mailinglist with a guy who made the device work by using the firmware for the 3C. But It would be better if we can make it work with the correct firmware :)
>
>
>
>
>
>
>
> ----- Original message -----
> > Hi,
>
> > It's possible that the size of the new firmware is different. You could
> > try using current instrucctions, but if this doesn't work, you should
> > extract the firmware from the usbsnoop log as described in the kernel
> > section.
>
> > best regards,
> > Pedro
>

> > 2012/2/18 Dave Satterfield <david...@gmail.com>

>
> > > Hi,
> > > My driver did not come with SmiUsbGrabber3C.sys. Instead, I have
> > > SmiUsbGrabber3E.sys. Are there instructions on how to extract the
> > > firmware from this version of the driver?
> > > Thanks,
> > > David Satterfield
>
> > --
> > cordiales saludos,
> > Pedro Ignacio Martos

> > pmar...@fi.uba.ar / pimar...@gmail.com
> >http://web.fi.uba.ar/~pmartos

[calamari]

Maybe it's as simple as setting subaddress 02h to the desired CVBS
input?

Mode 0: CVBS (automatic gain) from AI11 (pin 4)
Mode 1: CVBS (automatic gain) from AI12 (pin 7)
Mode 2: CVBS (automatic gain) from AI21 (pin 43)
Mode 3: CVBS (automatic gain) from AI22 (pin 1)

Right now we're using "Mode 0", but it'd be trivial to support
selection of those other modes. I'm curious, does the
extract_somagic_firmware program find any firmware in
SmiUsbGrabber3E.sys? If it does, then the firmware is identical and
maybe the above change to the capture program is all that is needed.

calamari

[Dave Satterfield]

extract_somagic_firmware does not find the firmware.

[calamari]

Does anyone have a copy of SmiUsbGrabber3E.sys they'd be willing to
send me for analysis?

Thanks,
calamari

[Jon Arne Jørgensen]

I have a usbsnoop log. I will add it to git..

[calamari]

Thanks.

Looking on Amazon, I notice the "Easycap Model 002" is supposed to be
able to play back video from 4 CVBS inputs simultaneously. It seems
like the SAA7113H only allows one input to be selected at a time. Any
ideas how they are accomplishing multiple simultaneous inputs? Maybe
they are rapidly switching between the inputs? I'm not sure how
quickly it can change. Or maybe a different chip inside?

calamari

I wonder if we'd have to do something like is being done in both.c to
play multiple things simultaneously.. or is that completely different,
since it's two different chips?

calamari

On Feb 19, 11:44 am, Jon Arne Jørgensen <jonjon.arnea...@gmail.com>

[<=K]

Got the 3E firmware extracted (for the Somagic EasyCAP 002); it has a length of 6634 bytes. When the 002 firmware is used, the device is given a USB id of 1c88:003e (makes sense). Seems to work fine even on the DC60.

I've updated the extract-somagic-firmware program so that the 002 firmware can be extracted from SmiUsbGrabber3E.sys.

I've also updated somagic-init and somagic-capture to work with the 002. 

NOTE: Because we are now able to use the DC60 and 002, it seems like somagic_dc60 is no longer an appropriate project name (in the source file headers). I've replaced somagic_dc60 with somagic_easycap in the windows, tools, and user directories. I didn't touch the files in the kernel directory, because I wasn't sure if the naming was deliberate for the kernel driver.

David, could you please try extracting the firmware from your SmiUsbGrabber3E.sys file using extract-somagic-firmware, and see if the user space somagic-init and somagic-capture programs work for you? I haven't yet added the input selector, working on that as soon as I send this email.

Thanks,
calamari

[<=K]

David,

I've committed the input selector. To select the input, use -i # (where # is from 1 to 4), instead of -c (CVBS) or -s (S-VIDEO). Could you please try out inputs 1 through 4 and see if they work? I'm noticing that -i 2 seems to work on the DC60 (gives monochrome).. so that worries me.

Thanks,
calamari

[Jon Arne Jørgensen]

According to the SAA7113 Datasheet - Page 53 (as I'm able to read it).

The SAA7113 Has 4 analog inputs, and 2 AD Converters.
Analog IN 1 & 2 Is connected to the first AD converter. (This is
called A11 & A12 in the datasheet)
Analog IN 3 & 4 Is connected to the second AD Converter (This is
called A21 & A22 in the datasheet)
A CVBS signal uses only 1 Input + Ground, so there should be no
problem using 4 CVBS inputs on the SAA7113

S-VIDEO on the other hand needs two Analog inputs, one for Y (LUMA).
and one for C (CHROMA).

If you are receiving a monochrome image when choosing input 2,
I guess that is because you have a video source connected to your S-VIDEO input.

For the Easycap with 1 CVBS & 1 S-VIDEO, we have figured out that to
receive S-VIDEO, we need to set the chip to MODE7.
According to the datasheet, this means that the S-VIDEO input is
connected to Analog in 2 & 4 on the SAA7113 chip.

On Analog IN 2, the chip receives the S-VIDEO LUMA channel. While the
Chroma channel is on analog input 4.
So when you set the SAA7113 to MODE1, the chip is only decoding the
LUMA channel received from the S-VIDEO,
and you will receive a monochrome image.

Hope I managed to make my self clear here.
Just ask if you have any questions :)

-- Jonarne

--
Jonarne
http://jonarne.no

[Jeffry Johnston]

Thanks! I didn't even think to check the s-video input pins, only looked at the cvbs, and didn't consider that they'd share. You are right, I had both CVBS and S-VIDEO plugged in, and your explanation makes perfect sense. Whew!

Anyone had a chance to try -i on the real device?

calamari

2012/2/20 Jon Arne Jørgensen <jonjon....@gmail.com>

[Dave Satterfield]

Good news. The 3E firmware seems to work, and I get video from the #2
input. There seems to be an issue with the input selection however. -i
1 grabs from the #2 input, and the other options (-i 2, -i 3, -i 4)
don''t seem to select anything. Thanks for getting this far, hopefully
getting the other 3 inputs working won't be too hard. Let me know if
you need me to help test.
David Satterfield

On Feb 20, 1:04 pm, Jeffry Johnston <j...@kidsquid.com> wrote:
> Thanks! I didn't even think to check the s-video input pins, only looked at
> the cvbs, and didn't consider that they'd share. You are right, I had both
> CVBS and S-VIDEO plugged in, and your explanation makes perfect sense. Whew!
>
> Anyone had a chance to try -i on the real device?
>
> calamari
>

> 2012/2/20 Jon Arne Jørgensen <jonjon.arnea...@gmail.com>

> > On Mon, Feb 20, 2012 at 5:03 AM, <=K <calam...@gmail.com> wrote:
> > > David,
>
> > > I've committed the input selector. To select the input, use -i # (where
> > # is
> > > from 1 to 4), instead of -c (CVBS) or -s (S-VIDEO). Could you please try
> > out
> > > inputs 1 through 4 and see if they work? I'm noticing that -i 2 seems to
> > > work on the DC60 (gives monochrome).. so that worries me.
>
> > > Thanks,
> > > calamari
>

[Jeffry Johnston]

Thanks for testing it and volunteering for further testing! I've pushed a quick version where it allows -i from 1 to 16. Do any of the 5-16 inputs correspond to plug "1"?

Thanks,
calamari

[Dave Satterfield]

Perhaps a slight step backwards with the new version:

./somagic-capture -n -i 1
Claim failed with error -6

On Feb 20, 1:16 pm, Jeffry Johnston <j...@kidsquid.com> wrote:
> Thanks for testing it and volunteering for further testing! I've pushed a
> quick version where it allows -i from 1 to 16. Do any of the 5-16 inputs
> correspond to plug "1"?
>
> Thanks,
> calamari
>

[Dave Satterfield]

Ignore that last post, I had two instances running.

Input selections 1, 5, 7, 9 select input 2.
None of the selections choose inputs 1,3, or 4.

Hope that gives a clue.

> ...
>
> read more »

[Jeffry Johnston]

Bummer! I wonder if the model 002 could be using a very similar, but different Philips chip? I will need to do more research.

Does the audio capture program work if you use the 3c firmware?

calamari

[Dave Satterfield]

Audio capture program does not work with 3C firmware.

On Feb 20, 1:50 pm, Jeffry Johnston <j...@kidsquid.com> wrote:
> Bummer! I wonder if the model 002 could be using a very similar, but
> different Philips chip? I will need to do more research.
>
> Does the audio capture program work if you use the 3c firmware?
>
> calamari
>

> ...
>
> read more »

[Dave Satterfield]

I cracked open my adapter to see what's inside. It seems to have the
same 3 chips as listed in the wiki, but there's an analog mux in front
of the SA7113H. The only input that gets used is the AI11 input (pin
4). Controlling of the analog mux seems to be done via the SMI-2021CBE
chip, probably through the gpio pins from what I gather from the
sparse datasheet.

If the SMI-2021CBE is oriented so that the alignment dot is in the top
left corner, the pins in question would be the leftmost 2 on the north
side of the chip. They are right above the alignment dot. So, I think
the answer to switching the inputs lies in the SMI-2021 chip.

Does that help? Also, is there a detailed data sheet for the SMI-2021?

> ...
>
> read more »

[Jeffry Johnston]

Wow, thanks! I hope you can put it back together! That helps a lot. I will go ahead and remove the input select stuff for now, since my theory was completely wrong. Can always put the input select back in when we figure out the right way to do it. I've emailed Somagic asking them for a data sheet, hopefully I hear back.

calamari

[Pedro Martos]

Hi,

Could be possible to get this information from the usbsnoop captures? (selecting a channel and doing the same setup for the four channels and seeing what changes in every log)

regards,

Pedro

2012/2/20 Jeffry Johnston <je...@kidsquid.com>

--
cordiales saludos,

Pedro Ignacio Martos

[Dave Satterfield]

I tried to do a capture using the camera app that came with the
capture dongle, but it's really noisy. Lots of data coming back, and I
don't know what to look for. I have no experience looking at these
logs. Any helpful ideas on how to reduce the data coming back?

On Feb 20, 5:06 pm, Pedro Martos <pimar...@gmail.com> wrote:
> Hi,
>
> Could be possible to get this information from the usbsnoop captures?
> (selecting a channel and doing the same setup for the four channels and
> seeing what changes in every log)
>
> regards,
> Pedro
>

> 2012/2/20 Jeffry Johnston <j...@kidsquid.com>

>
>
>
>
>
>
>
> > Wow, thanks! I hope you can put it back together! That helps a lot. I will
> > go ahead and remove the input select stuff for now, since my theory was
> > completely wrong. Can always put the input select back in when we figure
> > out the right way to do it. I've emailed Somagic asking them for a data
> > sheet, hopefully I hear back.
>
> > calamari
>

> ...
>
> read more »

[Jon Arne]

I assume you meant that you did an usb capture?

I'm not sure what application you used to do this capture, but anyhow.
The captures should contain some info about what kind of usb packet
the computer is sending or receiving.
And any data that is transmitted.

If you look in the Samples folder of the git repo, you can see some
different captures.

When I do a capture with my own device, I can first see a lot of
regular usb messages going back and forth.

They might look like this:

No. Time Source Destination
Protocol Info
1 0.000000 host 79.0
USB GET DESCRIPTOR Request DEVICE

Frame 1: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
Arrival Time: Dec 5, 2011 16:26:16.046401000 CET
Epoch Time: 1323098776.046401000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 64 bytes (512 bits)
Capture Length: 64 bytes (512 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb]
USB URB
URB id: 0xffff88012dbe5480
URB type: URB_SUBMIT ('S')
URB transfer type: URB_CONTROL out (0x02)
Endpoint: 0x80
Device: 79
URB bus id: 2
Device setup request: relevant (0)
Data: not present ('<')
URB sec: 1323098776
URB usec: 46401
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 40
Data length [bytes]: 0
[Response in: 2]
[bInterfaceClass: VENDOR_SPECIFIC (0xff)]
URB setup
bmRequestType: 0x80
1... .... = Direction: Device-to-host
.00. .... = Type: Standard (0x00)
...0 0000 = Recipient: Device (0x00)
bRequest: GET DESCRIPTOR (6)
Descriptor Index: 0x00
bDescriptorType: DEVICE (1)
Language Id: no language specified (0x0000)
wLength: 40

0000 80 54 be 2d 01 88 ff ff 53 02 80 4f 02 00 00
3c .T.-....S..O...<
0010 98 e2 dc 4e 00 00 00 00 41 b5 00 00 8d ff ff
ff ...N....A.......
0020 28 00 00 00 00 00 00 00 80 06 00 01 00 00 28 00 (.............
(.
0030 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00
00 ................

No. Time Source Destination
Protocol Info
2 0.000141 79.0 host
USB GET DESCRIPTOR Response DEVICE

Frame 2: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
Arrival Time: Dec 5, 2011 16:26:16.046542000 CET
Epoch Time: 1323098776.046542000 seconds
[Time delta from previous captured frame: 0.000141000 seconds]
[Time delta from previous displayed frame: 0.000141000 seconds]
[Time since reference or first frame: 0.000141000 seconds]
Frame Number: 2
Frame Length: 82 bytes (656 bits)
Capture Length: 82 bytes (656 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb]
USB URB
URB id: 0xffff88012dbe5480
URB type: URB_COMPLETE ('C')
URB transfer type: URB_CONTROL out (0x02)
Endpoint: 0x80
Device: 79
URB bus id: 2
Device setup request: not relevant ('-')
Data: present (0)
URB sec: 1323098776
URB usec: 46542
URB status: Success (0)
URB length [bytes]: 18
Data length [bytes]: 18
[Request in: 1]
[Time from request: 0.000141000 seconds]
[bInterfaceClass: VENDOR_SPECIFIC (0xff)]
DEVICE DESCRIPTOR
bLength: 18
bDescriptorType: DEVICE (1)
bcdUSB: 0x0200
bDeviceClass: 0
bDeviceSubClass: 0
bDeviceProtocol: 0
bMaxPacketSize0: 64
idVendor: 0x1c88
idProduct: 0x0007
bcdDevice: 0x0100
iManufacturer: 1
iProduct: 2
iSerialNumber: 3
bNumConfigurations: 1

0000 80 54 be 2d 01 88 ff ff 43 02 80 4f 02 00 2d
00 .T.-....C..O..-.
0010 98 e2 dc 4e 00 00 00 00 ce b5 00 00 00 00 00
00 ...N............
0020 12 00 00 00 12 00 00 00 00 00 00 00 00 00 00
00 ................
0030 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00
00 ................
0040 12 01 00 02 00 00 00 40 88 1c 07 00 00 01 01
02 .......@........
0050 03 01 ..

This is the Host (computer) requesting some standard info from the
device,
and the device's reply.

This is a request of type: "GET DESCRIPTOR", and usualy not of any
interest to us.

The thing we are looking for is packages that look like this:

No. Time Source Destination
Protocol Info
159 75.948778 host 79.0
USB URB_CONTROL out

Frame 159: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
Arrival Time: Dec 5, 2011 16:27:31.995179000 CET
Epoch Time: 1323098851.995179000 seconds
[Time delta from previous captured frame: 0.008893000 seconds]
[Time delta from previous displayed frame: 0.008893000 seconds]
[Time since reference or first frame: 75.948778000 seconds]
Frame Number: 159
Frame Length: 64 bytes (512 bits)
Capture Length: 64 bytes (512 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb]
USB URB
URB id: 0xffff88012eeee680
URB type: URB_SUBMIT ('S')
URB transfer type: URB_CONTROL out (0x02)
Endpoint: 0x80
Device: 79
URB bus id: 2
Device setup request: relevant (0)
Data: not present ('<')
URB sec: 1323098851
URB usec: 995179
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 2
Data length [bytes]: 0
[Response in: 160]
[bInterfaceClass: VENDOR_SPECIFIC (0xff)]
URB setup
bmRequestType: 0xc0
1... .... = Direction: Device-to-host
.10. .... = Type: Vendor (0x02)
...0 0000 = Recipient: Device (0x00)
bRequest: 1
wValue: 0x0001
wIndex: 0
wLength: 2

0000 80 e6 ee 2e 01 88 ff ff 53 02 80 4f 02 00 00
3c ........S..O...<
0010 e3 e2 dc 4e 00 00 00 00 6b 2f 0f 00 8d ff ff
ff ...N....k/......
0020 02 00 00 00 00 00 00 00 c0 01 01 00 00 00 02
00 ................
0030 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00
00 ................

No. Time Source Destination
Protocol Info
160 75.948893 79.0 host
USB URB_CONTROL out

Frame 160: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Arrival Time: Dec 5, 2011 16:27:31.995294000 CET
Epoch Time: 1323098851.995294000 seconds
[Time delta from previous captured frame: 0.000115000 seconds]
[Time delta from previous displayed frame: 0.000115000 seconds]
[Time since reference or first frame: 75.948893000 seconds]
Frame Number: 160
Frame Length: 66 bytes (528 bits)
Capture Length: 66 bytes (528 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb]
USB URB
URB id: 0xffff88012eeee680
URB type: URB_COMPLETE ('C')
URB transfer type: URB_CONTROL out (0x02)
Endpoint: 0x80
Device: 79
URB bus id: 2
Device setup request: not relevant ('-')
Data: present (0)
URB sec: 1323098851
URB usec: 995294
URB status: Success (0)
URB length [bytes]: 2
Data length [bytes]: 2
[Request in: 159]
[Time from request: 0.000115000 seconds]
[bInterfaceClass: VENDOR_SPECIFIC (0xff)]
CONTROL response data

0000 80 e6 ee 2e 01 88 ff ff 43 02 80 4f 02 00 2d
00 ........C..O..-.
0010 e3 e2 dc 4e 00 00 00 00 de 2f 0f 00 00 00 00
00 ...N...../......
0020 02 00 00 00 02 00 00 00 00 00 00 00 00 00 00
00 ................
0030 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00
00 ................
0040 01 07 ..

Here we have a request of type "URB_CONTROL".
This is not a standard usb request.

If your capture program don't give you this info, you can also have a
look at the field called "URB setup".
On my capture it looks like this:

URB setup
bmRequestType: 0xc0
1... .... = Direction: Device-to-host
.10. .... = Type: Vendor (0x02)
...0 0000 = Recipient: Device (0x00)
bRequest: 1
wValue: 0x0001
wIndex: 0
wLength: 2

The important part here is "bmRequestType - Type" this is set to
"Vendor",
this says that this is not an standard USB message, and is probably
important to the device.

Now, the rest of the package is device specific, and this is what we
are looking for.
On my device, the "bRequest" is always set to "1", and the index is
always "0".
The "wValue" field changes based on what we are sending.
"wLength" is the size of data in this request or the expected length
of the data we want to receive from the device.

The byte list in the end is all the raw bytes sent over usb.
The first 64 Bytes, are all part of the standard usb header, so this
is mostly unimportant.
Any bytes beyond these 64 for are important data from the device.

In the message above, you can see that we received "0x01 0x07" as raw
data from the device.

Now, after looking trough your log, you should see that the Host is
sending lots of "URB_CONTROL" messages to the device.
The data-part of these messages should look something like this (13
Bytes):

0b 00 00 82 01 00 35 00 80 14 1b 89 00

Or, they can look like this (notice 0x4a instead of 0x00 in the second
position):

0b 4a c0 01 01 0e 81 ba 02 01 00 00 10

Now, the last message here, is setup information for the SAA7113 chip
in the device.
This message, sets register "0x0e" to "0x81".

Now, after sending lots and lots of this kind of data, eventually you
will see ISOCHRONOUS messages passed between the device and the host.
On my device, they look something like this:

o. Time Source Destination
Protocol Info
622 822.620104 host 78.2
USB URB_ISOCHRONOUS out

Frame 622: 224 bytes on wire (1792 bits), 224 bytes captured (1792
bits)
Arrival Time: Dec 5, 2011 08:55:20.206583000 CET
Epoch Time: 1323071720.206583000 seconds
[Time delta from previous captured frame: 0.000013000 seconds]
[Time delta from previous displayed frame: 0.000013000 seconds]
[Time since reference or first frame: 822.620104000 seconds]
Frame Number: 622
Frame Length: 224 bytes (1792 bits)
Capture Length: 224 bytes (1792 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb]
USB URB
URB id: 0xffff8801093eec00
URB type: URB_SUBMIT ('S')
URB transfer type: URB_ISOCHRONOUS out (0x00)
Endpoint: 0x82
Device: 78
URB bus id: 2
Device setup request: not relevant ('-')
Data: not present ('<')
URB sec: 1323071720
URB usec: 206583
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 30720
Data length [bytes]: 160

0000 00 ec 3e 09 01 88 ff ff 53 00 82 4e 02 00 2d 3c ..>.....S..N..-
<
0010 e8 78 dc 4e 00 00 00 00 f7 26 03 00 8d ff ff
ff .x.N.....&......
0020 00 78 00 00 a0 00 00 00 00 00 00 00 0a 00 00
00 .x..............
0030 01 00 00 00 00 00 00 00 02 02 00 00 0a 00 00
00 ................
0040 ee ff ff ff 00 00 00 00 00 0c 00 00 00 00 00
00 ................
0050 ee ff ff ff 00 0c 00 00 00 0c 00 00 00 00 00
00 ................
0060 ee ff ff ff 00 18 00 00 00 0c 00 00 00 00 00
00 ................
0070 ee ff ff ff 00 24 00 00 00 0c 00 00 00 00 00 00 .....
$..........
0080 ee ff ff ff 00 30 00 00 00 0c 00 00 00 00 00 00 .....
0..........
0090 ee ff ff ff 00 3c 00 00 00 0c 00 00 00 00 00
00 .....<..........
00a0 ee ff ff ff 00 48 00 00 00 0c 00 00 00 00 00
00 .....H..........
00b0 ee ff ff ff 00 54 00 00 00 0c 00 00 00 00 00
00 .....T..........
00c0 ee ff ff ff 00 60 00 00 00 0c 00 00 00 00 00
00 .....`..........
00d0 ee ff ff ff 00 6c 00 00 00 0c 00 00 00 00 00
00 .....l..........

The data-part of these messages look very different, and should
contain raw video.
The devices we have seen, all seem to split this data into packages of
1024 bytes, that have a header like "00 00 aa aa",
so you can look at your logs, and see if you find this pattern. But I
don't think this is necessary.

If you take a couple of packages of 1024 Bytes and remove the 4 header
bytes.
Then concatenate the remaining bytes, you have the bytes that is sent
from the SAA7113 chip.
This is raw video data, split into packages of 1448 Bytes like this:

[FF 00 00 XX] [1440 Bytes of RAW UYVY Video Data] [FF 00 00 XX]

This is 4 Bytes header, then 1440 Bytes of data, then 4 Bytes footer.
The header and footer bytes are called "Time Reference Code" (TRC) in
the Datasheet.
The last byte of the header/footer is a marker, called Start of Active
Video (SAV) or End of Active Video (EAV).

I hope this answers some of your questions :)

--Jonarne

> ...
>
> read more »

[Jon Arne]

I just added an UsbSnoop capture of the Model002 doing a video-capture
and toggle between inputs.
I received this capture from Aleksey Kudakov.

I have not inspected the capture very closely, just checked that it
actually contained video data.
I'll probably try to clean it up a bit in the near future.

I must apologize for the size of the commit,
I didn't realize that the capture was 134mb until after I pushed it.

The capture is located in Samples/Model002/

--
Jonarne

> Now, after sending lots and lots of this kind of data, ...
>
> read more »

[Jon Arne]

Hi,
Did some bit toggling on in somagic-capture.c, to find out more about
the 0x34/0x35 registers.
I'm now assuming that these register don't do anything in the DC60
version, but that it's used in Model002.

I had a look at the Model002 capture, and i see some references to
0x33, which I assume the PINC register.
You use that register to read input on the different pins.

On my DC60, i tried to set all pins HIGH or LOW, and as INPUTS or
OUTPUTS, but could not register any changes anywhere!

But we need some more research into this!

> ...
>
> read more »