Wednesday, December 30, 2015

Bringing Up a TW6805 Capture Card in Linux


Here are some basic notes on getting a Intersil Techwell Inc TW6805 capture card running in Linux (kind of). I originally pulled this card out of an e-waste bin with no information on it. The first thing I did was plug it into a computer and run "lspci" to hopefully get a part number out of it. It came back as two devices, a TW6804 and a TW6805:

02:09.0 Multimedia video controller: Intersil Techwell Device 6804 (rev 10)
02:09.1 Multimedia controller: Intersil Techwell Device 6805 (rev 10)

Lots of digging yielded some mentions of a Gitorious git repo for an unloved TW68 kernel module for these TW68XX devices, but Gitorious is currently offline. Some more digging found a github mirror of the TW68 module, with a mention that the TW68 module was merged into the mainline kernel in version 3.18. Sweet! I don't have to deal with out of tree kernel modules.

Of course, I was trying to get this capture card running under Ubuntu 14.04, which is still using v3.13. Upgrading my system to Ubuntu 15.10 (which runs kernel 4.2) and running "modprobe tw68" finally yielded the /dev/video0 device I was hoping for.

I then followed the first half of this tutorial, which pretty much boiled down to running "v4l2-ctl --device=/dev/video0 --list-inputs", which yielded: 

ioctl: VIDIOC_ENUMINPUT
Input       : 0
Name        : Composite 0
Type        : 0x00000002
Audioset    : 0x00000000
Tuner       : 0x00000000
Standard    : 0x0000000000FFBDFF (PAL-B/B1/G/H/I/D/D1/K/M/Nc/60 NTSC-M/M-JP/M-KR SECAM-B/D/G/H/K/K1/L/Lc)
Status      : 0x00000100 (no hsync lock.)
Capabilities: 0x00000004 (SDTV standards)

Input       : 1
Name        : Composite 1
Type        : 0x00000002
Audioset    : 0x00000000
Tuner       : 0x00000000
Standard    : 0x0000000000FFBDFF (PAL-B/B1/G/H/I/D/D1/K/M/Nc/60 NTSC-M/M-JP/M-KR SECAM-B/D/G/H/K/K1/L/Lc)
Status      : 0x00000000 (ok)
Capabilities: 0x00000004 (SDTV standards)

Input       : 2
Name        : Composite 2
Type        : 0x00000002
Audioset    : 0x00000000
Tuner       : 0x00000000
Standard    : 0x0000000000FFBDFF (PAL-B/B1/G/H/I/D/D1/K/M/Nc/60 NTSC-M/M-JP/M-KR SECAM-B/D/G/H/K/K1/L/Lc)
Status      : 0x00000000 (ok)
Capabilities: 0x00000004 (SDTV standards)

Input       : 3
Name        : Composite 3
Type        : 0x00000002
Audioset    : 0x00000000
Tuner       : 0x00000000
Standard    : 0x0000000000FFBDFF (PAL-B/B1/G/H/I/D/D1/K/M/Nc/60 NTSC-M/M-JP/M-KR SECAM-B/D/G/H/K/K1/L/Lc)
Status      : 0x00000000 (ok)

Capabilities: 0x00000004 (SDTV standards)



Not entirely encouraging that it's listing the status of channels 1-3 as "ok" since I don't have video signals fed into channels 1-3 when I took this, but it at least identified this as a four channel card. I have little understanding of what this all means, but it seems to be dumping a couple status registers and decoding them, and the decoded parameters mention NTSC, so that's good, I guess.

Finally, running "mpv --tv-device=/dev/video0 tv:///CHANNELNUMBER" and tried 0, 1, 2, and 3 for CHANNELNUMBER yielding a relatively screwed up signal.

I don't know if this is still a driver/software issue, or if I need to feed it some option that isn't default to render my test signal correctly, or if the capture card I pulled out of an e-waste bin is borked. In any case, it's almost midnight, so I'm writing this all down for my own future reference and going to bed.

Monday, December 7, 2015

Building a RICK-Based Crossband Repeater

Video:


One thing of note in this video is that I goofed on the "repeater gain". Repeater gain is important so that all the transmissions going into it are the same as what comes out on the other side, but in the video I forgot that my transmitters are encoding PL. The deviation from the PL encoder adds to the deviation from the actual audio tone, so setting the trim pots to target 3kHz deviation out is incorrect.

Both of these radios happen to encode PL with 800Hz deviation, so I should have been targeting 3.8kHz deviation on the service monitor.