Hello Sergio, Of course, if the channel (+ your receiver and your non-linear filters) would be completly equalized, it will come much better towards decoding. However, it would remain QRN (parasitics) and QRM which could not be equalized as they are completly random. Without QRN and QRM, the channel would be a perfect channel supporting only gaussian white noise (the best for the decoder).
Note: the equalization is a very complex technic. 73 Patrick ----- Original Message ----- From: Sergio Manrique Almeida To: [email protected] Sent: Tuesday, January 09, 2007 12:34 AM Subject: RE: [digitalradio] Channel Equalization, was: best mode to use for weak signal 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: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Patrick Lindecker Enviado el: lunes, 08 de enero de 2007 21:15 Para: [email protected] 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 To: [email protected] 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 [email protected], "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: [email protected] > 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 > > > > >
