[chirp_devel] [h777] Fix some settings not taking effect on Baofeng 888 and variants
There are plenty of issues related to settings not "sticking" or taking effect for Baofeng 888 and derivative radios. I experienced this personally on a Radioddity GA-2S.
Changes based on serial capture of Baofeng "V12" programming software. Many thanks to Dan Clemmensen's notes on easy Linux serial capture.
Tony
---
# HG changeset patch # User Tony F goldstar611@hotmail.com # Date 1566262713 18000 # Mon Aug 19 19:58:33 2019 -0500 # Branch issue_6969 # Node ID e8b99ab1ca358bbe25a662b02a7006cd292e0bf9 # Parent 1da5155c550477777c021fd6fbaf5036f0b0b5c0 [h777] Fix some settings not taking effect on Baofeng 888 and variants Fix #6969 https://chirp.danplanet.com/issues/6969 Changes based on serial output of latest "V12" programming software List of settings that were affected: - Scan On/Off - Voice Prompt On/Off - Language English/Chinese - Vox On/Off - Vox Level - Vox Inhibit on Rx (Untested) - Alarm On/Off - Radio On/Off (Untested) - Low Voltage Inhibit (Untested) - High Voltage Inhibit (Untested)
To the best of my knowledge, also Fixes #5027 Fixes #5985 Fixes #6283 Fixes #4959 Fixes #5153 Fixes #5343 Fixes #5797 Fixes #5833 Fixes #5831 Fixes #5857
diff --git a/chirp/drivers/h777.py b/chirp/drivers/h777.py --- a/chirp/drivers/h777.py +++ b/chirp/drivers/h777.py @@ -166,7 +166,10 @@ def _h777_write_block(radio, block_addr, block_size): serial = radio.pipe
- cmd = struct.pack(">cHb", 'W', block_addr, BLOCK_SIZE) + if 0x02B0 <= block_addr <= 0x02C0: + cmd = struct.pack(">cHb", 'Y', block_addr, BLOCK_SIZE) + else: + cmd = struct.pack(">cHb", 'W', block_addr, BLOCK_SIZE) data = radio.get_mmap()[block_addr:block_addr + 8]
LOG.debug("Writing Data:") @@ -281,8 +284,8 @@
_ranges = [ (0x0000, 0x0110), + (0x0380, 0x03E0), (0x02B0, 0x02C0), - (0x0380, 0x03E0), ] _memsize = 0x03E0 _has_fm = True
There are plenty of issues related to settings not "sticking" or taking effect for Baofeng 888 and derivative radios. I experienced this personally on a Radioddity GA-2S.
Changes based on serial capture of Baofeng "V12" programming software. Many thanks to Dan Clemmensen's notes on easy Linux serial capture.
Hmm, I've set several of these on my BF-888 clones and not had a problem. As such I'm a little reluctant to apply this, being concerned that maybe we have a variant out there and that applying this to fix half of them will break the others.
diff --git a/chirp/drivers/h777.py b/chirp/drivers/h777.py --- a/chirp/drivers/h777.py +++ b/chirp/drivers/h777.py @@ -166,7 +166,10 @@ def _h777_write_block(radio, block_addr, block_size): serial = radio.pipe
- cmd = struct.pack(">cHb", 'W', block_addr, BLOCK_SIZE)
- if 0x02B0 <= block_addr <= 0x02C0:
cmd = struct.pack(">cHb", 'Y', block_addr, BLOCK_SIZE)- else:
cmd = struct.pack(">cHb", 'W', block_addr, BLOCK_SIZE)
Your assertion is that between these ranges we have to use a different command, but with the same sized block? I've seen cases where we use W for low blocks and then something else (like X) for upper blocks of a larger size. It seems really weird to have a hole in the middle of the range where we switch from W to Y and then back again...
@@ -281,8 +284,8 @@
_ranges = [ (0x0000, 0x0110),
(0x0380, 0x03E0), (0x02B0, 0x02C0),
(0x0380, 0x03E0),
This also seems weird to me. It writes the low range, jumps to the upper, and then back to the middle? That seems quite illogical.
I guess I need to test this with some of my examples here, but maybe you can provide some more discussion about how you came across this, what all you tested it with, and why you think it matters?
--Dan
Hi Dan,
I have another datapoint, external to CHIRP and Radioddity. miklor.com has 2 software versions listed that can program the BF-888 class radio. One version is listed as "BF-888S v1.05" and the other is listed as "ZT-V68 2007"
- The "v1.05" software writes the data blocks in the same order as CHIRP, also using only the "W" commands. - The "ZT-V68" software, writes the data blocks in a different order than CHIRP (as reflected by my patch) and uses a "Y" command for those middle blocks.
I found through testing that: - The "Y" command is not strictly necessary. - Using all "W" commands works, as long as the order (_ranges variable in h777.py) is updated (as seen in my patch). - Using the "Y" commands with the original order (unmodified _ranges variable) does not work.
Additional comments are in line,
Tony
On Tue, 2019-08-20 at 18:01 -0700, Dan Smith via chirp_devel wrote:
There are plenty of issues related to settings not "sticking" or taking effect for Baofeng 888 and derivative radios. I experienced this personally on a Radioddity GA-2S.
Changes based on serial capture of Baofeng "V12" programming software. Many thanks to Dan Clemmensen's notes on easy Linux serial capture.
Hmm, I've set several of these on my BF-888 clones and not had a problem. As such I'm a little reluctant to apply this, being concerned that maybe we have a variant out there and that applying this to fix half of them will break the others.
Agreed. I would love to get more feedback. I've tested the changes on my older Baofeng 777S radios but my "collection" is quite small.
diff --git a/chirp/drivers/h777.py b/chirp/drivers/h777.py --- a/chirp/drivers/h777.py +++ b/chirp/drivers/h777.py @@ -166,7 +166,10 @@ def _h777_write_block(radio, block_addr, block_size): serial = radio.pipe
- cmd = struct.pack(">cHb", 'W', block_addr, BLOCK_SIZE)
- if 0x02B0 <= block_addr <= 0x02C0:
cmd = struct.pack(">cHb", 'Y', block_addr, BLOCK_SIZE)- else:
cmd = struct.pack(">cHb", 'W', block_addr, BLOCK_SIZE)Your assertion is that between these ranges we have to use a different command, but with the same sized block? I've seen cases where we use W for low blocks and then something else (like X) for upper blocks of a larger size. It seems really weird to have a hole in the middle of the range where we switch from W to Y and then back again...
This is where your intuition is much much greater than mine. My goal was pretty narrow since my background is close to nil, only trying to match the serial output of CHIRP to the working software. This is in fact what I observed: 57 02 B0 08 00 01 00 00 04 00 01 01 00 00 00 00 57 02 B8 08 00 01 FF FF FF FF FF FF 00 00 00 00
vs
59 02 B0 08 00 01 00 00 04 00 01 01 00 00 00 00 59 02 B8 08 00 01 FF FF FF FF FF FF 00 00 00 00
@@ -281,8 +284,8 @@
_ranges = [ (0x0000, 0x0110),
(0x0380, 0x03E0), (0x02B0, 0x02C0),
(0x0380, 0x03E0),This also seems weird to me. It writes the low range, jumps to the upper, and then back to the middle? That seems quite illogical.
Also agreed. Observation is documented in the issue I opened at https://chirp.danplanet.com/issues/6969
I guess I need to test this with some of my examples here, but maybe you can provide some more discussion about how you came across this,
CHIRP was listed as "supported" by the manufacturer (Radioddity) but did not update some settings at all.
what all you tested it with, and
Newly purchased Radioddity GA-2S and a much older Baofeng 777S (https://chirp.danplanet.com/attachments/4983/old_baofeng_888.jpg)
why you think it matters?
It's still an issue, someone posted yesterday about 888 settings not sticking. https://chirp.danplanet.com/issues/6997
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
I have another datapoint, external to CHIRP and Radioddity. miklor.com has 2 software versions listed that can program the BF-888 class radio. One version is listed as "BF-888S v1.05" and the other is listed as "ZT-V68 2007"
- The "v1.05" software writes the data blocks in the same order as CHIRP, also using only the "W" commands.
- The "ZT-V68" software, writes the data blocks in a different order than CHIRP (as reflected by my patch) and uses a "Y" command for those middle blocks.
I found through testing that:
- The "Y" command is not strictly necessary.
- Using all "W" commands works, as long as the order (_ranges variable in h777.py) is updated (as seen in my patch).
- Using the "Y" commands with the original order (unmodified _ranges variable) does not work.
Okay, so your suggestion is now to just change the ranges and not use the different command at all, correct?
Hmm, I've set several of these on my BF-888 clones and not had a problem. As such I'm a little reluctant to apply this, being concerned that maybe we have a variant out there and that applying this to fix half of them will break the others.
Agreed. I would love to get more feedback. I've tested the changes on my older Baofeng 777S radios but my "collection" is quite small.
Well, my collection isn't that large, but it turns out I'm a bit full of it anyway. In testing, I realized I too am unable to turn off the little chinese lady in my clones with the driver as it is in-tree, but can with your patch (which seems to work fine). Mine are only a couple years old at the most. I'm still worried about breaking older models, mind you, but I don't see to have any of those.
This is where your intuition is much much greater than mine.
Well, my intuition tells me that, if anything, the command should matter and the order of the ranges should not (or at least doing them in non-sequential order would not be better). So... :)
why you think it matters?
It's still an issue, someone posted yesterday about 888 settings not sticking. https://chirp.danplanet.com/issues/6997
I meant why you think the range order matters, not why you think we should fix bugs, but...thanks :D
So, answer my question above about trimming the patch to just the ranges so we can proceed. If that's what you suggest, please send an updated patch and I will test (again) and apply.
Thanks!
--Dan
Dan,
My comments are inline and patch is attached to the bottom of the email.
Tony
On Thu, 2019-08-22 at 16:21 -0700, Dan Smith via chirp_devel wrote:
I have another datapoint, external to CHIRP and Radioddity. miklor.com has 2 software versions listed that can program the BF-888 class radio. One version is listed as "BF-888S v1.05" and the other is listed as "ZT-V68 2007"
- The "v1.05" software writes the data blocks in the same order as CHIRP, also using only the "W" commands.
- The "ZT-V68" software, writes the data blocks in a different order than CHIRP (as reflected by my patch) and uses a "Y" command for those middle blocks.
I found through testing that:
- The "Y" command is not strictly necessary.
- Using all "W" commands works, as long as the order (_ranges variable in h777.py) is updated (as seen in my patch).
- Using the "Y" commands with the original order (unmodified _ranges variable) does not work.
Okay, so your suggestion is now to just change the ranges and not use the different command at all, correct?
I was hoping to just throw out a bunch of info and see what you came back with and what "stuck". Looks like I've still have to weigh in :)
Hmm, I've set several of these on my BF-888 clones and not had a problem. As such I'm a little reluctant to apply this, being concerned that maybe we have a variant out there and that applying this to fix half of them will break the others.
Agreed. I would love to get more feedback. I've tested the changes on my older Baofeng 777S radios but my "collection" is quite small.
Well, my collection isn't that large, but it turns out I'm a bit full of it anyway. In testing, I realized I too am unable to turn off the little chinese lady in my clones with the driver as it is in-tree, but can with your patch (which seems to work fine). Mine are only a couple years old at the most. I'm still worried about breaking older models, mind you, but I don't see to have any of those.
My 777S radios are probably the same age as yours. Also a few years old with the chinese lady. The newer GA-2S units have a male voice for the record. (If that ever helps debugging in the future)
This is where your intuition is much much greater than mine.
Well, my intuition tells me that, if anything, the command should matter and the order of the ranges should not (or at least doing them in non-sequential order would not be better). So... :)
why you think it matters?
It's still an issue, someone posted yesterday about 888 settings not sticking. https://chirp.danplanet.com/issues/6997
I meant why you think the range order matters, not why you think we should fix bugs, but...thanks :D
I knew that couldn't have been what you meant, but my kids were getting to me and I did not have much attention at that point ;) Why the range order matters? That is well beyond me as it makes no sense (IMO) that the order is more than that command ("Y" vs "W") I'm just not sure how one would code something so that order matters like that when all it's doing is taking an address and data. I guess when you're dealing with microprocessors you do what you can to get by, so I'm going to blame an intern somewhere. As I see it, a control loop should just wait for commands on the serial port and on data_ready() (or equivalent) 1) read command 2) act on it Also, another way to look at it is: if CHIRP didn't brick the radio by using "W"s to those locations in the first place, it *should* be ok to use "W"s now. I'm guessing the "Y"s may be required at some point in time if/when things break again.
So, answer my question above about trimming the patch to just the ranges so we can proceed. If that's what you suggest, please send an updated patch and I will test (again) and apply.
Patch is trimmed! See attched inline patch below.
Thanks!
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
---
# HG changeset patch # User Tony F goldstar611@hotmail.com # Date 1566262713 18000 # Mon Aug 19 19:58:33 2019 -0500 # Branch issue_6969 # Node ID 06a28023afbbbb5e0141b13b5f5dcc2638a4bf19 # Parent 1da5155c550477777c021fd6fbaf5036f0b0b5c0 [h777] Fix some settings not taking effect on Baofeng 888 and variants Fix #6969 https://chirp.danplanet.com/issues/6969 Changes based on serial output of latest "V12" programming software List of settings that were affected: - Scan On/Off - Voice Prompt On/Off - Language English/Chinese - Vox On/Off - Vox Level - Vox Inhibit on Rx (Untested) - Alarm On/Off - Radio On/Off (Untested) - Low Voltage Inhibit (Untested) - High Voltage Inhibit (Untested)
To the best of my knowledge, also Fixes #5027 Fixes #5985 Fixes #6283 Fixes #4959 Fixes #5153 Fixes #5343 Fixes #5797 Fixes #5833 Fixes #5831 Fixes #5857 Fixes #6997
diff --git a/chirp/drivers/h777.py b/chirp/drivers/h777.py --- a/chirp/drivers/h777.py +++ b/chirp/drivers/h777.py @@ -281,8 +281,8 @@
_ranges = [ (0x0000, 0x0110), + (0x0380, 0x03E0), (0x02B0, 0x02C0), - (0x0380, 0x03E0), ] _memsize = 0x03E0 _has_fm = True
I have another datapoint, external to CHIRP and Radioddity. miklor.com has 2 software versions listed that can program the BF-888 class radio. One version is listed as "BF-888S v1.05" and the other is listed as "ZT-V68 2007"
- The "v1.05" software writes the data blocks in the same order as CHIRP, also using only the "W" commands.
- The "ZT-V68" software, writes the data blocks in a different order than CHIRP (as reflected by my patch) and uses a "Y" command for those middle blocks.
I found through testing that:
- The "Y" command is not strictly necessary.
- Using all "W" commands works, as long as the order (_ranges variable in h777.py) is updated (as seen in my patch).
- Using the "Y" commands with the original order (unmodified _ranges variable) does not work.
Tony, have you been seeing the traffic on this bug?
https://chirp.danplanet.com/issues/7067
I believe my fears of introducing a regression came true and that these folks are hitting the problem.
I really don't want to have to register a "BF-888 (Old)" radio driver in CHIRP, but that might be the simplest thing to do. Would love to hear some analysis from you on this. All of mine are apparently the same vintage so I can't really test much.
--Dan
participants (2)
-
Dan Smith -
Tony Fuller