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
