<div dir="ltr">Yep,<br><br>Sounds like a pain... I can live with using the other SW for this. And I sort of answered #2 myself and it didn't look promising, so extra inclined to give up.<br><br> Thanks for the advice!<br><br>-H</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 25, 2024 at 7:21 PM Dan Smith via chirp_devel <<a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.danplanet.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 0) These are "clone mode" radios, and I don't see a change in memory after changing welcome screens with BF's sw. Would that be CHIRP ignoring/not reading the relevant memory section? Or is there precedent for baofengs to have settings that are not part of the normal clone?<br>
<br>
Yep, probably a different memory region, which is going to make it somewhat uncomfortable to make this happen. If the driver can be extended to download both regions at the same time (and in a way that won't break the current image format, then it's possible.<br>
<br>
> Probably for Dan:<br>
> 1) Would it be accepted for CHIRP to have this feature? Is it absent for some reason, or simply because nobody has implemented it? If I were to be the first to implement this, how would you like to architect it into the SW? Part of the driver? New functions for UI?<br>
<br>
The only way I can see this happening is to make it a "setting". Basically a new setting type of "image" or something, but then the UI will have to be extended to provide a way to let you choose an image. That's going to allow the user to open a PNG, JPG, etc and then I assume the driver is going to have to use something like PIL to access the pixel data to encode it in a suitable way for the radio. It's not going to be an easy thing.<br>
<br>
> 2) I have reverse engineered the encoding and some header info for the image write. Where should I look for details on the existing reverse engineered protocols for this device? I am hoping my answer to question 0 is "chirp is probably just not touching the memory we care about" and I only have to make minor changes, but this info will help in any case.<br>
<br>
I'm not sure what you're asking here, but maybe someone else does.<br>
<br>
> 3) Does anyone have other radios that have similar features to consider while designing how this will work?<br>
<br>
Not that I know of.<br>
<br>
> I have plenty to keep me busy between work and life, so I appreciate any advice and help that might make this easier. <br>
<br>
I'm sure I'm in the minority, but I've never (ever) felt like my life would be enriched by having a custom boot screen on my radio. That said, I don't have wallpapers on my desktop or phone (or ... my walls) either. IMHO, this is going to be a lot of work for very little functional gain, so my (humorous) "advice" would be to focus on something else :P<br>
<br>
--Dan<br>
_______________________________________________<br>
chirp_devel mailing list<br>
<a href="mailto:chirp_devel@intrepid.danplanet.com" target="_blank">chirp_devel@intrepid.danplanet.com</a><br>
<a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel" rel="noreferrer" target="_blank">http://intrepid.danplanet.com/mailman/listinfo/chirp_devel</a><br>
Developer docs: <a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers" rel="noreferrer" target="_blank">http://chirp.danplanet.com/projects/chirp/wiki/Developers</a><br>
</blockquote></div>