Message-ID: <5AB4FF13.5090805@posteo.de>
Date: Fri, 23 Mar 2018 14:20:19 +0100
From: DK7FC <selberdenken@posteo.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <8a85a7a8-7a1b-f38c-3581-88701aeaf955@n1bug.com> <5AAFE3B3.8050603@posteo.de> <BF78757DDB53418FBDBB44BDDF21C052@PCDaheim> <CAC+C6w41=_5R_po9Kn0Szd7dTtv6DQ4Cgn7uWAPjRwwyoXUpfQ@mail.gmail.com> <579355A36AEE9D4FA555C45D556003ABA3C3A19A@servigilant.vigilant.local> <8E11D917-1416-4D11-A173-E71E2C74FCC1@md.metrocast.net> <5AB42199.9070808@posteo.de> <43A27B71-3D0B-4080-9A82-A5AC340873FE@md.metrocast.net>
In-Reply-To: <43A27B71-3D0B-4080-9A82-A5AC340873FE@md.metrocast.net>
Subject: Re: LF: 2200m Trans-Atlantic QSO dream...
Content-Type: multipart/alternative;
 boundary="------------040403060609040101000301"
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

This is a multi-part message in MIME format.
--------------040403060609040101000301
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Rob,

Am 22.03.2018 23:41, schrieb Rob Renoud:
> As this is an amateur radio transmission, the minimum message should 
> be my 5 character amateur call sign, k3rwr.
On LF it has not been unusual just to transmit the suffix of a callsign 
(at night in QRSS/DFCW), so just 'RWR' would be fine for example.

> Your  suggestion in a previous post was 1/8K=19 Coding; CRC 24, 3 sec 
> Period with a resulting transmission period of 28:48.  Is this still 
> good even though the 3 sec period may be a bit longer than is optimum 
> for 2200m.  Any other suggestions?
The 16K codes need more RAM to compute the message and the CPU will have 
more work to do. But the 16K codes are more effective. On VLF i prefer 
16K21.
It will not make a difference of several dB. Both settings are fine for 
the first experiments. As long as you don't have a decode is is always 
good to use short messages and long symbol lengths. But there may be 
some QSB which turns the phase. EbNaut can correct the phase within 
certain limits ( up to 90 deg i think). Anyway, starting with a 
transmission length of 1 hour or longer may be contraproductive due to 
the QSB. But you can also try that, you will make your observations!
>
> I will transmit on 137.395 KHz with 1W EIRP.  Transmissions will start 
> once I reconfigure the TX hardware and verify that the EbNaut signal 
> is being properly modulated and transmitted.  I will post when the 
> station is up and operating.
As Markus said, it would be useful to TX between 137.45...137.55 kHz 
because there are a few stations already running grabbers for OPDS32, 
exporting FFT data that will contain your message.

Another pretest you could do: DF6NM is running a 424 uHz window on his 
grabber at http://www.df6nm.de/grabber/Grabber.htm You could try to 
leave a trace there, just by running an unmodulated carrier for a few 
hours at night. This way you can control your frequency stability and 
may get an impression about the phase stability over the path. A blurry 
line means high QSB (an AM component widening the trace).

73, GL, Stefan

>
> Tnx & 73,
> Rob - K3RWR
>
>
>
> On Mar 22, 2018, at 17:35, DK7FC <selberdenken@posteo.de 
> <mailto:selberdenken@posteo.de>> wrote:
>
>> Hi Rob,
>>
>> Indeed, i have a suggestion. If you can transmit EbNaut messages, 
>> then let's try if it works. My RX is not overloaded any more. Due to 
>> the high QRN i gave up with the 17 kHz TA attempt . Last night i 
>> copied N1BUG in DFCW-60, maybe 10 dB in 22 mHz in the best times.
>> If you could run a beacon transmission, repeating each 30 minutes, 
>> using these settings: 
>> http://abelian.org/ebnaut/calc.php?sndb=10&snbws=0.022&snmps=&code=16K21&sp=2&crc=18&nc=3&submit=Calculate
>> with a content that makes some sense (like 'YES' rather than 'T.4'), 
>> then i would try to decode you.
>>
>> 73, Stefan
>>
>>
>> Am 20.03.2018 12:17, schrieb Rob Renoud:
>>> Hi LF’ers,
>>>
>>> My LF station TX and RX hardware support EbNaut requirements and I 
>>> currently have EbNaut TX capability implemented and tested into a 
>>> dummy load.  Am working to implement EbNaut RX software and decode 
>>> capability.  Expect it will be several weeks before that capability 
>>> is functional and tested as I’m still learning what is required and 
>>> how to implement it.
>>>
>>> I do agree that EbNaut is most excellent for experimentation and 
>>> possibly QSOs on LF.  I believe the LF community should formulate an 
>>> initial signal configuration for development and testing and one 
>>> that will possibly support minimum QSO requirements as well.  I am 
>>> not smart enough about EbNaut at this point to offer any suggestions 
>>> or make any recommendations about signal configurations.
>>>
>>> I am also available to put a EbNaut signal at 1W EIRP on LF from my 
>>> QTH at FM18qi while I continue implementing full EbNaut RX and 
>>> decode capability.
>>>
>>> All ideas, suggestions and recommendations welcome!
>>>
>>> 73,
>>> Rob - K3RWR
>>>

--------------040403060609040101000301
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Rob, <br>
<br>
Am 22.03.2018 23:41, schrieb Rob Renoud:
<blockquote
 cite="mid:43A27B71-3D0B-4080-9A82-A5AC340873FE@md.metrocast.net"
 type="cite">
  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  <div>As this is an amateur radio transmission, the minimum message
should be my 5 character amateur call sign, k3rwr.</div>
</blockquote>
On LF it has not been unusual just to transmit the suffix of a callsign
(at night in QRSS/DFCW), so just 'RWR' would be fine for example.<br>
<br>
<blockquote
 cite="mid:43A27B71-3D0B-4080-9A82-A5AC340873FE@md.metrocast.net"
 type="cite">
  <div>Your  suggestion in a previous post was 1/8K=19 Coding; CRC 24,
3 sec Period with a resulting transmission period of 28:48.  Is this
still good even though the 3 sec period may be a bit longer than is
optimum for 2200m.  Any other suggestions?</div>
</blockquote>
The 16K codes need more RAM to compute the message and the CPU will
have more work to do. But the 16K codes are more effective. On VLF i
prefer 16K21. <br>
It will not make a difference of several dB. Both settings are fine for
the first experiments. As long as you don't have a decode is is always
good to use short messages and long symbol lengths. But there may be
some QSB which turns the phase. EbNaut can correct the phase within
certain limits ( up to 90 deg i think). Anyway, starting with a
transmission length of 1 hour or longer may be contraproductive due to
the QSB. But you can also try that, you will make your observations!<br>
<blockquote
 cite="mid:43A27B71-3D0B-4080-9A82-A5AC340873FE@md.metrocast.net"
 type="cite">
  <div><br>
  </div>
  <div>I will transmit on 137.395 KHz with 1W EIRP.  Transmissions will
start once I reconfigure the TX hardware and verify that the EbNaut
signal is being properly modulated and transmitted.  I will post when
the station is up and operating.</div>
</blockquote>
As Markus said, it would be useful to TX between 137.45...137.55 kHz
because there are a few stations already running grabbers for OPDS32,
exporting FFT data that will contain your message. <br>
<br>
Another pretest you could do: DF6NM is running a 424 uHz window on his
grabber at <a class="moz-txt-link-freetext" href="http://www.df6nm.de/grabber/Grabber.htm">http://www.df6nm.de/grabber/Grabber.htm</a> You could try to
leave a trace there, just by running an unmodulated carrier for a few
hours at night. This way you can control your frequency stability and
may get an impression about the phase stability over the path. A blurry
line means high QSB (an AM component widening the trace).<br>
<br>
73, GL, Stefan<br>
<br>
<blockquote
 cite="mid:43A27B71-3D0B-4080-9A82-A5AC340873FE@md.metrocast.net"
 type="cite">
  <div><br>
  </div>
  <div>Tnx &amp; 73,</div>
  <div>Rob - K3RWR</div>
  <div><br>
  </div>
  <div><br>
  </div>
  <div><br>
On Mar 22, 2018, at 17:35, DK7FC &lt;<a moz-do-not-send="true"
 href="mailto:selberdenken@posteo.de">selberdenken@posteo.de</a>&gt;
wrote:<br>
  <br>
  </div>
  <blockquote type="cite">
    <div>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
Hi Rob, <br>
    <br>
Indeed, i have a suggestion. If you can transmit EbNaut messages, then
let's try if it works. My RX is not overloaded any more. Due to the
high QRN i gave up with the 17 kHz TA attempt . Last night i copied
N1BUG in DFCW-60, maybe 10 dB in 22 mHz in the best times. <br>
If you could run a beacon transmission, repeating each 30 minutes,
using these settings:
    <a moz-do-not-send="true" class="moz-txt-link-freetext"
 href="http://abelian.org/ebnaut/calc.php?sndb=10&amp;snbws=0.022&amp;snmps=&amp;code=16K21&amp;sp=2&amp;crc=18&amp;nc=3&amp;submit=Calculate">http://abelian.org/ebnaut/calc.php?sndb=10&amp;snbws=0.022&amp;snmps=&amp;code=16K21&amp;sp=2&amp;crc=18&amp;nc=3&amp;submit=Calculate</a><br>
with a content that makes some sense (like 'YES' rather than 'T.4'),
then i would try to decode you.<br>
    <br>
73, Stefan<br>
    <br>
    <br>
Am 20.03.2018 12:17, schrieb Rob Renoud:
    <blockquote
 cite="mid:8E11D917-1416-4D11-A173-E71E2C74FCC1@md.metrocast.net"
 type="cite">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div>Hi LF’ers,</div>
      <div><br>
      </div>
      <div>My LF station TX and RX hardware support EbNaut requirements
and
I currently have EbNaut TX capability implemented and tested into a
dummy load.  Am working to implement EbNaut RX software and decode
capability.  Expect it will be several weeks before that capability is
functional and tested as I’m still learning what is required and how to
implement it.</div>
      <div><br>
      </div>
      <div>I do agree that EbNaut is most excellent for experimentation
and
possibly QSOs on LF.  I believe the LF community should formulate an
initial signal configuration for development and testing and one that
will possibly support minimum QSO requirements as well.  I am not smart
enough about EbNaut at this point to offer any suggestions or make any
recommendations about signal configurations.</div>
      <div><br>
      </div>
      <div>I am also available to put a EbNaut signal at 1W EIRP on LF
from
my QTH at FM18qi while I continue implementing full EbNaut RX and
decode capability.</div>
      <div><br>
      </div>
      <div>All ideas, suggestions and recommendations welcome!</div>
      <div><br>
      </div>
      <div>73,</div>
      <div>Rob - K3RWR</div>
      <br>
    </blockquote>
    </div>
  </blockquote>
</blockquote>
</body>
</html>

--------------040403060609040101000301--