On Tue, Mar 24, 2015 at 11:22 AM, Dan Smith dsmith@danplanet.com wrote:

Hi Jim,

...

I have been working on the basic channel editing support for the Anytone TERMN8R radio. Up until now, I have been using a separate driver file that I have in a work folder and I am loading as a module.

What I want to know is what is the best/correct way to submit this. It is enough different from the current driver that it needs to remain separate. But I would still expect that it should be added to the anytone.py driver similar to how several models are handled in the wouxun.py driver.

Does it inherit anything from the anytone driver? Or could/should it? If it doesn't inherit anything, then I think it should be a separate file. If it inherits some, but is still a lot of its own code, it can be a separate file, but still import and inherit pieces from the base anytone driver.

I believe a large portion of the download and upload routines are the same. I mainly had to "turn off" where it expects the sent data to be echoed back. If there is a way to say do this on the currently supported model but don't do it on the new models, this part could most likely be shared.

The structures vary quite a bit so they should be kept separate. I haven't looked at the OBLTR8R and NSTIG8R other than to capture "factory"images.

I've had to change quite a bit in "get memory" and "set memory" to accommodate the differences between the Anytone mobile radio and this handheld radio.

...

Also note that the OBLTR8R and NSTIG8R models will follow this one and should share some, if not most, of the TERMN8R's code.

Sounds like maybe it would be best to keep it in its own file if it's going to grow.

I was maybe thinking anytone.py for the current mobile radio and possibly anytoneht.py for the handhelds. But I am open to suggestions. I am also willing to make a single file work. That is why I am asking for advice.

Could you just send the .py file to the list so we could look it over and try to advise?

Included.

Thanks!

--Dan

Jim

Also this radio stores the squelch level on a per-channel basis. When a new channel is created using the OEM software, the level is initially set to level 3 (range 0 - 9). Any tips on how to set this to 3 when a new channel is programmed with chip but leave it as-is if it isn't a newly created channel?

Check the empty flag in the radio's memory before setting a memmory. If it's unset and you're setting it (to something other than empty) then you know you need to default the squelch value.

--Dan