[chirp_devel] New driver for Kenwood TM-D710G in true clone mode

[Rick DeWitt AA0RD]

OK, that makes sense to me. I will review what is in that 2nd block and 
may add a setting or two.
I have been searching the Wiki and repository for the documentation on 
porting to python3. Can you point me at those notes?


On 12/21/2019 9:35 AM, Dan Smith via chirp_devel wrote:
>> Regarding reading the memory blocks-
>> The first block is 32,512 bytes and contains the 1000 memory channels,
>> scan ranges, call channels, vfo values, masks, and radio settings.
>> The second block is 65,024 bytes and contains the power-on display
>> bitmap, Sky Command configuration,  APRS and GPS settings.
>> The third block is 131,072 bytes containing the GPS logs; tracks and
>> waypoints.
>> If I read the data after the first block, then I have to support all
>> those settings.
> No, you don't. All the other drivers pull the entire memory from the radio, and many don't support any settings at all.
>
>> Otherwise someone will load a saved image, modify a few
>> memory channels and upload it- clobbering anything the radio had saved
>> there.
> That's true even if you support the other settings. If you pull all the data, then someone doing this:
>
> 1. Download
> 2. Modify one memory in chirp
> 3. Upload
>
> Will not lose any settings.
>
> Further, even if you did support editing all settings, the following would happen:
>
> 1. Download
> 2. Modify one memory in chirp
> 3. Modify something on the radio itself
> 4. Upload
>
> They would have lost the setting they made on the radio.
>
>> I have avoided adding all that seldom-used data because my doctor
>> says I only have 30 more years to live and the Kenwood MCP software
>> currently covers it.
>> If you really want that stuff supported in CHIRP, then of course I can
>> do it.
> I don't care that it's supported in chirp, I care that it's in the image in case we want to support it later. I think it probably makes sense to not pull the GPS log and track data, because we'd need to write a whole new interface to the radio driver, and UI for doing that, and it's pretty far outside the scope of chirp's duties. You could argue the same about the bitmaps, although it'd be unfortunate to leave a hole in the middle. But, everything else is fair game and I think you should pull it regardless.
>
> I definitely don't think we need to support editing every last bit in the memory image. None of the drivers I've written have as complete coverage as this one that you wrote, because I don't see the benefit of spending all that time. So, I'm with you. My primary concern is not about compete coverage, it's about compatibility.
>
> The other point is that all the other drivers pull the entire memory image, which means I can create a full backup of my radio with CHIRP, then make some changes on the radio, and restore it exactly with the image. It would be very confusing for some clone-mode drivers to behave like this and not others.
>
>> I can create a Windows exe version of the short image for my local ARES
>> centers to use until then.
> Well, I can't stop you, but I really wish you wouldn't. Your local group will be creating images that would no longer be valid with the later version that pulls the full set of data, either requiring your driver to maintain compatibility for those things forever, or to eventually orphan those. Someone shares that version with a buddy and/or posts it somewhere and now we've forked the world with people generating chirp image files that won't be compatible with other ones. We should be avoiding breaking compatibility over time, whenever possible, since CHIRP's primary reason for existing is to avoid lock-in to one model's software and data format.
>
> Based on what I said above, you should be able to just make the driver pull all the relevant ranges into the image, regardless of whether or not you have settings support for those things with minimal extra effort right? Hopefully that is easy enough to avoid the need to fork?
>
> --Dan
> _______________________________________________
> chirp_devel mailing list
> chirp_devel at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers

-- 
Rick DeWitt
AA0RD
Sequim, Washington, USA 98382
(360) 681-3494