Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Xcat 9000 Rev A
|
I've attached the first cut of a schematic for a possible Xcat for the X9000.
This design will not support Doug Hall or CI-V directly.? Another fairly easy project would be a radio protocol converter for our TBD odd ball SB9600 commands. This project will only move forward if there's enough interest from the group to make it worthwhile. Comments please! 73's Skip WB6YMH |
|
Awesome! On Sun, Aug 14, 2022 at 1:10 PM Skip Hansen <skip@...> wrote: I've attached the first cut of a schematic for a possible Xcat for the X9000. |
|
On Sun, Aug 14, 2022 at 11:10 AM, Skip Hansen wrote:
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 ? 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? 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. 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. ? 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. 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. 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. |
Another fairly easy project would be a radio protocol converter for our TBD odd ball SB9600 commands.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. 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. 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 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. 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. 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. It certainly COULD be done, but messy! 73's Skip WB6YMH |
|
?@ Skip,
Regarding the usefulness of the onboard USB, I wasnt sure what you had in mind for connectivity devices and if any of them other than a PC could natively connect to the USB. I was thinking that the 2.4ghz radio was to be exterior anyway and the lines to I/F with it would have to exit the case somehow. There are the keyloader pins.......hang on donning the asbestos suit.......... Sound like you are all in on the SB9600 interfacing. When I referred to "single ended", I should have said "not differential". There are points on the? option connector that look like they connect to circuitry in the radio that does the same job as the SN65176BP. TTL TX/RX lines referenced to gnd, with busy (bidirectional signaling). The reference to an outboard AT or PIC to handle the SB9600 commands was to hand off dealing with the busy line and send? properly timed pre-formatted packet(s) to trigger mode change/read EEPROM. A simple "doit" command from the Pico via I2C was what I was thinking. Let the AT/PIC deal with any busy buss issues. Might be useful to monitor COS etc and I2C that back to the Pico as well. If SB9600 is to play a bigger role than I was thinking, this would be unnecessary.....and does add another n MHZ clock to the inside of the radio case. I think the Pico would be a perfect fit if we had just a bit more IO pins. I believe the much (much) slower, and higher pricepoint MiniMega2560 has enough I/O for everything we want. They are no Teensy for sure, but aree available, and half the price even if you could get a Teensy....and native 5v device to boot...... Tapping the LED and BootSel on the Pico does add complexity for those lacking that skillset, but so does soldering SMTs. In for a penny, in for a pound I guess. Working with old school parallel HW in a world that natively and almost exclusively speaks multi serial formats is the real challenge. I dont care for serial/parallel anything either. It is messy, HW wise and code wise. The addr lines consumes so much of the I/O, it looks like our wants/needs are greater than our haves. How are you invisioning loading the initial codeplug data and maintaining the configuration? I've been tagging up on some things I've been putting off, but have taken a bit of time to research the PL side of this some more. Because the RSS plays "cup and ball" games with the PL value storage, alterations made outside of the RSS will get wiped if any PL settings are modified with the RSS. The behavior is difficult to pin down because the RSS moves around/deletes a lot of stuff when a value is edited/deleted. Maintaining compatibility with how the RSS handles PL may be a challenge. The other big thing is as far as I can tell, is the 16 MPL limit is operationally hard coded (in RSS?). Meaning it is possible to set any number of MPL but the storage area for the mode slaved PL values starts 16 tx/rx sets above the end of 16 MPL tx/rx sets. Writing values to MPL 17 and up with the RSS begins overwriting the modeslaved PL data. For maximum compatibility I've been working with a 2k codeplug image. The RSS that is modified to allow 32 MPL only allows it for 8k images. I have not determined if the overwriting issue exists with the 8k version. I'm still not done exploring...as time permits. |
Sound like you are all in on the SB9600 interfacing. When I referred> to "single ended", I should have said "not differential". There are > points on the option connector that look like they connect to > circuitry in the radio that does the same job as the SN65176BP. TTL > TX/RX lines referenced to gnd, with busy (bidirectional signaling). It does seem like it might reduce parts count if we tapped the SB9600 bus at a point where it's single ended. I haven't studied the schematic yet to see where / if that's possible. > I believe the much (much) slower, and higher pricepoint MiniMega2560 > has enough I/O for everything we want. "Much slower" in this case means "about the same speed as the PIC on the original Xcat -- roughly 1/8 the speed. The higher pricepoint is like eight times the price of the Pico. It's a hell of a tradeoff for getting 5V i/o, especially given how simple the necessary design appears to be. I also suspect getting the Mega to work in the x9k version is impractical: Skip said getting the timing right for the old X version was tricky. Part of the idea here was to do a next-generation X device, learning along the way, before doing an X9k device. > How are you invisioning loading the initial codeplug data and > maintaining the configuration? If the X9kcat can emulate an eeprom, then the "how" doesn't really matter -- RSS works, but so will anything else that can pretend to be RSS. If it additionally has a command set accessible over some sort of (probably serial) channel, whatever that may be, then there's an additional way code plug data could be shoved in. De |
It does seem like it might reduce parts count if we tapped the SB9600> bus at a point where it's single ended. I haven't studied the > schematic yet to see where / if that's possible. Specifically, having now looked, single-ended versions of the /TX DATA and RX DATA are available on the accessory connector next to the CPU. Otherwise, based on the observed implementation in the radio, we'd need an op-amp and supporting passives for receive, and two or three transistors and supporting passives for transmit. De |
|
Hi Group,
toggle quoted message
Show quoted text
Just a quick note, more later... I would really like to keep the differential driver so we can **ALSO** use the same board with different firmware as an external protocol converter. CV-I <-> SB9600 and Doug Hall -> SB9600. And who knows ... drum roll... look at all those now unused GPIOs that go to header .. can you envision them hooking up to an LCD and keypad ??? I'll bet you CAN! 73's Skip On Thu, Aug 18, 2022 at 5:33 PM Dennis Boone <drb@...> wrote:
|
> How are you invisioning loading the initial codeplug data andCurrently the write line isn't connected and the level converters aren't bidirectional so the X9kcat can't be written to by RSS in the usual manner. Additionally there's the open question of if the radio writes to the EEPROM during normal operation. This may be a fatal error in the currently proposed design. **IF** it is possible to get or generate a RAW EEPROM image from the RSS disk file then that could be loaded over SB9600 via a protocol converter or we could flash it using the USB port with the initial firmware. Targeting a 2K radio might be a necessity if write support is needed. BTW: I bought a high band X9000 yesterday, it should be here next week. I don't have a control head or cable yet... 73's Skip WB6YMH |
Sound like you are all in on the SB9600 interfacing.Yes, I'm convinced. I think we so we can get the radio re-read the mode data when it's changed if nothing else. It shouldn't be difficult to deal with the timing on the Pico directly. Handing it off to another processor would still require Tx and Rx lines so we might save one pin. Tapping the LED and BootSel on the Pico does add complexity for those lacking that skillset, but so does soldering SMTs.The larger SMT parts aren't impossible to hand solder, but I do hope that someone might fill Lee's roll and offer built and tested boards for those who would want that. Once we have a workable design we can sort out the SMT vrs DIP issues. Adafruit also has "breakout" boards that we could use... not my preference but something to think about. Excellent work so far! Getting a handle on this is essential to say the least! The orignal X was a cake walk since all of reverse engineering had been done when I moved on from Micors to Syntors! 73's Skip WB6YMH |
|
On Thu, 18 Aug 2022, swguest via groups.io wrote:
Sound like you are all in on the SB9600 interfacing.According to documentation I read somewhere at one time, SB9600 is essentially half-duplex, so while the bus driver and bus reciever are "full duplex", it is for jabber and collision detection. I think it's documented in the Siren/PA amplifier manual, e.g. HLN1185. -- Kris Kirby, KE4AHR Disinformation Architect, Systems Mangler, & Network Mismanager |
According to documentation I read somewhere at one time, SB9600 is> essentially half-duplex, so while the bus driver and bus reciever are > "full duplex", it is for jabber and collision detection. I think it's > documented in the Siren/PA amplifier manual, e.g. HLN1185. I know it's covered in the Microcomputer section of the service manual. Wouldn't surprise me if each peripheral device manual covered it too. There's a busy line used for claiming the bus, and then the radio monitors the transmitted data to make sure it receives what it sent, or it retries. De |
to navigate to use esc to dismiss