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.

Tuesday, November 24, 2015

Introduction to Crossband Repeaters

One of the simplest types of duplex repeaters is the crossband or XBand repeater. This video discuses why crossband repeaters are so much cheaper than conventional repeaters, and lists many of the possible applications for XBand repeaters.

Video:

Wednesday, November 4, 2015

What Circulators Do In Repeaters

Here's the fourth video in my lecture series on FM voice repeaters. I've recently gotten a contract to design and build a cross-band repeater using a RICK and a pair of Kenwood radios, so this lecture series will possibly keep going. Enjoy.

Video:


Saturday, October 31, 2015

What Duplexers Do In Repeaters

Here's the third video in my lecture series on FM voice repeaters. Enjoy.

Video:


One of my good friends, Marcel, recently gave a talk at Pacificon on how to tune duplexers. Apologies on the poor audio quality; the acoustics in the room were terrible.

Video:


Wednesday, October 28, 2015

Whitepaper on Soldering Aluminum

I was recently cleaning out some of my old papers, and found a whitepaper written by my grandfather on soldering aluminum. Link here.

Walter worked as a metallurgist for Kaiser Aluminum in their bonding department developing joining processes with aluminum.  One of his most visible accomplishments can be easily seen if you live in the SF bay area; he developed the welding process for the steel/aluminum third rail on the BART system.

Monday, October 5, 2015

Lectures on Radio Repeaters

After having someone at a BBQ ask me to explain what a repeater is for about the 30th time in my life, I decided that I may as well record my standard 10 minute talk on what a repeater does.

Introduction to Radio Repeaters:


Of course, once I've got the camera turned on, why not record another 20 minutes on the internals of a repeater?

Internals of a Repeater:


I suspect there are a few more videos in this series, which I'm currently working on and will record time-permitting.

Monday, February 2, 2015

Designing and Building a 2m Low Pass Filter

 I've been playing with the DRA818V modules that have been making quite a stir in the amateur radio world at the moment. I haven't gotten one on a spectrum analyzer yet, but I have reason to believe that it will require a low pass filter to be RF legal. I'll write more about that once I get a look at it, but figured I'd first built myself a low pass filter in case I need it (if not for these modules, but some other VHF project in the future).

My process for building a low pass filter went as follows:

  • Select the type of filter and cutoff frequency desired
  • Look up normalized coefficients in the ARRL Handbook
  • Divide these coefficients by the cutoff frequency
  • Convert the inductances into turns on some core and capacitors into the nearest values
  • Build the filter.
Since I wanted this filter for 2m, the highest frequency I'm interested in passing is 148MHz, so I selected a cutoff frequency of 150MHz. In hind-sight, this was a poor choice, since a -3dB point only 2MHz above the band caused for a lousy insertion loss. A better choice would have been 10% higher than the top of the band, so 148MHz * 1.10 = 162MHz

I decided to build a 5 pole T configuration Chebyshev filter with 0.1dB of ripple.

Looking this filter up in a random copy of the ARRL Handbook (1981, but any recent one will do), it gives the component values needed for a 50 ohm filter at 1MHz. I'm also building this for 50 ohms, so all I need to convert is the frequency by dividing by 162MHz.

  • L1 = 9.126uH / 162 = 56nH -- 3 turns on 1/4" air core
  • L2 = 15.72uH / 162 = 97nH -- 5 turns on 1/4" air core
  • L3 = 9.126uH / 162 = 56nH -- 3 turns on 1/4" air core
  • C1 = 4364.7pF / 162 = 27pF -- 30pF on hand
  • C2 = 4364.7pF / 162 = 27pF -- 30pF on hand
To convert the inductance values into solenoid designs, I have an old magazine article from the 70s that published a whole table of different diameters of air wound inductors.
For extra blog cred, I built the filter in an Altoids tin with SMA connectors on each side. The four solder pads were formed from a strip of copper clad with three hacksaw cuts.
Next step was hooking this up to a vector network analyzer to see how far off I ended up, which is when I realized that 150MHz was a poor corner frequency choice. Reforming the inductors and taking a turn out of L2 got me closer, but I would have ended up with better performance if I had designed it all correctly from the start.


 The SWR at 2m is about where it's expected to land at 1.3
 The insertion loss at 2m isn't so great at 0.8dB. This would be improved by better component layout, but I built this filter kind of sloppy. It does suppress all the harmonics of 2m as expected. I only bothered to note that 200MHz was down ~23dB, so 440MHz will be well below that.
In an ideal world, points 1 and 2 on the smith chart would fall at the center (1,0), but 45+19j ohms is close enough for me.

Now once I get to the point of experimenting with keying up my DRA818V modules, I'll have a nice LPF on hand in case the harmonics do end up too high for on the air testing.

Sunday, January 11, 2015

ARKnet - Cupertino Emergency WiFi Network

So now that I'm graduated and looking for work full time (hey, you hiring in the Silicon Valley?), I've been spending my free time volunteering with the city of Cupertino as the technical lead building out a test network for a project we're calling the ARKnet.

In the name of emergency preparedness, Cupertino maintains a number of shipping containers throughout the city filled with emergency response equipment and supplies. Traditionally, if a disaster happens to be large enough to knock out communications, when citizens respond to activate these ARKs, these teams include Cupertino ARES members who tender communications back to the city Emergency Operations Center (EOC). In addition to voice communications, we also provide 1200 baud packet for long textual messages via the Santa Clara County's amazing AX.25 BBS system (Callsigns W1XSC-W6XSC). 1200 baud is a very useful data rate when compared to zero in the case of an emergency, but we decided that the time is ripe to start running some serious experiments moving data on the 5.8GHz band instead of on 144MHz.
For this pilot, the city gave us funding for a minimalist network linking the city EOC to a single ARK. To accomplish this, we got permission from one of the few tall buildings in the city to erect a 90 degree beam width access point. This sector antenna is pointed towards the EOC and one of the ARKs, both of which have high-gain uplink radios connected to it. The EOC contains an applications server and an edge router to provide Internet access to the entire network.

Since emergency communications is a major part of the charter for ARKnet, we're only considering uses for the network where the entire application can be entirely self-contained within the network. There's no interacting with the cloud when the Internet is down, so all our applications need to be running on a local server with emergency power. This network will be "Cloud-Free!™"
For the point-to-point links, we're using Mikrotik SXT 802.11ac routers (which come in both 90 degree beam width and 28 degree beam width variants). Mikrotik is unusual in that their products combine both good long-haul WiFi and commercial grade routing features in a single package. We looked at using Ubiquiti for the long-haul links (which I've used before), but being able to have the links also speak OSPF to make the network self-healing is attractive.
Our test ARK isn't profoundly far away from our sector AP (about 1.25 miles), but we do need to punch through a large cluster of trees, so the link isn't great. After a few weeks of lab testing, this weekend was the big rollout where we brought up all the gear and testing the throughput from the ARK to the EOC, which ended up being about 10Mbps.

This kind of bandwidth is certainly usable for any of the applications we've come up with so far, and the next big step for ARKnet is that we need to start developing viable applications to run on this network which will be useful in the case of a disaster.
Of course, I haven't been doing this alone. Thanks to all my fellow CARES volunteers who have helped make this first test-link possible!