#74: TSQL and Duplex save setting
----------------------------------+-----------------------------------------
Reporter: TheSndGy@… | Type: Bug
Status: new | Priority: Functionality
Milestone: | Component: Memory Editor
Version: | Keywords:
Platform: Windows |
----------------------------------+-----------------------------------------
When setting a tone mode of TSQL but leaving Duplex as "None", the file
will not save properly; upon opening, the value is set to "-".
IC-2820
--
Ticket URL: <http://trac.chirp.danplanet.com/trac/ticket/74>
CHIRP <http://trac.chirp.danplanet.com/trac>
CHIRP Development
On Thu, Dec 16, 2010 at 8:53 AM, Dan Smith <dsmith(a)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
>
