Folks, I really don't know if I am failing to understand the problem, or underestimating the complexity of the solution, but I'd like to propose at least a dialog here of what it would take to implement a busy frequency detector. I'm not at all interested in discussing systems that may or may not use such a detector, or the politics / etc. involved. I am interested in at least defining the process of how a busy frequency detector should work, and defining some base requirements for how well it would need to work to be considered 'adequate' for use in amateur radio.
My idea is to first define what the system should do, then define how well it would have to work to be considered successful or useful, and finally to consider the technical details required to implement such a system. To that end, the following to which I am inviting comments from this group, is my first pass at defining what a busy frequency detector should do (please hold comments on how well it would have to work, and how to implement it for follow-up threads, for now lets focus on getting the process definition refined): ------------ General process flow for a signal detector / frequency busy detector implemented as a part of a semi-automated RF based client server message transport system. - A server (semi-automated which will respond to a request) is listening on a fixed frequency and 'sampling' a given range of its audio passband at a given sample rate. At this time is is listening to 'noise', and remembering what noise 'probably' sounds like. - The server learns and continuously refines its model for what noise has sounded like recently, and 'predicts' what noise is likely to sound like in the very near future, adapting to minor changes in noise. - The server 'hears' a client request. The client is not automated, and a human listened to the frequency to determine it was not in use (it is possible for this process to be replaced by the same black box used on the server side to determine if the frequency is in use). The clients request to the server should serve as a QRL? to all stations on frequency that can hear it. If the client receives a QRL (i.e. any signal that isn't an ACK from the server), it sends a CANCEL to the server. If the client doesn't get an ACK from the server, it will assume the server has detected the frequency is busy on its end, and wait a reasonable period of time before retrying to connect to the server. - If the server doesn't 'think' there is any other signal in its pass band, the server waits a given period of time, 'listening' for a QRL from any stations that may have heard the client request or a CANCEL from the client. If it doesn't hear a QRL (which for our purposes would be any signal that isn't a client request), or a CANCEL from the client, the server will ACK the client request, the ACK will function as the servers QRL?. If the server 'thought' there was already a signal in its passband, it would ignore the clients request outright. - The server listens for a given period of time for a response to its ACK/QRL?, if it doesn't hear one, it 'decides' the frequency is clear and responds to the client request. ------------- So what do you folks think, is this a reasonable process for an rf based client / server busy frequency detection system? 73, Erik N7HMS PS. Everyone knows a software project will never be successful without a catchy acronym or code name... if this ever becomes a real software product / project, lets NOT use the acronym BFD!
