It may be that Dave et. al. decide not to incorporate an automatic mode recognition feature, and so an external program may be the only route, but I'd hope not since I think automatic mode recognition inside fldigi would be great.
However, I'd like to suggest separating the incremental development of such a feature from its eventual implementation. Personally I think it's more easily developed and prototyped externally because of the ease of writing the test programs and algorithms in scripting languages such as Perl or Python. Leigh/WA5ZNU > Sounds like an excellent candidate for a separate program. > > This might be somewhat involved from what I am hearing and if the approach > would turn out to be like > ALE , if not a separate program then perhaps a separate fork. > > I haven't experienced the difficulty in identifying signals especially > since > the samples of the different modes > supported in Fldigi were posted some time ago. That was very nice indeed. > We use it in our training very heavily along with > the throughput charts to help folks understand why one might choose a > particular mode over another. > > Just my thoughts. It is an intriguing idea though. > > 73's > > Mike > > On Tue, Jun 1, 2010 at 7:23 PM, [email protected] < > [email protected]> wrote: > >> Hi, >> >> Thanks for the answer. >> >> Maybe we could have this kind of architecture: >> >> * A scanning module which handles the logic of working on a range >> frequency, with given steps depending on the frequency. Tempo for each >> frequency, loop or stop after one scan, etc... ( xml-rpc >> main.set_frequency >> ). It might run as well on a list of predefined frequencies (ALE). >> >> * A list of 'reasonable' modes to try, based on the frequency and user >> choices. Based on usual rules and frequency usage. >> >> * A module which 'decides' to 'try' a frequency because there is a >> signal. >> It uses the signal/noise ratio, and can be customized given the mode, >> but by >> default just uses the power. Maybe uses xml-rpc modem.get_quality >> function ? >> Or modem.search_up and modem.search_down, but at the moment the virtual >> function modem::searchUp is implemented only for psk and rtty, and we >> would >> also have to extend the maximum frequency where this function can go, >> because it is limited at the moment to IMAGE_WIDTH-bandwidth. >> >> * A module which 'tries' to decode ( text.get_rx / main.rx ) with the >> current mode and, given the result, decide whether it is positive or >> not. >> Depending on the modem, it can be the entropy, or a reasonable number of >> English words, etc... abstracted in a boolean value. Uses >> modem.set_by_id >> >> * An optional module sending a specific message when something is >> detected >> on a frequency ( main.run_macro or main.tx ). It would wait until the >> current emission is finished. >> >> * A function which saves the frequency map + time + detected sample, in >> a >> browsable format (DBLog database or ADIF for example) >> >> Would we create a new program or adds this to an existing prog ? Or >> create >> a super-macro ? >> >> Thanks >> >> Remi >> >> >> Leigh L. Klotz, Jr WA5ZNU wrote: >> >>> I wanted to do this a few years ago; one idea I had then was letting >>> the >>> user pick the bandwidth of the signal, and then decoding and measuring >>> the >>> entropy of the received text. It might be good to use the network >>> interface >>> to do this, because you then have the freedom to prototype in any >>> language. >>> >>> I've done some tests and just calculating entropy or Phi value >>> (approximation of English letter frequency) isn't good enough yet. >>> I did this by analyzing fldigi log files, not by comparing decoding >>> output >>> of different modems, so maybe entropy would be good enough. >>> Phi is not useful, though, because of the high frequency of acronyms, >>> Q-signals, and numeric reports in short samples of QSOs. >>> >>> Leigh/WA5ZNU >>> >>> >>> On 05/31/2010 02:00 PM, [email protected] wrote: >>> >>>> Thanks for the answer. This is something like that I have in mind: A >>>> kind >>>> of software-based scanner looping on every frequency of a given >>>> frequency >>>> range, with a given step. >>>> At each step, it measures the signal/noise ratio. If it is powerful >>>> enough, it tries a subset of modem types (Subset based on the >>>> frequency for >>>> example). For each of them, it waits a couple of seconds, and tries to >>>> decode something meaningful. Instead of looping on a frequency rqnge, >>>> it >>>> might as well try a list of given frequencies. >>>> >>>> If it can find something 'interesting' (Occurence of given strings >>>> such >>>> as 'CQ', callsigns, english words etc...) , it writes the data and the >>>> frequency in a logbook (Or database like DBlog's one). >>>> >>>> I wondered whether <SRCHUP> and <SRCHDN> may help, but I could not >>>> really >>>> understand them nor make them work. >>>> >>>> Thanks >>>> >>>> R >>>> >>>> >>>> >>>> Andy obrien wrote: >>>> >>>>> I have a problem guessing which are the transmit modes of some >>>>> signals >>>>>>>> we receive. >>>>>>>> >>>>>>>> So, do you please think it would be possible to have an automatic >>>>>>>> system >>>>>>>> for guessing the mode of a signal ? >>>>>>>> >>>>>>>> Something which would try all fldigi modes, wait a couple of >>>>>>>> seconds >>>>>>>> to >>>>>>>> decode something, >>>>>>>> >>>>>>> >>>>> You may be able to do thisalready via the macros. To save sometime, >>>>> break it down in to a couple of macros differentiated by distinct >>>>> classes of signals, leave out the ones you are already knowledgeable >>>>> about (e.g. RTTY is so distinct you probably do not need that in a >>>>> macro, same for PSK31. ) example >>>>> >>>>> >>>>> <MODEM:CTSTIA:250:8> >>>>> <MODEM:CTSTIA:500:16> >>>>> <MODEM:CTSTIA:1000:8> >>>>> <MODEM:CTSTIA:1000:16> >>>>> <MODEM:CTSTIA:500:8> >>>>> >>>>> >>>>> and play around with the <TIMER:NN> commands in between each mode >>>>> command. >>>>> >>>>> Andy K3UK >>>>> _______________________________________________ >>>>> fldigi-alpha mailing list >>>>> [email protected] >>>>> https://lists.berlios.de/mailman/listinfo/fldigi-alpha >>>>> >>>>> >>>> _______________________________________________ >>>> fldigi-alpha mailing list >>>> [email protected] >>>> https://lists.berlios.de/mailman/listinfo/fldigi-alpha >>>> >>> >>> >> _______________________________________________ >> fldigi-alpha mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/fldigi-alpha >> > _______________________________________________ fldigi-alpha mailing list [email protected] https://lists.berlios.de/mailman/listinfo/fldigi-alpha
