[chirp_devel] Add new radio Icom IC-E90/T90/T90A

[Jaroslav Skarvada]

----- 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