OK. I didn't know if the COS was in software or hardware.
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.
toggle quoted message
Show quoted text
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
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@... <mailto: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@...>
> <mailto: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@...>
> <mailto: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
> >
> >
> >
> >
> >
>
>
>
>
>
>
