BCD436HP/BCD536HP: when is new firware coming

Status
Not open for further replies.

Voyager

Member
Joined
Nov 12, 2002
Messages
12,060
Or that some issue came up that was not easy to fix...

Or that they had merely 9 iterations with two being more significant fixes and the last 6 being minor (1.08.02 through 1.08.07).

But likely somewhere between 6 and 197. :D
 

trentbob

W3BUX- Bucks County, PA
Premium Subscriber
Joined
Feb 22, 2007
Messages
5,817
... mjs 438... if it did address LSM issues I would think they would say something in the announcement whether it really worked or not... I would be curious as to why your getting better performance now... there is nothing in these updates for the x36's that I'm interested in or would make a difference in my application... I had some hope they would address some of the major issues that really need to be addressed but not surprised to see they didn't... I don't use the x36's anymore because of the display issue and don't use any scanners at all now due to LSM... I need dependable performance for my job so I went the other route... so you say you're getting less missed transmissions with Philly with the recent update?... how about Camden P2 that has bad LSM... also check out the Bucks p2 going on line Oct 14th... that also has awful LSM with all scanners during the testing...
 

mjs438

Member
Joined
Sep 27, 2014
Messages
86
Location
Philadelphia, PA
Bob,

It may have been a false hope. At the time I updated the firmware,an unusual amount of fire and police traffic was occurring.. Realized it was several incidents in the area at once. Oh well a fellow can hope. I will continue monitor for improvement
 

mancow

Member
Database Admin
Joined
Feb 19, 2003
Messages
6,884
Location
N.E. Kansas
Or that some issue came up that was not easy to fix...

Or that they had merely 9 iterations with two being more significant fixes and the last 6 being minor (1.08.02 through 1.08.07).

But likely somewhere between 6 and 197. :D

Or they don't want to pay to continue development.
 

SOFA_KING

Member
Joined
Apr 25, 2004
Messages
1,581
Location
SE Florida
That's it? Really? After a lot of good suggestions and requests, that is all you did?

How pathetic. Not even a fix for the ever insistent "USB Cable Detected Select USB mode Mass Storage="E" Serial Port ="." " that hangs up your scanner forever without you even being aware of it.

One thing I can't stand about x36 scanners are those stupid "halt everything" interruptions or dumb questions it demands an answer to before it will do what I just told it to do. Just do it! And never hang up doing nothing forever until someone notices it is not receiving anything. Argh! :mad:

Phil
 

mjs438

Member
Joined
Sep 27, 2014
Messages
86
Location
Philadelphia, PA
bcd536hp

The issues you discribe I haven't experienced them.. If you can post more clarification so I can understand and determine if I have the same issues on my scanner.
 

mjs438

Member
Joined
Sep 27, 2014
Messages
86
Location
Philadelphia, PA
Trentbob,

I have read alot about the display issues on the BCD536hp which I have owned since Oct. 2014. Display is still bright and I have the scanner on for about 6-7 hours daily. Havent notice the problems reported.. Maybe I when I get older I will, I will be 63 soon. lol
 

trentbob

W3BUX- Bucks County, PA
Premium Subscriber
Joined
Feb 22, 2007
Messages
5,817
... the display issues where the display becomes so dim that you can't read it anymore only affects some radios and it is a matter of luck if you have the problem or not... when your spending that kind of money for a product then luck should be left in the casino... some accept the problem and rationalize excuses for Uniden (especially those who don't have the problem)... others see it as consumer fraud, especially since this far in Uniden has not addressed the problem and until recently didn't even acknowledge it... it does make the radio unusable in most professional applications so all these bells and whistles people are complaining about being missing don't matter if you can't see what you are monitoring... it has damaged Uniden's one time excellent reputation, not only for the faulty components, poor quality control, releasing faulty products without proper testing and R&D but for the lack of response recalling the radios and fixing the problem in a timely fashion... the financial condition of Uniden is ripe fodder for another thread but is what it is... if they go out of business they deserve it and have damaged their once excellent reputation... unfortunately they are the only game in town (don't expect anything from Whistler/ Rat Shack)... if anyone could serve us the best it would be Uniden but judging by this update I wouldn't hold your breath......
 

rbn_rr

Member
Joined
Feb 7, 2015
Messages
41
HELP! BCD436HP protocol changes & additions?

With Firmware Version 1.08.06, the handling of BCD436HP menus (the way menu data is sent to a computer connected via USB) has changed.

Previously the <GSI> or <PSI> commands would return no useful XML data while the scanner was displaying any menu -- just the typical 'OK' ACK to confirm that the scanner received the <GSI> or <PSI> command. In order to programmatically replicate what was being displayed on the scanner's display, it was necessary to issue an <STS> command and parse the return data.

With 1.08.06, while the scanner is displaying any menu the return XML data will include a <ScannerInfo.Mode> == 'Menu tree' and a <ScannerInfo.V_Screen> == either 'menu_selection' (for any menu with a sub-menu) or 'plain_text' (for any menu with no further navigation path other than BACK).

In the 'menu_selection' case, other returned data includes <MenuSummary.name> (the value of which is a string that matches the heading displayed on the scanner's screen) and <MenuSummary.index> (the value of which is an integer, likely an index to some definition of the menu selections.)

EXAMPLE 1
Scanner on "See Scanner Information" screen (which has sub-menu selections):
GSI,<XML>,
<?xml version="1.0" encoding="utf-8"?>
<ScannerInfo Mode="Menu tree" V_Screen="menu_selection">
<MenuSummary name="See Scanner Information" index="4293001180" />
<ViewDescription>
</ViewDescription>
</ScannerInfo>

EXAMPLE 2
Scanner on "Firmware Version" screen (which has no sub-menu selections):
<?xml version="1.0" encoding="utf-8"?>
<ScannerInfo Mode="Menu tree" V_Screen="plain_text">
<ViewDescription>
<PlainText Text="Firmware Version" />
<PlainText Text="Version 1.08.06 " />
<PlainText Text="SN37626048007560" />
<PlainText Text="SUM=156,M-Ver= 1" />
<PlainText />
<PlainText />
<PopupScreen Text="Firmware Version&#xD;Version 1.08.06 &#xD;SN37626048007560&#xD;SUM=156,M-Ver= 1&#xD;&#xD;">
<Button Text="&quot;E&quot; (OK)" KeyCode="E" />
</PopupScreen>
</ViewDescription>
</ScannerInfo>

I can 'fake' the previous (1.05.01) behavior by issuing an <STS> command whenever I get <ScannerInfo.V_Screen == 'Menu_selection'), but this seems a pretty backward way to do things (especially since <STS> seems to have been deprecated as of the Remote Command Specification Version 0.17.)

Is there an update to the Version 0.17 spec, in sync with the 1.08.06 Firmware update?

Also, the implementation of the XML for <PlainText> items displayed on the scanner screen seems sub-optimal...unlike multiple lines of <InfoArea> text fields during scanning (returned with unique identities, <InfoArea1.Text> and <InfoArea2.Text>), as shown in "Example 1" above multiple lines of text shown on the scanner screen are tagged with the same <PlainText.Text> attribute. My guess is the <PopupScreen.Text> is unpacked and used to populate the multiple <PlainText> fields (with '&#D;' terminating each line of text), and rather than numbering each newline (<PlainText.Text1> or <PlainText1.Text>, <PlainText.Text2> or <PlainText2.Text>, etc.) the same attribute <PlainText.Text> is used for each newline. I can fix this while I'm parsing the XML in my code, but it's annoying. Okay, I'll stop complaining now. :)

I'd like to update my code to handle menus the *proper* way with 1.08.06...so I appreciate any *pointers* on how to use the *index values*! :)

-rbn
 

SOFA_KING

Member
Joined
Apr 25, 2004
Messages
1,581
Location
SE Florida
The issues you discribe I haven't experienced them.. If you can post more clarification so I can understand and determine if I have the same issues on my scanner.

On the 436, if there is the slightest power interruption, like with poor contact issues that many cigar lighter plugs experience in a vehicle that has vibration, that will prompt the scanner to hold up everything and demand a response before scanning again. The prompt is triggered when there is a change in the USB connection as voltage was just applied, or reapplied. It basically asks if you want to program the radio or use it as normal with serial data as an option for programs like ProScan. As someone here suggested, a simple timeout for this prompt to default to Serial Mode would have solved the scan halting forever on this prompt, or until you notice you are not hearing anything and look down to see it is waiting for an answer.

The other annoying prompts are stupid questions like "Recording Started [date and time] Yes="E" / No="." ". I just gave it a command to start recording, so why ask me if I want to do it or not? Just freaking do it! I'm driving a car here, so I don't want to answer stupid questions and drive into a ditch looking for the buttons to push answering stupid questions! And it asks a bunch of those when you command it to do other tasks. Who came up with that Windows approach, where it assumes you are stupid, made a mistake issuing a command, and challenges you because it assumes you don't know what you are doing?

Bad interface design on the software. If they wanted to help someone who might have made a selection mistake, maybe allow the option in settings (that can be saved in config) to skip these prompts...or maybe better yet, give it 10 seconds for an answer (time to abort if you made a mistake) and do what was initially commanded. Simple!

I would also like to see the name of the favorite list I just quick keyed on or off display for a second or two so I know I selected the correct QK selection. That would be helpful.

It couldn't have been that hard for Uniden to take the suggestion and run with it, but they did nothing. Just a couple of bug fixes.

Phil
 

scanboyca

Member
Joined
Sep 12, 2014
Messages
56
PSI XML incomplete?

In the 'menu_selection' case, other returned data includes <MenuSummary.name> (the value of which is a string that matches the heading displayed on the scanner's screen) and <MenuSummary.index> (the value of which is an integer, likely an index to some definition of the menu selections.)

I am seeing the same behavior in the remote PSI response syntax. It seems like the response is not fully formed. I would think the XML response would include elements for each item in the current menu tree along with an attribute indicating which item is currently highlighted. I don't see how Uniden plans to virtualize the scanner menu system given the current PSI syntax.

The parsing of XML sibling elements with the same name is relatively easy and supported by XML parsing libraries like pugi. I had this same challenge when parsing the "Button" elements in the "Popup" element :)

I am hoping Uniden will post an update to the remote control spec soon for this latest firmware. The currently posted version 0.17 is really poor.
 
Status
Not open for further replies.
Top