Uniden's BCD996T and Linux

Last updated on 2009.10.05

The following methods of communication with the BCD996T are possilble, with preference of using Wine with the Uniden (UASD) software.

(DSctl is usable and almost completed -- See my notes within the Sctl/DSctl section.)

Using QEMU with Windows
Using Wine
Patching SCTL or Using DSctl


Using QEMU with Windows

QEMU is quite system resource intensive, but offers the best simulated enviroment of Windows including ease of install *if* you have already successfully labored installing QEMU.

To use the Uniden UASD software within QEMU with Windows, start QEMU with the following incantation:

$ qemu -localtime -hda /home/roger/Windows/winxp.img -boot c -m 256 -kernel-kqemu -cdrom ~/Windows/winxp.iso -smb /home/samba -serial /dev/ttyUSB0 -std-vga -no-acpi

Focusing on the "-serial" switch, point it to either your COM port or USBtoSerial device file.  For me, I'm using a USBtoSerial cable for connecting the Uniden unit instead of the default serial DB9 cable.

QEMU does a good job of doing the rest for you including matching the speed of the port to the port of the operating system. :-)  No messing with the Device Manager -- No just don't, because doing so might cause Windows to crash.  All you should have to do from here is, inform the UASD software to use the specified COM port and set the COM port speed within the UASD software.  I'll explain this below within the "Using Wine" section.

(I had no success using a regular DB9 serial cable connected to the COM ports as I think the UASD software refused to find a BCD996T within Windows under QEMU.)

(Another note, I can't use USB in QEMU as I get CPU runs whenever a USB device is activated in QEMU.)

Using Wine

(Both reading and writing is possible, although it is sometimes touchy and/or glitchy.)

Using Wine gives the user a much better experience with most Windows software as the software seems to run much quicker and smoother having access to the benefits of a Linux operating system.  This is my preferred method of running most Windows software.

Make a symlink from ~/.wine/dosdevices/com# to your tty device file for the Uniden unit.  (ie. /home/roger/.wine/dosdevices/com3 -> /dev/ttyUSB0)

$ ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com3

(Make sure /dev/ttyUSB0 is your USBtoSerial cable device file, or if you're using a DB9 serial cable using COM ports, you'll want to specify a /dev/ttyS# device file instead.)

Within the Uniden's UASD software, open either "Write to Scanner" or "Scanner View" and click the Setup button to set the COM port option to "Com3" as well as the speed to "115200", or your specified ~/.wine/dosdevices/com#.

(To write to the scanner, you'll first need to register and be provided a registration code to be able to write.  The "Write to Scanner > Setup" will provide you an option to enter your registration code.)

Patching SCTL or using DSctl

(Read fuctions are completed for DSctl with write functions written but not hooked in -- some write functions are hooked in such as upload all and firmware write.  Firmware read/write is also possible with DSctl.  Live streaming  with  live updated vorbis tags is also possible.  See my SVN notes on Sourceforge for specifics on this as well.  Below are my initial coding ramblings and you'll notice I stopped updating this site and focused pushing all documentation to the DSctl Sourceforge website.)

I've started intial work for including BCD996T support for Sctl for including BCD996T.  (This command set also includes BCD396T support as well.)
I've posted an initial patch (or, preferably, checkout the svn version).  This mainly demonstrates we can use the same communication and frontend code used in Sctl.  I'm still split on the idea of patching vs. branching.  I'm hinting the code might get ugly, as the Sctl code is a masterpiece.  So branching for *only* supporting BCD* devices might be ideal.

Updated: Several years ago, I did branch Sctl into DSctl.  As I stated previously, I took Sctl and dropped all analog scanner support and migrated it to explicitly handle the digital scanners.  I then renamed this branch Dsctl.

Sctl and Dsctl Subversion and other downloads can also be found on their approriately located Source Forge project pages.

Preferred method of contact is by my email or the Dsctl Mailing List.  Discussion is available at the project's #sctl IRC channel on freenode.net.


2009.10.05:  Updated this page to reflect the fact I did branch Sctl into a DSctl (or digital scanner only branch).  Also will note, DSctl read functions are completed along with firmware read & write (at your own risk).  Write functions are written, but some have yet to be hooked into the user commands for usage.  If anybody has time, feel free to help connect the functions and test.  Also, I realize the code is simply written and migrating the functions to structs might be wise!  Since only one person has questioned about Linux support since I started writing DSctl, I lost interest and have moved onto other things. :-/
2007.06.15:  Completed making things use Forward Indexes for dumping System Index, System Info, Group Info, Channel Info when using "sctl dump".  Everything seems to be functioning well (aside from Uniden's manual being of draft quality rather versus something being proof read for readability).  You can checkout the svn version from this project's Source Forge site for the progress.
 Next on my agenda, formatting output of the dump command instead of just printing raw "answer" output as it includes the '\r' on line endings.  (I think these '\r' are read by the scanner h/w for formatting it's own display, but when we dump this data to a remote text file, they're a hassle to deal with & probably should be filtered on retreival.  So, I've tried to do this w/i parse_fields function.)  After I get prettier text output, I'll finish dumping the rest of the data, maybe segregating some of this into another function.  I've still to get SIF, TRN, TIN data as I've just figured it out.  Also, instead of just probing, I need to also use the forward & reverse index.
2007.06.07:  I've gotten to dumping channels today.  (For a complete dump, just additional  Site Info (SIF), Trunk Info (TRK), Talkgroup ID Info (TIN), etc.)  However, since I'm down to Channel Info, I should start thinking of dividing this new code into cleaner, more readable functions.  Also, need to think of CVS/SVN, especially if anybody else wants to chime in here.
2007.06.06:  WooHoo!  I've got the new parse_fields function (utils.c) working!  Now, "sctl dump" works... but it's messy as I haven't sorted the output.  And, I'm only walking the System & Group trees and not the channels yet.  Also, I'm seeing one bug where it's probing memory locations.  So, it will appear as nothing is happening for 2-5 minutes, but it will continue.
2007.06.05:  Argh!  I'm just posting what I got.  I started adding a new csv parser within utils.c (parse_fields).  My original do_parse funtion uses strtok, and strtok skips null values.  This isn't good as System & Group Info return embedded null values and will offset the field enumeration (and sscanf simple quits reading at the first site of NULL).  Almost there, but I'm stuck on copying a pointer to a (multidimensional?) array.  (Also fixed some other minor sytanx errors.)
2007.06.02:  I'm going to stop playing with the output of the status command for now.  The status & version commands work, but needs to output nicer readable text.  I have some ideas stenciled into humand_commands.c.  I want to concentrate on getting the "dump" command working for this unit.  Important notes are put in docs/bcd996t.txt!
2007.05.26:  Working (unformated output) commands are "status" and "version" commands.  I've also added a "do_parse" function for parsing the comma separated values from the BCD996T into an array called fields[].  The GLG (status) command demonstrates this function.

*Sctl is hard-coded to use 9600bps.  When using Sctl, set the your unit's Menu > Settings > Serial Port ... settings to use 9600BPS.  My patch will probably use 115200bps soon as it's much faster.  Just remember,  115200bps might be incompatible with an older device.


Day 1) After upgrading to firmware version 1.03.11, I lost connectivity with simply using Wine and the Uniden USAD software.  So, I had to learn to fooled QEMU Windows into thinking /dev/ttyUSB0 was a normal COM port.  For some reason, communication drops-out after awhile and I had a failed firmware upgrade on the first try.  The  firmware upgrade finally took after +10 tries.  I used the "-serial /dev/ttyUSB0" switch for QEMU as noted above.

The firmware version shipped with my BCD996T (version 1.02.01), I had no problems simply using WINE with the UASD software.  Communication was just fine and dandy, not too mention, the UASD software worked much better using Wine then using it in Windows!  Now, nothing but problems communicating with the unit with the software after the firmware upgrade.

I've already filed a bug on the WINE website.  Here's the output on stdout after Uniden's UASD software fails to communicate with the unit:

fixme:comm:set_queue_size insize 4096 outsize 4096 unimplemented stub
fixme:comm:GetCommProperties (0x88 0x34f954 )

Day 2) Basically, I have concluded it looks as if somebody within the Uniden employee community does not like the mct_u232 Serial to USB adapter.  For some reason, as of firmware version 1.03.11,  my "Serial to USB" adapter using the mct_u232 linux kernel driver has problems with the UASD, Wine, BCD996T combination.  (During the firmware upgrade using the USB to Serial adapter, the upgrade will fail and it took 10+ tries to get a successful firmware upgrade to take using a generic DB9 serial cable.)  I'm currently just using a generic DB9 serial cable until this bug is further resolved.  For reference, I've test this bug with Wine versions 0.9.30, 0.9.31 & 0.9.32

After further debugging, I've found the above Wine "fixme" debug output to be normal.  To include, it looks as if it's a speed related problem because the debug output from the serial to usb driver (mct_u232) shows wine communicating successfully with the unit but still an error code to is returned.  If some time, I'll post a debug.log.  If you have the mct_u232 serial to usb adapter, you can see for yourself by loading the module with:

# modprobe mct_u232 debug=1

Hopefully this page makes some sense as I'm just typing it in for all you Linux guys who just happen to have one of these units and are now in futility after a borked firmware upgrade!