Posted on

DWM-W034 UART

In response to my previous post about UART access on the Alfa AWUS036NHA, I got a nice email from Jim Ewing about the DWM-W034, an ath9k_htc device that apparently is embedded inside HDTVs and readily available for $10. He found the TX/RX pins on the board, and it looks like it would be a bit easier to put a socket on one of these compared to the Alfa since there are no pesky chips nearby.

With his permission, and so that this information doesn’t get lost to the sands of time, here’s the pic he sent me. Enjoy!

Posted on

Reserialized

I got a shiny new device today and the first thing I did was crack it open and heat it to 680 degrees. A good feeling.

The device in question is an ath9k_htc USB wifi dongle. A colleague suggested this one has an easy to access UART because they brought out the TX/RX pins out from the SoC to dedicated pads. He and I apparently have different definitions for “easy.” Unlike the TP-Link routers which give you through-holes to work with, these are simply SMT pads, and they are tiny in comparison. My soldering iron tip is at least double the size of the pad. Yes, it is somewhat better than trying to solder directly to the pins on the SoC, but not by a whole lot.

As it happens, this is my first attempt at soldering SMT. What could go wrong?

Because the pads are small I used some wire-wrap wire (30 gauge? All I know is that it’s at least two stops smaller than the smallest hole on my wire stripper: getting insulation off was “fun”). During my comedic attempts at getting the wires stuck in the right places, I managed to completely obliterate one of the two pads. Luckily, the one I screwed up was the RX pin, which I don’t really need or care about. Having got the TX and ground wires (badly) soldered in place, I made a some circumspect passes with the magnifying glass and continuity tester to convince myself there were no shorts.

Even so, I am as surprised as you are that it actually worked when I turned it on the first time. And the wifi still works too.

==>[cUSB_REQ_COMP]: 0x%08x
VendorCmd: DownloadComplete!
5. usb only!!
 A_WDT_INIT()
 ==>warm start<==
ALLOCRAM start 0x50d80c size 106484
Enable Tx Stream mode: 0x367
USB mode: 0xf
[+++Magpie_init]
[+++VBUF_init(100)]
[+++VBUF_init(100)]
: Attaching the driver
: Vendor id 0x168c Dev id 0x24
ath_pci_probe 24
 ath_hal = 0x00510928 

        =>[dnQ] 0x0050f288 
[       =>[upQ] 0x0050f264 
[       =>[hp dnQ] 0x0050f240 
[       =>[mp dnQ] 0x0050f21c 
[Tgt running]
Posted on

serialized

router += serialMy ath10k-based router now has serial headers, after I managed to crash it a few times over the weekend while testing out some patches. Thank you, TP-Link, for making the pins so easily accessible, to the extent that it’s easier to whip out the soldering iron than remind oneself how to setup kexec/kdump.

I do need to get one of these nifty usb-serial cables so that the JTAG ribbon cable + FTDI-breakout-on-a-breadboard monstrosity can go back into the
parts bin, but it is working fine otherwise. [The pictured 7-segment display and TTL chips are just misdirection, by the way.]

There was a momentary bit of confusion on my part when the console showed the router stuck in a loop requesting recovery firmware over TFTP instead of the normal boot process…until I realized that the reset button was wedged in the depressed state by the case. Whoops.

Posted on

Spectrum

The ath9k and later chips support a spectral scan feature for measuring channel occupancy. I played with it for the first time last week over the Thanksgiving holiday. Simon Wunderlich’s FFT_eval is a great tool to look at the captured RF spectrum, but I found myself wanting something more real-time, and the various other things I found on github with that aim didn’t work for me. So, this too-ugly-to-live python hack happened.

It turns out that the samples are rather coarse and infrequent, so the result is not as dynamic as I’d hoped. However, I made the pretty heatmap below with a few hours’ worth of samples, and although I didn’t yet label frequencies, you can see a couple of channels in active use. There’s still plenty of room for improvement in the visualization.

Posted on

wmediumd speed test

Thanks to some inquries on linux-wireless, I took a look at wmediumd recently. The code could use a bit of work, and there are some features I’ve been meaning to add since forever, so I started gutting it with an eye towards sprucing up the architecture and feature set (changes can be found here).

One of the questions from the mailing list was whether wmediumd adds a lot of overhead compared to mac80211_hwsim. It is of course doing more work, with additional memory copies, context switches, etc — but is it enough to make wmediumd unworkable?

So I did a quick TCP iperf test on my laptop with an open mesh, and get the following numbers.

hwsim without wmediumd:

    [  3]  0.0-10.0 sec  1.36 GBytes  1.16 Gbits/sec

hwsim with wmediumd:

    [  3]  0.0-10.0 sec  1.27 GBytes  1.09 Gbits/sec

It looks like wmediumd is doing fine. This is with monitors running, the non-monitor case does about twice that. Actually, I think this is a bit lower than it should be, but considering both cases are close, and a good deal faster than your typical wifi connection, it’s probably good enough for some level of bandwidth simulation.