开云体育

So I just found a fun one.

If you enable SELCALL ENCODE, but not SELCALL DECODE, one of the
configuration screens has the entry items for both, but the DECODE ones
will all say N/A. But it turns out that if you hit the arrow key, the
values for at least the horn and lights timers actually change, even
though you don't see them.

This could lead to confusion when diffing code plug patterns, so watch
out!

De

Yup, backing up is like voting. One should do it early and often.

I had a couple dozen 27C devices but I cant find where I put them.
Apparently they are in a "safe place"....very very safe....
My Willem clone and the UV eraser were together on a shelf above the bench. I thought I had kept the chips with them. They'll turn up when I'm looking for something completely unrelated...lol

We still have the whole DIP socket HW interface to work out. Jameco has 24p wide DIP ribbon connectors. I picked up a few to play with. I have yet to see a 28 or 32 pin version though.

With a bit of creative jumpering we can get by w/24 pins. I think we need an alternate means of getting 5v and gnd to the Pico ensemble anyway.

@ Skip,
? The more I think it thru, the more I think making a look up table for all standard PLs and DPLs is overall a better plan anyway.

Initially it will be labor intensive to builds them. Giving each item a static location, and uniformly referencing them via byte 7 in the mode byteset is a more reliable and untimately probably going to be easier to implement codewise.

It also solves the problem of shuffling and orphaned data the RSS insists on leaving behind.

I still have one idea on how to keep PL/MPL from untimately colliding, but I havent run any tests yet.

I didnt take the byte 7 pointer values testing all the way to FFh, but I dont see why it wouldnt continue to work beyond what I did test.

If 64 modes are to be allocated in a 2k codeplug, there is only enough room left for 64 unique PL/DPL byte sets. If so this method will require an 8k configuration to create a table with all standard (ATM, I dont know how many there are)PL/DPL values.

Another advantage is the PL calc algo can be used to alter the mode one/FPP function, and write non standard frequencies if desired to the static MPL locations for operator use across all modes.

To keep from unintentionally overwriting PL data, using the OEM MPL setting limits it to 16 non standard frequency based selections, but how many custom PL frequencies does one really need?

I also have an idea on how to dynamicly link/daisychain user generated scanlists or in scanner speak, banks. Doable, but the Pico coding and UI to do it is definately next gen and beyond where we are trying to get to ATM.

Hey Casey,
Did you get back from Houston?
Yeah, I'm not sure if it's sloppy DOS, sloppy RSS or memory leak but I've seen it several times as well. If I were betting, my money would be on PC memory leak.

OK. Here's a bit more zero page info I've re-verified as viewed in Hexworkshop.

09h????????? ? ? ? ? number of modes for voice
10h????????????? ? ? number of modes total - difference is number of option modes. Set these to the same value. Increasing options modes in RSS will reduce available voice? modes

01Bh??????????? ? ? number of MPLs. Standard RSS max values is10h(16d)
019h & 01Ah??? data pointer to beginning of MPL data area. OEM value is set to 0700h. First byte of MPL1 value is in 0701h

Those default value locations will definately be needed when a replacement for the RSS is coded.
The FFh at 20CEh is likely noise or a keyboard mispunch. Anything over 1FFFh in an 8k codeplug is ignored.
Every byte is counted towards filesize, as the RSS wont load a file that is not waht it expects to see.
AFAIK, the only area above the 1FFFh boundry written to by the RSS is the Description/Comments option offered when you save the file.
I have occasionally seen "junk bytes" scattered in that area in various codeplugs I've looked at.
They arent in the checksummed data so changing clearing has no effect on the actual coeplug written to the radio.
Might make for a good place to store encryption key values, etc for future reference.

I've never done anything but a passing glance when it comes to DCS. Untill recently nothing I was interested in accessing used it, and what does now is on 900mhz.

If it cant be sorted by alpha or beta testing time and all else fails, we could build a lookup table.
Ugly and ineffecient, but it would be functional.

Here's the difference when you turn on the radio-wide peripheral option
W269 (siren with public address):

-00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
+00000040 00 89 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

-000020c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
+000020c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 |................|

so 0x41-0x42 is related to siren/pa. 0x20ce is a little harder to
interpret, as it's down in the variable position / size area.

When you turn on W269, a new menu entry appears, and is defaulted to:

HILO / AIRHORN SIREN TONES ... YES
MANUAL SIREN TONE ............ WAIL
IGNITION SENSE FOR SIREN ..... YES
SIREN POWERS UP RESET ........ NO

OPTION AUDIO ROUTING ................ YES
IGNITION SENSE FOR PUBLIC ADDRESS ... NO
IGNITION SENSE FOR EXTERNAL RADIO ... NO
DEFAULT P.A. VOLUME LEVEL ........... 11

Changing "hilo / airhorn" to no gives:
+00000040 00 89 2b 00 00 00 00 00 00 00 00 00 00 00 00 00 |..+.............|
so offset 0x42 bit 0x20 is /SIREN-HILO-AIRHORN-SIREN-TONES, as it were.

Changing "manual siren tone" to airhorn gives:
+00000040 00 a1 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
so offset 0x41 bit 0x08 is probably WAIL, and 0x20 is probably airhorn.

Changing "manual siren tone" to yelp gives:
+00000040 00 91 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
so offset 0x41 bit 0x10 is probably YELP.

Changing "ignition sense for siren" gives:
+00000040 00 88 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
so offset 0x41 bit 0x01 is ignition sense for siren.

Changing "siren powers up reset" to yes:
+00000040 00 89 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
so offset 0x42 bit 0x10 stores this option.

Changing "option audio routing" to no gives:
+00000040 00 89 4b 00 00 00 00 00 00 00 00 00 00 00 00 00 |..K.............|
so offset 0x42 bit 0x40 is /SIREN-OPTION-AUDIO-ROUTING.

Changing "ignition sense for public address" to yes gives:
+00000040 00 8d 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
so offset 0x41 bit 0x04 enables this sense.

Changing "ignition sense for external radio" to yes gives:
+00000040 00 8b 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
so offset 0x41 bit 0x01 handles this function.

Changing "default pa volume level" to 15 gives:
+00000040 00 89 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
so offset 0x42 bits b3-b0 store this level.

De

On Tue, Aug 30, 2022 at 04:47 PM, Skip Hansen wrote:

(Can anyone playing with X9000
radios be called "lazy" ?? It certainly ain't easy)??

...or any of this mad scientist stuff for that matter.

I bet the Spectra, A/S guys are waiting to see what's next on the chopping block!
Those are serial/SPI based synth coms.
AFAIK, MCS,LCS,GTX and probably the Warris line are as well.
Shouldnt be a major thing to capture the data stream via an LA setup and reverse engineer it.
I'll bet the format is very similar to the Maxtroller/Maxdroid projects.....

...but for now we aint done kicking this dawg.

@ Dennis,

Yes, that's how to do it but the change at 04h is the checksum updating.
It looks like data for the default squelch setting it's at 0Ch.

Changing the home mode value at 0Fh by one either way should inc/dec the 03h value by the same amt and direction.

@Skip.

Definately gets us more resolution, but ~5k isnt a lot of range.

Have you pictured how a real time UI is going to work yet?

So ... 3 examples of DPL codes and what RSS generated:

023 0xf864
025 0xfc54
026 0xfc4c
031 0xf434

Anyone know how to generate the hex from the code?

73's Skip WB6YMH

A digital squelch pot can certainly be supported via I2C. Using the
existing if course adjustment would be for the "lazy" that don't want
to install and wire a digital pot. (Can anyone playing with X9000
radios be called "lazy" ?? It certainly ain't easy!)

73's Skip WB6YMH

On Tue, Aug 30, 2022 at 3:01 PM swguest via groups.io
<swguest@...> wrote:

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.

Here's the difference between a home mode of 1 and a home mode of 39:

-00000000 00 1f ff 3c c5 00 13 07 01 40 18 08 04 09 14 01 |...<.....@......|
+00000000 00 1f ff 62 c5 00 13 07 01 40 18 08 04 09 14 27 |...b.....@.....'|

So offset 0x0f is the home mode.

De

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?

Here's the difference between a code plug with default squelch of "4"
set in RSS, and one with "0" set.

-00000000 00 1f ff dd cc 00 13 07 01 40 18 08 04 09 14 01 |.........@......|
+00000000 00 1f ff dd c8 00 13 07 01 40 18 08 00 09 14 01 |.........@......|

RSS provides settings zero through four.

Here's default squelch of "1":

+00000000 00 1f ff dd c9 00 13 07 01 40 18 08 01 09 14 01 |.........@......|

"2":

+00000000 00 1f ff dd ca 00 13 07 01 40 18 08 02 09 14 01 |.........@......|

"3":

+00000000 00 1f ff dd cb 00 13 07 01 40 18 08 03 09 14 01 |.........@......|

So it appears that the plug uses three bits, offset 0x04, bits b2-b0, to
encode squelch 0-4.

De

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.

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

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

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