[chirp_users] Kenwood TH-D72 and Linux

[Vernon Mauery]

On Thu, Dec 16, 2010 at 8:53 AM, Dan Smith <dsmith at danplanet.com> wrote:
> Hey Vernon,
>
> Wow, super-awesome.  Thanks a bunch :)
>
>> In the process of trying to understand the radio, I found that I can
>> do partial reads and writes.  This opens up a lot in the way of faster
>> syncing with the radio.  I am hoping to find a way to mark blocks of
>> the mmap as 'dirty' and only flush those dirty blocks out to the
>> radio.
>
> Hmm, okay, well, that would be pretty different than how most of the
> other stuff works.  Perhaps you need to model it more as a LiveRadio
> than a mmap-ed one.  The UI changes behavior in some areas depending on
> whether it thinks the radio is live or not (like warning the user about
> long-running operations).

Well, for now I am just going to leave it as a clone radio.

>> In addition, the windows MCP-4A program offers a lot more than just
>> editing the memories.  I would like to be able to modify some of the
>> other behaviors on the radio from the GUI as well.  But I am not sure
>> UI-wise the best way to go at this.  A new tab or a new popup window
>> or something.  This is still a ways out since I am still trying to
>> figure out memory offsets and data formats for all the settings.
>
> Yeah, so, the thing is: all radios have memories, and they're all fairly
> similar.  The problem comes when you have a ton of other little
> radio-specific things to change that it becomes harder to make the tool
> universal.
>
> I'm definitely not opposed to this, but I think we need to do some
> thinking on how best to model it internally.  The UI already has
> multiple tabs on some of the radios (like the D-STAR radios, for setting
> callsigns and stuff).  It shouldn't be too hard to do the same for
> specific radio features.

I agree that some discussion needs to take place.  That is one reason
I didn't just jump right in.  The other is that I don't have much in
the way of pygtk know-how.

> Maybe we should come up with a subset of non-memory things we want to
> support for all radios first?  Things like display color, power-off
> time, etc?  I'm not sure how far down the rabbit hole you want to go :)

1) Compile a list of all the options all the supported radios have
2) Find the subset of common options
3) Come up with a nice UI for that.

I think that steps one and two are the ones that will take the most work.

>> +CROSS_CODES = [
>> +    "DCS->Off",
>> +    "Tone->DCS",
>> +    "DCS->CTCSS",
>> +    "Tone->CTCSS",
>> +]
>
> Hmm, would you consider splitting (or letting me split) the patch into
> one for the D72 and one for the "cross code" thing?

This version has that split out.

> Am I correct in saying that this lets you transmit DCS but receive Tone,
> or something like that?  Does the MCP call it "cross code"?

The MCP interface has a choice of which method to use
(Tone/CTCSS/DCS/Cross) and then if Cross is selected, the "Tx Cross
Tone" and "Rx Cross Tone" fields are enabled.  The manual calls it
Cross Mode, so that is what I have altered it to be.

>> +# memory channel
>> +# 0 1 2 3  4 5     6     7     8     9    a     b c d e   f
>> +# [freq ]  ? mode  tmode rtone ctone dtcs cmode [offset]  ?
>> +POS_MODE   = 5
>> +POS_DUP    = 6
>> +POS_TMODE  = 6
>> +POS_RTONE  = 7
>> +POS_CTONE  = 8
>> +POS_DTCS   = 9
>> +POS_CMODE  = 10
>> +POS_OFFSET = 11
>> +
>> +MEM_LOC_BASE = 0x1500
>> +MEM_LOC_SIZE = 16
>> +MEM_TAG_BASE = 0x5e00
>> +MEM_FLG_BASE = 0x0C00
>
> So, you may hate me for this, but I think you might want to take a look
> at some of the other radios that I've been porting to a new way of doing
> things.
>
> Look, for example, at the vx8.py driver.  I've defined a little
> mini-language that lets you define things like you did in the comment
> block above, but in a way that lets the code automate a bunch for you.
> I haven't converted the V71 driver because I don't own one and don't
> want to port it to the new model until I have one handy to test with.
>
> Anyway, I definitely think it's the "way forward" with this stuff, and
> makes the code much smaller and simpler.  Not that I wouldn't take the
> patch as it is, but at least take a look first and let me know what you
> think.

I took a look at the vx8 driver and modified the thd72 driver to work
with the bitwise parser.  It took some time, but since this was the
first day of my end-of-the-year holiday, I didn't have anything else
to do.  It worked out nicely.

I used hg record to break apart my changes and then used hg export to
create the patch.  Is this the preferred method of submission or
should I do something else next time?  I have never used hg before, so
I am breaking new ground all over the place with this project.

--Vernon

> Otherwise, thanks a ton for doing this work!
>
> --
> Dan Smith
> www.danplanet.com
> KK7DS
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_th-d72-v2.patch
Type: text/x-patch
Size: 9131 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20101217/def9159b/attachment.bin