Yeasu FT-1D redux

http://blog.radioworld.ca/?p=2941
Found a copy of the brochure on the FT-1D radio at the above website. No real surprises for me. It's fairly thin but really looks a lot like some of their newer handies. VX7R comes to mind.

• data transfer speed of 9.6kbps - I would ask if it's compatible with packet but then I realize it doesn't really matter because there's no really a lot of the 9600baud packet stuff out there and it's surely not.
• 1 button switch between digital and analog modes
• Wide-band RX .5-999Mhz
• micro SD slot seems to provide:
• GPS log - location and tracking
• picture image data
• memory backup/clone
• potentially other uses not listed in the brochure "and other useful information is stored on the micro SD card"
• USB connector - this surprised me a bit. It seems the optional microphone plugs in here.
• There's reference to a firmware update function available by plugging the PC into there.
• I wonder if it's a USB2GO type of device. If the optional microphone plugs in there then I'd bet that it is actually using USB protocols to communicate.
• optional microphone - I really saw this one coming.
• NOT included
• 320x240 or 160x120 modes
• Image can not be viewed on FT1D, LCD limitation of course
• Image is time and date stamped, has geotag from GPS
• 20 seconds TX for 320x240, 4s TX 160x120
• Jpeg format
• I wonder how much this mediocre accessory will add to the cost of the radio?
• Digital ARTS
• Auto-Range Transponding System
• A technology that lets you know when you move out of range of a sister station. I'm guessing it has a watchdog timer and sends a ping out every so often. If you get a ping, the watchdog is reset. If the watchdog runs out, you're alerted. Just a guess.
• Does anyone use this? I have a FT-50R with the older ARTS and I've never once used it.
• GPS
• "E-GPS" a way to transmit GPS data to other users. Sounds like a proprietary version of APRS to me. There's a distinct lack of reference to APRS in this document.
• GSM - Group Short Message
• Texting for Ham Radio. But it looks like it has two major limitations: Your message goes to everyone in the vicinity/group and it's 80 characters. SMS is 160.
• At least you can request a receipt response.
• Maybe, maybe you can limit who is notified of a message. I know due to the nature of Ham Radio there's no expectation of privacy so you can't block other people from reading messages, but they could at least let you choose who is notified of a new message.

The last piece of the puzzle that I'm still waiting to learn is price. As of May 20 2012, universal-radio has yet to publish anything about MSRP: http://www.universal-radio.com/catalog/ht/0111.html
I would note, one of their bullet points is APRS but I think that was an assumption on their part, there's no reference to it in the brochure.

Yaesu FT1D

I caught the gibgab about this today. Looking forward to more details coming out of the Hamvention. (I'm probably not going, water heater going out on me)

radioreference.com seems to have the most information about it currently:
http://forums.radioreference.com/amateur-radio-equipment/238995-yaesu-ft1d-c4fm-digital.html

FT1D
Price undecided
Silver color
144/430MHz5W
The end of March or in the shortest
■ Compatible with dual communication mode analog / digital
■ common with the option VX8G
■ APRS function
■ featured wide-band receiver
■ Built-in AM bar antenna capable of receiving AM / FM
■ listening quietly vibrator function, valid at large noise!
■ Equipped with GPS logger
Digital-related
■ GSM (group message function)
Send and receive messages in katakana / up to 80 characters in the alphabet
of about 0.15 seconds
■ Snapshot Snapshot (image data transfer)
In the display screen of the machine about 20 seconds Handy time display
can not be sent in digital mode] [FDMA. Set (320 × 240) QVGA size
■ Convenient, etc. / clone image data storage backup / the contents of
memory equipped with a micro SD card slot
■ Connecting the camera microphone (terminal MiniUSB) USB data, the
connection between an external device such as a PC. Useful, for example, a
firmware update.
■ Easy! E20 support (Itsuo / Easy to Operation)
Redesigned the system operation as easy to use, multi-functional. Enables
one-touch operation of frequently used functions
• The one-touch button digital mode in the D
Wires X corresponding key button key, but also what features a digital
future
· GM GSM (group message) key
■ E-GPS (GPS data transmission feature easy)
GPS data can be exchanged easily with fellow ham. One-touch display at the
same time as the direction and distance of transmission.

Some of the later text is badly translated and I don't know what it's getting at but it's talking about the price. There's also this leaked ad in Japanese:

It almost seems like someone has been listening when I've been ranting about amateur radio being at least 20 years behind cellphones. My thoughts from this information:

• 1200/9600bps - D-star handhelds (and mobiles outside of ID-1) top out at 4800baud, but even then you can only use 791byte/s, I like
• SD card - though I don't know the purpose yet. I see GPS in the same block so it may only be to save your GPS tracks. I would hope that it would serve other purposes as well.
• GSM texting - If I'm reading the text from the forum post right. This is a big one that Ham Radio could've been doing since the early 90's with APRS but never got right. Even D-Star didn't get this right and it handles data all the time!
• GPS built in - Look, if I can buy tiny usb dongles for $20 or less with GPS there's no imaginable reason why this feature should be rare OR expensive besides stealing money from your customers.
• USB - I'm hoping for a lot here. It may only be so you can read the SD card on the computer. But there's a lot that can be done here. Data link to the radio for digital-modes, memory read/write, radio control, GPS, SD card, etc. Maybe audio modes would be too much to ask but I will anyways. Then they can make it charge the radio too.
• Camera Mic - I am not hot on this. One of the things cellphones do that Ham Radio is sadly behind on is pictures. Sure, we had SSTV years before cellphones were invented. No one has ever put it in a handheld radio. And they still haven't. It's in a mic that is probably optional, and expensive. I see no way that you will be able to view the pictures on that display which rules out two way pictures. Even an old Nokia color display might've fit the bill here. I'm not going to complain about the resolution, anything is better than nothing I guess. 320x240 even.
• Eh, it probably uses an AMBE codec from DVSI to compress the audio which is pretty much encryption. Encryption is encryption, even if the decryption key isn't a password but dollar bills $$$$. I'd give Yaesu a pass on this if it turns out they are going to open this radio up to third party development (which has really blown the smartphone market wide open. Remember when the Iphone was going to be locked down and the only way to run programs on it was going to be via web apps? Yeah, what happened when people hacked it to run native apps on it? Billions of dollars for Apple. Learn a lesson here Yaesu!) If they opened it up then maybe one day Codec2 could run on it and people would be more inclined to buy a radio that isn't under the constant threat of not catching on and dying off.

Yaesu better watch the price on this thing too. I think they will be smart enough to be competitive (cheaper) than D-Star radios at least. They are starting out at a natural disadvantage. In my opinion the best route to go would be to emulate the Chinese radio model as much as possible. Drastically undercut the competition in order to give more reasons to buy your product over theirs.

$500-600 will buy you a brand new, top of the line cellphone running Android, with a large high-resolution color touch-screen, built in GPS, Wifi, Bluetooth, MicroSD card slot, 5 MegaPixel camera,maybe a front facing camera for video conferencing, accelerometer, magnetometer, 6-32GB built in flash, USB charge, USB mass media (Flash and SD card access), USB data, etc

Yes, some of that stuff is possible because of mass production and the ability of manufacturers to make stuff cheaper the more they produce, I'm sure I'll remember the phrase for that after I publish. But we can benefit from that as well by using incredibly cheap components originally produced for cellphones. CPUs, flash, ram, even chips that integrate GPS, WiFi and Bluetooth.

I hope the traditional manufacturers are feeling pressure from the flood of cheap Chinese radios. Decades of little to no innovation should backfire as China moves into the market and undercuts Yaesu, Kenwood, Icom and even Alinco with radios that do the exact same functions for significantly less. Now the big manufacturers will either have to innovate or die. You know they're not feeling any pressure to innovate from most of their customers.

I'm glad to see someone trying to bring out a 21st century Ham Radio, but I'm feeling it's more akin to 1999 technology. To be honest, it's underwhelming. If the price is sweet then I'll consider buying one. I doubt it will be any less than a top of the line 2012 smartphone though. Maybe something will come out at the Hamvention that I can't glean from this information which will blow me away but I'm not expecting much.

TM-241a analyzing

Forgot about the simple logic analyzer mode on the Bus Pirate. Channel 1 is serial out. Channel 2 is clock. Channel 3 is serial in. Channel 0 is RD (Pin 6 on mic connector) This graphic looks a little glitchy. Since this is a digital sample, if you sample at too low of a frequency in relation to what you are sampling then you will end up with strange looking data. This may be at 5khz sample rate. You should have seen it at 1khz. I was playing with 10khz and 20khz sample rates which looked much better but had a shorter sample time. The Bus Pirate only has 4096 bytes of ram to save samples in. It wasn't designed as a logic analyzer, it just happens to be a bonus.

This is in a mode that I am calling RC-10 mode. In this mode the radio will allow you to use any and all of the buttons on the radio itself. It only clocks out data when you operate the controls on the radio or on the remote unit, and then the remote unit acts as the bus master. The radio will only send data out when the clock is running and it is receiving 0xFF on serial in. 1 byte out for each byte in. I'm still not sure how the radio indicates that it has data to send out. I think it may twiddle the serial out line a bit. I am currently unable to emulate even this mode so far. I may have to write some sort of bit bang code in order to get the Bus Pirate to handle UART in/out and also the clock line.

The other mode I am calling RC-20 mode and it's a little more mysterious, to me. If I hold RD high, and keep it high, then send something, anything, down serial in then the radio will start continuously sending display frames out the serial out line. It also clocks the clock line itself. I can't seem to make it see any data that I send after that point. Additionally, in contrast to the other mode of operation, once in this mode the radio completely ignores all operation of the controls on the radio itself. There must be some sort of protocol that I'm missing. Maybe something like pull the serial in line high for 50ms, then clock data in or something. Come to think of it, in this mode there is a one shot chance of changing the frequency. Sometimes it works once and then not again until I reset the radio. I wonder if I sent some 0xFF bytes down the line after that if it would work again. But then again, in the other made that only seems to happen so the radio will send out display packets. It does that anyways in this mode. It bears further experimentation.

Fascinating!

TM-241a Project update 4-7-12

Doh, I feel like such an idiot. Looking over the schematics for the TM241a and RC-20 manuals I see something I dismissed a long time ago. There's Serial In and Serial Out pins, but there's also a Serial CLK pin. Well, I was receiving data just fine without the clock, but apparently I've been spinning my wheels this whole time sending data to the transceiver. You have to clock the clock pin when sending data TO it. Unfortunately the Bus Pirate is apparently completely unable to clock it's clock pin in UART mode. Only in other modes like SPI and I2C. That sucks since I already have these nice probe cables for it and everything. I don't know if any generic FTDI type usb-serial chip does it. I think that's a pretty much dead part of the standard these days. I'd love to be proven wrong though.

Not even the latest v6.1 Bus Pirate firmware has support for this. You can see some commands in the help menu to twiddle the clock pin manually, but you get an error message in UART mode. :/

SDR with $20 TV Tuner card.

http://hackaday.com/2012/03/30/working-software-defined-radio-with-a-tv-tuner-card/
I was going to hold off posting about this until I got mine and could try it out, but I ordered 2 weeks ago and it hasn't shipped yet so I'll drop a line now. There's been some developments on this story since then anyways. Here's a video where someone is showing this running in real time in GNU Radio.



There's also suppose to be support in Windows now too.

Basically, these are $20 laptop TV Tuner dongles from China. USB connections and they are for DVB-T which is the European digital broadcast TV standard. The US uses ATSC for broadcast and QAM64, QAM128, QAM256 for cable typically. There's a fair bit of satellite stuff that uses DVB-S/S2 though. Someone did some sniffing of the card and discovered that the FM radio portion of it was actually a SDR. It's only 8-bit but the possible frequency range is 64-1700mhz.

I'm giddy over this for a couple of reasons. If it can be made to work cheaply, hello cheap receivers to stick in other places. Yeah, the downer is the processing power required for it to actually work. Processing power is cheap these days. Also, what a neat platform for a potentially automated receiver. No interface cables needed either, plug into USB and play.

Neat!

TM241 analysis

Thought it'd be fun to post a picture of my radio with the probes on the mic jack. I'm using a plug I bought in a pack to make interface cables. The antenna behind the radio is actually the rubberducky for a handheld scanner. My TM-241a is sitting on a wood block to separate it from the Alinco DR-600 below it. (My next target? Heh) These probes connect to a Bus Pirate out of the picture. The one alligator clip stands in for a particularly weak probe clip that kept falling off.

As I write this, I'm almost done rescanning the 2 byte block. 0000-FFFF unless something happens between 00FB and 00FF then I don't think there's going to be anything here. :(

I think my next target will be trying to ape the kind of stream the radio sends out. (Maybe I'll even rig up something to spit it back to it, see what it thinks of that)

Of course, one possible application when I figure this out maybe making my own remote head. Others might use it to make a D-Star homebrew head that can control the radio as well as do the digital voice. Or maybe I'll eventually figure out multiple radios and make a protocol droid to translate from one control head to a different radio. RC-D710 maybe? As I posted before, It's possible to use that head with other radios, as an APRS tnc. But without control.

One thing I'd love to inspire is some sort of USB for radios. Or some sort of multivendor connection standard. It'd be great to connect multiple radios into a bus along with a control head that can operate all of them. I'm not talking just Ham Radios either.

Update: Scan finished. No hits in 0000-FFFF. :(

TM241a Fuzzing

Okay, here are all of the possible combinations of data that I've tried:
(where I have "x" that's where I've stepped through 0-F in hex)
x0x2x1FF
x0x1FF
xxxx (Yes, every combination from 0000-FFFF)
That last one includes xxFF in the possibilities.

Nada. Nothing. Zilch. Zippo.

Like I've said before, the radio seems to follow a pattern for the second nibbles. Without the bitorder switched, the patterns are like this:
00 - Start
22622a1 Frequency
0222221 LCD elements
021 Mem Channel
01 Unknown (always 10 01)
FF - End

Sometimes S-Meter data shows up. It's the one element that breaks the pattern of the second nibble. But, the last 3 bits of it seems to always be 101. First 5 bits seems to be the S-meter bargraph length, or similar.
My thoughts have been on mimicing the patterns when trying to fuzz the data out.

I would also like to try to figure out what the I2C address search mode on the Bus Pirate looks like to a 1200 baud UART port. That may be my biggest clue because that's the one time I've really had an effect on the radio and it was completely junk data.

It could also be that the actual legit communications is so complex that it's not really possible to suss it out by searching a sequential pattern. I wouldn't think so, but there's got to be some sort of a memory access mode or I couldn't have entered corrupt data into Ch1 and 2 with the I2C search mode. The values were impossible to set by key entry alone. Heh, maybe the RC units communicate by writing to live memory. I wouldn't think so. I'd think a simple pattern of keycodes would be more than enough, but who knows what Kenwood was thinking when they designed these units.

I'd sure love to get my hands on one.

EDIT: Sigh, just noticed a rather glaring bug in my serial port TX in my program which probably resulted in me not sending out the values that I thought I was. In short, I have to run all of the above tests again. This time, sending the byte values out instead of the decimal representation of them. Snort. At least I didn't test 17 million values before discovering this tomfoolery.

April 1st

I'd like to officially register my annoyance of all of the fake news stories that every tech site, and some stores, seem to love to post on April 1st every year. It was tired in the 90s. It's over 10 years later. I need some sort of filter for this stuff.

TM241a Reverse Engineering Project Update

After a fairly long hiatus and a hard drive crash, I'm back at it working on this project. I am attempting to reverse engineer the remote control protocol in older Kenwood mobile radios. I'm using my TM241a but I understand that the RC-10 and RC-20 addons Kenwood used to make worked with a whole series of model numbers from TM-x21 through TM-x41 at least.

This was a secret from me until I found documentation and links talking about the RC10 and RC20 addons a year or two ago. I got my hands on operating manuals and service manuals for my radio, the RC-20 and the IF-20 addon. The IF-20 allowed you to connect up to 4 radios to a single RC-20. You could have 2,220,440 and 1.2 at your command if you were one of the lucky ones.

I've spent the last couple days poking around in the free Microsoft Visual Basic 2010 Express Edition writing a program to help me. My hardware interface consists of a Bus Pirate connected to the Mic plug on the radio using a spare plug I bought when working on a TNC project. I am running the Bus Pirate in transparent UART passthrough mode. Why not just use a usb-serial adapter? The Bus Pirate is already at the correct levels (TTL, not RS232) and I can program it to hold a pin HIGH, which is what the radio expects to enable it's remote control mode on the mic port.

Now, I can enter all of the Bus Pirate settings with a single button press on my program. I can read the display output continuously (though I still can't make sense of all of it yet). I can have a window with an active comparison going, output that is different is logged automatically. Right now, I'm running one of many routines to generate data and push it out the port. I'm trying to elicit a response from the radio by pretending to be an RC-20, or at least trying to guess what kinda of data one might send to it.

This would be unnecessary if I had access to either an RC-10 or RC-20, but alas they elude me. My fuzzing efforts are time consuming though. I've already ruled out 1 byte commands, sadly. That only took 255 guesses. I tried a 4 byte command guess with most of it filled in except for 3 nibbles. That took 4095 guesses. Nada. Now I'm sending 2 byte command strings, all guesses. That's 65535 guesses. Sadly, if I go up to 3 bytes then that's 16,777,215 combinations. Yes, almost 17 million!

BTW, I'm guessing about 40 times a second, so that's almost 30 minutes to run through 65535 guesses. 17 million isn't going to happen. There's a command for power on/off and transmit at least. Not to mention that while I was trying to figure out what protocol it used in the first place I accidentally entered junk data into it. Using the I2C address scan mode on my Bus Pirate somehow did it. That means there's a chance of a raw memory access mode. That could result in dangerous effects on my beloved radio, such as entering something that would cause the PLL to unlock permanently or TX at some weird frequency causing my finals to blow. I can't just let a fuzzing routine run all night while I'm asleep. A meltdown from excessive keydown is the least problem that could happen.

This is an example of the binary data the radio send out. It runs at 1200 baud 8,n,1 (ahh, bbs days)
00 82 22 A6 02 92 AA F1 40 42 02 12 02 22 01 E0 82 41 10 01 FF
The oddball part of this is that the bit order is reversed. ie 1100 would be 0011 actually.
If you reversed the bitorder and re-wrote the line:
00 14 44 56 04 94 55 F8 20 24 04 84 04 44 08 70 14 28 80 08 FF

The radio seems to use the first nibble for data, with the second nibble acting as some sort of checksum, or maybe even frame marker/address.
00 14 44 56 04 94 55 F8
0 1 4 5 0 9 5 F <- First nibbles only -- I'm on 145.095
0 4 4 6 4 4 5 8 <- Second nibbles only
Second nibbles of 0 and 8 seem to mark the beginning and end of subframes within the frame.

Second part of the frame from 20 through 08 seem to be fixed LCD elements (T +- BUSY etc)
70 - x8 are memory channels if you are in the MEM. This happens to be Memory Ch 12 for me.
70 14 28
7 1 2 <- ch 12.. Channels under 10 are 7 F x (where x is the channel #) so 7 F 9 is Ch. 09
0 4 8
...If I remember right, if you are in VFO or Call the Mem info is different, or missing entirely. That was in my notes that were lost forever in my hard drive crash a little while back.
80 08 are currently unknown for me.
00 and FF always mark the beginning and end of one whole frame.

Once you get the radio started, and all you need to do is send 1 byte of any sort at the right speed to it, then it continually sends display frames out at 1200 baud.
If you receive a signal, the S-meter data is sent out as well, in the form of setting one of the bits in the LCD element section and 2 additional bytes before the 80 08 pattern. It seems to have a hold pattern, if it's not changing then the radio stops sending the extra 2 bytes until it does change and then the radio will send out the changes again. I believe they resolve into the number of S-meter bargraph elements that should be lit up.

I'll keep plucking away at it. I do love a puzzle.

Ubuntu liveUSB

A couple of weeks ago disaster struck! I went into my office to compute a bit only to get an omnious message from Windows to back up my hard drive as it was about to die. I don't know how it devined that though. I downloaded a SMART utility which told me that there were some dead spots but I though the drive would work around those. I quickly saved some of my more precious data, which was mostly digital camera pictures and movies. I also managed to save my browser data, a couple of VMs I was experimenting with and some other stuff but not everything. I left that afternoon and when we came back, the drive was dead. I felt a little like I lost an old friend too. I managed to order some new parts from Amazon, I usually use Newegg but Amazon was cheaper in this case. Got a new 500GB hard drive, as well as a Bluray burner and some media. The whole kit was a little pricy but I needed the hard drive to bring my computer back to life and I'm hoping to use the bluray stuff to make it easier to do backups.

While I was waiting on all of that stuff though, I went to Best Buy the next day and bought a couple of 16GB flash drives for around $13/each. What a deal! I used one to have another copy of pictures, etc. Before that, the only copy was on my Ubuntu fileserver where I had copied it to in a hurry when my main drive was dying. The other drive I installed Ubuntu to. I was running a LiveCD version of Ubuntu but annoyed with installing packages every time I rebooted. Wish I had the URL for the guide I followed, but it was very easy to put on USB flash drive. It setup a 4gb partition for user files, I resized the main partition and the user partition to give me more like 12gb of space. I ran like that for several days before my new components came in. I was actually kinda sad to go back to Windows after using it too. I've always liked Linux, really most of the reason I use Windows still is because of gaming and very few other applications. 99% of what I do is more than possible on Linux though. It was also nice to not have a hard drive chugging because Windows somehow needs to use swap space even though it has 6GB of ram.

As an aside, I'm working at a computer place in town now that has a nifty setup with Xen running multiple virtual machines for networking services. Some of those machines have at least 16GB of ram. I setup a machine to run Windows Server with SQL Server that could do 2 Xeon cpus and 18 sticks of ram. It had 5 sticks for 16GB (3x4GB, 2x2GB iirc). I guess if you put a bunch of 4GB sticks in it, you could run 72GB of ram! That's pretty spiffy! Of course, there's 9 slots per processor, and you can't run ram in 9 of them unless you have the 2nd processor also.

Moving forward, I'd like to maintain my Ubuntu LiveUSB and maybe even run from it some more. I'd also like to see if I can get my virtual machines to run in it. One of them is an old XP licensed from a computer I don't use anymore. I have that setup to run my old HP ScanJet that won't ever have Windows 7 drivers. That could possibly do some of my applications that I like to run. I'm sure I can use WINE, but maybe not? Plus I'm not sure stuff like PDF printers work under WINE.

I'm also thinking about running My Documents style directory from a USB flash drive. This isn't the first time I've lost documents, some of the fairly important, in a hard drive crash. I do need some sort of backup regimen also. If I can set things up right, I'd like to just go ahead and buy a new hard drive every year or 2 and transfer the contents of my operational drive to the new one to keep away from having a crash related to wear and tear. The question then is what to do with the used drives? Maybe I'll set them up to have online storage of stuff I have backed up on disc, but never original copies of data.

I also do need to concentrate data in one place. I'm fairly sure I lost a large archive of Ham Radio info because it was stored in some random place on my hard drive and I forgot to grab it when I could. Mostly cached copies of homebrew pages, so it's not original data but still there was a lot of it.

It is nice to boot up my VM with Windows XP on it and see the stuff there is untouched by my latest catastrophe. I might put more of my necessary programs into a VM like that, or that one at least, just to speed recovery from future crashes. It's very easy to save a copy of the hard drive image the VM programs use.

Man, this turned out longer than I thought it would be. Sorry for rambling.

TM-241a Sniffing

May have found a RC-10 for sale. These were compatible with the remote control interface on this radio (and a few other Kenwoods) It looks like a car phone handset. Remember when cellphones came in a bag variety? Kinda like that. I'm hoping that I can use my Bus Pirate with it to sniff out the correct commands to control my radio. May be just what I need to get my TM-241a computer control project back up and running.

Soundcard Radio Direction Finding

Found an interesting post and video about doing soundcard based radio direction finding: http://dangerousprototypes.com/2012/01/27/28c3-soundcard-based-radio-direction-finding/

The talk is a little awkward but he gets the point across. The major takeaway is that he is feeding the audio from the radio into one channel on his soundcard, say left channel, and then the other side is a pulse to indicate the antenna switcher has switched. Then these signals may be processed using DSP techniques to figure out what the phase of the audio signal is and match it to which antenna is active from the pulses on the other channel. It seems like a lot of expensive processing to do something that can be done in hardware but a computer gives you the opportunity to send the data elsewhere over packet or wifi. Coordination could also be accomplished.

The other interesting bit I liked from his video is his use of an antenna switcher IC meant for cellphones. It can work from 300khz to 3.5ghz so it has plenty of range. It's a tiny surface mount chip but he did find it in SSOP-16 which is easier to solder than a QFN. The SSOP-16 was mounted on a SparkFun carrier board to allow easier access to the pins for breadboarding.

I've wanted to experiment with RDF for awhile. Not only could you apply it to Ham Radio uses, such as finding interference or foxhunting or other roles.. but it could also be handy for scanner enthusiasts. Imagine scanning through a frequency range, hearing some traffic and being able to locate the traffic right to the building it's coming from. This would be very handy for maintaining lists of frequencies for different factories and other workplaces.

Yeasu Digital Radios imminent?

Was browsing Yeasu's website this evening and discovered something interesting listed in their HT and Mobile radio sections. A listing with no picture labeled "Digital". Clicking on it gives a little blurb about downloading information about digital communications in the amateur radio world. It is a 6mb PDF file that contains a brochure talking about digital radio. Vertex Standard produces a line of HT and Mobile radios that do APCO-25, and another mode with uses TDMA. Time Division Multiple Access. On page 14 of this PDF, they say they are going to bring out an HT and a Mobile radio in early 2012 that does C4FM modulated digital voice in either FDMA (Frequency Division Multiple Access) or TDMA for the Amateur Radio market. C4FM is opposed to GMSK like what D-Star uses. I'm sure they'll probably wind up using the same or similar audio codec as D-Star though, AMBE. I would love to hear otherwise, especially if they decided to use the unfinished Codec2 somehow. I doubt it though.

TDMA would be interesting to see. You can have repeaters that allow two conversations at the same time, as if it was two repeaters, with just one set of hardware.

It's going to be an interesting year next year. "Amateur Radio should be progressive." is what the brochure says, I agree.

http://www.yaesu.com/downloadFile.cfm?FileID=7146&FileCatID=151&FileName=DigitalCommunicationsGuide%5FE%5B1%5D.pdf&FileContentType=application%2Fpdf
Let me know if this link doesn't work, it's a direct link to the PDF file.

PIC12LF1840T48A integrated radio transmitter

Just read about this on the Electronics Bus blog,
It's a new PIC microchip with an integrated radio transmitter intended for keyfobs and the like. There are 8 preset channels covering a couple of bands: 418-443.92 and 864-869.85mhz per the datasheet (Page 361). There's an application note as well. It supports FSK and OOK. FSK mode can run up to 100kbps(!) at a power output of up to +10dBm. (About 10mw if the online conversion tool I used is right).

Can you receive FSK with AFSK demodulation? This chip would be interesting paired with code and a cheap GPS chip to make a small, low-power, cheap APRS beacon. Add a homebrew power amp for the 430 or 440mhz band and you could have a platform for a remote APRS sensor or sensor network. Although, since it's just the transmitter, I'm guessing you'd have to be careful of collisions.

Of 3D printers and themes

Okay, so the theme I had up wasn't working for me. It was a new dynamic layout that Google is offering and even on my computer it was kinda bogging down. And my computer used to be fast... 4 years ago.

This is a new 3D printer project that I heard about. Called Printrbot, of course. What is a 3D printer? Wikipedia I've been following the news of a couple of homemade 3D printers for years, mostly the RepRap and the Makerbot. This seems to be a new one that is made to be easy to build and inexpensive. And actually, from reading the Kickstarter page there.. It's a special version of the RepRap? I don't know. Anyways, $500 there will get you all the parts to assemble one of these 3D printers. $750 will get you one assembled and ready to go.

"Printrbot is small and intended to be your FIRST printer. The print area is roughly 5″ x 5″ x 5″. It does make a few sacrifices to keep things simple, but it is designed to be upgradable and expandable. You can easily increase the build area to whatever size you want. You can mount it inside a box or frame for rigidity. The included hardware is “full-sized” and on par with the Prusa – the current high-resolution champ. While Printrbot could happily serve your 3D printing needs sitting on your desk in your office, right next to your computer, it could also be the seed that spawns a never-ending series of upgrades to a bigger and better 3D future. You’ve got options."

I could easily see this being beneficial to homebrewers. You could print plastic cases, a front panel for a radio, knobs.. small ones or big VFO wheels, standoffs, plastic morse code key?, insulators for antennas, etc I'm sure there are a ton more things you could use a 3D printer for.

New theme, TM-241, etc

I'm trying out a new theme to go with the changes behind the scenes at Blogger. It's a little less plain than my old one but I'm not sure if the navigation is going to be a pain, especially for people with older computers. If anyone experiences that, leave me a message on this post?

I haven't forgotten about my work on reverse engineering the remote control protocol for the Kenwood TM-241a radio. I've been very busy with school work lately. I'm in my final month of my Associates degree at IvyTech for Computer Information Technology. I am on track to keep my 4.0 GPA too, which is great. It's caused me no end of stress right now though. I'm on a program that let people who had their jobs displaced to other countries go back to school for a 2-year degree. Many of us did so with the idea that the economy was going to be in much better shape by now. At least, I did. I've been applying for positions since June and haven't had much luck even getting interviews. Once my education program ends, so does my unemployment. Shortly after that... we're going to be in trouble. Of course, one of the places I have applications at right now may come through and save us at the last second. Not that I can count on that though.

I'm thinking about trying some ads on here to see if I can get a little ad money.

If anyone knows anyone hiring within 30-60 minutes of Richmond, IN.. please, let me know. I'll have an Associates degree and I also already have my A+ certification. I'll be taking the Network+ soon and should get that easily.

Speaking of the Kenwood TM-241a work.. I haven't managed the basic application to fuzz out the numbers. It seems doing serial comms under .NET is a little hairy. Also, the Bus Pirate's binary mode is easy to get into but a little hard to use so far. I'm a little inexperienced in it, so it might just be I'm not understanding it right. From what little by-hand fuzzing I've done using a terminal mode on the Bus Pirate.. I feel like my original theory is wrong. I was hoping it would be a simple 3 byte command.. an address and two bytes for the command. The protocol to send the display information out seems to have 1 nibble of data along with 1 nibble of check information. So for example, 0x00 0x04 0x04 0x04 0x08 might be a valid packet with the first nibble having data and the second nibble being a check digit of some kind. The nibbles might have BCD numbers or be bit-level information for single LCD elements. My theory with the control scheme was with 1 byte for address, and 2 bytes for data.. that's 2 nibbles or one whole byte for data giving 256 possible combinations of buttons or commands.

Now, in previous experiments I have managed to affect something while sending data. Once I managed to have the radio skip around in the memory channels by significant steps. Another time, before I figured out the exact communication settings, I managed to overwrite the memory channels with bogus data. That's probably the greatest clue that what I may be dealing with is direct control over the internal memory of the radio. If so, my job is significantly harder. I need to figure out how to address specific areas of memory and what the contents mean, all while not being able to read it directly.

...

Or can I? Looking at the service manual, there's no information on what the main cpu is, and it looks like no external memory. If I could figure out what the cpu is, I can at least figure out my constraints. Working further on fuzzing the interface, I may be able to figure out the correct way to issue address commands and data. The main questions are: How many bytes do I need for an address? Do they require the checkdigits like what is used to talk to the LCD? How many bytes do I send after the address? Checkdigits? What is the constraints on memory area I can address? With that, I can start poking values into memory to see what happens. I know there's a soft power off feature, so you can turn the radio off from the remote control interface. There's also got to be a method to key the transmit, because the PTT line is one used for the communications.

There's apparently an internal basic scripting language on the newer Bus Pirate firmwares. I may need to look into upgrading mine. If it doesn't work, I have a cheap ICSP capable programmer here that I can maybe revert it with.

TM-241 again

Figured out how to read the S-meter data when it is active. Not too shabby. Still trying to figure out what kind of format the button data is in when transmitted. I have been doing a little hand fuzzing, aka sending random data bytes. I had a theory that they used the exact same control scheme not only on the remote control interface, but also on the internal configuration. That might be true for the LCD commands, but upon closer examination of the schematic, the buttons are in a matrix on CPU pins, SQL and VOL are variable resistors and the VFO knob is a quadratic encoder. Still, it might be valuable to open it up, and patch into the internal LCD signals if it helps me figure out which bits control what LCD elements.

I might also need to write a basic program to start fuzzing. If I could figure out some representative commands, maybe I could go from there and send test commands that are more likely to have a response. At the very least, I need to figure out: VFO knob, VFO button, MEM button, VOL, SQL, and PTT. The last one is important because the MIC connection on the radio is part of the communication scheme for the remote control interface.

TM-241 Progress

After a misstep where I had faulty data, I am getting valid data out of it now. I can tell because I have figured out how the frequency is encoded and I can predict the results of changing to a different one. There's a lot of work still to be done because so far all I can do is read. I also don't know how everything is encoded.

So far I can read the frequency, if there's an offset and which direction, if I'm in VFO mode, CALL mode or Memory channel mode and which channel. I can also see if there's a signal but I haven't figured out how the S-meter is transmitted yet.

There are several bytes where I'm sure data is encoded at the bit level, I've already seen it with offset, CALL and there's a bit that is set if I'm receiving a signal.

There are quite a few LCD elements that I don't know where they map yet. Much of my experimentation so far has been to set something on the radio, turn it off, configure the Bus Pirate, turn the radio on and read it. If I had a RC-10 or especially RC-20 I could probably rig it up to drive it from the Bus Pirate. Then I could configure the packet of bytes to feed it and see what it does. I could also use it to send control packets to the radio to see what they are. I'm guessing the remote control interface is like a "dumb terminal".. if you push a key, it send that key to the radio instead of doing processing itself. That explains why the radio isn't sending a lot of information out such as what the offset is, or if there's a CTCSS tone and what it is. All the radio is sending is what should be displayed on the LCD. I can probably expect a different packet if I'm in a screen to change the tone, for example. Already I have noticed that when I'm on the CALL channel, it omits data for the VFO and MEM channel.

I'm also a little curious as to how the IF-20 sends information to the RC-20 when there's a second (at least) radio connected. The TM-241a only sends out information for itself. The IF-20 would connect to multiple radios and format the information from all of them into a form that can drive the main and sub display on the RC-20. I'm guessing it's an addressing change.

I know Kenwood killed off the remote control displays sometime after the x41 series. I wonder if the protocol survived in the x51 and future radios? Probably not, but you never know. There's a lot of potential power here, this could have been a major selling feature even now.

Kenwood TM-241a

I'm working on reverse engineering the remote control interface on my TM-241a. When it was a new radio you could buy options to use it: RC-10, RC-20, IF-20. The RC-20 looks like any other remote head but with the IF-20 you could hook it up to 4 radios. You could end up with one control and microphone to drive a 2m radio, 440, 220 or 1.2ghz. It also worked across different revisions of the radios although I think the x41 were the last ones.

I emailed Kenwood looking for any information on this interface awhile back, they couldn't help me with the protocol but they were kind enough to send me PDF documents with schematics on the RC-20 and IF-20. Between those, and a PDF service manual for the TM-241a I found.. I have figured out how to do an electrical interface. I'm using a Bus Pirate v3 from Sparkfun to do it. Not entirely sure if I'm interfaced correctly, but I am getting repeatable data. It's quite noisy because I am just using the unshielded probe cables I got with my Bus Pirate.

I did accidentally overwrite a couple of the memories already with junk information. Somehow one wound up with 444.900 and the other had 109.490 in it. Obviously didn't try transmitting there. The radio probably wouldn't have let me, it gave me the error beep when I pushed the REV button to see where the offset ended up. I'm mostly concentrating on receiving the display data that the radio constantly sends out right now. I'm making a bit of progress on the puzzle but it would probably go a lot quicker if I had a RC-10 or RC-20 to experiment with.

All well, I love a puzzle.

My next step may be to collect a lot of information and make Visual Basic programs to help me analyse it. Both for errors, and also for changes between samples (ie, data for one frequency in a memory channel, and then data for another frequency in the same channel)

Freescale MC13260 SoC Two-Way Radio IC

Found this in a mailing-list post the other day. Very neat, it's a System-on-Chip that is almost everything you need to make a radio from 60MHZ-960MHZ.



From the Freescale website:

Target Applications:
Comprehensive analog FM radio
Comprehensive digital radio (DMR, P25, TETRA, dPMR)
Dual-mode analog FM and digital voice/data
"Talk around the network" feature for cellular applications

Features

ARM926EJ-S™ MCU operating at clock speeds up to 150 MHz
Modem processor (software-defined radio) operating at clock speeds up to 100 MHz
640 KB of integrated RAM
MCU peripherals to support control and monitoring functions
High-performance integrated RF transceiver supporting RF frequencies of 60 MHz–960 MHz
Fully integrated, high-performance RF fractional-N synthesizer
Integrated 13-bit audio CODEC with analog input/output
Three 12-bit DACs for support functions
10-bit general purpose ADC with four multiplexed inputs
Receiver supports linear modulation
Linear transmit support using integrated I and Q DACs and an external modulator
Advanced Encryption Standard (AES) module for secure communication
Full-speed USB device with integrated PHY

Pretty feature rich! I assume the RF components you need amount to bandpass filtering, preamp, transmit/receive switch, and filtering, power amp for transmit side. This chip implements the SDR conversion, AD/DA conversion, etc. It has an ARM9 CPU and a separate "modem" DSP. I'm unclear if the DSP handles the FM mod/demod and any modem processes such as encoding or decoding PSK, FSK, GMSK, QAM, etc.

This chip is pre-release, according the press release the chip will be available in Q1 2012.

Press Release: http://media.freescale.com/phoenix.zhtml?c=196520&p=irol-newsArticle&ID=1537559
Product Details: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC13260&tid=vanSoCRadio
Fact Sheet: http://cache.freescale.com/files/rf_if/doc/fact_sheet/MC13260FS.pdf?fr=g
Support Info: http://cache.freescale.com/files/rf_if/doc/support_info/MC13260_TRN_SI.pdf?fr=g
Product Brief: http://cache.freescale.com/files/rf_if/doc/prod_brief/MC13260PB.pdf?fpsp=1

Other chips I've covered include:
CMX7163 QAM Modem

The CMX7163 QAM Modem is a low power half-duplex device supporting multiple channel spacings under host microcontroller (µC) control. Its Function Image™ (FI) is loaded to initialise the device and determine modulation types.
The 7163FI-4.x supports 4-, 16- and 64-QAM modulations up to 96kbps in a 25kHz channel, with channel estimation and equalization to provide robust performance under realistic channel conditions.
Flexible bit rates support a wide range of applications requiring a selectable bit rate and robustness.

An integrated analogue interface supports 'direct connection' to zero IF I/Q radio transceivers with few external components; no external codecs are required.TI CCxxxx series
From my blog post on the Ubertooth One:

A CC2591 2.4ghz PA/LNA,CC2400 2.4ghz RF transceiver and a LPC175x series ARM chip.
What inspired him to use a chip like the CC2400? He previously played around with a kids toy called an IM-ME. It's a pink pager-like device meant for girls to send instant messages over the Internet (via a usb dongle plugged into a computer)... He was able to turn it into aninexpensive spectrum analyzer type device. How? It has a CC1110 chip. This is an RF transceiver chip with an integrated 8051 cpu. According to the linked site:


Frequency range: 300 – 348 MHz, 391 – 464 MHz and 782 – 928 MHz
Pretty neat, it's capable of operation in the 70cm and 33cm bands at up to 500kBaud. This was in a toy that was less than $20 on ebay.

Raspberry Pi ARM Single-Board Computer

This is the Alpha prototype board according the the wiki.

This is a very low cost ARM SBC that is being developed right now. It is unreleased but once it comes out, there could be a multitude of applications in Ham Radio for it. They are talking about making two versions, Version A for $25 and Version B for $35.
Here are the "Provisional Specifications" from the community written wiki

• 700MHz Broadcom media processor featuring an ARM11 (ARM1176JZF-S) core, Broadcom GPU core, DSP core and support for Package-on-Package (PoP) RAM
• 128MiB (Model A) or 256MiB of SDRAM (Model B), stacked on top of the CPU as a PoP device
• OpenGL ES 2.0
• 1080p30 H.264 high-profile decode
• Composite and HDMI video output
• One USB 2.0 port provided by the BCM2835
• SD/MMC/SDIO memory card slot
• General-purpose I/O (About 16 3v3) and various other interfaces, brought out to 1.27mm pin-strip
• Optional integrated 2-port USB hub and 10/100 Ethernet controller (Model B)
• Open software (Ubuntu, Iceweasel, KOffice, Python)
• Capability to support various expansion boards

Anyone's guess if it will come out at the price point they are hyping up. In my experience stuff like this tends to slip into higher price ranges when people get excited about it. Kinda like electrons jumping into higher orbits.

Besides including 256MB RAM, the B version is also suppose to have a chip on board that is a 2-port USB hub and ethernet controller. I'm assuming the ethernet will also use your USB bandwidth.

It is interesting to me that they are stacking the RAM chips right on the processor. That should save some space at least! The Broadcom SoC seems to be pretty neato too. It has the ARM11 CPU, a GPU that does Open GL and 1080p30 H.264 decode, and a DSP but there's currently not enough information known to access that yet.

16 GPIO at 3v3, I2C and SPI interfaces will come in handy, it also has stereo audio out. I wonder if it would also have stereo audio in? That could make a very small interface to something like a SoftRock. They also talk about being able to interface to a cheap LCD module for portable operation. Otherwise, it looks like HDMI output.

v---Click on the sbc label to see my other single-board computer posts.

"High-Speed" data and digital voice

It's a sham that faster digital modes haven't really caught on. I've read about 56k packet in the past. Most radios today support 9600 baud packet, if you can find the discontinued equipment that support those speeds. What does this have to do with digital voice?

Codec2 can squeeze voice into 2550bit/s AMBE can do voice in 2400bit/s and MELP can do it in 2000bit/s. D-Star does a continuous bitstream at 4800baud with 2400 for AMBE voice and 1200 for FEC(Forward Error Correction) (And the voice frames are transmitted blank if you're doing data only, FEC doesn't cover data and you really only get 751bit/s data, I'm not a fan of the protocol)

If someone built a system with Codec2, some FEC and a packetized modem at 9600 baud (or, better 19.2k for the overhead). I'm betting we could have a single-channel digital voice digipeater. I think you'd have to be careful not to use 50% of the channel on each side just because of overhead from headers and the like. It'd be like 802.11, I tx some time, you tx some time, I tx some time, etc. 1 frequency digital repeater. No duplexer cans.

In fact, if the data speed was fast enough we could probably do multiple logical channels with simultaneous users on the same frequency.

More to come.

D-star, P25, other AMBE/IMBE modes

For some reason people are going around saying that "the DSP chip in D-Star, etc radios is really no different than having a DSP in modern HF radios. People don't suddenly refuse the operate their HF radio because they can't see what the DSP is doing."

This statement is a prime example of wrong thinking. What's worse is the same people explain to me that the only difference is the HF radios use the DSP for "IF-level modulation and detection" while the chips in D-Star are just vocoders.

Okay, what is a vocoder? (I am playing stupid here for the benefit for people who really don't know)

Wikipedia.org defines it as:

A vocoder ( /ˈvoʊkoʊdər/, short for voice encoder) is an analysis/synthesis system, mostly used for speech. In the encoder, the input is passed through a multiband filter, each band is passed through an envelope follower, and the control signals from the envelope followers are communicated to the decoder. The decoder applies these (amplitude) control signals to corresponding filters in the (re)synthesizer.

I don't understand the math behind it. Basically, instead of digitizing the speech and sending it directly over.. the vocoder system renders it into a series of much smaller operations that can be done on the other side to recreate the speech.

This quote from codec2.org backs this up:

A vocoder works by analyzing speech and encoding it as phonemes and other higher-level information, rather than as a continuous waveform. It can thus compress speech into substantially less bandwidth than a waveform codec. Vocoders are generally less intelligible than codecs. They reproduce an evocation of the orginal voice, rather than the actual voice, but sophisticated vocoders like AMBE do so well enough that - except at the lowest bandwidths - the speaker's identity is immediately and easily recognizable. 

The problem with that is certain operations can be patented which will make your vocoder unable to be reproduced legally by anyone other than yourself.

Dave Rowe writes on his website:

Proprietary codecs typically have small, novel parts of the algorithm protected by patents. However proprietary codecs also rely heavily on large bodies of public domain work. The patents cover perhaps 5% of the codec algorithms. Proprietary codec designers did not invent most of the algorithms they use in their codec. Typically, the patents just cover enough to make designing an interoperable codec very difficult. These also tend to be the parts that make their codecs sound good.

So, no one can make a codec that will be compatible with DVSI's codecs, but it is possible to make a codec that works just as good. Codec2 is such a project. It sounds pretty good to me right now, but it is just alpha software at the moment.

The only company that can make chips that are compatible with the vocoder in D-Star, P25 and other radios that use AMBE or IMBE is DVSI. It's true that DVSI just provides the programming on the chips and they are DSP chips from TI. You might even find the same model DSP chip in your HF radio. The problem is to communicate by D-Star you have to have a chip from DVSI in both sides of the conversation.

On the other hand, anyone with a homebrew radio that can do modulation in CW/SSB/AM or FM can communicate with any Gee-Whiz HF radio with a DSP inside of it just fine.

Anyone who says that the DSP in a D-Star radio and a DSP in an HF radio is equivalent is acting in a dishonest manner.

As soon as someone makes a legal source code available that I can load onto a fresh DSP from TI or any other DSP company, build into a radio and communicate with D-Star radios, then I'll stop complaining about the chip inside of them. While DVSI is the only source in the world for said chips, then I'm not going to shut up about it.

Downloading programs over Ham Radio

Wanted to have this as a separate post. Someone on a digital radio mailing list posted this video from 1984:
http://www.itnsource.com/shotlist//ITN/1984/05/21/AS210584001/

It's a mostly alarmist piece about how piracy is destroying the software industry. It seems to be intact nearly 30 years later. In the last 30 seconds or so it includes a bit about Hams who are doing basically shared development of software by sending it back and forth over the radio. The software was stored on cassette tapes in this. The Ham at the end holds his microphone up to the tape player and hits play.

I wonder how long he had to sit there like that. Hah. Those things only ran at 1200baud I think. Maybe it was a really short program, just like 1 or 2k.

Icom 900A, etc

I was clued into these radios awhile back: http://www.universal-radio.com/catalog/fm_txvrs/900a.html
It's a very neat idea. Get a common control point and then buy swappable modules that cover the band you want. I know other radios did the same sort of thing internally: Kenwood TM 741/742/941/942, Yeasu 726R/736R, and a few others.

Kenwood even had a remote head RC-20 that would work with a bunch of their otherwise standalone mobiles. I think it worked from the X21 to the X41 series. IE TM-221, TM-241, etc. With the optional IF-20 accessory you could even hook up 4 different radios to it. You could attach radios for 2m/220/440/1.2 to it.

Neat concept, I'm sure it got expensive though. These systems were probably all phased out for single radios with everything in them. Makes me wish someone had settled on an open protocol for connecting external controls to these radios. Even make it industry wide, not just Ham Radio. Would it be against the rules to have a single control head and microphone that can switch between controlling 1 or more Ham Radios, a CB radio, GMRS, scanner, etc. Each radio could be type-certified for their task but controlled from one vantage point? I guess you would have to be careful to conduct yourself appropriate for the service you are using.

Kenwood's new TM-281 2m radio

Link: http://www.universal-radio.com/catalog/fm_txvrs/0281.html

With exciting new features!
LCD backlight color now back to orange instead of green!
Hi Power boosted to an incredible 65W. That's a whole 5W more than the TM-271! Wow!


Throw that old junk away and buy today!
Only $164.95

ARISSat-1 Finally Deployed from ISS

http://www.arrl.org/w1aw-bulletins-archive/ARLS007/2011

Just got the announcement from the ARRL about ARISSat. I've read the news before about it being deployed. The word is the NASA-tv feed showed it and that it was being handled rather roughly. I didn't see the stream, I wonder if anyone managed to screen capture that and post it somewhere like Youtube or Vimeo? I guess it's rather regrettable that the UHF antenna was forgotten/lost/broken. You would think after all the time it took to get it up there, they would be a little more conscientious with it. According to the ARRL bulletin, if they scrubbed the deployment, the next opportunity would be Feb 2012. Well, it's taken this long to get it up what's 6 more months? Especially since now the UHF component will never work? Then again, maybe it was basically a "now or never" decision, I doubt we'll ever know.

Well, on brighter news I heard a couple of seconds worth of SSTV from it last night. I haven't managed to find any tracking elements so I don't know where it is. I had my Kenwood 241A tuned to 145.950 and heard a few seconds of SSTV even though my antenna is a Ringo Ranger 2. Still want to try to find resources around here to make a WA5VJB cheap yagi sometime.

SSTV images in video games

I'm very late to the parade on this one but I don't know if there's been enough attention paid to this. In March last year Valve Software updated one of their games, Portal, to have radios that would play Morse Code and SSTV signals when you carried them to specific spots in the game. They did this as part of an Alternate Reality Game that led to the announcement of the sequel game, Portal 2. They actually included 4 more SSTV images in the sequel. One can be received during the first play through of the game, and the other 3 are part of a developer's commentary. More info about the Portal ARG here.

To receive these images, you can use any computer software such as MMSSTV and point the soundcard input to StereoMix, or similar. It's even possible to receive off of the youtube video in the above link.

2 interesting new(?) Chinese HTs

Couple of neat Chinese radios I've learned about recently. The first is the Baofeng UV-3R. It is a shirt pocket sized 2m/440 DUAL BAND radio. It does both bands in the same radio. Apparently it does 2w out, no indication if that's true for both bands. G4ILO has reviewed this handheld. One thing that he notes is that his came with separate vhf and uhf antennas, but some sellers on ebay are offering them with dualband antennas as well. It is currently $54.50 on 409shop.

The second one is the Puxing PA968. Here's something interesting.. You can buy it in either 2m or 440 varieties. The usual frequency ranges too, 136-176 or 400-470mhz. BUT, not only is it a radio, it is also a quadband GSM cellphone, with provision for 2 sim cards. This one is upwards of $194.74 on aliexpress. 

What would a modern BBS look like?

I remember the good old days of dialing into a BBS before the Internet was really big. You could use a terminal emulator included with Windows or something more specialized like Minicom in DOS. Sometimes you'd have to wait for hours to get connected because someone was tying up the telephone line and you'd end up getting busy signals. Then finally, you'd get connected! Then you could login and navigate pretty much a text-only system, with the only graphics being ASCII art or anything you downloaded and viewed offline. I had a 2400 baud modem through most of my BBS days. I think it took an hour to download 1MB. Anyone could run a BBS, it just took a dial-up modem and software on your computer.

What would a modern one look like?
I think it would be based entirely off of the Internet technologies that have become more popular since the 90's. You could set up a dial-up server with TCP/IP connections. Anyone who connects in would get a private IP address, then have a captive portal (such as used in wifi hotspots) to redirect people into a webserver you have set up. You could run a phpBB instance on the webserver and call it a day. That would get you forums, you could run other servers for other services. For example, have a FTP server set up for files. The users might even upload a file and link it in a forum post. Or run an email server for the users.

Depending on location or access to locations, it could be possible to set up wifi access points to allow for high-speed access to this modern BBS. It's a shame that DSL isn't a little more like dial-up, not speed-wise but with dial-up's ability to just call anyone and get a digital conversation going.

Uses? Community-oriented network, really private network, backup communications path if a group loses access to the Internet, maybe useful in places like Egypt etc. I could see a case where wifi access is available and someone walks by with a Windows CE palmtop or similar device to send/receive email real quick.