-
Here's a follow-up.
I've integrated a do_parse function for parsing the comma separated values returned from the BCD996T (and BCD396T?) scanner.
Newer patches will be posted on my homepage dedicated for this development:
http://www.eskimo.com/~roger/programming/bcd996t.html
File Added: sctl-20070526.patch.
2007-05-26 22:29:48 UTC by roger-linux
-
After spending the day, think it's best to code a separate program for operating with the bcd*t series utilizing the base code of sctl.
Sctl is great code and easily read and it functions as it says it does. So why muck with something that works and make it more confusing.
2007-05-22 00:42:37 UTC by roger-linux
-
Guess what i could do is, use if/then/else to implement bcd396t/996t support.
Although messy, it is keeping support for all models within sctl rather then branching. And, it's a step in the right direction omitting having to rewrite the model specific commands into one central file... one step at a time. ;-)
2007-05-21 18:26:42 UTC by roger-linux
-
Just a quick note on BCD996T support, it looks like BCD996T support could be easily done because it looks like the communication protocols are basically the same as the earlier models. However, the BCD99T communication codes are 3 letters instead of two letters and use a completely different naming scheme ie. "SI" for bcd245xlt == "MDL" for bcd996t.
If I can get some help with structure...
2007-05-21 17:33:52 UTC by roger-linux
-
Logged In: YES
user_id=348797
Ok. This bug is fixed and closed with my bc245xlt scanner.
Thanks to most of the code already being written in
human_commands.c
I've implemented a check to exclude the bc245xlt and pro2052
scanners from getting the SG command and then using the WI
command to report the frequency data.
This bug appeared in both the idreport and sreport functions
of...
2005-04-09 21:40:58 UTC by roger-linux
-
Logged In: YES
user_id=348797
I've debugged some of this patch and it prevents sctl from
exiting abnormally by providing a check in two spots within
commands.c.
I get the following output now on an edacs system:
$ ./sctl idreport
ID report mode enabled
04/09 13:44:09 end ID: 000002
04/09 13:44:30 start ID: 000002 Freq: 0.0000 S:
04/09 13:44:38 end ID: 000002
04/09 13:44:39...
2005-04-09 20:57:52 UTC by roger-linux
-
Logged In: YES
user_id=348797
Wow! That's a five minute delay until post!
2005-04-08 21:24:29 UTC by roger-linux
-
Logged In: YES
user_id=348797
(I'm seeing no changes to this bug, so I'll reissue a
proposed patch to fix this bug.)
If you're using either a BC245* or PRO-2052, the "sctl
idreport" command should work without error now. I'm not in
a trunked area and cannot test for another day or so.
2005-04-08 21:23:16 UTC by roger-linux
-
Logged In: YES
user_id=348797
Here's a quick patch to check for model compatability before
issueing the SG command.
I'm not sure if it works yet as I'm not in a trunked area to
test the "sctl idreport" command.
If you're using a BC245* or PRO-2052 model, and "sctl
idreport" reports no errors, then it works.
(I'll be able to test this myself in the next day or so.)
2005-04-08 21:17:24 UTC by roger-linux
-
sctl-0.2.3 doesn't check for SG bc245 compatability.
$ sctl idreport
ID report mode enabled
04/06 20:46:24 end ID: 000002
*** Error: The command failed because an error
condition was returned.
Command: SG
Reply: ERR
This command is not support for the bc245 scanners (as
well as radio shacks PRO-2052).
Insert if/then or elseif code to check for these models
should surfice.
2005-04-07 03:53:57 UTC by roger-linux
