Dave, This went only to me. I think you wanted to send it to the list? BTW I was involved in the development of the visual ID, in 2004-2005, during previous discussion about the ID. I also was the one who got implementation details from Patrick FC6TE about how RSID worked, since originally he had it only in MultiPSK and there wasn't enough information, though of course Stelios and Dave did the implementation.
Here's previous discussion from 2005 on parallel-decoding: http://www.mail-archive.com/[email protected]/msg02826.html Here's my 2004 write-up of the Visual CQ: http://wa5znu.org/log/2004/09/psk-visual-cq.html As for ear signal processing (ESP?) I have a lot of trouble telling the difference between Domino and Domino-FEC, and also am not too good at distinguishing QPSK63 from PSK63. Thor and Domino look a lot alike to me, too. Leigh/WA5ZNU. > GM Gentlemen, > > So what do you call the RSID feature built into FLDIGI if not automatic > mode recognition? The only drawback I see to it is that it requires the > cooperation of the TXing station. Otherwise, it does a great job for > recognizing the various modes automatically. Or, what about the video > IDer? You can send the mode with it. > > Actually, the best automatic mode recognition software available is > between the ears. With a combination of listening to, and looking at, the > signal on the waterfall a lot of the digital modes can be identified or a > lot can be eliminated from the list of modes the signal might be. Of > course, the caveat to that is it takes some practice and some people just > don't want to take the time to practice!! > > Anyway, FWIW as usual. > > Dave K3GAU > > > >>>> "Leigh L. Klotz, Jr. WA5ZNU" <[email protected]> 6/1/2010 8:28 PM >>> > 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 > _______________________________________________ fldigi-alpha mailing list [email protected] https://lists.berlios.de/mailman/listinfo/fldigi-alpha
