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.

That interleaved biz the X uses.... I think that was just a brain

> teaser from the engineers for anyone who dared to figure it out...lol

Well, it loads the dividers into the chip 4 bits at a time, so it'd be
loading, masking and shifting anyway. At that point having tx and rx in
the same byte vs having a separate range of bytes for each direction is
largely a wash.

De

@ Dennis,
Yup,
That's pretty much my take on the reason for the differences in codeplug structure as well.
With a different uC, especially not even in the same family would surely be better served if the design was in favor of it's capabilities instead of adapting a structure designed for a completely different piece of HW.

...and the X9000 frequency storage method is about as efficient as you can get considering 10 bits and 7 bit dont fit efficiently in 8 bit bytes.

That interleaved biz the X uses.... I think that was just a brain teaser from the engineers for anyone who dared to figure it out...lol

Yes the math for the synth and the way the data is loaded is identical, as the X and the X9000 are the same from that respect once the data leaves the flip flops.

Have you explored Casey's direct drive of the synthesizer?
The level of complexity used to load the synth is pretty impressive.
I'm pretty sure the designers didnt expect some guy to take a couple of low end $10 experimenter boards and replicate the operation.

I suspect it could be done with one if he used the IDE's serial monitor to input the frequency.

@ Casey,
?I dunno maybe, at least a part of it.
I've seen some really WTH were they thinking designs that I just could not figure the "WHY like this" of the design.

I had a friendly, but heated converation with an EE one time over his design of a particular addition to the system.? I finally said "Mike you are over-engineering this."? to which he said "That's my job."
I replied "You mean to overcomplicate things"? His reply "YES!"
So there you have it. I dont think KISS is even in their vocabulary,...lol
As for uploading your synthesizer project code, Bravo! I have to say I believe that particular equine is in need more abuse.
For anyone interested in the guts of these radios, there is a lot to be learned following your work.
Yeah, the higher level the language the more disconnected you get, but I've done just enough asm to say damn there's got to be an easier way.......lol

Of what I recall looking into PICs, MPLab is a lot like asm.
C+/++ was very abstract to me at first, and still is on some levels.
One generation of DCS systems we had ran on a derivative of Fortran. It looked as Greek to me then as it would today.

I could see no association with the X's formula. Even inverting

> some/part/all, swapping bytes, nothing lined up. I gave up on that
> path shortly since the tx/rx freq storage was so different why expect
> the PL method to match either.

Brute force it is. :)

I've been starting with the theory that a lot of things are going to be
pretty similar, since most of the radio is the same other than the
personality board. It's not really a surprise the the x9k has different
math for PL, since that's generated by the processor, and the clock and
processor type are different. It also makes sense that for a different
processor architecture you might well choose a different storage layout
because the most efficient way to convert stored patterns into pin
outputs probably isn't the same.

However, the "same" theory does work in frequency divider math. Best I
can tell, those calculations come out exactly the same. The way you bit
stuff the results into the code plug after that is different, of course.
This makes sense to me: those bit fields all get stuffed into the same
sort of chip on the same sort of io / interface / rf boards.

De

@ Dennis,
The short answer is the same way I sorted out the what/where/how for the tx/rx frequency bytes, a lot of perseverence, spreadsheet tables, and some serendipitous luck.

If spreadsheets were actually sheets of paper and I owned a paper mill, I'd be my best customer, and broker than I already am.

Finding what/where/how the RSS dealt with PL data was a big part of it. First, I had to get the hex data associated with the entered PL code and the RSS wasnt giving that secret up without a fight.
With the indexed delete/shuffle/move and orphaning of PL codes, the more I changed the codeplug to see a difference, the more cluttered it got with identical, but non indexed values in memory locations that made no sense.

Once I established an abreviated table of codes=values, I could see no association with the X's formula. Even inverting some/part/all, swapping bytes, nothing lined up.
I gave up on that path shortly since the tx/rx freq storage was so different why expect the PL method to match either.

Foutunately the RSS allows .1hz resolution entry which let me build formulas in Excel that could be tightly incremented and analyzed.

Excel is good with that because you can do a dectobin or hextobin conversion and see bit level changes and patterns you cant (or at least I cant) envision in hex or decimal.

I knew there had to be a multiplier like the X does, so I just started with different sets of values until things began to line up.

The cool thing about Excel is it really good like that in that once you set up your formulas, you can do a lot of columns of "drag to increment" and convert the data to columns of various formats at the same time.
I guess you could call it a form of brute force attack.

I dont recall if it was the tx or rx first but I hit pay dirt when the the lower half of byte1 and all of byte2 started consistantly matching the RSS value. It took a while longer to get the other mutiplier but it finally worked out.
I had to experiment quite a bit with the resolution as Excel's floating point function is about as good as a $8 calculator from Walmart.

The math cosistantly adds up to the RSS calcs so it must be close.

Just to give you an idea of physical aspects of our new projects ... here's an legacy Xcat next to a Raspberry Pi Pico.

Maybe it will still be a plug in board after all ...? we will see.



73's Skip WB6YMH

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

I just uploaded the X9000 synthesizer calculator ino sketch to the files. I know it's not germain to this topic but figured it was the latest discussion. My god my mind is strange. I can seem to learn things at a high level rapidly but I can't seem to retain it. I'm looking at the code now it's like someone else wrote it a decade ago. Whew... I got a lot to brush up on. High level stuff like Python is such a cheat. C level stuff is where it's really at to make metal move.

X9000 PL Bytes Worksheet and Calculator posted in the files section.

I'm curious how you derived the PL constants. They seem to differ
slightly from the X ones.

De

The following files and folders have been uploaded to the Files area of the [email protected] group.

• /X9000 files/X9000 PL Worksheet and Calc .rar

By: swguest <swguest@...>

For anyone interested.
X9000 PL Bytes Worksheet and Calculator posted in the files section.

The Doug Hall controller for the radios was a rare thing in 2004 when I designed the Xcat.. It's the INTERFACE that's interesting because most commercial repeater controllers support it.? Doug Hall is actually an extension of the "BCD" interface that predated it.? The "BCD" interface was just a couple of CMOS shift registers that were wired across the BCD switches that some old radios had.?

Other than "real" radios the BCD "programmable" Kenwood tr7400 was one of the best two meter radios of it's day and more than a few found their way to local hilltops.?I had one on my packet BBS for YEARS and it was still working when I got out of the packet racket.

Again it's amazing we're still talking about Syntors !!? I wonder if the engineers that designed them have any idea!

73's Skip WB6YMH

I know at one time the Doug Hall Controller was quite coveted, and if you found one available expect to pay a premium for it.
That was before the numerous uc repeater controller projects were published. I expect there are a lot of lrgacy stand alone installations out there just chugging along as expected.

Being as full featured as possible is always a good thing (from the end users side of the equation)

I too have no idea the most used features for Amateur installations.
You've met the equal compatibility design for the Xcat with 2k support.

The X9000 is really the only application where not having 8k codeplug support could hinder it's abilities.
It may be possible to use in 2k configuration if Doug Hall support was required.

Looking at the addr lines used, 1k emulation operation is not possible for the X9000 to be compatible with OEM RSS, and maybe not at all.

In the OEM configuration for a 2k EEPROM, the PL data storage area is above the 1k boundry.

I bought 3 low band units surplus and they were all 2K from the surplus. I immediately updated to 8K 128 mode. but still have original firmware.? I have several other radios from another ham and suspect they are 8K upgrades. So a bit of a mix depending upon if you buy surplus or from ham.? the control heads are another issue. Some are difficult to bump to 8K thus limiting them. I think having both options is a benefit. my use will be mobile and base, but not remote base control.?

开云体育

guys

Frankly I don't know how existing Xcat owners are suing their Xcats.? Personally I have two use cases:

1. Code plug replacement for my 440 base.? I used the pre-prorgrammed modes 99% of the time but I kept the Xcat connected to my PC so I could tell at a glance what mode was active when scanning.? I also used the VFO capability from time to time.

2. As a "remote base". I used the CI-V mode exclusively with my own software (/g/thelinkbox).? This mode of operation use to be a big thing in the 70's but has largely died out in my area.

I know there are a number of people using Xcats with Allstar systems for remote base operation, AllStar uses the CI-V interface.

I know of a couple of people using the Doug Hall interface with commercial repeater controllers.

I now of ONE person that used the Xcat with a Palomar/Cactus controller.? (BTW the Palomar mode is flaky, the Palomar keyed the radio and THEN changed the frequency.? This causes the Xcat grief since it can't process sync data WHILE the Syntor is actively reading the code plug).

I know of no one who is using a Xcat in a mobile, but I assume there are some.

73's Skip WB6YMH