开云体育

Hi Group,

I think I've figured out how the Rx and Tx frequencies are stored in the code plug.? So far I've only tested with the low band code plug that was posted earlier.

--- snip ---

I think I've figured out how the Rx and Tx frequencies are stored in

> the code plug. So far I've only tested with the low band code plug
> that was posted earlier.

I did the exercise of comparing hand-calculated bit patterns for tx/rx
frequency, using the Syntor X rules, with ones from a high band plug I
built with RSS. If I did it right, they all matched. The _layout_ is
different, but the bit fields are all the same. This isn't surprising,
since those parts of the radio are essentially identical.

De

> I think I've figured out how the Rx and Tx frequencies are stored in
> the code plug. So far I've only tested with the low band code plug
> that was posted earlier.

I did the exercise of comparing hand-calculated bit patterns for tx/rx
frequency, using the Syntor X rules, with ones from a high band plug I
built with RSS. If I did it right, they all matched. The _layout_ is
different, but the bit fields are all the same. This isn't surprising,
since those parts of the radio are essentially identical.

I've heard you can swap out a X9000 personality board with an X and
it'll work so that kind of confirms it and I made that assumptoin.

I spent a lot of time (re)reading
as well
as Casey's code.

I think I did find an error in the R0, R1 to reference frequency table
from why back. I doesn't agree with the service manual and I got
wrong results using it. I think the correct table is

0 - not used
1 - 6.25khz
2 - 4.1666 Khz
3 - 5 Khz.

73's Skip

De

I posted the? X9000 freq calc .xls with sheet protection on (w/o password) to keep cell formulas from being accidentally overwritten. Trust me it happens.
It can be unprotected and the formulas can been seen.
I left the graphic representation of the byte data in it to help illistrate the composition to those that dont quite get bit data.
The how the 10 bit, 8 bit and reference bits are stored in the 3 bytes per freq value and where they are stored in a mode's 24 byte set are on the "info" page of the 1st version (LB only) Dennis found somewhere (RR maybe) that I posted years ago. I dont know if that made it here but Dennis posted a link to it early in the discussions. I think I still have a .psf version I made and sent to Casey back then too. I'll see if I can find it and post it
I have discovered more than it covers and some corrections may be needed. I stopped researching it shortly thereafter.......
After things began to fall in place, the LB was the simplest. Only one PIN switchpoint for TX and one for RX, and no C1/C0 calcs.
One rule the RSS uses for all bands is that 6.25khz reference is used for any freq divisible by 6.25, even 440.000 or 52.525.? The 5khz reference can be used of course in calculation but the main divisor, hence the 10 and 6 bit values change for that frequency. Edit the value, recalc the CS and away ya go. The radio doesnt care it will generate the same freq for either calculation.

For compatibility, I made the calculator comply with the RSS's 6.25khz rule.
The PITA was sorting the C1/C0 values used by the VHF and up
?calculations.

On Tue, Aug 30, 2022 at 08:16 AM, swguest wrote:

OOPS....."even 440.000 or 52.525." .. .that should have read 52.000.

"I've heard you can swap out a X9000 personality board with an X and
it'll work so that kind of confirms it and I made that assumptoin."

True. I've done it. The sifference is the X doesnt have an unswitch 5v source so powering down looses the customer configuration.
I spent a lot of time (re)reading
as well
as Casey's code.
Yes that's some impressive bit management....and presents another avenue for the hard core experimenter to play with.

"I think I did find an error in the R0, R1 to reference frequency table
from why back. I doesn't agree with the service manual and I got
wrong results using it. I think the correct table is...."

The bits are stored inverted. Yeah, that one thru me for a while too...lol

Mad scientest note...the 4.166 khz reference would be awesome to use in a FHSS setup...the VCO is fast enough..........

Dammit....."The bits are stored inverted. ."... The V0/V1 bit are the ones stored inverted.....that's what happens with decade old memory...lol
Anyway the original LB only calculator .xls explains more than the multi band version.
I found it and the .pdf form of the info tab I created way back when...

On Mon, Aug 29, 2022 at 07:10 PM, Skip Hansen wrote:

I think I did find an error in the R0, R1 to reference frequency table
from why back. I doesn't agree with the service manual and I got
wrong results using it. I think the correct table is

0 - not used
1 - 6.25khz
2 - 4.1666 Khz
3 - 5 Khz.

According to what I formulated in the .xls, b1 of the 3rd byte of the 3 byte set is:

0 = 5khz
1 = 6.25 khz
These seem to work/match up with the RSS's calculation for a given frequency.

I've never seen b0 change from a 1, or b6 change from a 0 in this byte for any frequency I've entered via RSS.
If these two bits have a function related to frequency/VCO control, I havent discovered it.

There is enough structure data to make a simple x32 or VM based program to read the values and modify basic frequency, PL values and scan list in an existing codeplug.

I have little practical experience in such, and would have to "bone up" on a means to write such program.

I never pursued that part of the project? as some life events occured and I had to put the whole thing on pause at the time.

I have discovered more than it covers and some corrections may be

> needed. I stopped researching it shortly thereafter.......

This data, if you have it, would save others some work, if you could
post it. Preferably in _text_ form.

De

0 = 5khz

> 1 = 6.25 khz

> These seem to work/match up with the RSS's calculation for a given
> frequency.

> I've never seen b0 change from a 1, or b6 change from a 0 in this
> byte for any frequency I've entered via RSS. If these two bits have
> a function related to frequency/VCO control, I havent discovered it.

The X apparently supports at least three reference frequencies. The
fourth bit combination is even more mysterious. I have never actually
put a counter on the appropriate pin and played with the two bits in the
X to see what was being generated, and I've never been able to locate a
data sheet for that chip. The X documentation doesn't mention the 4166
frequency, at least not in the -O version of the high band manual, nor
does it mention the unused combination, so in effect there are two bits
but only one is really adjusted by real RSS. It's possible that other
band radios do use one or both of the other combinations.

Since that circuitry is on the RF board, it seems likely that the
function should work in the same way for the X9000 as in the X.

X factory default reference frequency for high band seems to have been
5000. Low band, UHF ranges 2-5, and 800 seem to have been 6250. I
don't have a factory UHF range 1 plug. We should probably check for
similar in the X9000.

De

but only one is really adjusted by real RSS.

Er, I should say by the factory programming tools. Based on things I've
read, I'm pretty sure their ordering system fed programming data to
manufacturing, and I rather imagine they didn't use the suitcase
programmer or the Epson HX-20 in the factory. :)

De

@ Dennis,

The "info tab" has the lion's share of what I've determined and have recorded outside of today's unsure memory. Even that *may* have some "unforseen at the time" errors.

The post I made earlier regarding PL/MPL data storage and managment is the result of recently re-affirming the function/process before posting erroneous /mis-remembered information.
I started down that rabbit hole just before I paused research, so I had to re-create and refresh my memory of the process before I posted anything.

The finished/presentable .xls PL calc you see is the great granchild of the scratchpad tab? I thru some formulas in to translate what I viewed in raw data into what the RSS displayed for that mode slaved PL/MPL location.

Read references I make in post referencing zero page values as "I remember it was there, but dont recall the exact memory location" As of yet, I havent gone back and re-affirmed any of that non specific information.

I will need to perform some up to date re-evaluation of the codeplug structure to refresh my memory and post what those variables are and where they are stored.

For example, from memory, and because I "used" them repeatedly I can correctly say (as viewed in HexWorkshop):
bytes 02h and 03h store the size (last byte location) of the codeplug.? I remember those clearly because that is how I confirmed what size codeplug I was exploring/mapping.
The RSS created codeplug files are all ~9k bytes. Data above the point referenced here is ignored when writing the codeplug to the radio.

bytes 03h and 04h are the checksum values. I remember those clearly because those are the locations I had to write corrected CS values to in order for the RSS to accept the edited codeplug. It wont even load a file that has a bad CS much less write it to the radio.

Anything beyond that I will need to confirm exact function(s)/location(s) in order to provide verified correct information.
I've spent recent time available on the PL data management as it is more complex and more critical to the project to manipulate these parameters

As is the fequency calculation, location(s) in the codeplug for a given mode, and method of storing the 10 bit, 6 bit, reference freq bit, V0/V1 bits, and C0/C1 bits I have already posted or presented in the .xls files.

Currently it is possible to:
import a standard RSS generated codeplug file to a hex editor,
edit any/all frequency values for a given mode (using the .xls frequency to byte calculator to determine the values)
edit any PL value for a given mode (using the .xls PL calculator to determine the values)
edit the NP scan list for a given mode (I suspect sorting info for P1/P2 manipulation is relatively easy but was not high on the priority list)
correct the checksum
save the file
and re-open it in RSS to write to the radio.

I believe with more research, it is possible to manipulate all the X9000 features, eventually.

As I said the verified/documented structure data appears to have been on a long dead now HDD. Anything I have posted I have verified. Anything left I havent posted is yet to be re-verified.

Sigh, I didn't notice that spreadsheet for some reason ... I did set
the one for PL and I've been looking at it all AM.

I tested VHF and UHF this morning and fixed a couple of problems. I
probably made multiple errors that cancelled themselves out or
something as I'm now able to decode my test cases for lowband,
highband and UHF.

I'll have a look at the spread sheet I'll probably answer questions
that I don't even know I have yet...

73's Skip WB6YMH

On Tue, Aug 30, 2022 at 8:16 AM swguest via groups.io
<swguest@...> wrote:

I posted the X9000 freq calc .xls with sheet protection on (w/o password) to keep cell formulas from being accidentally overwritten. Trust me it happens.
It can be unprotected and the formulas can been seen.
I left the graphic representation of the byte data in it to help illistrate the composition to those that dont quite get bit data.
The how the 10 bit, 8 bit and reference bits are stored in the 3 bytes per freq value and where they are stored in a mode's 24 byte set are on the "info" page of the 1st version (LB only) Dennis found somewhere (RR maybe) that I posted years ago. I dont know if that made it here but Dennis posted a link to it early in the discussions. I think I still have a .psf version I made and sent to Casey back then too. I'll see if I can find it and post it
I have discovered more than it covers and some corrections may be needed. I stopped researching it shortly thereafter.......
After things began to fall in place, the LB was the simplest. Only one PIN switchpoint for TX and one for RX, and no C1/C0 calcs.
One rule the RSS uses for all bands is that 6.25khz reference is used for any freq divisible by 6.25, even 440.000 or 52.525. The 5khz reference can be used of course in calculation but the main divisor, hence the 10 and 6 bit values change for that frequency. Edit the value, recalc the CS and away ya go. The radio doesnt care it will generate the same freq for either calculation.

For compatibility, I made the calculator comply with the RSS's 6.25khz rule.
The PITA was sorting the C1/C0 values used by the VHF and up
calculations.

Thanks !!!!!!!!!

This looks like a gold mine. I've been reinventing the wheel, but I'm
learning Python in the meantime so I guess it wasn't a complete waste
of time.

It's looking clear to me that the group knowledge is sufficient to do
an Xcat X9000 that'll support ham needs for rx and tx frequency
control, PL encode and decode frequency control and scanning.

I'm thinking that the initial code plug contents will be generated by
RSS and loaded into the Xcat. CI-V, or Doug Hall can be used to
change the basics of mode 1 which would be used as the "VFO" mode.
Copying modified mode 1 data into other modes and saving them to flash
should be easy.

I'm not super interested in dynamically configuring anything else
except perhaps the squelch. Is there anything I'm missing that we
want/need to be able to control via a control head or repeater
controller that I'm missing?

73's Skip WB6YMH

Off to ebay to spend some more $$$, ugh.

On Tue, Aug 30, 2022 at 8:46 AM swguest via groups.io
<swguest@...> wrote:

Dammit....."The bits are stored inverted. ."... The V0/V1 bit are the ones stored inverted.....that's what happens with decade old memory...lol
Anyway the original LB only calculator .xls explains more than the multi band version.
I found it and the .pdf form of the info tab I created way back when...

On Tue, Aug 30, 2022 at 12:16 PM, Skip Hansen wrote:

"interested in dynamically configuring anything else
except perhaps the squelch"

Unless you intend to do that via a sigital pot, a macro of a couple of SB9600 command packets should do it.

I dont think the v1 of the calc was ever posted here, only linked to by Dennis near the beginning of the discussions.

"I'm thinking that the initial code plug contents will be generated by
RSS and loaded into the Xcat. CI-V, or Doug Hall can be used to
change the basics of mode 1 which would be used as the "VFO" mode.
Copying modified mode 1 data into other modes and saving them to flash
should be easy."

I was thinking that the initial flash programming to the Pico should be more native to it
ie: using the Pico programming tools via the onboard USB port. Should be a lot less transform/convert coding needed to get the data in it's memory.
I know for "maximim usability" that means bringing the USB? lines outside the case.
If the ESP32 or whatever future 2.4ghz link can be operated over the USB that could be dual purpose and justify the modification to the case.?
If any VFO/PL parameters changed are RAM only, then checksum routines shouldnt be needed either. Otherwise that will need consideration as well.
There is still the issue (so far) of a codeplug with modified/non RSS compliant PL configuration being "re-educated" if imported back into RSS.

On Tue, Aug 30, 2022 at 12:52 PM, swguest wrote:

There is still the issue (so far) of a codeplug with modified/non RSS compliant PL configuration being "re-educated" if imported back into RSS.

I could have made that clearer.
IF the RSS is used on such a file, to modify,add or delete parameter that references PL values, it will "re-educate" all the PL data locations and pointers.
Changing freq or scanlist data *probably* (read as yet to be verified) wont affect the "custom" PL configuration.

On Tue, Aug 30, 2022 at 10:46 AM, swguest wrote:

?

HMMMMMMMMMMM!,,,

For example, from memory, and because I "used" them repeatedly I can correctly say (as viewed in HexWorkshop):
bytes 02h and 03h store the size (last byte location) of the codeplug.?

Change that to 01h and 02h.....That's 3 OOPS's today already......

I'm not super interested in dynamically configuring anything else

> except perhaps the squelch. Is there anything I'm missing that we
> want/need to be able to control via a control head or repeater
> controller that I'm missing?

In the longer term, I can see it being useful to e.g. control the siren
module -- hear the radio outside the car sort of thing, and possibly
other native capabilities. But they don't have to be in the first cut.

De

Unless you intend to do that via a sigital pot, a macro of a couple

> of SB9600 command packets should do it.

Not sure you really have the option. The radio has various settings and
control signals related to squelch (and/or sorts of things, plus pl/dpl,
plus the tightness/looseness stuff which iirc is set in distinct steps.

I think we need to understand those bits in the code plug. We can
certainly generate the SB9600 messages that the control head would
generate.

De

My understanding is that via SB9600 you have 5 options: open, plus 4
levels. (See Squelch Threshold Adjustment on
for details).

RSS had a "default squelch setting" which implies there is a place to
override it but I haven't found it. Maybe you have to "warm boot" the
radio to get it to re-read the default squelch settings?

I don't know enough about X9000 radios to say...

73's Skip WB6YMH

Yes, squelch threshold.

That's where I was talking about using a digital pot, but that still may not add much resolution. If understand Mike's description correctly, it appears anything > 4k7 has no effect on the threshold.

As you noted, the CH adjustable feature is very coarse.

I *think* the default squelch at boot time can be set in the RSS, and then stored in the codeplug, but I suspect any adjustments made after boot up are held in register(s) in the Hitachi itself until rebooted.