The PMBO server software is an an application, not an operating
system running on bare hardware. Assuming the PC hosting this
software runs Windows, Linux, or Unix, then hosting the SCAMP Busy
Detector (SBD) as an independent process would definitely be trivial.
73,
Dave, AA6YQ
--- In digitalradio@yahoogroups.com, "jgorman01" <[EMAIL PROTECTED]> wrote:
>
> I really don't know anything about the pmbo software. What you
> describe may be trivial from a system analysis standpoint but
actually
> coding it may not be so easy. What you're describing is running a
> second process (SBD) and making the pmbo software communicate with
> that process. That may or may not be trivial depending on the pmbo
> software design.
>
> Jim
> WA0LYK
>
> --- In digitalradio@yahoogroups.com, "Dave Bernstein" <aa6yq@>
wrote:
> >
> > No, it's actually trivial:
> >
> > 1. The PMBO's tranceiver's audio output is currently connected to
the
> > Pactor Modem's audio input; add a connection to the soundcard
input
> > (this might require adding a soundcard if one isn't already
present
> > in the PC that hosts the PMBO server software)
> >
> > 2. The SCAMP Busy Detector (SBD) is incorporated in the PMBO
server
> > software (Server); this is entirely initialization and
configuration
> > (e.g. soundcard selection, detection thresholds). Once configured
and
> > initialized, the SBD is a black box with a single boolean output
that
> > indicates whether or not the current transceiver frequency is
busy.
> >
> > 3. The PMBO server software (Server) is in one of two states:
Idle,
> > or Processing a User Request; we need only modify its Idle state
> > behavior. When the SCAMP Busy Detector (SBD) transitions
from "not
> > busy" to "busy" while the Server is Idle, there are two
possibilities:
> >
> > a. the frequency is busy because a WinLink user is transmitting a
> > request to the PMBO
> >
> > b. the frequency is busy because another QSO has begun or become
> > audible due to changing propagation
> >
> > To distinguish between these two possibilities, the Server waits
X
> > milliseconds after the SBD first reports "busy frequency", where
X is
> > the worst-case time required by the Pactor Modem to decode and
report
> > an incoming WinLink request. If such a request arrives from the
> > Pactor Modem within this interval, then the Server processes it
as
> > usual, ignoring the SBD. If no such request arrives within the
> > interval, then the Server clamps the Pactor Modem into its reset
> > state, preventing transmission on the frequency; this clamped
reset
> > is maintained until the SBD reports "frequency clear" for Y
> > consecutive seconds, after which the Server re-initializes the
Pactor
> > Modem and returns to Idle. 60 < Y < 300.
> >
> > 73,
> >
> > Dave, AA6YQ
> >
> >
> >
> > --- In digitalradio@yahoogroups.com, "jgorman01" <jg6164@> wrote:
> > >
> > > I don't know how hard it would be to pull this part of the
software
> > > out and run it on its own AND to control a transmitter with it.
> > > Remember, the pmbo is probably seeing a CTS indication from the
> > pactor
> > > modem. You would have to use another receiver and pc running
scamp
> > > and somehow get the pmbo software to recognize the CTS from that
> > > route. Probably not easy. It might be easier to get SCS to
include
> > > it in their firmware.
> > >
> > > Jim
> > > WA0LYK
> > >
> > > --- In digitalradio@yahoogroups.com, "Dave Bernstein" <aa6yq@>
> > wrote:
> > > >
> > > > I agree with your point, Jim. However, it doesn't explain the
> > failure
> > > > of the WinLink organization to incorporate the SCAMP busy
> > detector in
> > > > each of their PMBOs. This would have no impact on WinLink
users,
> > and
> > > > minimal $ impact on PMBO operators.
> > > >
> > > > 73,
> > > >
> > > > Dave, AA6YQ
> > > >
> > >
> >
>
