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" <[EMAIL PROTECTED]> 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 > > > > > >
