[Laser] WOLF-GUI program

[James Whitfield]

Yves:

Interesting reading.  I was wondering what audio frequencies were being used
for the testing?  If it is only 20 Hz then each bit is sent as only two full
cycles of data at 0.1 seconds per bit.


I also have a comment about a possible future modification of the program to
optimize it for light communication use:

As I understand the WOLF system it is a package of 960 bits sent BPSK at 10
bits per second.  Half of the transmitted data a pseudo random reference bit
stream.  The other half is the 80 bit payload message expanded by FEC to 480
bits.  The two bit streams alternate bit by bit.  The part that I read says
that the reference is used to lock in the signal frequency and phase.
This is very useful for a radio system that may not have a known, or maybe
not a stable, transmitter frequency or receiver system.  However......

My comment:  For use with a light communication system, you should not
"need" the reference data to get very accurate frequency or timing data.
I wonder if the pilot data stream is still needed for some other reason that
was not stated?   If it is not needed at all, then I have to assume that the
system will work better if it is removed -----  either double the data rate
with the same performance or increase the time allocated to each bit to
improve the performance even more.

It may be that the pilot data is still needed.  In that case, why?  Also, is
it necessary to use half of the system throughput for the pilot data.  If is
still needed to make the system work, but not for frequency stability, and
not using half the throughput, how much pilot data is needed?  25 percent?
10 percent?  Less?




While I am thinking about "tweaking" the system to get a little more out of
it, I wonder if there is any benefit to using different frequency tones
depending on which type of message is being sent.  Suppose N5GUI wants to
send the equivalent of  CQ, and does it by sending the call sign at 80 Hz.
If KE7NB receives the CQ ( the 80 Hz tone but not clear enough to copy the
call sign ) the reply is his call sign on 81 Hz.  If CQ and call sign is
copied, the reply is on 83 Hz.  Similarly, if N5GUI receives either an 81 or
83 Hz tone the reply would be on 82 Hz ( cannot copy the call sign ), or 84
Hz ( can copy the call sign ).   If I understand the protocol of weak signal
exchanges, then a confirmation is not needed, but is proper courtesy.
Simple tones ( call sign already confirmed, so need not be sent ) of 85 Hz
to confirm 84 Hz.  I would extend the protocol by suggesting that the tones
at 86, 87, 88, and 89 Hz be used for messages that contain "conversational"
data instead of  call signs.

That brings up the possibility of a "chat" mode, but I would suggest that be
done at a higher tone frequency and higher data rate than would be typical
of a weak signal contact.  Perhaps an exchange would be like this:

310 Hz   Station A sending CQ ( and willing to chat )
311 Hz   Station B responding to your last call, did not copy, please repeat
at reduced transmission speed
312 Hz   Station A responding to your last call, did not copy, please repeat
at reduced transmission speed
313 Hz   Station B copied your previous transmission, continue at current
transmission speed
314 Hz   Station A copied your previous transmission, continue at current
transmission speed
315 Hz   Station B copied your previous transmission very clearly, suggest
you can increase transmission speed
316 Hz   Station A copied your previous transmission very clearly, suggest
you can increase transmission speed

You might set the values for "copied so little please repeat at slower
speed", "copied most, continue but at slower speed", "continue at same
speed", or "continue at faster speed or reduce FEC for more throughput".
Very dynamic.  Adjust frequency to pass information that is not part of the
text.


James
N5GUI