Date   

Re: 10 Meter FM Data USA Par97 limitations ?. #Intro

M5AKA
 

Sounds like the Packet operation you heard on 29.250 MHz didn't conform to the FCC license conditions.

You're correct the bandwidth for a 1200 baud FSK transmission with 1 kHz shift would be about 3 kHz but the "(7) RTTY" definition indicates you could only use it below 28.3 MHz if it had Emission Designator codes of either F1B or J2B.

Feeding 1200 baud FSK with 1 kHz shift into an FM transmitter would be an Emission Designator of F2B and this is not permitted for RTTY on 10m.

73 Trevor M5AKA



Re: 10 Meter FM Data USA Par97 limitations ?. #Intro

Graham
 

Hi, Trevor 

The  VARA FM modem base band  is  about  3 KHz  bandwidth , will  pass  via  normal  FM voice  channel , the  9600  version is  wider of  course . 

Regulations  allow  for  FSK, which is a variation  of  FM  to  be   1200  baud  at  1 KHz  shift , as to the  effective  bandwidth   , has to be  over 3 KHz 
The modem should  work  with a  normal narrow  band  FM voice  channel on  10 meters ,  out side the  Union,  packet  used to  exist  , using FM  on  29.250 ,

If the  FM version  is not  possible,  then  HF remains the  only  option, at 7 K its  still   quick ..  users  may  not  of  linked the  FM version  with , HF , ie 10 meters  , The object of the  thread was to  explore  possible  deployments ,out side the accepted  norm ,  some  are possible , some not, the  graphic illustrates this 

The  badge FM did  cause some  confusion , the  modem  is  designed  to  be  conveyed  via   'ssb'   or  'fm , where  as the  FM version  can only be  conveyed , via  FM, the  HF version  is able to  accommodate  all transmission  modes  and paths.

73- Graham 

 



Re: 10 Meter FM Data USA Par97 limitations ?. #Intro

Gary Chatters WA9ZZZ
 

On 11/4/18 9:52 AM, Graham wrote:

[...]
There  is no  mention  of actual  transmission 'mode'  though ,  FSK by  hard keying ,  is base band  FM
[...]

As I understand the regulations, RTTY and Data on 10m are permitted only from 28.000 MHz to 28.300 MHz.

To determine what transmission modes are referred to by "RTTY" and "Data" you have to look in section 97.3 "Definitions".

Then to learn what each of those emission designators refer to, look them up in section 2.201 "Emission, modulation, and transmission characteristics." Note: This is Part 2, not Part 97.



Many years ago (before maybe 1970) RTTY on 10m was permitted in the 29.0-29.7 MHz range using frequency modulation techniques (F1 or F2).

gc


Re: 10 Meter FM Data USA Par97 limitations ?. #Intro

M5AKA
 

Graham, if you are suggesting a 12 kHz bandwidth FM transmission on 10m it seems it would not be permitted in USA, see the definitions of "Data" and "RTTY":

(2) Data. Telemetry, telecommand and computer communications emissions having (i) designators with A, C, D, F, G, H, J or R as the first symbol, 1 as the second symbol, and D as the third symbol; (ii) emission J2D; and (iii) emissions A1C, F1C, F2C, J2C, and J3C having an occupied bandwidth of 500 Hz or less when transmitted on an amateur service frequency below 30 MHz. Only a digital code of a type specifically authorized in this part may be transmitted.


(7) RTTY. Narrow-band direct-printing telegraphy emissions having designators with A, C, D, F, G, H, J or R as the first symbol; 1 as the second symbol; B as the third symbol; and emission J2B. Only a digital code of a type specifically authorized in this part may be transmitted.


73 Trevor M5AKA

On Sunday, 4 November 2018, 14:52:49 GMT, Graham <g0nbd@...> wrote:


Thank's Ev,

Right , that  look's  like the  same as  I found , your upto  1200  baud , with  fsk 1 Khz shift ,  [now that's  'buzzing' along  hihi]
There  is no  mention  of actual  transmission 'mode'  though ,  FSK by  hard keying ,  is base band  FM  

(4) Only a RTTY or data emission using a specified digital code listed in §97.309(a) of this part may be transmitted. The symbol rate must not exceed 1200 bauds, or for frequency-shift keying, the frequency shift between mark and space must not exceed 1 kHz.

There  used to  be  activity on  29.250   , 1200 packet FM  , ie  Voice  channel  B/W  , I see  from the  regulations  [part97]  that  only   'Voice  and  Image'  is  permitted  above  28.300 , I assume,  image  use to  mean  , Analogue  fax like  transmission and not  image  by  data  transfer , hence the  de-bar ?  The two  tone packet  modem, is , via , heterodyne , is producing  FSK , so  = ok ?

The  regulations  appear to define  content and not  method in this  case ,  with other pre limitations  ,  already defined.     . 


If  data can be  sent  under 28.300 MHz  using  FSK/FM  , then ,  its  possible to  deploy  the  VARA modem   'FM'  1200  baud  replacement  version  on  10 meter HF using  FM speech bandwidth  ???

Tnx-Graham.



NB: VARA FM is  
NOT replacement  for the   HF version ....But  , 
If stations  have  good  10 meter  link's  ,  its  possible  to  deploy the  FM version and  achieve  higher  data  throughput   
trial  deployment is  recommended , 

VAAR is provided  in two  versions ,  
HF  requires  SSB  and may be  deployed  via  FM  
FM requires FM and is  not  compatible  with SSB


Re: 10 Meter FM Data USA Par97 limitations ?. #Intro

Graham
 

Thank's Ev,

Right , that  look's  like the  same as  I found , your upto  1200  baud , with  fsk 1 Khz shift ,  [now that's  'buzzing' along  hihi]
There  is no  mention  of actual  transmission 'mode'  though ,  FSK by  hard keying ,  is base band  FM  

(4) Only a RTTY or data emission using a specified digital code listed in §97.309(a) of this part may be transmitted. The symbol rate must not exceed 1200 bauds, or for frequency-shift keying, the frequency shift between mark and space must not exceed 1 kHz.

There  used to  be  activity on  29.250   , 1200 packet FM  , ie  Voice  channel  B/W  , I see  from the  regulations  [part97]  that  only   'Voice  and  Image'  is  permitted  above  28.300 , I assume,  image  use to  mean  , Analogue  fax like  transmission and not  image  by  data  transfer , hence the  de-bar ?  The two  tone packet  modem, is , via , heterodyne , is producing  FSK , so  = ok ?

The  regulations  appear to define  content and not  method in this  case ,  with other pre limitations  ,  already defined.     . 


If  data can be  sent  under 28.300 MHz  using  FSK/FM  , then ,  its  possible to  deploy  the  VARA modem   'FM'  1200  baud  replacement  version  on  10 meter HF using  FM speech bandwidth  ???

Tnx-Graham.



NB: VARA FM is  
NOT replacement  for the   HF version ....But  , 
If stations  have  good  10 meter  link's  ,  its  possible  to  deploy the  FM version and  achieve  higher  data  throughput   
trial  deployment is  recommended , 

VAAR is provided  in two  versions ,  
HF  requires  SSB  and may be  deployed  via  FM  
FM requires FM and is  not  compatible  with SSB


Re: 10 Meter FM Data USA Par97 limitations ?. #Intro

Ev Tupis <w2ev@...>
 

Sure, Trevor.  Set your mode switch to SSB and operate 1200 baud packet in the USA data sub-bands (not the voice sub-bands).  Perfectly legal.

In the early days of the PropNET project, we used this approach to fantastic success (in fact, the speed of the transmission allowed occasional meteor scatter...despite those that predicted otherwise).

Cheers,
Ev, W2EV


On Sunday, November 4, 2018, 6:55:31 AM EST, AKA via Groups.Io <m5aka@...> wrote:


Ev, could you clarify what you mean when you say - "SSB-based" data transmission is allowed, however. 
Are you suggesting "SSB-based" data modes are permitted in the phone bands??

My interpretation of Part 97 is that Data modes in 10m are only permitted between 28.000 and 28.300 MHz and are subject to a 1200 baud symbol rate restriction.

73 Trevor M5AKA



On Sunday, 4 November 2018, 11:42:50 GMT, Ev Tupis via Groups.Io <w2ev@...> wrote:


In a nutshell...

There is no US allocation on the 10 meter band within which DATA and FM is concurrent.

"SSB-based" data transmission is allowed, however.

Ev, W2EV


On Sunday, November 4, 2018, 6:35:29 AM EST, Ev Tupis via Groups.Io <w2ev@...> wrote:


On Saturday, November 3, 2018, 5:28:10 PM EDT, Graham <g0nbd@...> wrote:


Can someone clarify the position on sending   data using FM on 10 meters , inside USA 

used to be  1200 packet on 29.250 , using FM , many moons ago  in Europe , rest of world 
but, is data allowed  at that end of the band in the part97

Are there limits for FM data on the band,  300 baud still apply ? Inside data segment ?
Max b/with ?

Tnx  Graham
G0nbd


Re: 10 Meter FM Data USA Par97 limitations ?. #Intro

M5AKA
 

Ev, could you clarify what you mean when you say - "SSB-based" data transmission is allowed, however. 
Are you suggesting "SSB-based" data modes are permitted in the phone bands??

My interpretation of Part 97 is that Data modes in 10m are only permitted between 28.000 and 28.300 MHz and are subject to a 1200 baud symbol rate restriction.

73 Trevor M5AKA



On Sunday, 4 November 2018, 11:42:50 GMT, Ev Tupis via Groups.Io <w2ev@...> wrote:


In a nutshell...

There is no US allocation on the 10 meter band within which DATA and FM is concurrent.

"SSB-based" data transmission is allowed, however.

Ev, W2EV


On Sunday, November 4, 2018, 6:35:29 AM EST, Ev Tupis via Groups.Io <w2ev@...> wrote:


On Saturday, November 3, 2018, 5:28:10 PM EDT, Graham <g0nbd@...> wrote:


Can someone clarify the position on sending   data using FM on 10 meters , inside USA 

used to be  1200 packet on 29.250 , using FM , many moons ago  in Europe , rest of world 
but, is data allowed  at that end of the band in the part97

Are there limits for FM data on the band,  300 baud still apply ? Inside data segment ?
Max b/with ?

Tnx  Graham
G0nbd


Re: 10 Meter FM Data USA Par97 limitations ?. #Intro

Ev Tupis <w2ev@...>
 

In a nutshell...

There is no US allocation on the 10 meter band within which DATA and FM is concurrent.

"SSB-based" data transmission is allowed, however.

Ev, W2EV


On Sunday, November 4, 2018, 6:35:29 AM EST, Ev Tupis via Groups.Io <w2ev@...> wrote:


On Saturday, November 3, 2018, 5:28:10 PM EDT, Graham <g0nbd@...> wrote:


Can someone clarify the position on sending   data using FM on 10 meters , inside USA 

used to be  1200 packet on 29.250 , using FM , many moons ago  in Europe , rest of world 
but, is data allowed  at that end of the band in the part97

Are there limits for FM data on the band,  300 baud still apply ? Inside data segment ?
Max b/with ?

Tnx  Graham
G0nbd


Re: 10 Meter FM Data USA Par97 limitations ?. #Intro

Ev Tupis <w2ev@...>
 

On Saturday, November 3, 2018, 5:28:10 PM EDT, Graham <g0nbd@...> wrote:


Can someone clarify the position on sending   data using FM on 10 meters , inside USA 

used to be  1200 packet on 29.250 , using FM , many moons ago  in Europe , rest of world 
but, is data allowed  at that end of the band in the part97

Are there limits for FM data on the band,  300 baud still apply ? Inside data segment ?
Max b/with ?

Tnx  Graham
G0nbd


Re: #SDR Anyone Using SDRUserListBrowser ? #SDR

James Clark
 

CsVUserListBrowser is not too difficult - I installed it yesterday and am pretty relaxed in using it by today. Make good use of its "Help" facility, it explains things well.

Setting up the virtual COM ports may be taxing for non computer people but it's not as hard as you may think. Download Com0Com, run it and accept all the defaults.

Post back to this list if you have specific questions - it's not good to take such issues to e-mail as a major aspect of mailing lists is to create a base of knowledge for others to use and they can't do that if it's in private e-mail.


10 Meter FM Data USA Par97 limitations ?. #Intro

Graham
 

Can someone clarify the position on sending   data using FM on 10 meters , inside USA 

used to be  1200 packet on 29.250 , using FM , many moons ago  in Europe , rest of world 
but, is data allowed  at that end of the band in the part97

Are there limits for FM data on the band,  300 baud still apply ? Inside data segment ?
Max b/with ?

Tnx  Graham
G0nbd


#SDR Anyone Using SDRUserListBrowser ? #SDR

rmrrgs
 

Hello,

If this is a duplicate, I apologize.  pc acting up again.

Have a new SDRPlay RSP-2 and am using it with HDSDR.
Am also working on using CSVUserListBrowser with it.  Terrific program.

Sr. Citizen now, and I miss many of the nuances, I think.

Don't want to bother everyone here with all my dumb questions.

Anyone willing to work with me a bit off line on using CSVUserListbrowser ?

Would be most appreciative.

I'm at RGSROSE@...

Thanks,
Bob


Re: pre-processing signals for digimode #Software

William Kimber
 

You mean something like this:


KerberosSDR - 4x Coherent RTL-SDR


I have no connection with them but might consider buying from their Indiegogo campaign.


Cheers,

Will

ZL1TAO

On 31/10/18 2:13 AM, Siegfried Jackstien wrote:
<SNIP>
better would be coherent receivers with adding some phasing .... but then you loose the polarisation diversity

dg9bfc sigi

ps ... best would be 4 antenna horizontal and 4 antennas vertical in a circle ... plus EIGHT receiver inputs and some clever dsp that does all the beam forming and noise surpression with phasing and adding or substracting signals


Re: pre-processing signals for digimode #Software

Kristoff Bonne
 

Mariano,



You know. This is funny.
For some reason, every time I discuss digital-modes, I end up with a link to astronomy.

One of my side-projects is the promotion of amateur-radio to the open-source / hacker / maker community (*). That is why I describe digimodes as basically "digital signal-processing techniques that happens to be applied to radio, but can be applied everywhere".

One of the nice examples of this is also related to astronomy (or more precisely, astrophotography).
When taking pictures of very weak objects (like deep-sky objects, outside the Milky Way), the problem is that the amount of light they receive is actually less then the inherent noise of the CCD-chip of a camera. For that reason, astronomy uses a technique called "photo-stacking": instead of taking one photograph of on object, take a multiple of them and for every pixel calculate the average of that pixel in all these photos.
This "averaging out noise" is exactly one of the techniques used by the amateur-radio weak-signal modes to decode signals with negative S/N values.

And; in fact, a professor who was visiting our ham-radio infobooth at FOSDEM explained to me that in his field he used electron-microscopes, and they have exactly the same problem ... and use the same technique to solve it.


If you don't mind, I will use your remark during my next presentation on amateur-radio. :-)



73
kristoff - ON1ARF

(*) And the other way around, promoting open-source, hacker/maker spaces and fablabs to the amateur-radio clubs, which turns out to a lot more difficult then the former!

On 29/10/18 16:05, Mariano Sanchez Pont wrote:
Hello to everyone!

In astronomy, the use a similar approach to effectively cancel the atmospheric turbulence. They use sodium lasers to project an artificial star in the upper atmosphere, all the characteristics of this star are known, and a special detector is used to see this star. The differences between the original and the observed star are calculated and with this data a small deformable mirror is used to correct the atmospheric turbulences in the real images. The results are awesome.
I think that it could be possible to do something similar with radio.

73s

El lun., 29 oct. 2018 15:56, Rick Muething <rmuething@cfl.rr.com <mailto:rmuething@cfl.rr.com>> escribió:

Kristoff/All,

That is a good question and you have highlighted the major
obstacle in
preforming lets call it "DSP pre emphasis or post processing" of
signals
to offset distortions caused in propagation.  Here are the major
issues:

1) Propagation changes fairly rapidly...sometimes as fast as every
100
ms (ever hear of fast flutter on a signal).  Normally HF has
significant
changes every 1- 5 seconds or so.  Its rare to have a stable channel
with just random Gaussian noise.

2) Some of these changes can be reduced with post reception DSP
processing....PROVIDED: You have a recent (within the last few
seconds)
reference (known signal) to use as a template from which to "measure"
the channel distortion.   This is done to at least some degree on
some
modes (Pactor 4 I think) but requires significant real time DSP
horsepower (basically implementing something like a reverse HF
propagation simulator to try and partially null the effects of the
channel changes).  Of course sending the reference signal also
contains
little or no message information so this itself degrades the net
throughput of the channel. (part of the no free lunch Theorem!)

3) Some of the most common channel degradation is deep fading due to
multipath.  We have all heard this and seen this on HF. If the
desired
signal (or reference signal in 2 above) fades deep into the noise
it is
not practical to recover it. True random (near Gaussian) noise
cannot be
filtered out of a very weak signal ....its random.

4) Much of the interference we hear on HF (as opposed to
VHF/UHF/Microwave) is atmospheric and NOT random Gaussian noise.
Things
like QRM, Static crashes or motor/arc interference (noise but not
Gaussian noise) and these demand much different approaches and are
not
easy to implement and often are not very effective. This is why
normally
on digital modes turning on a radio's "noise blanker" seldom helps
and
often hurts reception.  The same is true with things like notch
filters.

One other worthwhile (but sometimes hard to implement
...especially for
remote mobile stations) is diversity reception (two antennas using
different polarization or spaced from each other).  With the right
combination diversity reception can significantly improves things
like
deep fading but this is not really normally a DSP type function.
(Though I guess you could have two receivers and use DSP to
combine the
audios emphasizing the one with the highest S:N.)

So that's my thoughts. I have a lot of experinece in DSP and have and
MSEE degree but I think there are always room for good ideas to
try and
this is the way we make progress (but sometimes SLOW progress!!)
Perhaps others may have some experience or suggestions.

73,

Rick Muething, KN6KB Winlink Development Team, Author of WINMOR
and ARDOP

On 10/29/2018 8:12 AM, Kristoff Bonne wrote:
> Hi all,
>
>
> A very basic "digital" question.
> Yesterday, I was doing some basic DSP 101 (trying to create a
> FIR-filter based on the measured impulse response of an analog
filter)
> and was watching this video by Dave Gunness for some more
background
> information. It talks on how measuring the acoustics of a
loudspeaker,
> turn that is a mathematical model and finally a FIR-filter. The
goal
> is to "pre-process" the audio-signal send to the loudspeaker in
such a
> way to "undo" the effects the physical build of the loudspeaker
has on
> the audio-signal before it is send to the loudspeaker.
>
> https://www.youtube.com/watch?v=jL_1DwUMD2w
>
>
> This got me wondering.
> In essences, this is basic signal-processing, .. in a way that also
> digimode communication is basically signal-processing
techniques: you
> send out a signal over RF, the radio-propagation does all kind of
> weird things to that signal, and -at the receiving end- the
digimode
> software must try to "undo" these changes so to extract the
original
> data.
>
> So, my question.
> Are there ham-radio digimodes that use the same idea as
explained in
> the video and "pre-process" the signal before transmitting.
> I know this requires a communication return-path from the
receiver to
> the transmitter as the receiver must be able to tell the
transmitter
> how it receives the transmission.
> Or does this not make sense for HF? (perhaps the conditions on HF
> change to fast)?
>
>
>
> Anybody any idea on this?
>
>
> 73
> kristoff - ON1ARF
>
>
>
>
>





Re: pre-processing signals for digimode #Software

Kristoff Bonne
 

Hi Rik, all,


First, thanks for the reply :-) (and also everybody else who replied)


On 29/10/18 15:56, Rick Muething wrote:
Kristoff/All,

That is a good question and you have highlighted the major obstacle in preforming lets call it "DSP pre emphasis or post processing" of signals to offset distortions caused in propagation.  Here are the major issues:

1) Propagation changes fairly rapidly...sometimes as fast as every 100 ms (ever hear of fast flutter on a signal).  Normally HF has significant changes every 1- 5 seconds or so.  Its rare to have a stable channel with just random Gaussian noise.
Well, I did not realise that a HF radio-channel could change that fast. (but then again, I guess that is something you only notice when you deal with digital communication at low-level).


I guess this is also what Patrick explained.

(...)

3) Some of the most common channel degradation is deep fading due to multipath.  We have all heard this and seen this on HF. If the desired signal (or reference signal in 2 above) fades deep into the noise it is not practical to recover it. True random (near Gaussian) noise cannot be filtered out of a very weak signal ....its random.
I guess that where interleaving comes in.


But interleaving requires a error-correction scheme on top of it, which requires more bits for the same data, .. which then reduces the overall net bitrate. ..
I know, "no free lunch".



4) Much of the interference we hear on HF (as opposed to VHF/UHF/Microwave) is atmospheric and NOT random Gaussian noise. Things like QRM, Static crashes or motor/arc interference (noise but not Gaussian noise) and these demand much different approaches and are not easy to implement and often are not very effective. This is why normally on digital modes turning on a radio's "noise blanker" seldom helps and often hurts reception.  The same is true with things like notch filters.
This in interesting. Then how do you deal with this?
Or do you just throw more error-correction bits at this hoping that sufficient of them make it to the receiver so the original data can be reproduced?



So that's my thoughts. I have a lot of experinece in DSP and have and MSEE degree but I think there are always room for good ideas to try and this is the way we make progress (but sometimes SLOW progress!!)  Perhaps others may have some experience or suggestions.

As I am just starting of at this, I will surely not be the one to teach you how to do your job.


But I must say that, for somebody who is interested in this but has never had any experience with this or learned this at university, the learning-curve is very steep. I haven't found that much information on how to learn this step by step.

Learning and understanding general principles and ideas (modulation-schemes, error-correction, interleaving, basic signal-processing techniques) is one thing. But actually learning how to actually implement this, is a very different beast.

As we now have tools like gnuradio, it would be nice if there would be some flow-graphs of basic digimode receivers to help introduce newcomers to the basic ideas of digital signal-processing, to experiment with it and wrap their head around it.


I think that the radio-hobby -as a whole- as everything to gain from having more people actually learn, understand and -perhaps- develop digimodes, instead of just being a user / operator, .. but I really think that, without some basic tools to get people started, this is a very difficult thing to do.


73
kristoff - ON1ARF


Re: pre-processing signals for digimode #Software

Siegfried Jackstien
 

i can tell you that polarisation changes are very often to be seen (heard) on rf

when i do dxing on 20 or 40 (as an example) i always have two antennas running ... one is a multiband vertical on the other is a horizontal loop antenna ... and during a longer qso when there is a deep fade i just switch antenna and the signal is clear again ... and when on that antenna the signal fades ... flip the switch again to the first antenna

that helped me to keep the qso going even on loger fade outs (exactly it was fading out on one antenna only and was strong on the other)

a few years ago i had two sdr running on two different antennas and received better as with a single antenna (see example above) .... but there i just added the audio streams together (on left and right speaker) and let the brain do the rest

better would be coherent receivers with adding some phasing .... but then you loose the polarisation diversity

dg9bfc sigi

ps ... best would be 4 antenna horizontal and 4 antennas vertical in a circle ... plus EIGHT receiver inputs and some clever dsp that does all the beam forming and noise surpression with phasing and adding or substracting signals



Am 29.10.2018 um 14:56 schrieb Rick Muething:

Kristoff/All,

That is a good question and you have highlighted the major obstacle in preforming lets call it "DSP pre emphasis or post processing" of signals to offset distortions caused in propagation.  Here are the major issues:

1) Propagation changes fairly rapidly...sometimes as fast as every 100 ms (ever hear of fast flutter on a signal).  Normally HF has significant changes every 1- 5 seconds or so.  Its rare to have a stable channel with just random Gaussian noise.

2) Some of these changes can be reduced with post reception DSP processing....PROVIDED: You have a recent (within the last few seconds) reference (known signal) to use as a template from which to "measure" the channel distortion.   This is done to at least some degree on some modes (Pactor 4 I think) but requires significant real time DSP horsepower (basically implementing something like a reverse HF propagation simulator to try and partially null the effects of the channel changes).  Of course sending the reference signal also contains little or no message information so this itself degrades the net throughput of the channel. (part of the no free lunch Theorem!)

3) Some of the most common channel degradation is deep fading due to multipath.  We have all heard this and seen this on HF. If the desired signal (or reference signal in 2 above) fades deep into the noise it is not practical to recover it. True random (near Gaussian) noise cannot be filtered out of a very weak signal ....its random.

4) Much of the interference we hear on HF (as opposed to VHF/UHF/Microwave) is atmospheric and NOT random Gaussian noise. Things like QRM, Static crashes or motor/arc interference (noise but not Gaussian noise) and these demand much different approaches and are not easy to implement and often are not very effective. This is why normally on digital modes turning on a radio's "noise blanker" seldom helps and often hurts reception.  The same is true with things like notch filters.

One other worthwhile (but sometimes hard to implement ...especially for remote mobile stations) is diversity reception (two antennas using different polarization or spaced from each other).  With the right combination diversity reception can significantly improves things like deep fading but this is not really normally a DSP type function.  (Though I guess you could have two receivers and use DSP to combine the audios emphasizing the one with the highest S:N.)

So that's my thoughts. I have a lot of experinece in DSP and have and MSEE degree but I think there are always room for good ideas to try and this is the way we make progress (but sometimes SLOW progress!!)  Perhaps others may have some experience or suggestions.

73,

Rick Muething, KN6KB Winlink Development Team, Author of WINMOR and ARDOP

On 10/29/2018 8:12 AM, Kristoff Bonne wrote:
Hi all,


A very basic "digital" question.
Yesterday, I was doing some basic DSP 101 (trying to create a FIR-filter based on the measured impulse response of an analog filter) and was watching this video by Dave Gunness for some more background information. It talks on how measuring the acoustics of a loudspeaker, turn that is a mathematical model and finally a FIR-filter. The goal is to "pre-process" the audio-signal send to the loudspeaker in such a way to "undo" the effects the physical build of the loudspeaker has on the audio-signal before it is send to the loudspeaker.

https://www.youtube.com/watch?v=jL_1DwUMD2w


This got me wondering.
In essences, this is basic signal-processing, .. in a way that also digimode communication is basically signal-processing techniques: you send out a signal over RF, the radio-propagation does all kind of weird things to that signal, and -at the receiving end- the digimode software must try to "undo" these changes so to extract the original data.

So, my question.
Are there ham-radio digimodes that use the same idea as explained in the video and "pre-process" the signal before transmitting.
I know this requires a communication return-path from the receiver to the transmitter as the receiver must be able to tell the transmitter how it receives the transmission.
Or does this not make sense for HF? (perhaps the conditions on HF change to fast)?



Anybody any idea on this?


73
kristoff - ON1ARF






Re: pre-processing signals for digimode #Software

Patrick Lindecker
 

Kristoff,

In the audio-example, it must be placed on the transmitting-side as the goal is that the "receiver" (i.e. the listener) should >not have to do any "correction" but for HF communication,
For HF, it would be curious that the correction could be proposed by the TX as it ignores how the ionosphere will react (the ionosphere behavior effects must be considered as random for very small durations). For audio, I suppose that the transfer function of the channel is known by the TX and so can be proposed by the TX to the RX.

Question. Do you really need these "known patterns"?
Once you have a 100 % correctly decoded signal, you should be able to recreate the signal as it was transmitted no? Why not use >that as a reference?
You are right, it is not absolutely necessary. It is possible to use the signal itself to do the equalization. But I guess that the decoding result must not be very good compared with equalization from known patterns which are relatively easy to detect (at least professionals have chosen between both possibilities).
Of course, as says Rick there is a loss in the throughput, so there is a compromise to do.

Example: I tried to counterbalance the Doppler in BPSK31 (it's an option in Multipsk), from the signal information itself, but I noted that it worked only with strong signals, which remove much interest.

73
Patrick




-----Message d'origine-----
De : main@digitalradio.groups.io [mailto:main@digitalradio.groups.io] De la part de Kristoff Bonne
Envoyé : lundi 29 octobre 2018 15:41
À : main@digitalradio.groups.io
Objet : Re: [digitalradio] pre-processing signals for digimode #Software

Bonjour Patrick,


OK, I understand it.
In essence, it does not make a difference where you place the "correction" algorithm, at the transmitter side or in the receiver.

In the audio-example, it must be placed on the transmitting-side as the goal is that the "receiver" (i.e. the listener) should not have to do any "correction" but for HF communication, I guess placing it in the receiver is better as it does not require a return-channel.


Sometimes, signal-processing can logical, ... if you just think about it :-)


Question. Do you really need these "known patterns"?
Once you have a 100 % correctly decoded signal, you should be able to recreate the signal as it was transmitted no? Why not use that as a reference?


(I know, coding this is probably a lot more difficult than just discussing it) :-)


Thx
Kristoff - ON1ARF


On 29/10/18 13:48, Patrick Lindecker wrote:
Hello Kristoff,

Equalization is used for several professional modes (HFDL for example), i.e quick PSK modes used in HF for long distances. Note that without equalization the decoding would be almost impossible.

For this, known sequences are sent regularly. From these sequences, using complex equalization algorithms, you can determine the best corrections to do under the form of a filter, more or less the inverse of the ionosphere effects transformed in the form of a filter: i.e Amplitude=f(t, t+dt, t+2*dt...). These corrections will apply to the next unknown sequence, as it is implicitly supposed that the ionosphere will not change while transmitting the unknown sequence.

As far as I know, equalization is not used for Ham communication.

73
Patrick


-----Message d'origine-----
De : main@digitalradio.groups.io [mailto:main@digitalradio.groups.io] De la part de Kristoff Bonne
Envoyé : lundi 29 octobre 2018 13:12
À : main@digitalradio.groups.io
Objet : [digitalradio] pre-processing signals for digimode #Software

Hi all,


A very basic "digital" question.
Yesterday, I was doing some basic DSP 101 (trying to create a FIR-filter based on the measured impulse response of an analog filter) and was watching this video by Dave Gunness for some more background information. It talks on how measuring the acoustics of a loudspeaker, turn that is a mathematical model and finally a FIR-filter. The goal is to "pre-process" the audio-signal send to the loudspeaker in such a way to "undo" the effects the physical build of the loudspeaker has on the audio-signal before it is send to the loudspeaker.

https://www.youtube.com/watch?v=jL_1DwUMD2w


This got me wondering.
In essences, this is basic signal-processing, .. in a way that also digimode communication is basically signal-processing techniques: you send out a signal over RF, the radio-propagation does all kind of weird things to that signal, and -at the receiving end- the digimode software must try to "undo" these changes so to extract the original data.

So, my question.
Are there ham-radio digimodes that use the same idea as explained in the video and "pre-process" the signal before transmitting.
I know this requires a communication return-path from the receiver to the transmitter as the receiver must be able to tell the transmitter how it receives the transmission.
Or does this not make sense for HF? (perhaps the conditions on HF change to fast)?



Anybody any idea on this?


73
kristoff - ON1ARF





---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus





Re: pre-processing signals for digimode #Software

Mariano Sanchez Pont
 

Hello to everyone! 

In astronomy, the use a similar approach to effectively cancel the atmospheric turbulence. They use sodium lasers to project an artificial star in the upper atmosphere, all the characteristics of this star are known, and a special detector is used to see this star. The differences between the original and the observed star are calculated and with this data a small deformable mirror is used to correct the atmospheric turbulences in the real images. The results are awesome.
I think that it could be possible to do something similar with radio.

73s

El lun., 29 oct. 2018 15:56, Rick Muething <rmuething@...> escribió:
Kristoff/All,

That is a good question and you have highlighted the major obstacle in
preforming lets call it "DSP pre emphasis or post processing" of signals
to offset distortions caused in propagation.  Here are the major issues:

1) Propagation changes fairly rapidly...sometimes as fast as every 100
ms (ever hear of fast flutter on a signal).  Normally HF has significant
changes every 1- 5 seconds or so.  Its rare to have a stable channel
with just random Gaussian noise.

2) Some of these changes can be reduced with post reception DSP
processing....PROVIDED: You have a recent (within the last few seconds)
reference (known signal) to use as a template from which to "measure"
the channel distortion.   This is done to at least some degree on some
modes (Pactor 4 I think) but requires significant real time DSP
horsepower (basically implementing something like a reverse HF
propagation simulator to try and partially null the effects of the
channel changes).  Of course sending the reference signal also contains
little or no message information so this itself degrades the net
throughput of the channel. (part of the no free lunch Theorem!)

3) Some of the most common channel degradation is deep fading due to
multipath.  We have all heard this and seen this on HF. If the desired
signal (or reference signal in 2 above) fades deep into the noise it is
not practical to recover it. True random (near Gaussian) noise cannot be
filtered out of a very weak signal ....its random.

4) Much of the interference we hear on HF (as opposed to
VHF/UHF/Microwave) is atmospheric and NOT random Gaussian noise. Things
like QRM, Static crashes or motor/arc interference (noise but not
Gaussian noise) and these demand much different approaches and are not
easy to implement and often are not very effective. This is why normally
on digital modes turning on a radio's "noise blanker" seldom helps and
often hurts reception.  The same is true with things like notch filters.

One other worthwhile (but sometimes hard to implement ...especially for
remote mobile stations) is diversity reception (two antennas using
different polarization or spaced from each other).  With the right
combination diversity reception can significantly improves things like
deep fading but this is not really normally a DSP type function. 
(Though I guess you could have two receivers and use DSP to combine the
audios emphasizing the one with the highest S:N.)

So that's my thoughts. I have a lot of experinece in DSP and have and
MSEE degree but I think there are always room for good ideas to try and
this is the way we make progress (but sometimes SLOW progress!!) 
Perhaps others may have some experience or suggestions.

73,

Rick Muething, KN6KB Winlink Development Team, Author of WINMOR and ARDOP

On 10/29/2018 8:12 AM, Kristoff Bonne wrote:
> Hi all,
>
>
> A very basic "digital" question.
> Yesterday, I was doing some basic DSP 101 (trying to create a
> FIR-filter based on the measured impulse response of an analog filter)
> and was watching this video by Dave Gunness for some more background
> information. It talks on how measuring the acoustics of a loudspeaker,
> turn that is a mathematical model and finally a FIR-filter. The goal
> is to "pre-process" the audio-signal send to the loudspeaker in such a
> way to "undo" the effects the physical build of the loudspeaker has on
> the audio-signal before it is send to the loudspeaker.
>
> https://www.youtube.com/watch?v=jL_1DwUMD2w
>
>
> This got me wondering.
> In essences, this is basic signal-processing, .. in a way that also
> digimode communication is basically signal-processing techniques: you
> send out a signal over RF, the radio-propagation does all kind of
> weird things to that signal, and -at the receiving end- the digimode
> software must try to "undo" these changes so to extract the original
> data.
>
> So, my question.
> Are there ham-radio digimodes that use the same idea as explained in
> the video and "pre-process" the signal before transmitting.
> I know this requires a communication return-path from the receiver to
> the transmitter as the receiver must be able to tell the transmitter
> how it receives the transmission.
> Or does this not make sense for HF? (perhaps the conditions on HF
> change to fast)?
>
>
>
> Anybody any idea on this?
>
>
> 73
> kristoff - ON1ARF
>
>
>
>
>





Re: pre-processing signals for digimode #Software

Rick Muething
 

Kristoff/All,

That is a good question and you have highlighted the major obstacle in preforming lets call it "DSP pre emphasis or post processing" of signals to offset distortions caused in propagation.  Here are the major issues:

1) Propagation changes fairly rapidly...sometimes as fast as every 100 ms (ever hear of fast flutter on a signal).  Normally HF has significant changes every 1- 5 seconds or so.  Its rare to have a stable channel with just random Gaussian noise.

2) Some of these changes can be reduced with post reception DSP processing....PROVIDED: You have a recent (within the last few seconds) reference (known signal) to use as a template from which to "measure" the channel distortion.   This is done to at least some degree on some modes (Pactor 4 I think) but requires significant real time DSP horsepower (basically implementing something like a reverse HF propagation simulator to try and partially null the effects of the channel changes).  Of course sending the reference signal also contains little or no message information so this itself degrades the net throughput of the channel. (part of the no free lunch Theorem!)

3) Some of the most common channel degradation is deep fading due to multipath.  We have all heard this and seen this on HF. If the desired signal (or reference signal in 2 above) fades deep into the noise it is not practical to recover it. True random (near Gaussian) noise cannot be filtered out of a very weak signal ....its random.

4) Much of the interference we hear on HF (as opposed to VHF/UHF/Microwave) is atmospheric and NOT random Gaussian noise. Things like QRM, Static crashes or motor/arc interference (noise but not Gaussian noise) and these demand much different approaches and are not easy to implement and often are not very effective. This is why normally on digital modes turning on a radio's "noise blanker" seldom helps and often hurts reception.  The same is true with things like notch filters.

One other worthwhile (but sometimes hard to implement ...especially for remote mobile stations) is diversity reception (two antennas using different polarization or spaced from each other).  With the right combination diversity reception can significantly improves things like deep fading but this is not really normally a DSP type function.  (Though I guess you could have two receivers and use DSP to combine the audios emphasizing the one with the highest S:N.)

So that's my thoughts. I have a lot of experinece in DSP and have and MSEE degree but I think there are always room for good ideas to try and this is the way we make progress (but sometimes SLOW progress!!)  Perhaps others may have some experience or suggestions.

73,

Rick Muething, KN6KB Winlink Development Team, Author of WINMOR and ARDOP

On 10/29/2018 8:12 AM, Kristoff Bonne wrote:
Hi all,


A very basic "digital" question.
Yesterday, I was doing some basic DSP 101 (trying to create a FIR-filter based on the measured impulse response of an analog filter) and was watching this video by Dave Gunness for some more background information. It talks on how measuring the acoustics of a loudspeaker, turn that is a mathematical model and finally a FIR-filter. The goal is to "pre-process" the audio-signal send to the loudspeaker in such a way to "undo" the effects the physical build of the loudspeaker has on the audio-signal before it is send to the loudspeaker.

https://www.youtube.com/watch?v=jL_1DwUMD2w


This got me wondering.
In essences, this is basic signal-processing, .. in a way that also digimode communication is basically signal-processing techniques: you send out a signal over RF, the radio-propagation does all kind of weird things to that signal, and -at the receiving end- the digimode software must try to "undo" these changes so to extract the original data.

So, my question.
Are there ham-radio digimodes that use the same idea as explained in the video and "pre-process" the signal before transmitting.
I know this requires a communication return-path from the receiver to the transmitter as the receiver must be able to tell the transmitter how it receives the transmission.
Or does this not make sense for HF? (perhaps the conditions on HF change to fast)?



Anybody any idea on this?


73
kristoff - ON1ARF




Re: pre-processing signals for digimode #Software

Kristoff Bonne
 

Bonjour Patrick,


OK, I understand it.
In essence, it does not make a difference where you place the "correction" algorithm, at the transmitter side or in the receiver.

In the audio-example, it must be placed on the transmitting-side as the goal is that the "receiver" (i.e. the listener) should not have to do any "correction" but for HF communication, I guess placing it in the receiver is better as it does not require a return-channel.


Sometimes, signal-processing can logical, ... if you just think about it :-)


Question. Do you really need these "known patterns"?
Once you have a 100 % correctly decoded signal, you should be able to recreate the signal as it was transmitted no? Why not use that as a reference?


(I know, coding this is probably a lot more difficult than just discussing it) :-)


Thx
Kristoff - ON1ARF

On 29/10/18 13:48, Patrick Lindecker wrote:
Hello Kristoff,

Equalization is used for several professional modes (HFDL for example), i.e quick PSK modes used in HF for long distances. Note that without equalization the decoding would be almost impossible.

For this, known sequences are sent regularly. From these sequences, using complex equalization algorithms, you can determine the best corrections to do under the form of a filter, more or less the inverse of the ionosphere effects transformed in the form of a filter: i.e Amplitude=f(t, t+dt, t+2*dt...). These corrections will apply to the next unknown sequence, as it is implicitly supposed that the ionosphere will not change while transmitting the unknown sequence.

As far as I know, equalization is not used for Ham communication.

73
Patrick


-----Message d'origine-----
De : main@digitalradio.groups.io [mailto:main@digitalradio.groups.io] De la part de Kristoff Bonne
Envoyé : lundi 29 octobre 2018 13:12
À : main@digitalradio.groups.io
Objet : [digitalradio] pre-processing signals for digimode #Software

Hi all,


A very basic "digital" question.
Yesterday, I was doing some basic DSP 101 (trying to create a FIR-filter based on the measured impulse response of an analog filter) and was watching this video by Dave Gunness for some more background information. It talks on how measuring the acoustics of a loudspeaker, turn that is a mathematical model and finally a FIR-filter. The goal is to "pre-process" the audio-signal send to the loudspeaker in such a way to "undo" the effects the physical build of the loudspeaker has on the audio-signal before it is send to the loudspeaker.

https://www.youtube.com/watch?v=jL_1DwUMD2w


This got me wondering.
In essences, this is basic signal-processing, .. in a way that also digimode communication is basically signal-processing techniques: you send out a signal over RF, the radio-propagation does all kind of weird things to that signal, and -at the receiving end- the digimode software must try to "undo" these changes so to extract the original data.

So, my question.
Are there ham-radio digimodes that use the same idea as explained in the video and "pre-process" the signal before transmitting.
I know this requires a communication return-path from the receiver to the transmitter as the receiver must be able to tell the transmitter how it receives the transmission.
Or does this not make sense for HF? (perhaps the conditions on HF change to fast)?



Anybody any idea on this?


73
kristoff - ON1ARF





---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus



821 - 840 of 51567