[chirp_devel] Yaesu question: fixed memory
Many Yaesu models (FT-1, FT2, FT-3, and probably others) have some fixed memory data (frequencies for SW broadcast, Weather, Marine and GMRS/FRS) pre-installed. In the FT-1 and above, these fixed memories are accessed via flags in the memory module (one flag bit per type of location). That makes the memory locations appear much bigger than the ‘real' channel memory; ‘real’ channels are at the moment accessed by stripping off the flag bits, and not saving any such data in the CHIRP model. This has caused at least one error request to be submitted and fixed when a Yaesu FT-2D user entered a WX channel into his radio by hand and tried to use CHIRP to help modify and save his memories; CHIRP died until I did the masking and prevented CHIRP from reading or saving such a memory.
BUT I’d like to find an adjunct to the CHIRP model so that the fixed memories can be accessed. Are “immutable” memories an appropriate mechanism? I have no idea where the fixed memories are stored in the actual radio. I presume that one would build several tables of “immutable” memories that can be pre-defined and accesssed. The fixed memory definitions are listed in the Yaesu manuals, and seem to be identical between models.
Is there an easily-accessible memory model that would allow this to “just work”??? Please and thank-you.
______ Declan Rieb WD5EQY wd5eqy@arrl.net
Many Yaesu models (FT-1, FT2, FT-3, and probably others) have some fixed memory data (frequencies for SW broadcast, Weather, Marine and GMRS/FRS) pre-installed. In the FT-1 and above, these fixed memories are accessed via flags in the memory module (one flag bit per type of location). That makes the memory locations appear much bigger than the ‘real' channel memory; ‘real’ channels are at the moment accessed by stripping off the flag bits, and not saving any such data in the CHIRP model. This has caused at least one error request to be submitted and fixed when a Yaesu FT-2D user entered a WX channel into his radio by hand and tried to use CHIRP to help modify and save his memories; CHIRP died until I did the masking and prevented CHIRP from reading or saving such a memory.
BUT I’d like to find an adjunct to the CHIRP model so that the fixed memories can be accessed. Are “immutable” memories an appropriate mechanism? I have no idea where the fixed memories are stored in the actual radio. I presume that one would build several tables of “immutable” memories that can be pre-defined and accesssed. The fixed memory definitions are listed in the Yaesu manuals, and seem to be identical between models.
Are these fixed memories read-only special locations? I'm not sure what you mean in the case where a user stored a WX channel. If they store it in their radio in a normal location, it's just a normal memory right? Why is it different? And I'm not sure what you mean about them "appearing much bigger" than a normal one.
Maybe you can point me to something in the code you changed where I can get a handle on the situation?
Memories are not immutable, but fields in a memory can be made immutable. That just means the UI and modeling in between tries to stop you from making changes to a field. If you make all of the fields immutable, then, I guess the memory is immutable, but at the end of the day, it's pretty much up to the driver in its set_memory() to do the right thing.
But, help me understand more of what you mean and we can figure something out.
Incidentally, do you have an FT1 or FT2? I need something tested with both of those radios, but haven't found anyone yet to do that.
--Dan
participants (2)
-
Dan Smith -
Declan Rieb