On Tue, Aug 9, 2022 at 5:12 PM swguest via groups.io
<swguest@...> wrote:
I'm thinking the data update write to EEPROM is going to be (relatively) slower than a mirror copy to RAM.
It seemed logical to pre-calculate all the bytes to change to their new values, checksum the changes and write that to the EEPROM first. Once there, a simple mirror copy would be quick(er) and complete, if the radio got a reset cmd for some reason and executed a re-check of the codeplug integrity.
The way the legacy Xcat worked was that all frequency / PL / scan list
changes just updated RAM for the special "VFO" mode (mode 1). A
separate (custom) command could store the current contents of the VFO
(mode 1) into a specified mode. That's the only time flash was
written. When the radio was used as a remote base via standard CI-V
commands or Doug Hall control nothing was ever written to flash. On
the plain X there wasn't any kind of checksum on the code plug.
Also, I'm thinking in terms of permanent freq/PL/NPscanlists etc changes to the codeplug vs a VFO mode of operation which need not be permanent or need a checksum re-calc and store function.
VFO mode from the codeplug side could get tedious.
Your original routine worked with 1/8th the horsepower so this should too. Does the Xcat's VFO lock-step the TX with the RX or is it RX only?
The setting the VFO set the RX frequency, the TX frequency was also
set by adding a signed TX offset value to the specified receive
frequency.
Yeah, loosing feature on next gen designs it always a bad thing. I dont know about the Doug Hall stuff but you had a couple of guys chime it when it was mentioned.
Doug Hall is a thing for remote base people, it's supported by lots of
controllers. Personally I never used it, my controllers were all DIY
and I found serial much easier to deal with. There's a fair number of
people using Xcats with Asterisk/AllStar systems for remote bases and
AFAIK they all use CI-V.
If there are any I/O or an SPI port available that might be a candidate for a serial accessory. I'm guessing since you have the feature worked out, the base code is pretty much boiler plate, if porting it isnt too much of a headache.
All of the pins are used, too bad the Pico PCB didn't bring out all
the rest of the GPIO lines (4) that would have made things a bit less
tight.
There's I2C GPIO expansion ports, but they are only good for slow signals.
With all of the level converters and pin limitations updating the
technology is certainly ADDING complexity and chip count... that's not
how it's supposed to work!
73's Skip WB6YMH
If the code is there, accessory design TBD.
I know it violates the KISS philosophy, but you could SPI the data into a ser to par FF/ reg W/ an /OE line (595's I think?) and free up a few I/O if needed.
Yeah, the SyntorX/X9000 squlech syndrome. I had aT74 that hated cold weather, and this is S Texas!
Sometimes it would be so cold in the morning the squelch wouldnt close. Sometimes even the vco drifted in/out of lock until the heater wamed up the back seat floorboard enough for it to behave. I think he just wanted to retire to Aruba or somewhere........
