开云体育

I would prefer seeing the discussion.

Joe M.

I will have to look at the data again but if I recall correctly it's part of the 4 but data word I believe. I recall doing a (if frequency is between.... Then bit high or low) type thing. It was then bit masked with the parallel data.?

the second arduino which ingested that data and did the math to

> convert to the corresponding parallel data lines into the synthesizer
> divider.

What did you do about the VCO V-bits?

De

I just found this:??are you guy's aware of it?? I remember searching and searching for SB9600 "back in the day" and finding little., times have changed!

I think my Spectra speaks SB9600 ... I sense a time sink coming.

73's Skip WB6YMH

Let's see... 2K x 8 requires 19 GPIO lines (11 address + 8 data). 8K
x 8 requires 21.

The ESP32-S3 (latest chip) has 45. That's the raw chip, the modules
use some of the GPIO internally and don't bring everything out. The
ESP32-S3-WROOM-1 module brings out 36 GPIOs.

My memory was faulty, it ONLY has 240 Mhz dual core CPUs, not 270. It
has WiFi and Bluetooth but the antenna is part of the module and RF
isn't going to get from a buttoned up case. Maybe far enough??
Personally I would prefer routing a serial port out like we did with
the Xcat rather than having an "intentional emitter" inside of the
radio.

GPIO0->GPIO7 - EEPROM data.
GPIO8->GPIO15 - bottom 8 bits of address line
GPIO16->GPIO20 - top 5 bits of address line
GPIO21 - chip select.

There are a couple of gotchas of course... The ESP32 is NOT 5 volt
tolerant so there would need to be some level conversion (just a bunch
of FETs perhaps?). Additionally some of the pins are strapping pins
that have special meaning at power up. For example if GPIO0 is held
low at reset then the ESP32 enters boot mode.

So my napkin says it can be done, but not as cleanly as just hooking
up the pins.

73's Skip WB6YMH

Emulation. It's the only viable option. Otherwise, you have to forego all the CTCSS/DCS, and whatever I/O and options the radio is capable of and reproduce them with other devices since the radio's uP does the signalling processing. I think using the radio's native capabilies is the simples, cleanest and most cost effective option.

Casey, are you on the "emulate the exisiting EEPROM" path or the "hijack the synth registers and latches" path?

As a die hard analog dinosaur I concur. These beasts were built to survive, and have, I see you've found the RSS that allowed 32 MPL. I think that was the 255 mode version. As the fuzzy clears a bit from my memory, I made an error (or two or more...lol)
A 2k EEPROM can hold up to 64 (not 255) modes if one ventures above the 32nd mode's data space. An 8k EEPROM can hold up to 255 mode w/o the 255 RSS quirks if you venture above the (stock for and 8k) 64th mode's dataspace. The byte that sets the MPL count will go to FFh too, but I think you will run out of codeplug? before you get that many in. Also, I think the max modes the CH will handle w/alpha tags is 224 not 240.
As built? it is a challenge. You cant get to the EEPROM from the "outside" without complying with RSS/SB9600 rules and protocols, and that'a a whole 'nother can o' worms.
An in circuit EEPROM emulation scheme like Casey and Skip are referring to with a accessible port to the outside world, in the case of an ESP32, TCP/IP over WiFi has promise.
I'm not familiar with the ESP device(s), or it's IO capabilities. I had no idea it was a dual core uP at 270mhz.
. That smokes the Teensy devices I was looking at a few years back, although I bet it's a 3v device so there;s some level transition needed as well if so.

Yup been there done that, the data field sort of bleeds down the screen:

"Also, the PC's screen goes wonky (that's a technical term) when you enter MPL data > than about 20. Keep up with where you are and it will enter the data as expeted. The RSS display routine wasnt written to handle the extra fields and the NL/CR functions are out of sync with the data fields. No biggy, pay attention, it will work."

I got interested in LB Syntor X9000 only recently, last couple of years. This put me about 15 years behind the curve on the knowledge base. I probably spent hundreds of hours researching every aspect of programming these, and downloading various versions of RSS that "sorta worked". I should add my DOS setup is also 15 (30?) years past its prime. My backed up spare IBM PS/2 pizza box having died in storage.? So I got a lot of help from Andy Brinkley, John W1PGO and other folks who live and breathe X9K.?

These radios have outlived the Spectra model and the Low Band radio is especially unique.

It would be great to be able to program and control these radios from a modern interface and be able to discard some of the aged control head group.

I meant the addy buss line in the radio. If I understand what you did you were

"serving" specific EEPROM data as requested the uC via the PIC's GPIO lines? Still had to know what addy the uC wanted and still had to put that data on the radio's buss lines in a timely manner, before it released the original EEPROM's CS line and went off to do other things. A dual core 270mhz uC would/should be plenty to process everything before the Hitiachi could blink. Does the ESP32 have enough I/O lines to do every thing in parallel?

BTW the EEPROM is connected to the F8's GPIO ports, not its memory bus.

Skip

On Thu, Jul 28, 2022 at 8:11 PM Skip Hansen via groups.io
<skip@...> wrote:

You have it right Casey. The Xcat emulates the 2K x 8 EEPROM. The
same concept could be used for the X9000, but of course the EEPROM
contents should have to be fully understood or at least the contents
we need to modify. The giants had already figured out the original
X's layout before I got involved. Getting the timing right was a
challenge, but that was with a 20Mhz PIC. With a 270 Mhz dual core
ESP32 it might be a little easier.

Skip

On Thu, Jul 28, 2022 at 7:47 PM Casey Crane <ccrane148@...> wrote:

My thought is to take out the EEPROM entirely and present a dynamically changing equivalent of it to the uP in sync with its EEPROM read requests. I believe this is what the XCAT does.

You have it right Casey. The Xcat emulates the 2K x 8 EEPROM. The
same concept could be used for the X9000, but of course the EEPROM
contents should have to be fully understood or at least the contents
we need to modify. The giants had already figured out the original
X's layout before I got involved. Getting the timing right was a
challenge, but that was with a 20Mhz PIC. With a 270 Mhz dual core
ESP32 it might be a little easier.

Skip

I remember asking Skip about that, way back when..... he will be back and fill us in I sure.
As I recall he saqid that the timing was? a challenge. I think he uses the EEPROM in the 16F877? ( I dont recall which PIC for sure and I dont know where I put the Xcat schematic? ATM). The X runs really slow ~1 mhz, and doesnt have any "houskeeping" duties. so sneaking in to write to the onboard EEPROM between having to serve EEPROM data to the uC on request was comparitively easy. The X9000 is somewhat faster and is using the addy/data lines all the time.

My thought is to take out the EEPROM entirely and present a dynamically changing equivalent of it to the uP in sync with its EEPROM read requests. I believe this is what the XCAT does.

To emulate an RSS write, or read for that matter, one would have to "snoop" the SB9600 stream, between the RSS in numerous configurations and the radio (for differentail analysis) to decipher what it was telling the uC to do per the contents of the codeplug, then figure out how to tell it to do what WE want it to do, and where WE want it done
It would be a challenge to say the least. That would all have to be sorted before app development could even begin....
In a real world service you shouldnt need to constantly write to the EEPROM. They do have a lifespan, but it's not unresonably short if properly managed.

How many times could this be done without damaging the EEPROM? Could

> a replacement EEPROM be installed that will tolerate such abuse?

IIRC the radio may write certain things like last phone number dialed
into the EEPROM during operation.

De

Well wasnt that special....lol
Skip did we exceed our Io bandwidth break the io server?
No wait! Let me check NTD news.
It was probably the CCP stealing all this high tech IP we are discussing.

@ RFI-EMI-GUY
16 MPL limit....no, but I'll need to qualify that.
First, as has been mentioned by others, I too have an acute case of CRS as in "Why did I walk in this room, or What did I have for breakfast....sometimes I truely cant remember. Would be funny if it wasnt so sad.
So,? boilerplate disclaimer....it's been at least 3 maybe 4 years ago since I even? took a poke at any of this.
Back on topic...MPL count is set by a byte on zero page of the memory, somewhere before 0Fh.
Change that and it sets the MPL count the RSS will let you enter.
Two caveats
1- Checksum...that can be delt with. If not the RSS will complain and will NOT save or fix it. If the CP is hex edited and the CS is not corrected the RSS will not open the file.
2- What function owns the memory that the RSS will now allow you to write PL data in?
In a bare bones operation, no encryption, no siren, VRS control, MDC and DTMF etc it would likely be fine. I have not mapped those functions so I cant say if they use that space or not, or if anything does.
Also, the PC's screen goes wonky (that's a technical term) when you enter MPL data > than about 20. Keep up with where you are and it will enter the data as expeted. The RSS display routine wasnt written to handle the extra fields and the NL/CR functions are out of sync with the data fields. No biggy, pay attention, it will work.
The other issue is the CH side. The memory space for the "alpha tags" gets screwy too. Like programming more modes (240?) than the CH has space to store the alpha tags. It works, but looks like crap on the CH.
There is a means to bump mode count to 255. Same deal. A byte on zero page controls the number of modes the RSS will let you enter in setup. Again same deal with the original owner of the memory space and the CH alpha tag issue.
Ever done the "increase the scan member limit" hex edit in Spectra/MCS/MTS etc RSS? Same thing only in the codeplug not the RSS. BTW the scan limit is a hard 64 on a mode by mode basis, unless you get the 128/255 RSS and FW. But that a totally different dog to kick.

So, 255 modes w/32 (or more) MPL in a 2k 2816 is possible, if the original owners (if any) of the memory real estate arent using it.
The ability to edit EEPROM memory locations "on the fly" is the cat's a$$ here. We know where the data resides in/for each mode (at least the tx,rx,alt tx freqs, the mode slaved tx/rx PL data, the 8 bytes per mode that are bit mapped to enable/disable the 1st 64 modes that can be scanned when that mode is selected, and the actual MPL data location.)
We know how to calculate the hex values needed for these values, and we know where and how to calculate and correct the checksum so the radio doesnt throw a codeplug checksum fault on the next bootup.
There are other? functions in the per mode byteset like TOT and Priority scan, I've not set out to find so far.
I agree, all I/O functions seem to be via SB9600 and done in or thru the CH and VIP ports.
Finding a siren cable may be as hard as finding an actual drawer/CH cable.
A thought about dual drawer operation.
I *think* I remember...lol that the radio1/radio2 was programmed in the CH with certain CH RSS. Again in the 1st line of the CP zero page a byte? or bit was set or cleared telling the radio if it was radio1 or 2. I think I have the CH RSS "somewhere" that sets up the radio1 or 2 button.
There was SP RSS and FW for this as well but I want to say the guy I learned this from said there was a work around. I'll have to scour my emails to see if I still have that exchange.

I agree, hardware hacks are not the desired path, but it's the only way to wedge ourselves in to the places needed to manipulate the system to our liking.
Or, it's possible Casey and I are just batsh*t crazy mad scientists....lol