Re: [chirp_devel] Request Guidance to Add CHIRP Support for the Baofeng UV-5RAX 150/220 MHz Radio
On Thu, May 2, 2013 at 9:46 PM, Jim Unroe rock.unroe@gmail.com wrote:
Hi Group,
I've been trying to figure out the best way to add CHIRP support for the Baofeng UV-5RAX dual-band radios that cover 136-174 MHz and 220-260 MHz.
Still trying...
I have been thinking that I just need a way to figure out a way to detect if the radio is a VHF/UHF model or a VHF/220 model and then use that to select between the following rf.valid_bands.
rf.valid_bands = [(136000000, 174000000), (400000000, 520000000)] # VHF/UHF
rf.valid_bands = [(136000000, 174000000), (220000000, 260000000)] # VHF/VHF220
I think I have a way to detect the difference. Below are the 1st 16 bytes of Baofeng UV-5R radios. The BFB231 is representative of firmware version BFB230 through BFB281 where the firmware verson was identified.
BFB231 (136-174/400-520) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F AA 42 46[42]32 33 31 DD 00 25 60 13 00 25 60 13 ªBFB231Ý.%`..%`.
The BFB291 is representative of firmware versions BFB291 and later. The format was revised to contain the lower and upper limits of each band.
BFB291 (136-174/400-520) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F AA 36 74[04]00 05 20 DD 00 25 60 13 00 25 60 13 ª6t... Ý.%`..%`.
The BFB296 is representative of firmware versions from a VHF/220 radio.
BFB296 (136-174/220-260) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F AA 36 74[02]20 02 60 DD FF FF FF FF FF FF FF FF ª6t. .`Ýÿÿÿÿÿÿÿÿ
Note the byte that I have surrounded with square brackets. On firmware BFB290 and lower, this will always be '42'. On firmware for a VHF/UHF radio, this will always be '04' or '05'. And finally on a VHF/220 radio this will always be '02'.
So if some way byte 0x0003 could be read so that rf.valid_bands can be set to
rf.valid_bands = [(136000000, 174000000), (400000000, 520000000)]
except when 0x0003=02 then it would be set to
rf.valid_bands = [(136000000, 174000000), (220000000, 260000000)]
Does this make sense? How would I go about it? is there a better way?
No. This makes no sense because it won't work. Once an image is uploaded from another model, these first bytes will be replaced. :(
It was discussed that the VHF/220 radio could be handled as a different Baofeng model. I guess I'm not opposed to that if that is what the consensus is. How would that be done?
Thanks in advance.
Jim KC9HI
Jim
No. This makes no sense because it won't work. Once an image is uploaded from another model, these first bytes will be replaced. :(
You mean if someone takes a VHF/UHF image and blows it into a VHF/220 radio?
Sounds like we should always read the first chunk of data from the radio before we push an image out to it and fail if it doesn't match what we want. We do this now for the firmware version, right? (see do_upload() and _get_radio_firmware_version().
I think the right thing to do is subclass the main radio driver for the 220, and stash the byte that we expect to see for each in their respective classes, so we can compare the driver being used to what the radio returns.
Also, we'd need to modify match_model() so that it would load files with the correct driver.
On Sat, May 4, 2013 at 4:51 PM, Dan Smith dsmith@danplanet.com wrote:
No. This makes no sense because it won't work. Once an image is uploaded from another model, these first bytes will be replaced. :(
You mean if someone takes a VHF/UHF image and blows it into a VHF/220 radio?
Yes
Sounds like we should always read the first chunk of data from the radio before we push an image out to it and fail if it doesn't match what we want. We do this now for the firmware version, right? (see do_upload() and _get_radio_firmware_version().
Yes. I believe this is already done when downloading or uploading. I see the "Ident:" in the command window. It displays the data that I think we can match against.
I think the right thing to do is subclass the main radio driver for the 220, and stash the byte that we expect to see for each in their respective classes, so we can compare the driver being used to what the radio returns.
I think this may be getting in over my head. 'Subclass' is what you did for the F-11, right? I will definitely need help with this.
Also, we'd need to modify match_model() so that it would load files with the correct driver.
Now that the main features of the UV-B5 are in place and the UV-5R 'hidden' firmware version as been addressed, I am in a better position to mess with something like this.
Jim
Yes. I believe this is already done when downloading or uploading. I see the "Ident:" in the command window. It displays the data that I think we can match against.
Yes it is, I was asking rhetorically :)
I think this may be getting in over my head. 'Subclass' is what you did for the F-11, right? I will definitely need help with this.
Yep!
Maybe take a look at how we do the firmware detection (and rejection) as well as how the F-11 subclass overrides the _idents and _basetype variable from the parent UV5R class. Then we can talk about details.
Thanks!
Sorry, Dan suggested that I get this out last month, but work has been a little hectic. I've posted the new model request and assigned it to myself. Seems to work fine on my radio.
Brett
# HG changeset patch # Parent f6c48f71ea6c96b969751f136e40e6c0128960a4 Code replicated from the TM-271 for the TM-471 series.
diff -r f6c48f71ea6c -r 35f12a487716 chirp/kenwood_live.py --- a/chirp/kenwood_live.py Sun May 05 10:30:26 2013 -0700 +++ b/chirp/kenwood_live.py Wed May 08 17:03:31 2013 -0600 @@ -158,7 +158,7 @@ return self.__memcache[number]
result = command(self.pipe, *self._cmd_get_memory(number)) - if result == "N": + if result == "N" or result == "E": mem = chirp_common.Memory() mem.number = number mem.empty = True @@ -1103,3 +1103,71 @@
if __name__ == "__main__": do_test() + +@directory.register +class TM471Radio(THK2Radio): + """Kenwood TM-471""" + MODEL = "TM-471" + + def get_features(self): + rf = chirp_common.RadioFeatures() + rf.can_odd_split = False + rf.has_dtcs_polarity = False + rf.has_bank = False + rf.has_tuning_step = False + rf.valid_tmodes = ["", "Tone", "TSQL", "DTCS"] + rf.valid_modes = THK2_MODES + rf.valid_duplexes = THK2_DUPLEX + rf.valid_characters = THK2_CHARS + rf.valid_name_length = 6 + rf.valid_bands = [(444000000, 479990000)] + rf.valid_skips = ["", "S"] + rf.valid_tuning_steps = [5.0] + rf.memory_bounds = (0, 99) + return rf + + def _cmd_get_memory(self, number): + return "ME", "%03i" % number + + def _cmd_get_memory_name(self, number): + return "MN", "%03i" % number + + def _cmd_set_memory(self, number, spec): + return "ME", "%03i,%s" % (number, spec) + + def _cmd_set_memory_name(self, number, name): + return "MN", "%03i,%s" % (number, name) + +def do_test(): + """Dev test""" + mem = chirp_common.Memory() + mem.number = 1 + mem.freq = 440000000 + mem.duplex = "split" + mem.offset = 442000000 + + tc = THF6ARadio + class FakeSerial: + """Faked serial line""" + buf = "" + def write(self, buf): + """Write""" + self.buf = buf + def read(self, count): + """Read""" + if self.buf[:2] == "ID": + return "ID %s\r" % tc.MODEL + return self.buf + def setTimeout(self, foo): + """Set Timeout""" + pass + def setBaudrate(self, foo): + """Set Baudrate""" + pass + + radio = tc(FakeSerial()) + radio.set_memory(mem) + +if __name__ == "__main__": + do_test() +
Hi Brett,
Sorry, Dan suggested that I get this out last month, but work has been a little hectic. I've posted the new model request and assigned it to myself. Seems to work fine on my radio.
Cool, thanks! What's the bug number?
# HG changeset patch # Parent f6c48f71ea6c96b969751f136e40e6c0128960a4
Hmm, this doesn't look like a proper HG header. Did you copy/paste this from "hg export" or what?
Code replicated from the TM-271 for the TM-471 series.
Bug number needs to be in here so that the system will apply the patch. Just add something like:
Fixes bug #123
if __name__ == "__main__": do_test()
You replicated this below, and this should be at the bottom anyway. Can you nuke this one so it's replaced below properly?
Otherwise, looks good, thanks for doing this!
Hi Dan,
Yes, first time running mercurial and of course setting it up initially I was su to root. Not easy to add information when the default TERM is rxvt and of course the default editor was vi. Didn't want it to email out from my workstation as root so cut/pasted into pine. This request is in the que as new model #861 so I'll add that to the message.
Sending again.
Brett
On Thu, 9 May 2013, Dan Smith wrote:
Hi Brett,
Sorry, Dan suggested that I get this out last month, but work has been a little hectic. I've posted the new model request and assigned it to myself. Seems to work fine on my radio.
Cool, thanks! What's the bug number?
# HG changeset patch # Parent f6c48f71ea6c96b969751f136e40e6c0128960a4
Hmm, this doesn't look like a proper HG header. Did you copy/paste this from "hg export" or what?
Code replicated from the TM-271 for the TM-471 series.
Bug number needs to be in here so that the system will apply the patch. Just add something like:
Fixes bug #123
if __name__ == "__main__": do_test()
You replicated this below, and this should be at the bottom anyway. Can you nuke this one so it's replaced below properly?
Otherwise, looks good, thanks for doing this!
-- Dan Smith www.danplanet.com KK7DS
participants (3)
-
Brett Bump -
Dan Smith -
Jim Unroe