> > 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.
This is the first problem. In EU you won't find any 'noise' on an open HF band, just 'qrm', from stations X kmiles away. You would have to define what level of 'qrm' defines a clear frequency. And you would have to define what 'bandwidth' should be clear. E.g. should I have 3 kHz of clear frequency to run a pskmail server which needs only 200 Hz + 100 Hz guard band? I can put a few waterfall pics up on the pskmail wiki which show a 'clear' frequency on 30m. > > - 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. Minor changes in noise won't do, the qrm will change drastically from second to second. One example would be the harmonics of the APRS packet frequency on 30m which spread > 3kHz, and certainly should not trigger 'busy'. > > - 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. Again,you should define what is a 'signal' here. This could be anything including the neighbour's kitchen sink. > 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. How should the server know if it is a client request? Is the criterium a fully decoded connect request in the mode which the server is runiing? Can it also be anything the server can decode in the mode it is operating in? 1 dB S/N can make the difference between decoding and not decoding and QSB can be 80 dB. The connect sequence is the most vulnerable in the whole arq procedure. Once the connect is done the arq can do its job. In my experience sometimes it is necessary to send 5 connect requests to set up the session, which does not have any problem to get the job done. In my opinion this step is too complicated. > > - 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. Is a QRL something the server decodes in its present mode, or is it any signal in the passband, like the switching charger in the next camper or the fan in the chicken farm next door? Why should the server wait after a connect request? It did listen on the frequency all the time so it knows if it is busy or not... > > - 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. This step is not necessary in my opinion. It is enough if the server has an idea if the qrg was 'busy' before the connect request. If it thinks the fequency is busy it can send a 'cancel' or a 'reject' to the client. In general think the procedure is too complicated. My 2cts Rein EA/PA0R/P (You could of course ask the client to give a 'QRL?' in CW before pushing the 'ON' switch, preferably with a 3 kHz wide signal so everybody can hear it within the span of his filters). > > ------------- > > 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! > > > > > Announce your digital presence via our DX Cluster > telnet://cluster.dynalias.org > > Our other groups: > > http://groups.yahoo.com/group/dxlist/ > http://groups.yahoo.com/group/themixwgroup > http://groups.yahoo.com/group/contesting > http://groups.yahoo.com/group/wnyar > http://groups.yahoo.com/group/Omnibus97 > > > Yahoo! Groups Links > > > > -- http://pa0r.blogspirit.com ------------------------ Yahoo! Groups Sponsor --------------------~--> Something is new at Yahoo! Groups. Check out the enhanced email design. http://us.click.yahoo.com/kOt0.A/gOaOAA/yQLSAA/ELTolB/TM --------------------------------------------------------------------~-> Announce your digital presence via our DX Cluster telnet://cluster.dynalias.org Our other groups: http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/themixwgroup http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/wnyar http://groups.yahoo.com/group/Omnibus97 Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
