开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. Xcat
  2. Messages
Expanded Topics Messages Polls
Date
Re: 2K, 4K or 8K EEPROM support for the X9000 ?

 


Addendum.......
@ Skip,
Even the I2C lines could be optionally liberated.
I2C support isnt for Doug Hall exclusively, but if Doug Hall is deselected and you have no express need for it spare then out for future use by the Pico as needed.
Re: 2K, 4K or 8K EEPROM support for the X9000 ?

 

@ Skip,
Was already thinking on that........
What if you made the genric protocol an option in the initial settings?
If selected only 2k codepulgs are available. Same at the SyntorX/Xcat.
To support 8k codeplugs deselect Doug Hall support and re-use those GPIO lines as needed.

.I dont know the major config for existing Doug Hall installations, but OEM Xcat is (2k)? 32 mode limit as built.
Do they use mode selection for frequency control or primarily VFO mode feature?
All the oter feature should be unaffected.
2K, 4K or 8K EEPROM support for the X9000 ?

 

If we support an 8K EEPROM on the X9000 and we don't have enough pins left to do Doug Hall, or CI-V.

Do we really need 8K support ?? If we only support 4K then we will have 2 pins left that we can use.

If we only support 2K then we will have 3 pins left over.

I'm assuming that if the radio has a 8K EEPROM we need the entire 8K and can't just cheat and only support 1/2 of it.? Of course we could change the EPROM but...

What's most common in the "market"??

73's Skip WB6YMH
Re: Xcat NG rev A

 

Yes. When enabled the Xcat sends a CI-V packet everytime the squelch
> opens or closes along with the channel. I used that to update the
> title bar of the Windoze app so it would show what mode it was
> listening to when scanning was enabled.

Ohhh, it's coming back to me. I mad xcatctl's `cosmon` for listening
for these.

De
Re: Xcat NG rev A

 

On Fri, Aug 12, 2022 at 7:22 PM Dennis Boone <drb@...> wrote:

> > 3. You don't have pull-ups on A8 and A9, Mode 6, or COS. Pretty sure I
> > don't understand this.

> Both of those are Syntor X weirdnesses and something we missed in the
> legacy Xcat, there are pullups on A0->A7 in the Syntor X code plug but
> not on A8, A9. Maybe it's an F8 thing.

I think part of the answer to A8/A9 can be found on PDF page 11 of the
F8 data book I uploaded to the files area the other day: they're on port
1, the others are on port 4. (The rest of the answer is probably locked
up in the way the firmware sets the output buffering.)

It looks like Mode 6 has pull-ups in the radio.

And COS is an input?
Yes. When enabled the Xcat sends a CI-V packet everytime the squelch
opens or closes along with the channel. I used that to update the
title bar of the Windoze app so it would show what mode it was
listening to when scanning was enabled. It's probably not something
for a "real" CI-V bus with multiple radios, but it's handy.


> > 4. We're getting 3V3 from the RPi?

> Yes, there's a regulator on the Pico, I'm kind of assuming there's
> enough head room to be able to power our level translators (and it's
> also something I "borrowed" from the C64 project).

Pico datasheet says it can probably do 300mA. The '244 sheet seems to
indicate that a typical current is 16mA. There would seem to be plenty
of headroom.
Excellent! I hadn't looked, that make me feel better!

73's Skip WB6YMH


De
Re: Xcat NG rev A

 

3. You don't have pull-ups on A8 and A9, Mode 6, or COS. Pretty sure I
> > don't understand this.

> Both of those are Syntor X weirdnesses and something we missed in the
> legacy Xcat, there are pullups on A0->A7 in the Syntor X code plug but
> not on A8, A9. Maybe it's an F8 thing.

I think part of the answer to A8/A9 can be found on PDF page 11 of the
F8 data book I uploaded to the files area the other day: they're on port
1, the others are on port 4. (The rest of the answer is probably locked
up in the way the firmware sets the output buffering.)

It looks like Mode 6 has pull-ups in the radio.

And COS is an input?

> > 4. We're getting 3V3 from the RPi?

> Yes, there's a regulator on the Pico, I'm kind of assuming there's
> enough head room to be able to power our level translators (and it's
> also something I "borrowed" from the C64 project).

Pico datasheet says it can probably do 300mA. The '244 sheet seems to
indicate that a typical current is 16mA. There would seem to be plenty
of headroom.

De
Re: Xcat NG rev A

 

You're _way_ better at this than I am.
I've probably just had more experience. I started out life as a hardware guy...

Questions to help me understand the magic:

1. You'd mentioned SN74LVCH8T245 bus transceiver / level shifter chips.
You did this circuit with SN74LV244APWR instead because the address
lines are always outputs, and the data always inputs, and you don't need
bidirectional translation, right?
Correct (and I just copied it from the C64 project).

2. You only have pull-ups on the address lines. This is because the
outputs need to be lifted, but for the inputs, the '244 chips are 5V
tolerant?
3. You don't have pull-ups on A8 and A9, Mode 6, or COS. Pretty sure I
don't understand this.
Both of those are Syntor X weirdnesses and something we missed in the
legacy Xcat, there are pullups on A0->A7 in the Syntor X code plug but
not on A8, A9. Maybe it's an F8 thing.


4. We're getting 3V3 from the RPi?
Yes, there's a regulator on the Pico, I'm kind of assuming there's
enough head room to be able to power our level translators (and it's
also something I "borrowed" from the C64 project).


5. The 'LV244 doesn't seem to be available in DIP?
I haven't gotten into the physical aspects of the board yet. DIPs are
getting rare, The larger surface mount parts aren't all that hard to
solder, but certainly changing out parts for buildability is something
to look at before Dave starts laying out the board.


Thanks for all of your effort!
This is the first schematic I've done in years ... it was fun learning
a bit of Kicad.

Thanks for looking!

73's Skip WB6YMH


De
Re: Xcat NG rev A

 

I've attached the first cut of a schematic for a possible Xcat NG for
> the original X. With the appropriate firmware it will retain all of
> the features of the legacy Xcat.

Skip,

You're _way_ better at this than I am.

Questions to help me understand the magic:

1. You'd mentioned SN74LVCH8T245 bus transceiver / level shifter chips.
You did this circuit with SN74LV244APWR instead because the address
lines are always outputs, and the data always inputs, and you don't need
bidirectional translation, right?

2. You only have pull-ups on the address lines. This is because the
outputs need to be lifted, but for the inputs, the '244 chips are 5V
tolerant?

3. You don't have pull-ups on A8 and A9, Mode 6, or COS. Pretty sure I
don't understand this.

4. We're getting 3V3 from the RPi?

5. The 'LV244 doesn't seem to be available in DIP?

Thanks for all of your effort!

De
Xcat NG rev A

 

I've attached the first cut of a schematic for a possible Xcat NG for
the original X. With the appropriate firmware it will retain all of
the features of the legacy Xcat.

Changes:

1. Doug Hall UF outputs are now optionally provided by an I2C port
expander. (For example of of these
)

2. The CI-V interface now uses 5 volt levels rather than RS-232.
Additionally a true single wire CI-V interface can be created by
simply tying the CI-V rx and tx line together.

3. The PCB will probably need use a ribbon cable to connect to the
code plug connector rather than just plugging into it for mechanical
reasons (TBD).

This project will only move forward if there's enough interest from
the group to make it worthwhile.

Comments please!

73's Skip WB6YMH

xcat_ng_rev_A.pdf
xcat_ng_rev_A.pdf

Re: XCat NG changes

 

The Elecraft KAT500 tuner uses CI-V for communications.

tnx
Mike / K5JR
Alpharetta GA

On Aug 11, 2022, at 9:36 AM, Skip Hansen <skip@...> wrote:

?I don't remember the exact timing of Doug Hall, but it's basically SPI
so dedicated lines is probably the best bet.

For wireless/BT link I'm thinking of an ESP32 or Linux based Raspberry
Pi external to the radio as a gateway.

Another issue that I just remember from the legacy Xcat project. CI-V
is supposed to be a SINGLE wire interface. When I did the original
Xcat I was planning on tying Rxd and Txd together and dynamically
controlling the output enable. Great plan, right? It turned out that
when you enabled the UART function the PIC helpfully enabled the
output for you so you didn't need to remember to do it ... which made
it impossible to do a true CI-V without additional hardware. I'll
make sure we can do real CI-V as well as the two wire version we've
been using for the Xcat.

Much to my surprise USB to CI-V cables are still readily available
which would make it easy to interface to modern PCs or a Linux based
Raspberry Pi.

73's Skip

On Wed, Aug 10, 2022 at 8:40 PM swguest via groups.io
<swguest@...> wrote:

On Wed, Aug 10, 2022 at 07:21 AM, Skip Hansen wrote:

I feel much better about this version as we don't lose any
functionality and I2C opens new possibilities.

Feedback please!

Sorry for the crickets from me. I've been down so many rabbit holes today I might have to change my name to Alice. I've been on the hunt thru my digital media swamp. I had to investigate everything I didnt recognize....Yup lots of rabbit holes.

So..the revision, I2C is good. No extra CS lines needed for multible devices like SPI.
IIRC I2C used to be 400khz max, may be more now, but that should handle any expansion one would want.

Doug Hall protocol needs discrete sync lines even using I2C?

The (future) wireless/BT link will have to be built out on the SB9600 command set....or?
Re: XCat NG changes

 

I don't remember the exact timing of Doug Hall, but it's basically SPI
so dedicated lines is probably the best bet.

For wireless/BT link I'm thinking of an ESP32 or Linux based Raspberry
Pi external to the radio as a gateway.

Another issue that I just remember from the legacy Xcat project. CI-V
is supposed to be a SINGLE wire interface. When I did the original
Xcat I was planning on tying Rxd and Txd together and dynamically
controlling the output enable. Great plan, right? It turned out that
when you enabled the UART function the PIC helpfully enabled the
output for you so you didn't need to remember to do it ... which made
it impossible to do a true CI-V without additional hardware. I'll
make sure we can do real CI-V as well as the two wire version we've
been using for the Xcat.

Much to my surprise USB to CI-V cables are still readily available
which would make it easy to interface to modern PCs or a Linux based
Raspberry Pi.

73's Skip

On Wed, Aug 10, 2022 at 8:40 PM swguest via groups.io
<swguest@...> wrote:

On Wed, Aug 10, 2022 at 07:21 AM, Skip Hansen wrote:

I feel much better about this version as we don't lose any
functionality and I2C opens new possibilities.

Feedback please!

Sorry for the crickets from me. I've been down so many rabbit holes today I might have to change my name to Alice. I've been on the hunt thru my digital media swamp. I had to investigate everything I didnt recognize....Yup lots of rabbit holes.

So..the revision, I2C is good. No extra CS lines needed for multible devices like SPI.
IIRC I2C used to be 400khz max, may be more now, but that should handle any expansion one would want.

Doug Hall protocol needs discrete sync lines even using I2C?

The (future) wireless/BT link will have to be built out on the SB9600 command set....or?
Re: XCat NG changes

 

On Wed, Aug 10, 2022 at 07:21 AM, Skip Hansen wrote:
I feel much better about this version as we don't lose any
functionality and I2C opens new possibilities.

Feedback please!
Sorry for the crickets from me. I've been down so many rabbit holes today I might have to change my name to Alice. I've been on the hunt thru my digital media swamp. I had to investigate everything I didnt recognize....Yup lots of rabbit holes.

So..the revision, I2C is good. No extra CS lines needed for multible devices like SPI.
IIRC I2C used to be 400khz max, may be more now, but that should handle any expansion one would want.

Doug Hall protocol needs discrete sync lines even using I2C?

The (future) wireless/BT link will have to be built out on the SB9600 command set....or?
Re: Has anyone fully decoded the X9000 memory mapping?

 

开云体育

There’s an in-depth explanation of the X9000 scanning nuances in the full X9000 service manual if haven’t seen that yet.?

tnx
Mike / K5JR?
Alpharetta GA

On Aug 8, 2022, at 1:38 PM, Casey Crane <ccrane148@...> wrote:

?
As for the synthesizer the radio updates it every 20 milliseconds regardless of mode change to maintain stability in the event some transient voltage or whatever corrupted something. My thought was a mode change would occur by way of changed emulated eeprom data representing mode 1 of only a 1 mode codeplug. I'm not seeing any reason for more than one mode of data since we are changing it dynamically and there would be no reason to chase data all over the memory map when we can just point it to one spot and change that.?

Scanning is something I've been mulling over. Can you? build a 1 mode codeplug and have a 1 mode scanlist? If so I would assume in scan mode the radio accesses and updates the synthesizer faster than the 20 milliseconds refresh static rate (how fast do they scan?). If so, then presenting emulated mode 1 data at a faster changing rate might work out as long as the radio is polling faster since it's thinking it's scanning. Of course we would have to keep it all in perfect time with what the processer wants but I assume that would be all part of the emulation process and dictated by the CE activity.



On Mon, Aug 8, 2022 at 12:08 PM Skip Hansen <skip@...> wrote:
Good points!? I had forgotten about needing to get the radio to
re-read the mode info, ugh.? In reality it might be worth taking this
approach just to solve the refresh problem.

An EXTERNAL to the radio ESP32 could provide CI-V to SB9600
translation plus be the basis for an Bluetooth or WiFi interface to
phone/tablet or head using app.

And ... ESP32 boads with RS485 support? exist already for $21.57
().? It just so happens I have
two sitting on my self from a work project ... Damn them squirrels !

73's Skip WB6YMH


73's Skip WB6YMH

On Mon, Aug 8, 2022 at 9:50 AM Dennis Boone <drb@...> wrote:
>
>? > Yea, but then you have to conform to the SB9600 protocol, yuck! For
>? > computer control you'd also need a SB9600 "gateway" or a rib and a
>? > serial port, again yuck.
>
> Going back to Skip's comment, a couple of thoughts, devil's advocate:
>
> 1. But you don't have to find a hack/slash way to get your control path
> out of the radio, because it's already there, and it's compatible with
> the whole existing system.
>
> 2. One way to get the radio to notice new mode data set by the external
> frequency agile control setup would be for the x9000cat-2022 to spoof a
> mode change onto the sb9600 channel.
>
> FWIW.
>
> De
>
>
>
>
>
Re: Has anyone fully decoded the X9000 memory mapping?

 

That would be great.


On Wed, Aug 10, 2022 at 7:02 PM Joe M. <mch@...> wrote:
I might be able to dig out the code I used.

Joe M.

On 8/10/2022 7:08 PM, Casey Crane wrote:
> Weird in as how to code it into software for an encoder/decoder.
>
> On Wed, Aug 10, 2022 at 5:58 PM Joe M. <mch@... <mailto:mch@...>>
> wrote:
>
>? ? ?What is weird about it? I think I had both encode and
>? ? ?decode working on a Maxtrac project about a decade ago.
>
>? ? ?I will have to dig out the schematic to see how I connected it.
>
>? ? ?Joe M.
>
>? ? ?On 8/10/2022 6:28 PM, Casey Crane wrote:
>? ? ? > I wish DPL wasn't so weird. If I could get a handle on that then
>? ? ?I could
>? ? ? > start looking at the direct VCO drive option again and forego all
>? ? ?the rest.
>? ? ? >
>
>
>
>
>
>





Re: Has anyone fully decoded the X9000 memory mapping?

 

I might be able to dig out the code I used.

Joe M.

On 8/10/2022 7:08 PM, Casey Crane wrote:
Weird in as how to code it into software for an encoder/decoder.
On Wed, Aug 10, 2022 at 5:58 PM Joe M. <mch@... <mailto:mch@...>> wrote:
What is weird about it? I think I had both encode and
decode working on a Maxtrac project about a decade ago.
I will have to dig out the schematic to see how I connected it.
Joe M.
On 8/10/2022 6:28 PM, Casey Crane wrote:
> I wish DPL wasn't so weird. If I could get a handle on that then
I could
> start looking at the direct VCO drive option again and forego all
the rest.
>
Re: Has anyone fully decoded the X9000 memory mapping?

 

Weird in as how to code it into software for an encoder/decoder.


On Wed, Aug 10, 2022 at 5:58 PM Joe M. <mch@...> wrote:
What is weird about it? I think I had both encode and
decode working on a Maxtrac project about a decade ago.

I will have to dig out the schematic to see how I connected it.

Joe M.

On 8/10/2022 6:28 PM, Casey Crane wrote:
> I wish DPL wasn't so weird. If I could get a handle on that then I could
> start looking at the direct VCO drive option again and forego all the rest.
>





Re: Has anyone fully decoded the X9000 memory mapping?

 

What is weird about it? I think I had both encode and
decode working on a Maxtrac project about a decade ago.

I will have to dig out the schematic to see how I connected it.

Joe M.

On 8/10/2022 6:28 PM, Casey Crane wrote:
I wish DPL wasn't so weird. If I could get a handle on that then I could start looking at the direct VCO drive option again and forego all the rest.
Re: Has anyone fully decoded the X9000 memory mapping?

 

I wish DPL wasn't so weird. If I could get a handle on that then I could start looking at the direct VCO drive option again and forego all the rest.
Re: Has anyone fully decoded the X9000 memory mapping?

 

I played with software based PL and touch tone decoding at lot and
> while I got a couple of them to work they were NEVER anywhere close
> to as good as a Motorola radio.

Pretty sure you were trying to beat an RC low-pass filter, op-amp
limiter, and hardware counter-timer. The 3870 has event timing built
in, with a base input to the timer unit of 1.8 MHz, and various dividers
and prescalers.

De
Re: XCat NG changes

 

When I was reviewing the pin assignments I thought too bad there
aren't I2C digital pots, we could save a pin ... wait... of course
there are!

I've revised the pin assignments
()
to reflect using an I2C port expander for Doug Hall user functions and
I2C digital pots. The I2C port expander would be external to the Xcat
PCB as would the digital pots.

I feel much better about this version as we don't lose any
functionality and I2C opens new possibilities.

Feedback please!

73's Skip WB6YMH
221 - 240 of 646