|
Yes, exactly. The thing was amazingly fast. The "problem" is the radio took on the attributes?of whatever mode was selected at the time. So, if mode 1 was selected, had a PL of 151.4 etc.... if I tuned away to a different frequency those attributes followed, being only the frequency was changing. It would basically require duplicating all the other features of the radio in hardware/software to take advantage of this method fully which is of course absurd.? My thought was to present the uProcessor with one mode's worth of data and then change that data dynamically, allowing the uP to do all the rest of the work. I have the service manual and it appears it has a strobe line which basically thumbs through pages?of the eeprom grabbing data for different modes. If it were fed data that we could dynamically update despite whatever mode (eeprom data offset) it's looking for then we could control it all. As said earlier, life has taken priority and caused a stall on the project but I do have some very nice code I came up with for the Raspberry Pi which I think could be used to feed an arduino as an internal decoder resulting in a very nice full color capacitive touch screen 4.3" user control interface with infinitely configurable mode names, scan lists, search parameters etc... all fed to the radio via a simple lightweight serial interface or perhaps even via one of the bluetooth serial dongle boards leaving only audio paths to be dealt with.? As the solar cycle has heated up it's something that has got me thinking about it all again.? I just don't know if this is the place to discuss it and I don't want to infringe or step on any toes regarding the project this group is about so I should probably start another group so as not to clutter this one. Casey On Thu, Jul 28, 2022 at 4:16 PM swguest via <swguest=[email protected]> wrote: Bradley, |
