----- Original Message -----
My opinion is that multi-device radio drivers tend to be a little buggy-er than others, and it's annoyingly hacky in the tests to make it work right. If you feel strongly, then that's fine, but especially since I expect nobody to have any real reason to use those channels anymore, it's probably better to opt for simplicity. Your call.
Yes, I noticed it's a bit buggy :) but it works for me. I tried to rewrite the code to use special channels also for TV, but it's a bit complicated. Is there a way how to force users not to set e.g. certain modulations for such special channels? Or is the only way to let them to select whatever they want from the listbox and do the check in the set_memory method and if Memory items aren't valid, change them to some sane values? I think this could be confusing for users.
I am rstriping(0x00) which is used by the radio as a pad for unfilled channels. The radio supports space in its charset, so I am not rstriping it. What confused me a bit is that the space was included in both 'expected'/'obtained' reports of the testsuite.
It's a CHIRP requirement that the driver not return a memory with trailing whitespace. It's annoying to edit that way, and tends to propagate through import and copy/paste operations.
Thanks, it works now.
This is because this radio uses longer icf lines, but it is still small address, i.e. it doesn't use the 10 chars prefix and it uses the 6 chars prefix, but it's detected as the 10 chars prefix, because the detection routine wasn't flexible enough. This is an attempt which assumes that the length of the data line (after the prefix) will be multiply of 8 (I thought that sane people would do it this way :) , so the rest has to be the prefix. This calculation works for the 38 chars line length as was hardcoded before and also for the IC-E90. If there is a better way how to detect this, I am ready to change it.
Put a big fat comment over it, at the very least. Explain what it used to do and what your rationale is for doing it this way. Otherwise it'll be hard to suss out later without blame.
Added.
To be honest I don't know what's the difference between T90 and T90A, I saw there are radios around which uses both labels on the case. I also noticed there are manuals for both. So I will probably do more investigation about it - i.e. I will probably diff the manuals. Or if by an accident is here somebody who knows more, please let me know. But if you think it's not necessary, I will drop it.
I think it's a marketing thing. The -A variants are usually for North America, -E is for Europe and without either means something else. Not all models have all those variants. In other cases where necessary, we support the A and the E, but I have never heard of an A not working for the un-suffixed variant.
Thanks, it seems you are right. The IC-T90 manual just exists in Japan language (I wasn't able to get it in the English language). And according comparison of these two manuals, it seems the radios are nearly identical - just minor different configuration for Asia, similarly as with the IC-E90. So, I added alias just for IC-T90. Or maybe I could name the radio IC-T90 and alias as IC-E90.
Regarding the clone status check, I spent some time on digging into the USB sniffs and it seems there is a bug in the Chirp code. After adding:
--- a/chirp/drivers/icf.py +++ b/chirp/drivers/icf.py @@ -183,6 +183,7 @@ def send_clone_frame(radio, cmd, data, raw=False, checksum=False): pass
radio.pipe.write(frame) + get_clone_resp(radio.pipe)
return frame
I.e. after calling already defined, but never used function, it started to work even with the clone status check enabled. In the original Icom SW sniffs the clone status check response is clearly visible. It seems the icf driver doesn't read the radio responses during the clone process and when it tries to read the last response code, there is already buffer full of previous data which it cannot correctly process.
But there is a problem with this patch, it breaks the tests so it waits forever on the pipe:
$ ./run_tests.py -d 'Icom_IC-E90' Icom IC-E90 Detect PASSED: All tests Icom IC-E90 Settings PASSED: All tests ^CTraceback (most recent call last): File "./run_tests.py", line 1300, in <module> failed = tr.run_one(options.driver) File "./run_tests.py", line 1232, in run_one "%s.img" % drv_name)) File "./run_tests.py", line 1210, in run_rclass_image failed += self.run_rclass_image(dev.__class__, image, dst=dev) File "./run_tests.py", line 1213, in run_rclass_image return self._run_one(rclass, image, dst=dst) File "./run_tests.py", line 1167, in _run_one failures = tc.run() File "./run_tests.py", line 984, in run self._run(self.SerialNone()) File "./run_tests.py", line 947, in _run radio.sync_in() File "../chirp/drivers/icx90.py", line 598, in sync_in icf.IcomCloneModeRadio.sync_in(self) File "../chirp/drivers/icf.py", line 627, in sync_in self._mmap = clone_from_radio(self) File "../chirp/drivers/icf.py", line 289, in clone_from_radio return _clone_from_radio(radio) File "../chirp/drivers/icf.py", line 237, in _clone_from_radio md = get_model_data(radio) File "../chirp/drivers/icf.py", line 140, in get_model_data send_clone_frame(radio, 0xe0, mdata, raw=True) File "../chirp/drivers/icf.py", line 186, in send_clone_frame get_clone_resp(radio.pipe) File "../chirp/drivers/icf.py", line 162, in get_clone_resp while not exit_criteria(resp, length): File "../chirp/drivers/icf.py", line 157, in exit_criteria return buf.endswith("\xfd") KeyboardInterrupt
So this needs to be addressed somehow
thanks & regards
Jaroslav