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
- Xcat
- Messages
Search
|
Re: DIY Xcats
开云体育Hi Skip, Thank you for giving your blessing to those of us who are brave/crazy in this way. I’ve wanted to do this for some time but didn’t want to step on your (or Lee’s) toes. ? Would you mind answering a couple questions for me? 1.?????? How did you guys program your PICs? Did you do it in a stand-alone programmer before soldering to the PCB, or did you do it via the RS232 serial port on the Xcat? 2.?????? Regarding the Xcat firmware, xcat_v033/xcat.hex, if I wanted to program it in my standalone programmer before soldering, would I use ‘Standard/Extended Intel HEX (*.hex, *.mcs)’ whose checksum comes to 001EA2F4, or force it to read in Binary whose checksum is 000CF1CF? I don’t want to do it incorrectly and not find out until the PIC is soldered in place. ? FYI, my programmer is a Phyton ChipProg-40. ? I like ExpressPCB and that’s what I used to lay out my Xcat ‘clone’ boards. If it works, and I expect it will, I’ll have some spares available if anyone is interested in obtaining them (at my cost) and using them to assemble their own. I’ll also be happy to upload the ExpressPCB .sch and .pcb files to the file section of this group, if you give that your blessing, Skip. I’d be willing to provide programmed PICs for those who are interested, as well as the other parts, but only with your blessing, Skip. ? 73, Brad KB9BPF ? ? From: [email protected] [mailto:[email protected]] On Behalf Of Skip Hansen ? I've uploaded the Xcat schematic and bootloader hex file to the file area. ? This will allow the brave/crazy to build a DIY Xcat.?? ? NB: We missed the need for pullup resistors on A0 to A7 in the original design.?? On a "real" Xcat this was fixed by adding a 2.2K SIP resistor pack on the back? of the connector (pins 9 to 16). ? The needed resistors are **NOT** shown on the schematic. ? 73's Skip WB6YMH |
|
Re: Xcat 9000 Rev A
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 |
|
Re: Xcat 9000 Rev A
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 |
|
Re: Xcat 9000 Rev A
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 |
|
Re: Xcat 9000 Rev A
> 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 |
|
Re: Xcat 9000 Rev A
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:
|
|
Re: Xcat 9000 Rev A
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 |
|
Re: Xcat 9000 Rev A
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 |
|
Re: Xcat 9000 Rev A
?@ 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. |
|
Re: SB9600 tools
I can do that later this coming weekend. I did it earlier but didn't save the file and I'm out of town.? On Wed, Aug 17, 2022, 12:32 Skip Hansen <skip@...> wrote: I've written a couple of python script to help me understand the SB9600 protocol better.? So far I've only used a Spectra.? |
|
SB9600 tools
I've written a couple of python script to help me understand the SB9600 protocol better.? So far I've only used a Spectra.?
Unfortunately one thing that I've determined is that RSS almost always uses the encrypted address option when accessing the EEPROM.? Since "If D7=1, then the option should prepare to receive address/data information (via MEMADD) which has been encrypted based on some previously determined algorithm." this is a dead end since I don't (currently) know what the "?previously determined algorithm" is! If someone would like to capture the traffic between RSS and an X9000 while reading the code plug that would be useful. I've put my scripts on github I haven't bought an X9000 yet ... but I AM looking at a couple. 73's Skip WB6YMH |
|
Re: firmware for the original Xcat
 Thank you Skip, this is awesome. On Mon, Aug 15, 2022 at 1:40 PM, Skip Hansen <skip@...> wrote: I've put the source for the firmware for the original Xcat on github for anyone that is interested (). |
|
Re: X9000 Codeplug Structure Information
From a uCs perspective that needs to output 4-bit data, it comes> pre-parsed and saves some shifting and ANDing steps to make it > presentable. It has to be balanced, of course, with limited EPROM space. If you _really_ wanted to minimize bit fiddling time, you'd put each four-bit unit in its own byte. Clearly they didn't want to double the space used, though. I'd love to know more about that divider chip. It seems like a fairly custom sort of thing. Guess I should spend some quality time with the databooks on Bitsavers to see if I can find anything related. > I remember seeing an article on how to replace the narrow DIP with a > DIY std wide DIP socket for "modern" EEPROMs. There are adapters that make a 27xx (or 28xx) ROM usable in a one-shot PROM socket. Among other places, Sandy Ganz maybe? had one for original Syntor. The original used two PROMs, one for frequency data, and one for PL. > Did you ever write anything to generate the codeplug data the > original Syntor? I did not. Just the X. Pretty sure I have the suitcase programmer ROMs for the original Syntor frequency and PL programming, if anyone is feeling a 6805 disassembly project. Those radios are nowhere near as useful though, in my opinion, because their front ends are far narrower than the X and X9000. De |
|
Re: Xcat 9000 Rev A
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 |
|
Re: X9000 Codeplug Structure Information
@ Dennis, |
to navigate to use esc to dismiss