Andy, Skip,
Andy that appears to be a good test and (assuming the N0 station was "hidden" from the calling European RMS Express station) an indication the busy detector does work to block the connect and help address the "hidden transmitter problem" often referenced. Some facts for Skip and others that may be less familiar with the busy detector and RMS WINMOR: The RMS WINMOR station of course automatically keeps a log. In fact every session is logged and every contact (UTC Time, call signs, frequency, bytes sent/received) is captured to the master data base for analysis. If the RMS WINMOR also has the debug log enabled it can also capture (UTC time tagged to 10 ms resolution) the intimate details of the connect request timing, busy detector output, blocking function, and a wealth of other internal details of the decoding process. The busy detector does now have a "squelch" adjustment. This was requested and necessary for fine tuning in higher noise environments (where a continual busy detection might occur). The squelch does not adjust the sensitivity to amplitude.that is always automatic.but the trip points for the wide and narrow ratio detectors that make up the busy detector. The busy detector for the RMS WINMOR (server) can be disabled by the sysop. Two reasons for this: 1) It is still experimental and being optimized but as Andy noted it does work fairly well and is being adopted. The first RMS WINMOR stations were brought on board in January. 2) In case of emergency it is prudent to give the sysop control over this function. The busy detector for the RMS Express (client) cannot be disabled but only causes a pop up warning to the operator that the channel appears busy. The operator could over ride this if required (again an emergency feature giving the operator some discretion). The busy detector only operates over a selected frequency range of interest (e.g. the bandwidth of the session + guard bands) so it is normally not necessary to IF pre filter it. Pre filtering does of course help to suppress receiver AGC capture by signals outside the desired pass band just as it would with any mode so pre filtering is helpful to reject strong adjacent channel signals but it does not affect the busy detector itself. I think the question that goes begging here is not is it possible or does it work.Andy's test shows at least one good example it can work. The question should be "Why don't other modes or clients implement a busy detector too? The code is not complex and is not mode specific. If you wish I'll post the VB.NET source which could of course be translated easily into any other language. Its 66 lines of code including comments. The only DSP utility required is the FFT to get the frequency bins. I'm sure if we had more skilled programmers working on it we could make it more effective and reliable. These busy detectors aren't perfect.can't be perfect for all modes and all conditions. but they help and in many cases they are more reliable than the human initiating the connection. At the least they can and should serve as an aid to the human operator. With today's DSP digital modes there is really no reason not to implement them as a tool to augment the operator's ear.especially important for new and untrained operators. Let me know if there is interest in the source code and I'll package it up for posting along with some description of its operation. Rick Muething, KN6KB
