On Thu, Dec 16, 2010 at 8:53 AM, Dan Smith dsmith@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