VE9QRP

The TH-D72 USB port is configured as a CDC device, using the CP2102 USB UART bridge. On Windows, presumably you should use the drivers provided by Kenwood. I accessed the port on my Ubunutu 10.04 desktop just by using /dev/tty.USB0, which popped open when I connected the device. CP2102 support evidently is built into recent kernels. Looking around, it seems that MacOS support is more dicey, so I'll probably experiment with it using a linux box or a virtual linux machine on my MacBook. For the person like me, who is hoping to connect this to an embedded device, there's some particularly bad news: this chip doesn't communicate using the plain CDC-ACM; I'm told it has a proprietary communication system to the host. The best bet is to port the software from the linux kernel, alas. 

The new TH-D72 is a dandy radio, with APRS and a built-in GPS engine. But I was a bit dismayed to see that the CAT commands are somewhat different from those for the TH-D7G, since I'd put quite a bit of time into programming for those. Guessing that Kenwood wouldn't rewrite this software for each rig, I took a look at this list of commands for the most recent similar radio, the TM-D710, and sure enough, it seems they work. Phew. In addition, if we want a micro-controller to talk to this thing, then I suppose it will need to have USB host mode on it, since the rig acts as a USB device, of course. The CUI32 apparently provides the hardware for this connection, so we'll see how that works.

Codec2 operates nicely in real-time on a modern-class laptop, but I've been trying to push it into other devices. Real-time encoding and decoding on PIC32s will need to wait for a 16 bit integer version (which can make use of Microchip's DSP library), but how about ARM hardware? I ported the code to a Nokia N800 (400MHz ARM11), and it works nicely, but the decoding is choppy after a while because it just can't spit out audio in real time. Decoding will need about a 2x speed up. I've been able to get pretty close to that by swapping out Dave's Fast Fourier Transform function with a different one licensed under the GPL.

Using a recent version of Ubuntu, we can use netcat to glue together some network transport of Codec2, preliminary to getting it on the airwaves. (Since Linux makes ax.25 <-> TCP/IP doable, we're theoretically half way there if we can get c2 within the network context.)

Here'a a bash script that takes as its first argument a string of quoted text. It then passes this through the festival text-to-sound processor and plays two versions of the result. The first version is unprocessed; the second version has been encoded with codec2 and then decoded. The results are generally impressive. But I hope this might be some help in improving the codec. For instance, the roughening of sibilants like 'sss' in English (which becomes something like a 'sh' under codec2) is easily reproduced with festival. To use this script, change the first line to point to the directory in which your c2enc file resides, save the script as, say, 'tts-codec2.sh' and then issue the command 'chmod a+x tts-codec2.sh' so that the script is executable. Then run it on the command line with 'tts-codec2.sh "Salmon steaks grill beautifully."' You'll hear the non-codec2 version, then the codec2 version. CODEC2_HOME=/home/brucerob/...

Here's a bash script to round-trip a 8000Hz, 16-bit signed raw audio file through codec2. It takes the input file name and output file name as arguments: CODEC2_HOME=/home/brucerob/codec2-2010-11-11/src TFILE="/tmp/$(basename $0).$$.tmp" $CODEC2_HOME/c2enc $1 $TFILE $CODEC2_HOME/c2dec $TFILE $2 Here's a sox command to get a wav file (or whatever) into the proper raw format for codec2: sox input.wav -r 8000 -t raw -s -2 output.raw

David VK5DGR is actively improving Codec2 in a process that he describes on his website . Until I became interested in this process, I hadn't realized how developing a codec is a pretty qualitative and subjective process. Anyway, some recent patches to the alpha code aim to get rid of crackles from the encoding, and I think I can provide evidence that they have done just that. Last weekend I recorded myself describing my QTH, etc. in typical long-winded ham fashion. I then encoded and decoded this raw audio file to see how intelligible it was after being passed through Codec 2. The result was quite impressive . I think the greatest criticism could be the clicks that appear on my name, 'Bruce' and when I draw my breath in early in the QSO. After reading that the recent changes aimed to eliminate those noises, I updated my repository, rebuilt the code, and then round-tripped this same file. Listen to the new file , and you'll hear that it has fewer distracting clicks,...

 Here's a uuencoded, 511 byte message in Codec2. It is a full sentence! begin 644 hello.c2 M&]&*F(K<H"O0CJB;_^`ATN[HOOK@L)#.[YYJX+*RQ.V>:F"YDLS*GFK@`=:L MJ;9;8.UQCJFV2>#M4XJIMLC@XU:,N;++8*56KJN>R^"[]J[.MLK@MI3D[YKN MX!-2K.Z?_6`+4:SJGMS@K=>.[Y;L0"-1K.R^U*`I$>[L_^7@)Q&,[I[%(*,1 MK.R[YL##$83N_^;@1_&,[)KF0`/1C.Z;<F#%4(3NO^)@'9&,[)KCX,.0BNZ> MX^`(].KKFM-@!+"N^8K1($C\C.N*P4`,-8[IOE#@6?&.V8Y'P`_PCLB&5.!H MEH[.AEU@T/*.SX9.X/+RCLV&SF#R](K+ADI@\MR.Z8;*X/+]BJF&RN#TMXB9 MA\M@_I&+^X_I8/_PB_^.Z6#_T(N]NDE@^=:/_;II8.GTC_6Z:V#KO.G]BDE@ MZ9RO_XYK8.N<K?J.RV#MG.N:CTM@Y+Y+F8=*8.K*QYJ+;^#JSN::C^[@YD+' MF8YM8.1"0XFO[>#J0,6ZB^S@`,V[N_)<X++J[?^V3<":E*2)BL[@;["LZ+O? MX(7PC$JJS^"!\*Q.BDW@AY"FROK-X)22XFRWS>"YEL(D_\W@\][B!+?,P`"V MP":W5"`8EL(,F]3@`M3"+X_4X`I\PBZ/5>`F?L(DI5?@/`K")*]6H`P^P"2/ 0UF`8?.(OCM)@&%3";H_2X``` ` end

In the dynamic field of digital ham radio projects,  Codec2  just might be the most exciting one of all. A very low-bandwidth voice-to-digital codec has any number of uses: in fact, it is so important to future digital radio infrastructure that the D-Star architecture ended up using a proprietary codec for this purpose. Of course, D-Star's black-box chips are not most ham's style; we like to tinker; and in some contexts, like SDR radios and satellite communications, it's very difficult to work with locked-in hardware and code. Enter Dav id,   VK5DGR. He is  using h is Ph.D. research to produce a patent-free voice codec for radio amateurs, with loud cheering from Bruce Perens, who has long championed this idea. The code is recently out in alpha  , compressing to 2500 bps. It built quite happily on my Linux box, and the c2enc and c2dec applications will convert from and to 8000 bps, 16 bit signed RAW audio, producing very intelligible results. Since I had...

Because I'd like to move to the SGP4 tracking algorithm for QRPtracker (and failed to port it well to the 8-bit ATMega644) and because there's no substitute for real programming power, I'm playing around with the PIC32 processor, as conveniently provided in the CUI32 experimenter's board. My goal is to milk this for all its SRAM and flash, but keep the power down to the single-digit mA level so that I can use a pair of AA batteries to power it. Here's some power observations to get things going:

My current iteration of the Satpack full doppler tuning device has about 30k of code space still available in the target hardware, a atmega 644p. Some of this will be eaten up with error checking around the tle loading and clock-setting, but there's still a fair bit of open space there. PC-based tuning programs will often tell you if a bird is eclipsed or in the sun, a feature that is even more useful these days as the aging AO-51 is not transponding in eclipse. Similarly, the AMSAT-UK video entitled 'FUNcube part one' states at its end that FUNcube will have a high-power telemetry mode while in sun (roughly when school is in session), and a low-power telemetry + transponder mode when it is in eclipse (roughly when school is out). This scheme fits the FUNcube KISS principle, but won't be ideal for the small but important number of students who live in Arctic regions. So a 'sat in sun' indicator on the LCD is going to be more important than ever, but I wonde...

Recently, I asked the amsat-bb list if its members knew of any obscure CAT controlled radios which I might doppler tune with my satpack project. Sergej, UZ2HZ, kindly pointed out to me the FT-727R . According to the previous link, "All serial data consists of single byte binary codes sent at 4800 baud, TTL levels, with two INVERTED stop bits and one INVERTED start bit." Yikes. Still, the price might be right for this HT. Another possibility is the Yaesu FT-5100 . It can be controlled at ttl levels with a modified mike interface.

The utility of a portable full doppler tuning device will depend on how easily it can be updated with new Keplerian elements, so I've put some considerable work into the program that does this through a USB/serial connection. Here's a GUI version demonstrated:

The performance of my 435 MHz AA2RX lindenblad has not been quite as good as the simple vertical that it replaced, leading me to take the assembly down and debug it. I don't have an antenna analyzer, so I relied on a good ole' 70cm SWR and power meter with a two-carbon-resistor 5w dummy load.

The pcbs shown in the previous posting have mated very nicely with the Arduino Mini Pro. The first photo shows the side with the Arduino.

PCBs for the satpack project arrived from BatchPCB.com about three weeks ago. These are designed to mate with the appropriate pins on a Arduino Mini Pro , and to provide that Arduino with access to the realtime clock, piezoelectric speaker, buttons and  mini-din 8 connector required to control a recent Yaesu radio. To the right is one side of the design, the critical side that mates onto the Arduino. The boards are made from this design , but it ought not to be used, due to the errors described below.

Several of the next applications of the qrpTracker codebase will require me to draw rudimentary maps on an LCD screen . I've been using Google Earth's polygon tool to make polygons that roughly correspond to, say, Prince Edward Island (in the small scale) and North and South America (in the large scale). Google Earth will allow you to copy the corresponding kml fragment. The following code snippet will turn that kml polygon into a C array of two point arrays, suitable for storing in your Arduino as Progmem.

The AA2TX parasitic lindenblad, which was published in Feb 2010 QST (and has been available online for some time), is proving to be an enjoyable project. I have modified some components because I could not find them here in Atlantic Canada. The #8 aluminum wire for the passive elements is not in our big box stores (different wiring regulations?), and the PVC ferrules require a special order, at least at this point in the year, when no sane person would be installing eavestroughing. So I made do with what I had, and the results are encouraging.

In my last post on the subject, I'd concluded The result is that for non-inverting transponders, the equation is this: `up_o = (dl_o - bc_d + bc_u)/(1-v_r/c)` For inverting transponders: `up_o = (bc_d + bc_u - dl_o) / (1 - v_r/c)` Soon after, I received a kind email from Tony AA2TX, with an offprint of his 1997 Space Symposium paper that describes the object-oriented computational approach  that is built into the InstantTune code.[1] Since I've been happily pillaging  the IT code for some time now, I'd noticed what this article confirms, namely that instead of using `(up_x) / (1- v_r/c)` to get the value of the origin signal from the received signal, InstantTune uses  `(up_x) (1+ v_r/c)`.

In a recent posting to amsat-bb, I asked if anyone knew of a way to grab the loudest-frequency and s/n data from an audio stream, thus saving for further analysis the data that Spectran shows in realtime over its waterfall. It seems this isn't an easy question to answer, so I did some more digging and came up with the following candidates.

As previous posts show, my sattrack code is working fine with uplinks and downlinks that do not have any interdependence, such as beacons and FM satellites. For linear transponders, I used a simplistic approach that was not giving good results, so I hit the books over the weekend to derive formulas that will determine the source uplink frequency (at the radio) for a given downlink frequency. In the following, I'm using the definitions of Davidoff, chapter 8.

10 minutes ago, my qrpTracker project passed its acid test, a real satellite QSO. Hearing rather good sigs from SO-50,  I decided to reply to KC4KMY's call. My side was hampered with using a 1/4 wave vertical as an antenna, causing his sig. to be heard only about 1/3 of the time, but it was good enough for the log. This means that the following automated functions of the latest 'satpack' code are working well: Downlink tuning Periodic uplink tuning of the FT-817, with switching VFOs. This is in the manner of instantune, HRD and SatPC32 CTCSS tone encoding to ensure access to SO-50 and similarly equipped radios CTCSS was only completed this weekend, so I'm delighted that the whole package is in place.

Lots of progress with 'satpack', my Arduino-based full-doppler-tuning satellite tracking application. On the right, you see a cardboard mockup of the pcb. On the software side, I've checked a fully working version of the code into the SVN repository.