Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- Xcat
- Messages
Search
|
Re: Xcat-2022 proposal
So questions for all that are interested:This wasn't exactly a question, but: I'll point out that for the X, one of the very handy things about having an Xcat is that you don't need to unbutton the radio to fish out its code plug unit. Even if you're not doing VFO, it's a far easier reflash over serial. For either the X or the 9000, the "RSS" is a lot easier to interact with, since it's not constrained to suitcase programmers, slow DOS machines, weird text-file driven unix command line tools, etc. What I'm roughly suggesting is that for both the Xcat-2022 and the Xcat9000-2022, one potentially nice operating mode to preserve is "load the code plug, then use the native control heads". *asbestos suit* De |
|
Re: Has anyone fully decoded the X9000 memory mapping?
Good points. We really need to figure out how to get something usable from this LA data. I assumed for whatever reason, the radio just iterated over the mode data again and again refreshing itself to make sure nothing was inadvertently corrupted along the way. I guess I got this mental picture?from the synth refresh description and likely incorrectly applied it to everything else. So, how do you suspect scan works? You are saying the radio reads the modes into the uP from the EEPROM all at once along with the PL data then executes operations using that data stored internally? I assumed it read in some codeplug structure info, determined what size of chip was on board, how many modes there are and then made the decision as to what EEPROM data locations to go and grab the freq an PL data, obtaining it on the fly based on scan flags in the codeplug and ultimately doing operations with it in a just in time manner by manipulation of the PL output lines, synth divider lines and other associated?functions. We really have to map out the order of operation before we can do anything else or it's all just speculation.? On Mon, Aug 8, 2022 at 1:28 PM swguest via <swguest=[email protected]> wrote: @ Casey, |
|
Re: Xcat-2022 proposal
开云体育Hi Skip,> Do we still need Doug Hall support?? If so we will need level converters for that interface.? Personally I'd like to drop it, I don't have any way to test it. I wrote the Doug Hall RBI-1 firmware support for the S-COM 7K controller.? I still get requests for RBI support on the S-COM 7330 -- I'm in the middle of implementing that now.? I have an RBI and radios to test with.? I don't have an Xcat and radio, though I'm sure we can fix that. Will the USB connector on the Pico replace the serial port? BTW, there's both a MicroPython (the original) and CircuitPython (supported by Adafruit). 73, ? Dave On 8/8/2022 9:22 AM, Skip Hansen wrote:
Good morning Dave! |
|
Re: Has anyone fully decoded the X9000 memory mapping?
To emulate the EEPROM in mode based operation the uC will have to be> commanded to re-read the EEPROM (ie:via a mode increment cmd) and it > is multiple memory locations so it will step thru at least 16 > (probably all 24) addresses to get the data it wants for a complete > byteset. The Xcat does this with a fly-lead from the xcat to a point inside the radio, since the switching on the X is all mechanical. Note that the radio may or may not just read addresses n through n+23 (for the 9000, +15 for the X) locations in order. Inquiring minds want to ... ooh, shiny! > I dont know of a single SB9600 or other cmd that will initiate a > re-read of the EEPROM for the same mode. There is a "switch mode" command, iirc. The question is whether, when the radio is sitting on Mode 1, sending it a "Switch Mode To 1" command will induce the required heartburn, or if the radio thinks its smarter than that. But even if the radio tries to filter out such "duplicate" or "repetitive" commands, there's a simple workaround: alternate between two modes for VFO type control. De |
|
Re: Xcat-2022 proposal
64 modes is what the Syntor X could support (sort of, two independent> banks of 32) from what I recall. The M6 mode line is used, as you would expect. It basically ends up selecting which moby of the EPROM to access. The ways that 64 modes aren't really supported are largely related to the control head stack (fixed interpretation of cable signals) and the scan programming (only 32 bits for scan definitions). The Operator Select MPL head uses the upper moby to provide the feature, so you can't really have 64 modes and MPL. The HHCH may differ slightly. De |
|
Re: Has anyone fully decoded the X9000 memory mapping?
@ Casey,
Unless your LA tests determined otherwise, I imagine the refresh is from data stored in the uC for that mode to the divider. Infact, that might explain a lot of the buss activity you were seeing since the divider FF/register is fed from the addr and data lines ?To emulate the EEPROM in mode based operation the uC will have to be commanded to re-read the EEPROM (ie:via a mode increment cmd) and it is multiple memory locations so it will step thru at least 16 (probably all 24) addresses to get the data it wants for a complete byteset. You have to decode the addr lines to know what it is asking for, so you might as well associate all that data to that address request in memory anyway. VFO mode is something that needs to be evaluated. I dont know of a single SB9600 or other cmd that will initiate a re-read of the EEPROM for the same mode. It would still be a 16 or 24 byte read regardless. Maybe a macro of the SB9600 commands that perfoms the random access to mode selection function....sel/keypad1/sel or whatever the actual sequence is...I dont recall ATM Repeating that macro should force the uC to re-read of the same place(es) in the EEPROM's memory, until a COS (in the case of a search feature, another input needed for non OEM scan function) or an end routine command is received. You would have to inc/dec or encode FPP input and write that data to the address of the 3 bytes used for rx VCO frequency in the Pico (or whatever is used) memory of the mode you are re-reading before each execution of the SB9600 macro. Likely doable, but could get complex. |
|
Re: Has anyone fully decoded the X9000 memory mapping?
Speaking of CTCSS, provisions for a non-standard user-settable tone> would be great, too. (user-settable meaning preprogrammed, but if it > can be set on the fly that is fine too) Since the programming for this is a computed divisor, you can set any frequency you want within the range. On the X, the ranges are different for tx vs rx, or at least, since it uses different scaling factors the bit field holds different ranges. Syntorxgen lets you do custom tones. De |
|
Re: Xcat-2022 proposal
64 modes is what the Syntor X could support (sort of, two independent
banks of 32) from what I recall. As for the mad scientist in you ... no problem! 73's Skip WB6YMH On Mon, Aug 8, 2022 at 10:32 AM swguest via groups.io <swguest@...> wrote:
|
|
Re: Has anyone fully decoded the X9000 memory mapping?
OK. I didn't know if the COS was in software or hardware.
toggle quoted message
Show quoted text
A limit search would be a great feature. I wish the scan could be made fast enough to emulate a GE MVS scan. It has Priority sampling so fast you could never hear the sampling unless a constant tone were transmitted on the non-priority channel (then you could hear the very small sampling gap). No other radio had that. Something else it did was sampled for COS first, then if active it sampled only long enough to determine matching tone/code. Speaking of CTCSS, provisions for a non-standard user-settable tone would be great, too. (user-settable meaning preprogrammed, but if it can be set on the fly that is fine too) Joe M. On 8/8/2022 2:06 PM, Casey Crane wrote:
I'll have to check my code again but I was able to drive the synthesizer |
|
Re: Has anyone fully decoded the X9000 memory mapping?
I'll have to check my code again but I was able to drive the synthesizer very quickly across the band. Definitely fast enough for a good limit search function.? The channel activity input to the processor would be the stop flag.? On Mon, Aug 8, 2022, 13:02 Joe M. <mch@...> wrote: If scan is external you would also need a squelch |
|
Re: Has anyone fully decoded the X9000 memory mapping?
If scan is external you would also need a squelch
toggle quoted message
Show quoted text
indication in order to stop scan (for active channels). I would check to see how fast the synth can lock at maximum change (and lowest decode rate (67.0 Hz or DPL - I forget which is slower), then double that to set the scan speed. If you are rewriting the scan, dual-priority should be a minimum. Two scan lists (or more) would be a bonus. Those could be mode-slaved. Joe M. On 8/8/2022 1:37 PM, Casey Crane wrote:
As for the synthesizer the radio updates it every 20 milliseconds |
|
Re: Has anyone fully decoded the X9000 memory mapping?
As for the synthesizer the radio updates it every 20 milliseconds regardless of mode change to maintain stability in the event some transient voltage or whatever corrupted something. My thought was a mode change would occur by way of changed emulated eeprom data representing mode 1 of only a 1 mode codeplug. I'm not seeing any reason for more than one mode of data since we are changing it dynamically and there would be no reason to chase data all over the memory map when we can just point it to one spot and change that.? Scanning is something I've been mulling over. Can you? build a 1 mode codeplug and have a 1 mode scanlist? If so I would assume in scan mode the radio accesses and updates the synthesizer faster than the 20 milliseconds refresh static rate (how fast do they scan?). If so, then presenting emulated mode 1 data at a faster changing rate might work out as long as the radio is polling faster since it's thinking it's scanning. Of course we would have to keep it all in perfect time with what the processer wants but I assume that would be all part of the emulation process and dictated by the CE activity. On Mon, Aug 8, 2022 at 12:08 PM Skip Hansen <skip@...> wrote: Good points!? I had forgotten about needing to get the radio to |
|
Re: Xcat-2022 proposal
On Mon, Aug 8, 2022 at 08:22 AM, Skip Hansen wrote:
So questions for all that are interested:I agree with the baby step process, It is easier to interface to the X's hardware. Not that it matters with the Pico, but it runs a bit slower too. No SB9600 commands to deal with. Wirelrss UI and no PC programability would still be PH II, but it would serve as an up to date Xcat 2.0 (Xcat 2022) Serial port - I dont see any reason to mandate legacy serial support either. Real com ports have all vut completeey dissapeard from new devices. USB for better or worse it it's replacement. Doug Hall support - That's a question for the remote base users and if those controllers are still around. If the code can be ported easily enough, sure, other wise probably not worth the extra effort. I thinks CI-V is still widely used and it is not hard to replicate a stand alone DTMF based controller/interface. BTW, are you any kin to or familiar with the work of a guy named? John Hansen? http://www.amalgamate2000.com/radio-hobbies/radio/a_dtmf_controlled_icr75.htm New features - More modes of course. Why stop at 64? An MPL type function that has them all in a table in FW and linked to a mode by executing a (probably custom) CI-V protocol command Motorola's interpretation of scan needs revised for our purposes. They think in PS/commercial terms as in "How many channels do you really need to monitor?" If you are listening to something other than dispatch, your being inattentative to your task. Banks of n channels, ala zones that can be chained to scan every channel in every bank if desired. Per mode lists are likely a bit too much. I do realize all that may be too much of a re-write of your PC based control program. See what happens when you ask a mad scientist for a Christmas wishlist? |
|
Re: Xcat-2022 proposal
I have a Doug Hall unit and radio(s) if you need for testing. Jeff - KD6GDB On Mon, Aug 8, 2022 at 8:22 AM Skip Hansen <skip@...> wrote: Good morning Dave! -- Pursuant to U.S. Code, title 47, Chapter 5, Sub chapter II, ?227, "Any and all non solicited commercial E-mail sent to this address is subject to a download and archival fee of $500.00 U.S.". E-mailing denotes acceptance of these terms. |
|
Re: Has anyone fully decoded the X9000 memory mapping?
Good points! I had forgotten about needing to get the radio to
toggle quoted message
Show quoted text
re-read the mode info, ugh. In reality it might be worth taking this approach just to solve the refresh problem. An EXTERNAL to the radio ESP32 could provide CI-V to SB9600 translation plus be the basis for an Bluetooth or WiFi interface to phone/tablet or head using app. And ... ESP32 boads with RS485 support exist already for $21.57 (). It just so happens I have two sitting on my self from a work project ... Damn them squirrels ! 73's Skip WB6YMH 73's Skip WB6YMH On Mon, Aug 8, 2022 at 9:50 AM Dennis Boone <drb@...> wrote:
|
|
Re: Has anyone fully decoded the X9000 memory mapping?
Yea, but then you have to conform to the SB9600 protocol, yuck! For> computer control you'd also need a SB9600 "gateway" or a rib and a > serial port, again yuck. Going back to Skip's comment, a couple of thoughts, devil's advocate: 1. But you don't have to find a hack/slash way to get your control path out of the radio, because it's already there, and it's compatible with the whole existing system. 2. One way to get the radio to notice new mode data set by the external frequency agile control setup would be for the x9000cat-2022 to spoof a mode change onto the sb9600 channel. FWIW. De |
|
Re: Has anyone fully decoded the X9000 memory mapping?
On Sun, Aug 7, 2022 at 06:21 PM, Skip Hansen wrote:
Yea, but then you have to conform to the SB9600 protocol, yuck! For@ Skip, True. Hand assembling a few basic commands like volume and mode select inc/dec, scan on/off etc might not be a major undertaking. I'd like to see a macro of commands that get you control of the squelch parameters too. Although forcing a mode increment cmd to the uC might be needed to force an EEPROM read to create a scan function that can be controlled in a PH II design. Doesnt the Xcat do something similar on one of the CH lines to X's uC to implement scan? Since the X9000 OEM head is intelligent too, mode information is a function of the radio commanding the head to "display the data you have stored for mode nn. Building that array could get complex. Likely OTF edits could get cumbersome too. Using/hijacking the SB9600 protocol to program the EEPROM via the host uC is unlikely. I doubt Motorola supports single byte writes in the FW, which is necessary for the goal. ? That's when we will need that wedge into the FW loop and a single byte write subroutine written......got 'er done yet? With a lot of research and dedication, some form of SB9600 based UI isnt unrealistic, but is probably Ph III or beyond. |
|
Re: Has anyone fully decoded the X9000 memory mapping?
After re-reading the txt a few additional thoughts....
The CE for the data line 245 must be an undefined (in the information presented) outboard connection to the host, probably an expansion window enable line of some sort. This appears to present a n Kbyte block into the memory map of the host, via an expansion window. That said, not absolute addressing, no zero page conflicts. I didnt see an example shown of using Arduino IDE to load the memory array, or mention of where. Comments show the 7FFF mask references the PCjr's memory not the Teensy's. I have never used it but have seen examples of how to load an array into the Arduino family's memory via the IDE. That method wont work for our goal. Running full tilt like it does assures data will alway be present, but it's not likely to win any power consevation awards...lol |
|
Re: Has anyone fully decoded the X9000 memory mapping?
I think the CPU *could* do it, but why bother? Plus playing with the
state machine will be the fun part of the project for me. The "page zero" ram stuff really doesn't apply to the Teensy, it's a 32 bit processor with a megabyte of RAM on chip. My take on the posted code was that you just defined the values of the RAM buffer in the C source, recompiled and reloaded using the Arduino IDE. 245's might not mind 3v3 on the data lines, but powering them from 3v3?? My data books are in the garage and I'm too lazy to go look... 73's Skip WB6YMH On Mon, Aug 8, 2022 at 8:17 AM swguest via groups.io <swguest@...> wrote:
|
Dave WA1JHK
to navigate to use esc to dismiss