[chirp_users] General inquiry on adding "settings"
Before I start, this is less a request to give me something for free, more an inquiry whether doing part of the job is enough to get someone else to finish it, and how that might work. I haven't seen this kind of development meta-discussion, so here goes:
I'm inquiring about adding Chirp control of feature settings as has been done on a few radios. I can see it's a separate significant project for each radio, but there's some general infrastructure in place since it's been done for some, and presumably the first one was the hardest. Since I'll get asked, my interest is my radios, Yaesu FT-60 & FT-8800.
I'm an old unix C hacker, with a bunch of shell and a healthy exposure to a number of others, but I retired before OOLs became needed to use on a regular basis. I can sort of read the Chirp Python source, but I'm thinking there's too much to learn to contribute code.
I expect that the first step is to map out the settings in the data stream. For example, the FT-60 seems to have 56 set parameters, most of which can take from 2 to a half dozen or so values. A few, such as repeater shift or tone value seem to be multi-bit data fields that one hopes are encoded binary values that be reverse-engineered with a few samples, and described.
I guess the process would be to change a setting via the radio's buttons, read into chirp. and record what changed in the data stream. Rinse and repeat. If someone (me, for example) were to do that and provide the map, would that likely be enough to have someone else pick it up and code it into Chirp?
And if so, what form should the 'map' take? Several hundred complete radio images seems less than optimal to me, for several reasons, most obviously that it still needs interpretation to code from. I could probably do a Python const data structure or equivalent if pointed to an example.
Just looking to understand this aspect of the development process.
Thanks and regards,
-dan
On Feb 2, 2014 1:05 PM, chirp.cordless@xoxy.net wrote:
I haven't seen this kind of development meta-discussion, so here goes:
This kind of discussion usually happens on the chirp_devel mailling list: http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
I guess the process would be to change a setting via the radio's buttons, read into chirp. and record what changed in the data stream. Rinse and repeat. If someone (me, for example) were to do that and provide the map, would that likely be enough to have someone else pick it up and code it
into Chirp?
Yep, you've got the process figured out.
And if so, what form should the 'map' take? Several hundred complete radio images seems less than optimal to me, for several reasons, most obviously that it still needs interpretation to code from. I could probably do a Python const data structure or equivalent if pointed to an example.
I think the best option would be for you to learn the syntax for the Chirp bitwise memory format. It takes its inspiration from c structs, so it should be very familiar to you. It is not Python, but a syntax Dan created to represent radio memory structures. It suits Chirp very well. You can find examples in every radio driver, usually at the top of the file in a string called MEM_FORMAT: http://chirp.danplanet.com/projects/chirp/repository/entry/chirp/ft60.py#L10...
If you can define the radio's memory layout in that format, and document the associated values (e.g., APO: 0: off, 1: 30m, 2: 1h, 3: 2h, etc.), then another Chirp dev should be able to pick up your work and add the GUI elements.
Please send your reply to the chirp_devel list so the right audience sees it.
Tom KD7LXL
participants (2)
-
chirp.cordless@xoxy.net
-
Tom Hayward