Patrick et al., 

 

I wonder if it would be an advantage having a digital mode/program able to
equalize frequency and/or group delay response of the transceivers, which
remain stable unless you switch filters, etc.

 

Regards,

Sergio, EA3DU

 

-----Mensaje original-----
De: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] En
nombre de Patrick Lindecker
Enviado el: lunes, 08 de enero de 2007 21:15
Para: digitalradio@yahoogroups.com
Asunto: Re: [digitalradio] Channel Equalization, was: best mode to use for
weak signal

 

Hello Vojtech,

 

I don't know either the Pawel code. It's too difficult to read. I know just
the main stages used.

 

>code contains input processor doing channel equalization and burst
As far as I know (and there is no such feature in Multipsk), there is no
channel equalization in Olivia. In HF there would be no interest as the
channel transfer function moves all times and too quickly. Moreover it will
need some impulse in input so to determine the transfer function with output
and input, which is not expected.

 

>burst removal

I think you mean the way to take the input among the carriers to do the soft
decision. The principle is to integrate the average level during a
sufficiently long delay and not to compare with the instantaneous value but
to this average level so as to forget bursts. I don't put this in the first
versions, but I add this after (it is quite complex in my code and I think
it might be much better written in the Pawell code).

 

Note: Pawel code uses FFT, Multipsk (and surely Mixw) use a bank of matched
filters so as not to be obliged to handle only one frequency.

 

> Does MultiPsk utilize channel equalization for Olivia/Contestia/RTTYM?
No.


>- Does MultiPsk utilize channel equalization for other MFSK modes like
>MFSK16/8, Throb/ThrobX or even old plain RTTY?
No


>- Do you find the channel equalization feature useful?
No in HF (except perhaps in 28 MHz), yes in VHF. In HF, you have too much
QRN, QRM, Doppler, multipath in random way with stochastic properties which
are not constant in time.

 

>running on my 200MHz StrongArm PocketPC with channel equalization

Bravo, well done!

 

73

Patrick

 

 

----- Original Message ----- 

From: Vojtech Bubnik <mailto:[EMAIL PROTECTED]>  

To: digitalradio@ <mailto:digitalradio@yahoogroups.com> yahoogroups.com 

Sent: Monday, January 08, 2007 11:02 AM

Subject: [digitalradio] Channel Equalization, was: best mode to use for weak
signal

 

Hi Patrick.

I studied the Olivia reference implementation from Pawel Jalocha. His
code contains input processor doing channel equalization and burst
removal in a way I do not understand well yet. I have a question on
you as a digital modes guru:

- Does MultiPsk utilize channel equalization for Olivia/Contestia/RTTYM?

- Does MultiPsk utilize channel equalization for other MFSK modes like
MFSK16/8, Throb/ThrobX or even old plain RTTY?

- Do you find the channel equalization feature useful?

I have a basic Olivia and Contestia based on Pawel reference code
running on my 200MHz StrongArm PocketPC with channel equalization
removed. My concern is power consumption of the device if I enable
channel equalization.

Thanks and VY 73, Vojtech OK1IAK

--- In digitalradio@ <mailto:digitalradio%40yahoogroups.com>
yahoogroups.com, "Patrick Lindecker" <[EMAIL PROTECTED]>
wrote:
>
> Hello Rick,
> 
> >If often wonder if a mode that has a very wide ability to print
even if 
> >not tuned in well has to have some tradeoffs in robustness compared
with 
> >critical to tune modes. Anyone have specific information about that?
> The ability of DominoEx to be tuned very easily is that the
modulation is an IFK one and not a MFSK one. It means that you measure
a difference of frequency not a frequency in absolute as in MFSK. The
good point it is easy to tune (no absolute reference of frequency) but
the bad point is that when you do an error, the second symbol is also
in error...you double the error (it's a bit like in PSK31, which one
measures a difference of phase: if you do a error on one symbol, the
next symbol will be also in error).
> 
> >Can anyone say with some degree of certainly what modes you think will 
> >get through on the low bands with high QRN levels?
> I think Olivia must be good but Contestia is more close to ideal as
twice quicker than Olivia with a minimum S/N just 1 or 1.5 dB superior
to Olivia.
> 
> 73
> Patrick
> 
> 
> 
> ----- Original Message ----- 
> From: KV9U 
> To: digitalradio@ <mailto:digitalradio%40yahoogroups.com> yahoogroups.com 
> Sent: Friday, December 01, 2006 7:49 PM
> Subject: Re: [digitalradio] best mode to use for weak signal HF
work and other mode discussions
> 
> 
> Brett,
> 
> There are several sound card modes commonly used in addition to
the most 
> popular PSK31 and 45 baud RTTY That would be MFSK16, Olivia, Hell,
and 
> Throb/ThrobX. Although there are others, I rarely, if ever hear
them. I 
> no longer seem to hear any MT-63 and the CHIP modes came and went
quickly.
> 
> I wanted to do more experimenting with DominoEX and last night I
got to 
> work some 160 meter NVIS. We started out on MFSK16 but I have been 
> having a lot of problems with this mode as of late and maybe it is 
> because my soundcard is not calibrated correctly, but I find that
I have 
> to use about 10 to 20 Hz offset RIT in order to print the other
station. 
> MFSK16 really does require extremely accurate tuning of perhaps 4
Hz or 
> so. My rig is an ICOM 756 Pro 2 which is supposed to have very good 
> stability at 0.5 ppm.
> 
> The other station and I tried some PSK31 for a short time when I lost 
> him on MFSK16 and was just able to get him to try DominoEX at 11
baud. 
> His signal was close to the noise although it was not that noisy
on 160 
> since we are in the winter season. The print was very poor at 11
baud, 
> so we dropped to 8 baud and things got better. Even at 8 baud, the
speed 
> of transmission is still faster than MFSK16. We had a CW station
come up 
> about 50 Hz below us and when that station was transmitting, it 
> drastically affected the print of the DEX mode, even at 8 wpm. The
one 
> thing that DEX has going for it is that it is less critical to
tune in.
> 
> If often wonder if a mode that has a very wide ability to print
even if 
> not tuned in well has to have some tradeoffs in robustness
compared with 
> critical to tune modes. Anyone have specific information about that?
> 
> We probably should have tried even slower speeds because later on
I had 
> great difficulty copying him and took lots of hits. He is running
Linux 
> so did not have the FEC version of DEX. My experience in the past was 
> that the Viterbi coding helps a great deal in good printing, even
at 11 
> baud, but of course your speed drops by all of 50% so you are just
a bit 
> slower at 11 baud/FEC than you would be with MFSK16.
> 
> It would be interesting to hear of other station's experience with
DEX 
> and DEX/FEC and various speeds with and without FEC, particularly
with 
> the lower baud rates on low band NVIS type operation.
> 
> One of the things that I have to accept is that almost none of these 
> modes will work very well on the lower bands with high QRN levels
from 
> summer static.
> 
> Can anyone say with some degree of certainly what modes you think
will 
> get through on the low bands with high QRN levels?
> 
> 73,
> 
> Rick, KV9U
> 
> Brett Owen Rees VK2TMG wrote:
> 
> > All,
> >
> > I find that I normally use PSK31 - as that is what most other
stations 
> > use
> > and is popular. But, I see a lot of stations that I cannot work
- yet 
> > I can
> > see their trace on the waterfall. Often, they are responding to
my CQ and
> > they just don't make it. Why do people respond to a 2 * 3 call
with a 
> > 1*1 or
> > 1*2 call? There seems to be a strategy for psk31 mode that involves 
> > sending
> > information multiple times - like a poor man's FEC. I expect
that is why
> > they know who I am - from listening to my 2 * 3 call.
> >
> > The thing is - is there a mode that if I can see them on the
waterfall 
> > then
> > I can work them? I see no reason why we can't just go 
> > narrower/slower/more
> > FEC and go right down into the noise. And why not have it be
adaptive 
> > - and
> > be able to become faster and wider if conditions are good - and
even 
> > have a
> > feature of being able to set a max bandwidth for those who may be
> > constrained or for where a number of stations are sharing a 2.4KHz 
> > segment?
> >
> > Things I like about PSK31:
> > - easy to tune with start bars, idle bars and ending tail
(sorry, my 
> > naming
> > scheme here)
> > - narrow bandwidth
> > - popular
> >
> > Things I dislike:
> > - lack of RX sensitivity at times
> > - errors at low SN
> >
> > Features that would be nice:
> > - reliable, verified delivery
> > - ability to use as part of a 'stack' so as to use for APRS or
TCP/IP or
> > file transfer or ALE or sounding or whatever
> > - easy tuning
> > - highly adaptive under trying conditions
> > - be basis of keyboard mode DX mode
> > - Open Source
> >
> > Please - I would like your opinions on this. Perhaps one of the
current
> > modes could be adapted - or am I trying to re-invent the wheel?
What 
> > is the
> > best that is out there currently and can we make use of it? In
an ideal
> > world what would be the theoretical best that we could aim for? I 
> > understand
> > that with Turbo codes that it is possible to come very close to 
> > theoretical
> > limits - are amateur protocols using such techniques? Having
done some
> > reading about DominoEX there appears to be various workarounds
which 
> > may be
> > required in order to make a mode practical - like being able to
work 
> > around
> > a carrier on the frequency.
> >
> > 73 de Brett VK2TMG
> >
> >----------------------------------------------------------
> >
> >No virus found in this incoming message.
> >Checked by AVG Free Edition.
> >Version: 7.1.409 / Virus Database: 268.15.3/562 - Release Date:
12/1/2006
> > 
> >
>

 

Reply via email to