Uniden Development (Attn: Stephane Fillod)

I'm seeing some dev work via mailing list done back in May 2008.

I have bc245xlt & bcd996t units.

I picked up development on Sctl and forked it into DSctl, adding support
for the bcd996t (& bcd396t).  (DSctl currently can dump the unit's data
over 30% faster then the Uniden software can -- I optimized by not using
the next_address -- saving the unit from an extra cpu cycle or two 
However, haven't done much else with DSctl due to no interest and it can
only dump (read) the data and little has been done for writing except
completing header functions for implementing writing to the unit.

I've yet to look back into the uniden.h/uniden.c files for hamlib, and
wonder what interest, if any, are there for including code into hamlib.
In other words, merging sctl and dsctl code into hamlib?

--

-- 
Roger
http://www.eskimo.com/~roger/index.html

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Uniden Development

Hi Roger,

Thank you for your interest in the Uniden backend.

roger skribis:
> I'm seeing some dev work via mailing list done back in May 2008.

Indeed, Jarrod asked for some support for the Radio Shack PRO-2052 (same
protocol as other Uniden scanners), so I did some work on it,
plus BC250D, BC895xlt, BC245, BC780xlt which are similar. I don't know 
whether he succeeded in fixing his hardware problem, but in the end,
the backend is still untested 

> I have bc245xlt & bcd996t units.

The bc245xlt backend should work. Some serious testing will be needed.
Would you like to help? You can start with the nightly snapshot[1] 
or the CVS repository is you're comfortable with.

The unitary testing is done using rigctl command. Read the file
README.betatester for more information. Commands expected to work
are: _, f, F, m, M (put 0 as the bandwidth), e, E, 1, h. Please report
to the list with full traces (max verbosity). You may try also 
any other Hamlib supported program (grig[2] for example).

[1] http://hamlib.sourceforge.net/bleeding-edge/
[2] http://groundstation.sourceforge.net/grig/

> I picked up development on Sctl and forked it into DSctl, adding support
> for the bcd996t (& bcd396t).  (DSctl currently can dump the unit's data

Re: Uniden Development

On Sun, 2008-10-05 at 23:10 +0200, Stephane Fillod wrote:
> Hi Roger,
> 
> Thank you for your interest in the Uniden backend.
> 
> roger skribis:
> > I'm seeing some dev work via mailing list done back in May 2008.
> 
> Indeed, Jarrod asked for some support for the Radio Shack PRO-2052 (same
> protocol as other Uniden scanners), so I did some work on it,
> plus BC250D, BC895xlt, BC245, BC780xlt which are similar. I don't know 
> whether he succeeded in fixing his hardware problem, but in the end,
> the backend is still untested 

Well, pushing "Test the backend changes" to the top of my winter TODO
list here.

> 
> > I have bc245xlt & bcd996t units.
> 
> The bc245xlt backend should work. Some serious testing will be needed.
> Would you like to help? You can start with the nightly snapshot[1] 
> or the CVS repository is you're comfortable with.

My CVS skills are a bit rusty... I like svn for pushing diffs. lol 

> The unitary testing is done using rigctl command. Read the file
> README.betatester for more information. Commands expected to work
> are: _, f, F, m, M (put 0 as the bandwidth), e, E, 1, h. Please report
> to the list with full traces (max verbosity). You may try also 

Re: Uniden Development

On Sun, 2008-10-05 at 22:00 -0800, roger wrote:
> On Sun, 2008-10-05 at 23:10 +0200, Stephane Fillod wrote:

> > The unitary testing is done using rigctl command. Read the file
> > README.betatester for more information. Commands expected to work
> > are: _, f, F, m, M (put 0 as the bandwidth), e, E, 1, h. Please report
> > to the list with full traces (max verbosity). You may try also 
> > any other Hamlib supported program (grig[2] for example).

Just glanced into the uniden.c, and *gladly*, I should be able to easily
trace the code... or implement bcd396t/bcd996t protocol.

Remembering, instead of two letter codes for the old analog uniden
scanners, they are now three letter.  There's one other little
modification needed for reading or writing to the unit... but can't
remember it off hand.  But I'll figure it out soon enough. 

Can I submit patches simply by posting to the mailing list with PATCH
w/i the subject?  (As far as CVS write access, I feel just fine & dandy
with only editing wiki pages.)

--

-- 
Roger
http://www.eskimo.com/~roger/index.html

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world

Initial Testing: Uniden BC245XLT

A *BIG* Thanks to the person who documented their variable definitions
at the top of uniden.c!!!

Just screwing around here.  My main interest is tracing the code and
examining how uniden.c handles the status command ("SI\r"), along with
the OK, NG & ERR responses (and then working to get something into the
tree for the BCD996T/BCD396T scanners).

Ok... so on with playing with the BC245XLT and current CVS rigctl.

>From Stephans email, I tried each of the commands he stated were
working.  If the output appeared good, I ignored providing strace
output.  Each command executed is divided by a double space.  Some notes
and guesses provided after scanning some of the uniden.c code.

----

I just tried using rigctl without "-s 9600".  I believe there's code in
uniden.c that tries to autonegotiate speed? (See line #636 of uniden.c -
Probe
how?  Or is it automagically done when speed is not specified?)

$ ./rigctl -r /dev/ttyS0 -m 802 _
read_string: timedout without reading a character
read_string: timedout without reading a character
read_string: timedout without reading a character
read_string: timedout without reading a character
None

open("/dev/ttyS0", O_RDWR|O_NOCTTY|O_NONBLOCK) = 3

New Scanner Import: Uniden BCD996T

A *BIG* Thanks to the person who documented their variable definitions
at the top of uniden.c!  This really helped when reading the code.

The bcd396t & bcd996t digital models use 3 letter codes along with some
varied responses, etc.  (Overall, still very similar to previous analog
uniden scanners, but also still needing some slight communication
modifications.  ... Don't ask me the specifics, I haven't reread my code
yet!)

There are a *lot* of scanner commands & functions to write for these
digital scanners and I don't think I should continue writing on top of
what's already in the uniden.h/uniden.c files.  (Trust me, this is the
main reason I forked sctl to dsctl and cut out all the analog scanner
stuff to concentrate on just the digital scanner.  I figured, once
completed, I would then re-emerge, or something.)

Anyways...

Recommendations?  Should I just focus on a separate bcd996t.h/bcd996t.c
files for the time being... just to get the initial status command for
the scanner completed, etc?? 

In the long run, uniden_analog.h/.c and uniden_digital.h/.c ... or
similar?

BC780, BC245XLT, BC250D, BC895, BC235XLT, BC785, BC786D, PRO2052,
BCT8 ... seem to be all supported by uniden.h/uniden.c and I believe all
use 2 letter commands.

Newer dynamic memory uniden digital apco scanners:

Re: Initial Testing: Uniden BC245XLT

On Monday 06 October 2008 06:03:30 roger wrote:

> I just tried using rigctl without "-s 9600".  I believe there's code in
> uniden.c that tries to autonegotiate speed? (See line #636 of uniden.c -
> Probe
> how?  Or is it automagically done when speed is not specified?)

If the backend provides a maximum serial rate value that differs from the 
minimum serial rate, then Hamlib will try the maximum rate unless another 
rate is given to rigctl (I'm not sure if that's rigctl specific or happens 
when any program sets up the serial port).

73, de Nate >>

--

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://n0nb.us/index.html

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Initial Testing: Uniden BC245XLT

roger skribis:
> A *BIG* Thanks to the person who documented their variable definitions
> at the top of uniden.c!!!

Sorry, the variable definitions (uniden_id_string_list/uniden_{ctcss,dcs}_list)
are not documented, but you can ignore them for now. However, the
function uniden_transaction() is documented. This very important
because it makes command easier to implement.

> Just screwing around here.  My main interest is tracing the code and
> examining how uniden.c handles the status command ("SI\r"), along with
> the OK, NG & ERR responses (and then working to get something into the
> tree for the BCD996T/BCD396T scanners).
> 
> Ok... so on with playing with the BC245XLT and current CVS rigctl.
> 
> >From Stephans email, I tried each of the commands he stated were
> working.  If the output appeared good, I ignored providing strace
> output.  Each command executed is divided by a double space.  Some notes
> and guesses provided after scanning some of the uniden.c code.

Don't forget to pass the "-vvvvv" argument to rigctl. This will bring
you all kind of traces, including the protocol traces over the serial
line, much easier to read than strace 

FYI, rigctl can also be used in an interactive way. Simply don't pass
any rigctl command on the command line, simply "./rigctl -s 9600 -r /dev/ttyS0 -m 802 -vvvvv"
in your case. Then, you get a prompt and can play with the radio.
The ? command list all the possible commands, but not all of them
may (yet) be implemented for your backend. Enter 'q' in order

Re: Initial Testing: Uniden BC245XLT

On Mon, 2008-10-06 at 21:10 +0200, Stephane Fillod wrote:

> Don't forget to pass the "-vvvvv" argument to rigctl. This will bring
> you all kind of traces, including the protocol traces over the serial
> line, much easier to read than strace 

oh.  missed this in "help" / ? ... figured I was.

> > I just tried using rigctl without "-s 9600".  I believe there's code in
> > uniden.c that tries to autonegotiate speed? (See line #636 of uniden.c -
> > Probe
> > how?  Or is it automagically done when speed is not specified?)
> 
> Like Nate said, the higher speed is selected. The min and max are 
> useful to check validity of user specified baud rate.
> BTW, does the (analog) Uniden models always startup at 9600 bauds,
> and then shall be instructed to go higher speed? Or is it auto-baud?
> User specified on the rig panel?

I believe the bc245xlt, is default to 9600.  I'm pretty darn positive on
this from all the testing for the past 5+ years. 

It can also be configured for 2400, 4800, 9600, 19200.

Curious, the code does time-out the serial connection after trying with
a command.  Why not just push a command with a range of speeds to the
scanner, until "OK" is returned?

(I'm also guessing the range of speeds can be manually entered into the
code as well... but, I still have much reading & tracing to do yet!

Re: New Scanner Import: Uniden BCD996T

On Mon, 2008-10-06 at 02:57 -0800, roger wrote:
> Recommendations?  Should I just focus on a separate bcd996t.h/bcd996t.c
> files for the time being... just to get the initial status command for
> the scanner completed, etc?? 

I'll answer my own thread here for historical ref.

I'm just going to focus on getting the STATUS command into a bcd996t.c
file for now.  Maybe one or two other commands as it usually goes.

It'll be a month or two before I really need to find the solution...
probably will find it from looking at others code in hamlib.

--

-- 
Roger
http://www.eskimo.com/~roger/index.html

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/