Now attached to SDS100FirmwareUpdates < UnidenMan4 < TWiki
SDS100/SDS200: SDS100 Protocol Docs
- Thread starter UPMan
- Start date
- Status
Hello,
Thanks for providing the Docs.
73 Eric
Thanks for providing the Docs.
73 Eric
Fantastic...thanks much for getting the Command Protocol docs to us, UPMan!
A question for UPMan, or for anyone else who actually knows the answer to this...is there a "right way" / "right place" to ask questions (with the hope of getting answers!) about the Command Protocol, sub-processor behaviour, etc? At present, questions and chatter are spread across various RR forum threads.
-rbn
A question for UPMan, or for anyone else who actually knows the answer to this...is there a "right way" / "right place" to ask questions (with the hope of getting answers!) about the Command Protocol, sub-processor behaviour, etc? At present, questions and chatter are spread across various RR forum threads.
-rbn
Note that the protocol is released without official support. I've never used the protocol for anything other than very basic things in hyperterm mode. That said, community support can be helpful.
interesting
Things that make you go hmmmmmmmm...
The question is, is this a subtle but intentional leak, an unintentional leak, or a red herring to stir up the great unwashed for someone's amusement?
I guess we'll know if UPMan changes his avatar.
Well played, Mr. Opitz. Well played.
So then it is not really 'protocol'. Look up the definition of protocol. If it is not official, then it is not protocol.
It is an official Uniden company internal protocol that Uniden has graciously shared with the public, has but without support.
W4ELL and Steve,
OK, but I am still lost as to how an official document cannot be supported just by the very definition of a protocol. Are you saying it is just not supported here or outside of Uniden (that is, they will not respond to comments)? That I can certainly understand, but it was not made clear.
OK, but I am still lost as to how an official document cannot be supported just by the very definition of a protocol. Are you saying it is just not supported here or outside of Uniden (that is, they will not respond to comments)? That I can certainly understand, but it was not made clear.
It's not that difficult. Uniden is making public the serial protocol data you need if you want to write a remote control program like ProScan. But it's your responsibility to figure it out if you choose to do so, Uniden isn't offering any assistance beyond providing the document.
Yes, I believe that was the intention.
The protocol docs do not pertain to a firmware update or reception issues, they are the data you need if you want to operate the scanner remotely, a la ProScan. If you believe you are having trouble with a firmware bug, make sure you are running the current firmware, record a debug log (hold avoid during power-on, and set debug log to SD Card in the Options menu), and post the log and a description of the problem you are experiencing in the firmware discussion thread.
https://forums.radioreference.com/u...7-sds100-firmware-1-03-01-public-release.html
That will help the firmware engineers figure out what is going wrong and fix the problem.
My 2 cents...
Great suggestion!
I cruised over to dictionary.com and looked up "protocol" -- and among the 8 definitions listed, the 7th seems to relevant here as it's the definition tagged as applying to 'computers':
I view the Uniden Command Specification as essentially, "Here's a high-level description of ways you can exchange messages with your scanner. You should be able to use this to communicate with your scanner interactively or programmatically. You're pretty much on your own beyond this point. Have fun!" Popular software like ProScan makes use of the command protocol Uniden exposes to greatly expand the capabilities of Uniden's scanners.
It's fairly common for libraries, APIs (Application Programming Interfaces)/SDKs (Software Development Kits), etc. as well as any associated documentation to be provided "as-is" with no expressed guarantee, warrantee or likelihood that future versions will match the current code or any specification regarding that code. If you find a bug in the code, or if there's something documented incorrectly or undocumented, the vendor is under no obligation to help you out.
As johnweinke said elsewhere in this thread, "The scanner thinks it's official, regardless of whether there is offical support offered by Uniden." I think of this as, "the code is going to do what the code is going to do -- it's code. Hopefully the documentation accurately describes the communication protocol enshrined in the code." I think it's a better use of Uniden's firmware developer(s) in Japan to be improving and expanding the firmware than to be providing "official support" for the command protocol, and I think it would be extremely unreasonable if not impossible for Uniden to provide a EULA (End-User Licence Agreement) asserting that the Command Specification docs accurately and exhaustively document each firmware release. "Unofficial" beats "unavailable" by a long shot in my book.
So...as someone who uses the Command Protocol for the BCD-x36HP (and now the STS100) fairly extensively, I very much appreciate the "best efforts" of Uniden (and specifically UPMan) to make the "internal" specs available for our "external" use. I find that it's one way that Uniden distinguishes itself from the competition -- probably helps to explain why I own 6 BCD-436HPs, one BCD-536HP and one SDS-100 (plus 2 HP-2's and 4 HP-1's) but only one each of Whistler's TRX-1 and TRX-2. The Whistlers are fine radios, but if I'm not able to programmatically extend their capabilities (the way I can and do with the Unidens) they tend to sit idle.
-rbn
Great suggestion!
I cruised over to dictionary.com and looked up "protocol" -- and among the 8 definitions listed, the 7th seems to relevant here as it's the definition tagged as applying to 'computers':
www.dictionary.com said:
I view the Uniden Command Specification as essentially, "Here's a high-level description of ways you can exchange messages with your scanner. You should be able to use this to communicate with your scanner interactively or programmatically. You're pretty much on your own beyond this point. Have fun!" Popular software like ProScan makes use of the command protocol Uniden exposes to greatly expand the capabilities of Uniden's scanners.
It's fairly common for libraries, APIs (Application Programming Interfaces)/SDKs (Software Development Kits), etc. as well as any associated documentation to be provided "as-is" with no expressed guarantee, warrantee or likelihood that future versions will match the current code or any specification regarding that code. If you find a bug in the code, or if there's something documented incorrectly or undocumented, the vendor is under no obligation to help you out.
As johnweinke said elsewhere in this thread, "The scanner thinks it's official, regardless of whether there is offical support offered by Uniden." I think of this as, "the code is going to do what the code is going to do -- it's code. Hopefully the documentation accurately describes the communication protocol enshrined in the code." I think it's a better use of Uniden's firmware developer(s) in Japan to be improving and expanding the firmware than to be providing "official support" for the command protocol, and I think it would be extremely unreasonable if not impossible for Uniden to provide a EULA (End-User Licence Agreement) asserting that the Command Specification docs accurately and exhaustively document each firmware release. "Unofficial" beats "unavailable" by a long shot in my book.
So...as someone who uses the Command Protocol for the BCD-x36HP (and now the STS100) fairly extensively, I very much appreciate the "best efforts" of Uniden (and specifically UPMan) to make the "internal" specs available for our "external" use. I find that it's one way that Uniden distinguishes itself from the competition -- probably helps to explain why I own 6 BCD-436HPs, one BCD-536HP and one SDS-100 (plus 2 HP-2's and 4 HP-1's) but only one each of Whistler's TRX-1 and TRX-2. The Whistlers are fine radios, but if I'm not able to programmatically extend their capabilities (the way I can and do with the Unidens) they tend to sit idle.
-rbn
Commands missing from latest Uniden spec
A quick search (running through all 3-letter possible commands from "AAA" to "ZZZ", including 9 uppercase/lowercase variations of each command) yields 63 commands (out of 26x26x26x9 == 158184 possibilities) that seem to be active (that is, the radio seems to ACK the command in some way, returning something other than "ERR<0D>" (or, in a few cases, returning _nothing_.)
27 of those commands are documented in the latest Command Specification thankfully "leaked" by UPMan and are not included in the list below.
36 of the "seemingly valid" codes do not appear in the "SDS100 (UB383Z) Remote Command Specification" Version 0.01 2018/04/13" doc. Some of them sound familiar to commands previously available in the 396XT or elsewhere (I'll have to go back and check these).
Here's a list of the "not yet documented" commands I was able to find:
If you discover anything about any of these commands, or if you discover others I may have missed, please share your discoveries here!
-rbn
A quick search (running through all 3-letter possible commands from "AAA" to "ZZZ", including 9 uppercase/lowercase variations of each command) yields 63 commands (out of 26x26x26x9 == 158184 possibilities) that seem to be active (that is, the radio seems to ACK the command in some way, returning something other than "ERR<0D>" (or, in a few cases, returning _nothing_.)
27 of those commands are documented in the latest Command Specification thankfully "leaked" by UPMan and are not included in the list below.
36 of the "seemingly valid" codes do not appear in the "SDS100 (UB383Z) Remote Command Specification" Version 0.01 2018/04/13" doc. Some of them sound familiar to commands previously available in the 396XT or elsewhere (I'll have to go back and check these).
Here's a list of the "not yet documented" commands I was able to find:
Code:
Starting BCDx36HP Command Sieve, 3-character commands ranging from [A] to [Z]
(9 case variations/command)
Scanner Under Test: SDS100 (ESN 383260880*****, Firmware Version: Version 1.03.01)
Active Commands not listed in the "SDS100 (UB383Z) Remote Command Specification
Version 0.01 2018/04/13."
Note that "active" is not the same as "useful", and that just because you
CAN do something doesn't mean you SHOULD...
use these carefully and cautiously and at your own risk!
ALV
AUF
cdb
cdc
cds
cli
crg
DIR
DLC
ESN Get Scanner's ESN (ESN,383260880*****,107,1<0D>)
esn Get Scanner's ESN (esn,383260880*****<0D>)
FPR
FRX Receive File?
FTX Transmit File?
GLG GLG,0156.2100,FM,0,97,Santa Clara,Santa Clara County - Sheriff,Primary,0,1,,,NONE<0D>
MSM Puts SDS100 in Mass-Storage Mode
pas
PRG "Remote Mode" / "Keypad Lock"
PWR
QKS
RBS
rbt
RBW
rdc 04602750, 04602750,FIR2=20989, Noise=28318, DA=320,595, 4240854
RMT RMT<09>ERR<09>494<0D>
sdc NO RETURN DATA -- interface "goes deaf" after this command
SDR Enters SDR demo/placehold visualisation
SQL Get/Set Squelch
SQV
SSC
SUS NO RETURN DATA
TST
UDP
UHC
VOL Get/Set Volume
WIN WIN,36,04602750If you discover anything about any of these commands, or if you discover others I may have missed, please share your discoveries here!
-rbn
- Status
Similar threads
