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
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
> 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@...
> <mailto:skip@...>> wrote:
>
>? ? ?Good points!? I had forgotten about needing to get the radio to
>? ? ?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@...
>? ? ?<mailto:drb@...>> wrote:
>? ? ? >
>? ? ? >? > 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
>? ? ? >
>? ? ? >
>? ? ? >
>? ? ? >
>? ? ? >
>
>
>
>
>
>
|
