Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: WOLF sources

To: [email protected]
Subject: Re: LF: WOLF sources
From: [email protected]
Date: Sat, 09 Apr 2005 21:44:18 +0200
Reply-to: [email protected]
Sender: [email protected]
Hi Stewart and group,

That's great news, thanks ! I don't have MS C (instead Borland C++Builder) but it shouldn't be too tough to create a project file. I will try to build your original project as soon as time permits. Will keep you (and all) informed, maybe on a temporary website.
At the moment, trying to get SP0PAPA's attention but inner-EU conditions seem 
to be very poor now (19:43 UTC).

Best regards,
Wolf DF0WD / DL4YHF
(sorry for any commercials added by webmail service)



--- original Nachricht Ende ----


Hi Wolf and all,

I just posted a copy of the WOLF sources at http://www.scgroup.com/ham/wolf-source.zip

This has the complete environment; if you have MS VC++
you should be able to build it right away.  Binaries
are also included, so you can see if the build gives
the same results.

The code is simple C, so it should not be hard to
build it with Borland or GCC.  All the real work
is done in wolf.cpp; there are various utility
functions in fft.cpp.

Although I don't presently have time to write new code,
I'd be glad to answer any questions that may come up.

In addition to a GUI and real-time operation, here are
some features I'd like to (eventually) see:

1. Slow it down!  Instead of a raw rate of 10 bps,
  operation at e.g. 1 or 2 bps would greatly
  reduce interference to stations operating on
  nearby frequencies, and permit operation between
  LORAN lines.  A slower format would also be much
  more tolerant of timing errors, in a future system
  using synchronized clocks.

  I believe that reducing the data rate is a simple
  matter of adjusting some parameters, but there
  are two problems: a) It's likely that many Tx or
  Rx would not be phase-stable over the 8 or 16
  minutes that a frame would now take.  One would
  need to add a "stability" setting to allow
  searching for carrier frequency and phase over a
  selectable fraction of a frame.  b) It would be
  a shame to have to wait 16 minutes for results,
  even when the incoming signal is strong.  One
  could perform a decode with e.g. 1/4 of a frame,
  substituting "erasures" for the missing bits.

2. Provide for Tx/Rx bit timing synchronization.
  This could use GPS or another external source,
  or simply depend on accurate computer clocks.
  That should greatly improve sensitivity, by
  eliminating false reference pattern sync on
  weak signals.

3. Implement "smart" signal averaging, weighting
  the incoming message symbols according to the
  quality of the received reference symbols.
  That would avoid degradation of data received
  during good propagation, by noise received
  during prior poor propagation.  Also, when
  the received reference is "excellent", the
  decoder could reset, allowing different
  messages to be sent in each frame.

A combination of (2) and (3) should permit
operation at "any" SNR, though it would of course
take 100 times longer to receive a signal 10 dB
weaker.

4. Implement some means of Tx/Rx carrier sync.
  This probably requires GPS at the Tx end,
  though it may be possible to use LORAN QRM
  on receive.  First, that would improve LF
  skywave performance by a few dB.  However,
  on a long-term phase stable path, e.g. VLF
  or groundwave, it should permit operation at
  any SNR, taking only 10 times longer to
  receive a signal 10 dB weaker.

If different folks are interested in tackling
these topics, perhaps I could act as a coordinator.

73,

Stewart KK7KA













<Prev in Thread] Current Thread [Next in Thread>