Re: Has anyone fully decoded the X9000 memory mapping?
toggle quoted message
Show quoted text
On Thu, Jul 28, 2022 at 6:43 PM Skip Hansen < skip@...> wrote: Well, I'm the list owner and I have no objections.? ?It's been a
pretty quiet list for many years. If anyone else has any issues let us
know.
73's Skip
On Thu, Jul 28, 2022 at 3:36 PM Bradley Andrews via
<kb9bpf=[email protected]> wrote:
>
> I'm very interested in what you guys have to say so if it were up to me (it's not) I'd say go ahead and continue your discussion here. Isn't it as good a place as any? Does anyone object?
>
> Brad
> On Thursday, July 28, 2022, 04:31:17 PM CDT, Casey Crane <ccrane148@...> wrote:
>
>
> Yes, exactly. The thing was amazingly fast. The "problem" is the radio took on the attributes of whatever mode was selected at the time. So, if mode 1 was selected, had a PL of 151.4 etc.... if I tuned away to a different frequency those attributes followed, being only the frequency was changing. It would basically require duplicating all the other features of the radio in hardware/software to take advantage of this method fully which is of course absurd.
>
> My thought was to present the uProcessor with one mode's worth of data and then change that data dynamically, allowing the uP to do all the rest of the work. I have the service manual and it appears it has a strobe line which basically thumbs through pages of the eeprom grabbing data for different modes. If it were fed data that we could dynamically update despite whatever mode (eeprom data offset) it's looking for then we could control it all.
>
> As said earlier, life has taken priority and caused a stall on the project but I do have some very nice code I came up with for the Raspberry Pi which I think could be used to feed an arduino as an internal decoder resulting in a very nice full color capacitive touch screen 4.3" user control interface with infinitely configurable mode names, scan lists, search parameters etc... all fed to the radio via a simple lightweight serial interface or perhaps even via one of the bluetooth serial dongle boards leaving only audio paths to be dealt with.
>
> As the solar cycle has heated up it's something that has got me thinking about it all again.
>
> I just don't know if this is the place to discuss it and I don't want to infringe or step on any toes regarding the project this group is about so I should probably start another group so as not to clutter this one.
>
> Casey
>
>
>
> On Thu, Jul 28, 2022 at 4:16 PM swguest via <swguest=[email protected]> wrote:
>
> Bradley,
>? ?Let me see what I can find. This was an X9000 but hardware wise at the point he made the connections the X and the X9000 *should* be the same animal. You will need service manuals for both to pursue the project.
>
> He basicly severed the uC's data/control lines to the synthesizer and injected data calculated by his arduino from info Mike B. shared about the radio's divider/synthesizer operational process.
>
> Again, POC. It would still take a fair amount of designing to hammer out the details and make an operational radio that doesnt resemble an alien autopsy.
>
>
|
Re: Has anyone fully decoded the X9000 memory mapping?
LOL yea the Uniden guy is me.?
The housings are now PETG and have held up fine in 100+ temps in direct Kansas sun on a dash board.
|
Re: Has anyone fully decoded the X9000 memory mapping?
I would have no problem doing the radio side of Bluetooth, but I'm not
a phone app developer. If there's an app developer that's interested
it might be doable.
I even have a cheapish Chinese Android head unit in my car already.
Skip
toggle quoted message
Show quoted text
On Thu, Jul 28, 2022 at 4:21 PM RFI-EMI-GUY <rhyolite@...> wrote:
There was a cheap Chinese dual band mobile on the market a couple years ago that used an Android phone and Bluetooth for the control head. I would post a link if my memory would serve me. The operational aspects were desirable but it was just another CCR as far as the radio unit. Still an attractive idea.
Using an Android device opens up the possibility of leveraging the Infotainment system of newer cars or the use of a cheap tablet with a large screen. It also eliminates the requirement to design a plastic box for a control head made with a cobbled up Arduino/Pi and touchscreen. Someone on another group has done this to control a Uniden scanner and the plastic control heads were 3D printed and did not hold up well to heat. Putting the microcontroller in a metal box near the drawer unit and use BT/Android to facilitate the user interface would be better in my humble opinion.
Thinking way out of the box because I am not a programmer beyond a simple PICAXE design.
Could the solution for FPP be in simply switching the radio to programming mode and loading channel 1 from the GUI? The GUI would have to emulate the RD.EXE RSS. This includes option support like MPL and scan etc..
How many times could this be done without damaging the EEPROM? Could a replacement EEPROM be installed that will tolerate such abuse?
Taking this further, the entire codeplug could be programmed from the GUI in a batch. The codeplug and firmware should be upgraded for 8K / 64 mode at minimum, but 32 mode could be supported. "Control Head" channel labels could be handled in the GUI. The GUI could store banks of 64 or 128 mode code plug configurations to be programmed at will.
|
Re: Has anyone fully decoded the X9000 memory mapping?
Well, I'm the list owner and I have no objections. It's been a pretty quiet list for many years. If anyone else has any issues let us know. 73's Skip On Thu, Jul 28, 2022 at 3:36 PM Bradley Andrews via groups.io <kb9bpf@...> wrote:
I'm very interested in what you guys have to say so if it were up to me (it's not) I'd say go ahead and continue your discussion here. Isn't it as good a place as any? Does anyone object?
Brad
On Thursday, July 28, 2022, 04:31:17 PM CDT, Casey Crane <ccrane148@...> wrote:
Yes, exactly. The thing was amazingly fast. The "problem" is the radio took on the attributes of whatever mode was selected at the time. So, if mode 1 was selected, had a PL of 151.4 etc.... if I tuned away to a different frequency those attributes followed, being only the frequency was changing. It would basically require duplicating all the other features of the radio in hardware/software to take advantage of this method fully which is of course absurd.
My thought was to present the uProcessor with one mode's worth of data and then change that data dynamically, allowing the uP to do all the rest of the work. I have the service manual and it appears it has a strobe line which basically thumbs through pages of the eeprom grabbing data for different modes. If it were fed data that we could dynamically update despite whatever mode (eeprom data offset) it's looking for then we could control it all.
As said earlier, life has taken priority and caused a stall on the project but I do have some very nice code I came up with for the Raspberry Pi which I think could be used to feed an arduino as an internal decoder resulting in a very nice full color capacitive touch screen 4.3" user control interface with infinitely configurable mode names, scan lists, search parameters etc... all fed to the radio via a simple lightweight serial interface or perhaps even via one of the bluetooth serial dongle boards leaving only audio paths to be dealt with.
As the solar cycle has heated up it's something that has got me thinking about it all again.
I just don't know if this is the place to discuss it and I don't want to infringe or step on any toes regarding the project this group is about so I should probably start another group so as not to clutter this one.
Casey
On Thu, Jul 28, 2022 at 4:16 PM swguest via groups.io <swguest@...> wrote:
Bradley,
Let me see what I can find. This was an X9000 but hardware wise at the point he made the connections the X and the X9000 *should* be the same animal. You will need service manuals for both to pursue the project.
He basicly severed the uC's data/control lines to the synthesizer and injected data calculated by his arduino from info Mike B. shared about the radio's divider/synthesizer operational process.
Again, POC. It would still take a fair amount of designing to hammer out the details and make an operational radio that doesnt resemble an alien autopsy.
|
Re: Has anyone fully decoded the X9000 memory mapping?
 Here it is, you can still get one! https://www.amazon.com/VR-N7500-Headless-Transceiver-Bluetooth-Programming/dp/B084D3V4MJ
|
Re: Has anyone fully decoded the X9000 memory mapping?
There was a cheap Chinese dual band mobile on the market a couple years ago that used an Android phone and Bluetooth for the control head. I would post a link if my memory would serve me. The operational aspects were desirable but it was just another CCR as far as the radio unit. Still an attractive idea.
Using an Android device opens up the possibility of leveraging the Infotainment system of newer cars or the use of a cheap tablet with a large screen. It also eliminates the requirement to design a plastic box for a control head made with a cobbled up Arduino/Pi and touchscreen. Someone on another group has done this to control a Uniden scanner and the plastic control heads were 3D printed and did not hold up well to heat.? Putting the microcontroller? in a metal box near the drawer unit and use BT/Android to facilitate the user interface would be better in my humble opinion.
Thinking way out of the box because I am not a programmer beyond a simple PICAXE design.
Could the solution for FPP be in simply switching the radio to programming mode and loading channel 1 from the GUI? The GUI would have to emulate the RD.EXE RSS. This includes option support like MPL and scan etc..
How many times could this be done without damaging the EEPROM? Could a replacement EEPROM be installed that will tolerate such abuse?
Taking this further, the entire codeplug could be programmed from the GUI in a batch. The codeplug and firmware should be upgraded for 8K / 64 mode at minimum, but 32 mode could be supported.? "Control Head" channel labels could be handled in the GUI. The GUI could store banks of 64 or 128 mode code plug configurations to be programmed at will.
|
Re: Has anyone fully decoded the X9000 memory mapping?
Sounds good Casey.
You are welcome to anythig I have that may help. I still check either email addys.
@ Skip, The X would be well served with a uC based control head w/FPP. For my X9000 interface I was looking at a MiniMega on a homebrew daughter board mounted above the uC/EEPROMs that has the addy/data busses brought up to it. Replace the 2816 with a xx64 NVRAM, link this sub assy to a NRF24L01 (I like the protocol, robust but simple and low level operation configurable). (or your favorite remote base controller).
I agree, the buss sharing issue could be a problem. An array of data selection gates to switch the busses as needed is one solution but increases parts count and complexity. The Hitachi has a pin? that *may* let the Mega " pause" it for a few cycles to access the EEPROM. I've not tried it, the pin is tied high and is going to be a bit of trouble to isolate. Status---TBD.
The head end is a mated NRF24L01 linked to another MinMega with Touch/LCD capabilities. Multimodes, multiPL, scan, zones (in non trunked speak, that would be banks...lol)? I suspect any version of an RF link would have to be "brought out" of the radio case to work very far.
I had considered adapting my ideas to the X platform but it hasnt made "the list"....yet.
The X9000 head is "smart" (not idiotphone smart) and speaks SB9600 with the radio drawer (and other SB9600 accesories). Much of it's function would be a lot of work to replicate and replace, The main failing for the X9000 is no FPP. That could be a feature that runs "outside" of the radio's normal operation used for programming as needed only.
@RFI-EMI-GUY
The 128 and 256 mode RSS is squirrely on a good day. They required different FW and the byte per mode is different due to the addition of scanning >64 modes. That moves EVERYTHING in the codeplug layout. Even on my NEC 386-20 the RSS was buggy.
As for best RSS the last release (R8.01?) is the most stable, runs on a pentium class uP (booted to real, DOS, ie MS 6.22 , not a cmd window or DOSbox), but OEM version has no OOB support. I did locate some of the locations to rectify that so it is functional for HAM.
I agree the X9000 CH could use a makeover, and having to give consideration to program it separately is a pain, or at least another module of the project of consider.
For low band antenna resonance concerns, a hardware hack. The bit that selects the noise blanker is available. Disconnect it from the NB circuitry and use that bit to control an antenna switch.
Set all 10m modes to NB on, all 6m to NB off...... It would have to be a PIN switch for scanning. A mechanical relay would never keep up...lol
|
Re: Has anyone fully decoded the X9000 memory mapping?
I'm very interested in what you guys have to say so if it were up to me (it's not) I'd say go ahead and continue your discussion here. Isn't it as good a place as any? Does anyone object?
Brad On Thursday, July 28, 2022, 04:31:17 PM CDT, Casey Crane <ccrane148@...> wrote:
Yes, exactly. The thing was amazingly fast. The "problem" is the radio took on the attributes?of whatever mode was selected at the time. So, if mode 1 was selected, had a PL of 151.4 etc.... if I tuned away to a different frequency those attributes followed, being only the frequency was changing. It would basically require duplicating all the other features of the radio in hardware/software to take advantage of this method fully which is of course absurd.?
My thought was to present the uProcessor with one mode's worth of data and then change that data dynamically, allowing the uP to do all the rest of the work. I have the service manual and it appears it has a strobe line which basically thumbs through pages?of the eeprom grabbing data for different modes. If it were fed data that we could dynamically update despite whatever mode (eeprom data offset) it's looking for then we could control it all.
As said earlier, life has taken priority and caused a stall on the project but I do have some very nice code I came up with for the Raspberry Pi which I think could be used to feed an arduino as an internal decoder resulting in a very nice full color capacitive touch screen 4.3" user control interface with infinitely configurable mode names, scan lists, search parameters etc... all fed to the radio via a simple lightweight serial interface or perhaps even via one of the bluetooth serial dongle boards leaving only audio paths to be dealt with.?
As the solar cycle has heated up it's something that has got me thinking about it all again.?
I just don't know if this is the place to discuss it and I don't want to infringe or step on any toes regarding the project this group is about so I should probably start another group so as not to clutter this one.
Casey
Bradley,
? Let me see what I can find. This was an X9000 but hardware wise at the point he made the connections the X and the X9000 *should* be the same animal. You will need service manuals for both to pursue the project.
He basicly severed the uC's data/control lines to the synthesizer and injected data calculated by his arduino from info Mike B. shared about the radio's divider/synthesizer operational process.
Again, POC. It would still take a fair amount of designing to hammer out the details and make an operational radio that doesnt resemble an alien autopsy.
|
Re: Has anyone fully decoded the X9000 memory mapping?
The X9000 has a multi PL option that unfortunately is limited to 16 slots, at least in the 128 channel firmware. Being able to select "PL" on the fly for a low band radio would be an improvement. Also in 6 meters the repeater splits vary depending upon region, state, etc. You can fudge two splits per repeater output channel using the direct mode button, however there are easily 4 different repeater splits in the US plus oddballs.
Then there are the option code bits. I am using DES-XL ( on the bench now) for future Part 90 station. The option bit controls the Securenet board installed on the personality board. Likewise there are option bits for Extender noise blanker, Scan, Talk back scan, Direct mode (simplex) , VRS control, MDC and DTMF encode/decode, single tone, MPL and Siren, etc if so inclined. As far as I can tell no I/O control is supported in the radio other than horn/lights activation.
edit: as far as form factor. An external box would not be objectionable if it can minimize the modifications to the radio. Also there would be less concern about EMI from the new circuits directly radiating into the receiver. The only drawback is availability of mating plugs, however a scrapped control cable from a radio, siren unit etc, can be put to use. edit 2: Also an external interface will make it easy to support spare drawer units for troubleshooting/repair and even facilitate multiple radio control.
|
Re: Has anyone fully decoded the X9000 memory mapping?
The problem with the Beaglebone Black is that it's unlikely to fit
inside of a Syntor if that's your goal.
My interest was always in "remote base stations" and I didn't care
about Motorola control heads. I don't really know how many people are
interested in mobiles vrs bases.
When I bought a new car in the 80s I went to "rice boxes" for my car
because I was too lazy to run control cables. When I got my last car
(2010) I went back to control cables and a Spectra under the passenger
seat. Replacing the caps in the Spectra wasn't fun, but it's still
running 12 years later. Not that I turn it on very much these days...
73's Skip WB6YMH
toggle quoted message
Show quoted text
On Thu, Jul 28, 2022 at 2:39 PM Dennis Boone <drb@...> wrote:
> If anyone is willing to do an Xcat-2022 with a modern processor I'd
> be willing to help with the firmware. With Kicad and places like
> JCLPCB it should be much easier now!
> Maybe just a daughter board for an ESP32 module or a "Blue pill? ??
> (Why an ESP32 ... because you can GET them! Unlike lots of other
> things.)
I've thought for some time that a Beaglebone Black, with its two PRU
(Programmable Realtime Unit) processors, would be nearly the whole
device. People have e.g. spoofed GPS signals and imitated old MFM hard
drives' flux interfaces with them.
De
|
Re: Has anyone fully decoded the X9000 memory mapping?
If anyone is willing to do an Xcat-2022 with a modern processor I'd > be willing to help with the firmware. With Kicad and places like > JCLPCB it should be much easier now! > Maybe just a daughter board for an ESP32 module or a "Blue pill? ?? > (Why an ESP32 ... because you can GET them! Unlike lots of other > things.) I've thought for some time that a Beaglebone Black, with its two PRU (Programmable Realtime Unit) processors, would be nearly the whole device. People have e.g. spoofed GPS signals and imitated old MFM hard drives' flux interfaces with them. De
|
Re: Has anyone fully decoded the X9000 memory mapping?
I havent looked at your syntorxgen source code. Do you derive the hex > values from a formula or use a lookup table? I remember some SyntorX > codeplug layout data on a site..Xbits something? that's gone now. I > thinks Mike B. replicated the info on his site. I think maybe the > DPL formula was in that info? I do know the CTCSS hex values are > derived via formula. The basic DPL code bits are simple. But there are three additional mystery bits in the code plug. Syntorxgen now uses a formula to calculate the proper values for those bits. It's not clear to me what those bits do, other than being a pita. I had originally just set those extra bits to zeros as suggested by Paul Kasley and Mike's code plug info, then found that there were one or two types of radios (VX-5R, and a Pacific Research repeater controller, iirc) that Didn't Like That <tm>. I then experimentally* built a table (it's still in the source, but no longer used) that mostly worked, and a few other folks (e.g. Andy Brinkley) contributed some effort to find corrections. Eventually the formula was worked out. Paul's site is long gone, but Mike may have a copy at onfreq, and I fished one out of the wayback machine for my Syntor X pages. For CTCSS, the value is basically a multiplier or divider value. Syntorxgen will let you set non-standard tones because it just does the math. The code plug page gives you the bit patterns for the standard tones. De * Yes, this was _exactly_ as fun as it sounds. 32 modes in a code plug will hold all 8 possible mystery bit patterns for 4 DPL codes. Burn EEPROM. Insert into radio. Select mode 1. Try a transmission. Try a reception. Note results. Mode 2. Lather rinse repeat. Decide which of multiple patterns opened the squelch _fastest_. There are, what, ~104 DPL codes? :)
|
Re: Has anyone fully decoded the X9000 memory mapping?
Yes, I have the logic analyzer and several low band units. All I'm missing is time but I'll do my best to set one up for testing.
On Thu, Jul 28, 2022 at 4:30 PM Skip Hansen < skip@...> wrote: If anyone is willing to do an Xcat-2022 with a modern processor I'd be
willing to help with the firmware.? With Kicad and places like JCLPCB
it should be much easier now!
Maybe just a daughter board for an ESP32 module or a "Blue pill? ??
(Why an ESP32 ... because you can GET them!? Unlike lots of other
things.)
The Xcat raced the F8 processor to provide data, I don't know if the
same technique would be viable with an X9000, but it will be easy to
find out.? Does anyone with an X9000 have a logic analyzer then can
connect to the "code plug" chip?
73's Skip
On Thu, Jul 28, 2022 at 2:20 PM RFI-EMI-GUY <rhyolite@...> wrote:
>
> The X9000 has a socketed 2 or 8K EEPROM for the code plug and is also programmable by the RIB interface which is a piggy back cable that the control cable plugs into along with the radio main plug. Likewise the control head is programmed with a separate executable via this interface. The radio has socketed firmware in 32, 64, 128 , and 256 channel capability. The 128 being most stable. The control heads vary in capability with some having socketed EEPROM and 8K expansion.
>
> The Syntor X9000 drawer units are plentiful. Control cables and heads are less plentiful, but are still available. Control head plastic, buttons and VFD display are limitations.
>
> The major obstacle is in the DOS RSS programs required. Finding a suitable DOS computer is becoming difficult as a 486 mother board with slow clock is a requirement.
>
> Finding a method of programming the radio and control head codeplug s out of circuit would be helpful.
>
> A second product to emulate the X9000 control head via an Android tablet and Bluetooth would be attractive. In this way a minimalistic control cable could be installed. However this would require an interface to emulate some analog control head circuitry, speaker? and mike connections, as well as provide a BT tranceiver for the SB9600 bus.
>
> There were dual drawer configurations of X9000 which might be possible with a new interface.
>
> On Thu, Jul 28, 2022 at 03:57 PM, Skip Hansen wrote:
>
> I'll admit that my memory SUCKS these days, but I don't recall the
> X9000 having a physical code plug. Wasn't it programmable via a
> cable? I never had any X9000 radios myself.
>
> 73's Skip WB6YMH
>
> On Thu, Jul 28, 2022 at 12:53 PM Dennis Boone <drb@...> wrote:
>
>
> > I *think* that included DPL
>
> Pretty sure the DPL coding for the '9000 is the same as the 'X. Formula
> for that is in the syntorxgen source.
>
> ISTR hearing that the '9000 code plug has a copyright statement and some
> executable code in it somewhere that are necessary for proper operation.
>
> De
>
>
>
>
>
|
Re: Has anyone fully decoded the X9000 memory mapping?
Good to hear from you as well. I will contact you direct and bring you up to speed on some ideas and also some info on some things taking time away from the project. I hope all has been good on your end.
|
Re: Has anyone fully decoded the X9000 memory mapping?
Yes, exactly. The thing was amazingly fast. The "problem" is the radio took on the attributes?of whatever mode was selected at the time. So, if mode 1 was selected, had a PL of 151.4 etc.... if I tuned away to a different frequency those attributes followed, being only the frequency was changing. It would basically require duplicating all the other features of the radio in hardware/software to take advantage of this method fully which is of course absurd.?
My thought was to present the uProcessor with one mode's worth of data and then change that data dynamically, allowing the uP to do all the rest of the work. I have the service manual and it appears it has a strobe line which basically thumbs through pages?of the eeprom grabbing data for different modes. If it were fed data that we could dynamically update despite whatever mode (eeprom data offset) it's looking for then we could control it all.
As said earlier, life has taken priority and caused a stall on the project but I do have some very nice code I came up with for the Raspberry Pi which I think could be used to feed an arduino as an internal decoder resulting in a very nice full color capacitive touch screen 4.3" user control interface with infinitely configurable mode names, scan lists, search parameters etc... all fed to the radio via a simple lightweight serial interface or perhaps even via one of the bluetooth serial dongle boards leaving only audio paths to be dealt with.?
As the solar cycle has heated up it's something that has got me thinking about it all again.?
I just don't know if this is the place to discuss it and I don't want to infringe or step on any toes regarding the project this group is about so I should probably start another group so as not to clutter this one.
Casey
Bradley,
? Let me see what I can find. This was an X9000 but hardware wise at the point he made the connections the X and the X9000 *should* be the same animal. You will need service manuals for both to pursue the project.
He basicly severed the uC's data/control lines to the synthesizer and injected data calculated by his arduino from info Mike B. shared about the radio's divider/synthesizer operational process.
Again, POC. It would still take a fair amount of designing to hammer out the details and make an operational radio that doesnt resemble an alien autopsy.
|
Re: Has anyone fully decoded the X9000 memory mapping?
If anyone is willing to do an Xcat-2022 with a modern processor I'd be
willing to help with the firmware. With Kicad and places like JCLPCB
it should be much easier now!
Maybe just a daughter board for an ESP32 module or a "Blue pill? ??
(Why an ESP32 ... because you can GET them! Unlike lots of other
things.)
The Xcat raced the F8 processor to provide data, I don't know if the
same technique would be viable with an X9000, but it will be easy to
find out. Does anyone with an X9000 have a logic analyzer then can
connect to the "code plug" chip?
73's Skip
toggle quoted message
Show quoted text
On Thu, Jul 28, 2022 at 2:20 PM RFI-EMI-GUY <rhyolite@...> wrote:
The X9000 has a socketed 2 or 8K EEPROM for the code plug and is also programmable by the RIB interface which is a piggy back cable that the control cable plugs into along with the radio main plug. Likewise the control head is programmed with a separate executable via this interface. The radio has socketed firmware in 32, 64, 128 , and 256 channel capability. The 128 being most stable. The control heads vary in capability with some having socketed EEPROM and 8K expansion.
The Syntor X9000 drawer units are plentiful. Control cables and heads are less plentiful, but are still available. Control head plastic, buttons and VFD display are limitations.
The major obstacle is in the DOS RSS programs required. Finding a suitable DOS computer is becoming difficult as a 486 mother board with slow clock is a requirement.
Finding a method of programming the radio and control head codeplug s out of circuit would be helpful.
A second product to emulate the X9000 control head via an Android tablet and Bluetooth would be attractive. In this way a minimalistic control cable could be installed. However this would require an interface to emulate some analog control head circuitry, speaker and mike connections, as well as provide a BT tranceiver for the SB9600 bus.
There were dual drawer configurations of X9000 which might be possible with a new interface.
On Thu, Jul 28, 2022 at 03:57 PM, Skip Hansen wrote:
I'll admit that my memory SUCKS these days, but I don't recall the
X9000 having a physical code plug. Wasn't it programmable via a
cable? I never had any X9000 radios myself.
73's Skip WB6YMH
On Thu, Jul 28, 2022 at 12:53 PM Dennis Boone <drb@...> wrote:
I *think* that included DPL Pretty sure the DPL coding for the '9000 is the same as the 'X. Formula
for that is in the syntorxgen source.
ISTR hearing that the '9000 code plug has a copyright statement and some
executable code in it somewhere that are necessary for proper operation.
De
|
Re: Has anyone fully decoded the X9000 memory mapping?
True,
The term has come to mean the customer's radio operational information contained inside the product. Up to and including APX stuff and beyond. The X is probably the last to use a physical code plug, save the Midland ST1 series.
Even though it's Moto term, in the world of CCRs and other programmable radios, it sticks.
A real GE or Johnson guy would never use the terms "PL" or "DPL" for CTCSS or DCS but pretty much everyone eles does....lol
|
Re: Has anyone fully decoded the X9000 memory mapping?
The X9000 has a socketed 2 or 8K EEPROM for the code plug and is also programmable by the RIB interface which is a piggy back cable that the control cable plugs into along with the radio main plug. Likewise the control head is programmed with a separate executable via this interface. The radio has socketed firmware in 32, 64, 128 , and 256 channel capability. The 128 being most stable. The control heads vary in capability with some having socketed EEPROM and 8K expansion.
The Syntor X9000 drawer units are plentiful. Control cables and heads are less plentiful, but are still available. Control head plastic, buttons and VFD display are limitations.
The major obstacle is in the DOS RSS programs required. Finding a suitable DOS computer is becoming difficult as a 486 mother board with slow clock is a requirement.
Finding a method of programming the radio and control head codeplug s out of circuit would be helpful.
A second product to emulate the X9000 control head via an Android tablet and Bluetooth would be attractive. In this way a minimalistic control cable could be installed. However this would require an interface to emulate some analog control head circuitry, speaker? and mike connections, as well as provide a BT tranceiver for the SB9600 bus.?
There were dual drawer configurations of X9000 which might be possible with a new interface.
edit: Another feature for Low Band versions would be some sort of support for antenna tuning and/or selection. For example a tuning mode to drop power during tuning for screwdriver or auto tuners and/or a set of I/O's mapped to channels that would select a particular antenna relay. This would have to be paused during scanning , perhaps to a default antenna.?
toggle quoted message
Show quoted text
On Thu, Jul 28, 2022 at 03:57 PM, Skip Hansen wrote:
I'll admit that my memory SUCKS these days, but I don't recall the
X9000 having a physical code plug. Wasn't it programmable via a
cable? I never had any X9000 radios myself.
73's Skip WB6YMH
On Thu, Jul 28, 2022 at 12:53 PM Dennis Boone <drb@...> wrote:
> I *think* that included DPL
Pretty sure the DPL coding for the '9000 is the same as the 'X. Formula
for that is in the syntorxgen source.
ISTR hearing that the '9000 code plug has a copyright statement and some
executable code in it somewhere that are necessary for proper operation.
De
|
Re: Has anyone fully decoded the X9000 memory mapping?
Bradley,
? Let me see what I can find. This was an X9000 but hardware wise at the point he made the connections the X and the X9000 *should* be the same animal. You will need service manuals for both to pursue the project.
He basicly severed the uC's data/control lines to the synthesizer and injected data calculated by his arduino from info Mike B. shared about the radio's divider/synthesizer operational process.
Again, POC. It would still take a fair amount of designing to hammer out the details and make an operational radio that doesnt resemble an alien autopsy.
|
Re: Has anyone fully decoded the X9000 memory mapping?
I'll admit that my memory SUCKS these days, but I don't recall the > X9000 having a physical code plug. Wasn't it programmable via a > cable? I never had any X9000 radios myself. Mine too! :) The code plug is loaded over the wire (RIB, programming cable, ...), but Moto seemed to stick to the term even though there wasn't a physical pluggable object any more. De
|
RFI-EMI-GUY