[chirp_devel] [uv-b5] unexpected response (or: these are not the ACKs you are looking for)
http://chirp.danplanet.com/issues/1263
I am able to reproduce this unexpected response issue about 1 in 3 or 4 times. My "unexpected" ack is 0x48, and other times the expected 0x78.
I think it might have been Jim that was looking at this oddity a while back.
Do we know why this damned radio has M.A.D (multiple ack disorder)?
ACKs must mean something significant, right!?
My deviant, hackish thought was to just grab the first ack the radio gives back and use it for the rest of the session, with the thought that as long as the ack was consistent throughout that transfer session, it would likely be a good download.
Thoughts?
-Jens
On Sat, Nov 23, 2013 at 1:49 AM, Jens J. kd4tjx@yahoo.com wrote:
http://chirp.danplanet.com/issues/1263
I am able to reproduce this unexpected response issue about 1 in 3 or 4 times. My "unexpected" ack is 0x48, and other times the expected 0x78.
Are you getting this from multiple 'reads' from the radio with no settings changes? My experience has been that the ACK value changes based on values selected for certain settings. Once the setting is changed, the ACK value is consistent.
I think it might have been Jim that was looking at this oddity a while back.
Yes. It drove me nuts until I realized that changing a setting would/could change the ACK returned.
Do we know why this damned radio has M.A.D (multiple ack disorder)?
M.A.D. I like that. This is just another in the list of bugs this radio family (UV-B5/UV-B6) has.
ACKs must mean something significant, right!?
I doubt it. I assume that the Baofeng software always works no matter what the ACK value is only because it ignores them.
My deviant, hackish thought was to just grab the first ack the radio gives back and use it for the rest of the session, with the thought that as long as the ack was consistent throughout that transfer session, it would likely be a good download.
Dan and I discussed what you suggest above when this issue first became apparent. It was decided to make a short list and see if it stabilized (which it seemed to have).
Thoughts?
I think I will just add "0x48" to the list and see what happens.
-Jens
Jim
Yeah, it would randomly choose to be 0x48 or 0x78 sort of randomly. I could download 4x in a row, without changing anything on the radio, and it would be 0x78 twice and 0x48 twice, or any other combination. It's definitely one of the weird things about this radio.
________________________________ From: Jim Unroe rock.unroe@gmail.com To: Jens J. kd4tjx@yahoo.com; chirp_devel@intrepid.danplanet.com Sent: Saturday, November 23, 2013 8:44 AM Subject: Re: [chirp_devel] [uv-b5] unexpected response (or: these are not the ACKs you are looking for)
On Sat, Nov 23, 2013 at 1:49 AM, Jens J. kd4tjx@yahoo.com wrote:
http://chirp.danplanet.com/issues/1263
I am able to reproduce this unexpected response issue about 1 in 3 or 4 times. My "unexpected" ack is 0x48, and other times the expected 0x78.
Are you getting this from multiple 'reads' from the radio with no settings changes? My experience has been that the ACK value changes based on values selected for certain settings. Once the setting is changed, the ACK value is consistent.
I think it might have been Jim that was looking at this oddity a while back.
Yes. It drove me nuts until I realized that changing a setting would/could change the ACK returned.
Do we know why this damned radio has M.A.D (multiple ack disorder)?
M.A.D. I like that. This is just another in the list of bugs this radio family (UV-B5/UV-B6) has.
ACKs must mean something significant, right!?
I doubt it. I assume that the Baofeng software always works no matter what the ACK value is only because it ignores them.
My deviant, hackish thought was to just grab the first ack the radio gives back and use it for the rest of the session, with the thought that as long as the ack was consistent throughout that transfer session, it would likely be a good download.
Dan and I discussed what you suggest above when this issue first became apparent. It was decided to make a short list and see if it stabilized (which it seemed to have).
Thoughts?
I think I will just add "0x48" to the list and see what happens.
-Jens
Jim
participants (2)
-
Jens J. -
Jim Unroe