Another fairly easy project would be a radio protocol converter for our TBD odd ball SB9600 commands.
@ Skip,
Thank you for all your efforts to put this together.
I really hate the idea of loosing the legacy protocols.
If there is a way to save at least I2C and maybe even CI-V that would make interfacing other devices much easier.
I've been researching the project needs vs the GPIO limits to see what alternatives there may be.
A few things come to mind, but it does become clear KISS is relative,
"Another fairly easy project would be a radio protocol converter for our TBD odd ball SB9600 commands."
I think I'm reading that as a sub-proccesor or co-processor to handle ?
I'm thinking of an external box with an ESP32 with an SB9600 bus
interface. This could give us Bluetooth connectivity to a phone app,
or Android head unit in a car as well as Doug Hall and CI-V.
If Bluetooth isn't needed another approach would be to use a Pico. In
fact, why not a second "Xcat 9000" !?! I'll modify the schematic to
allow it to be built as a code plug replacement (current) or as a CI-V
/ Doug Hall converter.
Here's some stuff I've mulled over:
Freeing up some I/O
1 - What can the onboard USB 1.1 be used for under uC program control?
Good point! Yes the USB port could be used for CI-V, but then you
would need to drill a hole and route a USB cable out of the radio.
I did something similar "back in the day". I put an USB sound card
inside of my Syntor along with a digital pot for squelch. The Xcat
was interfaced to GPIO on the sound chip so everything was
controllable over one USB cable
().
However ... I DID HEAR some odd ball signals here and there (one of
the reasons I added squelch port support). They weren't all that
strong and I never tracked them down or tried any shielding. I don't
know if they were coming from the USB cable, the USB sound card or the
Xcat. I haven't heard ANY comments from Xcat owners about
interference issues so I assume it's not the Xcat itself.
BTW I really lucked out on that radio ... it was one of the rare
136-154.4 splits and it included a factory preamp. I don't recall the
exact measured sensitivity, but it was VERY good.
I think it's best to avoid running USB into the radio, but it could be done.
HOWEVER the proposed board could be used as a CI-V protocol converter
EXTERNAL to the radio with different firmware if the USB port is for
the serial port.
2- Ideally we want to have RS232(can drive the BT radio?), SB9600, CI-V, Doug Hall, I2C, others?
Are any mutually exclusive or need I/O at all times in all mode of operation?
Could some of these protocols share the physical com line pins releasing them for another protocol when their task is done?
A wireless SB9600 interface is a nice idea but definately falls at PH II or PH III.
I don't think any of these can share pins, but there are a lot of
chips and boards that would have enough. To "do it all" we need:
1. 2 serial ports (one for SB9600 and one for CI-V).
2. 2 GPIOs for Doug Hall
3. 1 I2C interface
4. 2 GPIOs to monitor and control SB9600 the bus line (or one with a
bidirectional level converter).
5. Bluetooth ?
6. Optional but nice to have - WiFi
The only "have to have" SB9600 command is something to force the uC to read the EEPROM mode data as commanded by the Pico.
For that matter a dedicated ATTiny or PIC F8x could get a "send it" cmd via I2C, RS232 etc. and, with respect to the radio's busy line protocol, spit out the pre-formed packet(s). t's not going out of the radio so it could even be tied to the single ended side of the bus.
I don't feel comfortable just driving one side of the bus, if there's
a control head then we have that loading even if we aren't sending
commands to the head itself.
On the other hand we DO have one spare line which could be used to
receive CI-V commands. We wouldn't be able to read back the code plug
or get COS updates but we could send commands to the radio which is
90% of the use cases anyway.
3 - With properly manipulated zero page values, it *may* be possible, for the X9000 to functionally operate in a 4k space with a 128 mode limit.
The PL/MPL mapping is the challenge. I need to dig back into the details of that to verify.
Regardless it will operate in 2k space with 64 modes. Again PL management is a thing if >16 MPLs are expected, but I think that could be addressed in code with a form of expanded memory/page swapping routine.
None of these custom codeplugs would be compliant with RSS/OEM OS and if we tell the radio it has an 8k codeplug, it will need to see 8k of correct data to perform checksum verification.
We could free up to 2 I/O pins with this method.
I think we have enough problems understanding the "standard" code plug
format. We could add a jumper to select either 4k emulation with CI-V
or 8K without.
4- It looks like GPIO 28 is the only free pin left as drawn?
...and what's up w/GPIO25? Waste a GPIO just to have an on board LED to flash?
An onboard LED is a good feature. Not providing access (that I can find any reference to) and consume a General Purpose I/O just to flaxh an LED isnt.
Leaving KISS in the rear view mirror, for me, I'd tack a wire on that sucker and put it to work.
Yes it is a waste. Unfortunately the only connection to it is a small
test point on the BOTTOM side of the board. If it was on the top side
we could consider a flying wire connection.
To access the bottom side the pico would have to mount on our board
with pins rather than being soldered down directly. I guess that
could be done... There is also TP6/BootSel which we can access as
well.
5- Again, deviating from KISS, recapturing I/O by doing serial to parallel for the data lines would not even be a blip as fast as this thing runs. Actually I think it would have to be slowed down a bit.
A 595 takes 3 I/O to load and clear. That give us back 5 of the d0-d7 lines. The 595 comes in a DIP and may have a level translation version (I've never looked for one). If so, that would be a zero net gain of components by eliminating a 244.
I dont know how much driving serial vs parallel data, plus control lines would impact state machine/DMA code.
It certainly COULD be done, but messy!
73's Skip WB6YMH
