On Tue, Feb 4, 2014 at 9:40 AM, chirp.cordless@xoxy.net wrote:
As Tom requested, I'm moving this discussion here from chirp_users. I've registered to receive mail (digest form) on this list.
Great!
You may find that digest mode delays discussion. This list is low-traffic enough that there's not much benefit to digest (I don't use digest even on high traffic lists, but that's a personal decision).
Thanks for the response, it was what I was hoping for. I've looked over the FT-60 MEM_FORMAT structure you pointed me at, and it looks like something I can definitely handle, maybe with a little experimentation and poking around the code to resolve things like bit ordering etc.
I've seen the chirp developers tools option to view and diff the raw data. I think I'm probably self-contained as far as what I need to know to do this, but I'll ask if I get stumped.
The developer tool that will really help you here is the Browser tab (on the left). It breaks the MEM_FORMAT into a tree you can browse, so you can confirm Chirp is parsing your struct correctly and the bit ordering is correct. Thanks to Dan for this very useful tool.
I don't want to set expectations that I'm committing to do this until I get into it and size up just how much work is involved, but my sense is it's a reasonably finite task for one radio, and I'll get started on it for the FT-60. Don't open a feature bug on this, plenty of time to do that when I have an extended MEM_FORMAT struct ready to merge. A couple of months?
My only request now is that if someone is already working on adding FT-60 settings, stop me now so I don't waste my time.
Starting a feature request, assigning it to yourself, and setting "In Progress" would prevent anyone else from unknowingly working on this task.
However, I do have one issue that needs to be corrected that I noticed in looking over the referenced ft60.py The power levels described in lines 154-156 are incorrect. The FT-60 is 5w2w/0.5w, not 5w/2.5w/1w. See user's manual pages 15 and 79.
I haven't looked to see what the values are used for, if anything, but they're currently wrong except for high.
Having the values slightly off isn't going to break anything, but that's no excuse for keeping wrong data in Chirp! We'd love to see a patch from you that fixes it. This will be a nice way to ease you into Chirp's patch submission policy.
http://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess
Tom KD7LXL