开云体育

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

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

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.

@ 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.

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

@ 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.

@ 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.

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

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