Uniden's BCD996T and
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)
(DSctl is usable and almost completed -- See my notes within
the Sctl/DSctl section.)
Using QEMU with Windows
Patching SCTL or Using
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
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
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"
(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.)
(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
Make a symlink from ~/.wine/dosdevices/com# to your tty device file
for the Uniden unit. (ie. /home/roger/.wine/dosdevices/com3
$ ln -s /dev/ttyUSB0
(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
(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
Patching SCTL or using
(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
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.
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. :-/
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.
2007.06.08: 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.
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.
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.
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!
(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
*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:
insize 4096 outsize 4096 unimplemented stub
(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
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!