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 > > > > > > > > > >