Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: OPERA QSO

To: <[email protected]>
Subject: Re: LF: OPERA QSO
From: "Graham" <[email protected]>
Date: Thu, 2 Feb 2012 20:04:06 -0000
Importance: Normal
In-reply-to: <002201cce18f$b4c42c70$0401a8c0@xphd97xgq27nyf>
References: <002201cce18f$b4c42c70$0401a8c0@xphd97xgq27nyf>
Reply-to: [email protected]
Sender: [email protected]
Ok  Mal
 
Well  a data  mode was the  original  idea , actually  what  has  evolved  (so  far)  was never  really  envisaged , but  during testing , the  s/n  level  of the  decodes  started  to  drop and we had a  ring side seat  at a race to  the noise  floor ....
 
I did try  some time ago  to  get  some  interest  in adding , arq  function to the  popular  data  modes , after the  original  set of  simple  'shoot out'   data  tests ,  the  original  mfsk did give the  best  results , but  at  wide b/w , but never  managed to  gain any  ground , other than  with the  email  handling  facility  of  fldigi  ,  I think Jim was the  first  to  receive a  radio  email from  me  on 500  using  this method. 
 
The  problem  with  'All'  the  soundcard  based  data  modes is , you  need  to  be  able to  transmit, either  translated frequency  shift  and  some times   amplitude  variation , which  drops most  home made kit   out of the race , ROS -MF  modes  still  require  frequency  translation  from  audio  to  Rf  , but  runs  round  the  -22/-27 dB level  and can pass  via  class  e/d  amps
 
This is where  the  Op  idea  came from , could we use a  cw  tx. to  send serial  data ,
 
The  data  coding  seems  to  be  a  set  length of  6  chr's  for  Op , the  original  concept  , and  assumedly  still  is , that  the  Op system would  have    modes  running   , a  robust    mode  to  provide the  link /lock and  call sign  and a lesser  mode  to  act as the  data transfer ....  this  is  similar to the  ROS  mode , where  the  initial  lock  sequence  is  more  robust  than  the  fasted  data  transfer . I think  we have the lock  phase  on test  at the  moment  ...
 
FEC is provided  , by  way  of the  data  spreading  , not  in the  classic  interleaving / overlaying stepped  in time  , but  as result  of the  numeric  spreading  , which  allow 's  for a  random  loss  of  round 55%  of the  data  to  occur , whilst  still  decoding.
 
The  most  simply  way to  visualise the  process  is a  jig-saw  , where  all the  pieces of the  puzzle  are  gathered together , then assembled to   re-create  the  original  data  , that  why there  is no  Rx  progress  indicator , nothing  is  really  known  until  the final   decode  phase  is entered.
 
Thanks' to all  , makes  all  the  time  Gary  and  I sat during  testing,  waiting  for a  ding  , and yes the  song is  quite  right  , 'it don't mean a  thing if it don't  go  ding'  worth while ...
 
G..

Sent: Thursday, February 02, 2012 9:47 AM
To: rsgb
Subject: LF: OPERA QSO

Graham
Opera seems popular,  are there any plans ahead for a basic QSO mode instead of Beacon only.
At present on MF/LF it has popularity in its favour over the other data modes.
Instead of FEC how about the amtor approach where the transmission triggers a RX stn who responds and a QSO begins. The exchange need only be a few key words.
How about modifying Amtor or Pactor for MF use.
mal/g3kev
 
<Prev in Thread] Current Thread [Next in Thread>