Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by klubnl.pl (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w8DB1479021326 for ; Thu, 13 Sep 2018 13:01:06 +0200 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1g0PGa-0003OJ-Eb for rs_out_1@blacksheep.org; Thu, 13 Sep 2018 11:54:32 +0100 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1g0PGX-0003O8-D1 for rsgb_lf_group@blacksheep.org; Thu, 13 Sep 2018 11:54:29 +0100 Received: from omr-a005e.mx.aol.com ([204.29.186.50]) by relay1.thorcom.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.91_59-0488984) (envelope-from ) id 1g0PGU-0001Gz-21 for rsgb_lf_group@blacksheep.org; Thu, 13 Sep 2018 11:54:28 +0100 Received: from mtaomg-aac02.mx.aol.com (mtaomg-aac02.mx.aol.com [172.27.2.36]) by omr-a005e.mx.aol.com (Outbound Mail Relay) with ESMTP id A643F380008B for ; Thu, 13 Sep 2018 06:54:24 -0400 (EDT) Received: from core-ace01a.mail.aol.com (core-ace01.mail.aol.com [172.27.23.1]) by mtaomg-aac02.mx.aol.com (OMAG/Core Interface) with ESMTP id 1956838000081 for ; Thu, 13 Sep 2018 06:54:24 -0400 (EDT) Received: from 80.146.228.86 by webjasstg-vab38.srv.aolmail.net (10.96.25.105) with HTTP (WebMailUI); Thu, 13 Sep 2018 06:54:22 -0400 Date: Thu, 13 Sep 2018 06:54:22 -0400 From: Markus Vester To: rsgb_lf_group@blacksheep.org Message-Id: <165d2914d2e-1eb9-ea@webjasstg-vab38.srv.aolmail.net> In-Reply-To: <5B9A37A3.5080505@posteo.de> MIME-Version: 1.0 X-MB-Message-Source: WebUI X-MB-Message-Type: User X-Mailer: JAS STD X-Originating-IP: [80.146.228.86] x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1536836064; bh=tHOKEWQGotCA2o3n3QcMj6vi3WMZFUDwq8waJyZcTz8=; h=From:To:Subject:Message-Id:Date:MIME-Version:Content-Type; b=Wf4JV54n085HAaH8Aqf9q5GVSFdr9OwFhqoCEk2Il16Z3FqnY5B0+tpEnnW2CaWor /ZaVOIh+xgzHDhUMePxWZtcYWu1h0Z1fbRpZJHmIfHaI8uEt/4uodj1a1k7wpOcPmO 3Mjv2/civ3j/BdWp/e1GK3PesfwU2bSVggdqlY/U= x-aol-sid: 3039ac1b02245b9a41e01601 X-Spam-Score: 0.0 (/) X-Spam-Report: Spam detection software, running on the system "relay1.thorcom.net", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Yes these look like dB's instead of I and Q pairs. I think you have to go to FFT settings and select "FFT Output Type: complex (real+imaginary)". 73, Markus -----Ursprüngliche Mitteilung----- Von: DK7FC An: rsgb_lf_group Verschickt: Do, 13. Sept 2018 12:12 Betreff: Re: LF: The return of EbNaut for Dummies [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [204.29.186.50 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (markusvester[at]aol.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 T_KAM_HTML_FONT_INVALID BODY: Test for Invalidly Named or Formatted Colors in HTML 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Scan-Signature: 32e708ed211ab495d8d0439a22dd5d82 Subject: Re: LF: The return of EbNaut for Dummies Content-Type: multipart/alternative; boundary="----=_Part_316_1561956319.1536836062508" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_40_50,HTML_MESSAGE autolearn=no version=2.63 X-SA-Exim-Scanned: Yes Sender: owner-rsgb_lf_group@blacksheep.org Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false ------=_Part_316_1561956319.1536836062508 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes these look like dB's instead of I and Q pairs. I think you have to go t= o FFT settings and select "FFT Output Type: complex (real+imaginary)". 73, Markus -----Urspr=C3=BCngliche Mitteilung-----=20 Von: DK7FC An: rsgb_lf_group Verschickt: Do, 13. Sept 2018 12:12 Betreff: Re: LF: The return of EbNaut for Dummies Luis,=20 The numbers in the exported FFT data look different here. Not sure if this= is the reason. Thus i asked for the usr file of your SL RX instance. I cou= ld compare it to mine and may find a difference.=20 Another way could be just to transmit the message on your antenna, with so= me power, and i try to decode it from here. What was your TX power in that test? 73, Stefan Am 13.09.2018 11:47, schrieb VIGILANT Luis Fern=C3=A1ndez:=20 #AOLMsgPart_2_caad68d6-02ff-4081-b830-9444c5916108 td{color: black;} @font-= face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face {font= -family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face {font-fami= ly:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;}.aolReplacedBody p.aolmail_MsoNo= rmal,.aolReplacedBody li.aolmail_MsoNormal,.aolReplacedBody div.aolmail_Mso= Normal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"T= imes New Roman",serif; color:black;}.aolReplacedBody a:link,.aolReplacedBod= y span.aolmail_MsoHyperlink {mso-style-priority:99; color:blue; text-decora= tion:underline;}.aolReplacedBody a:visited,.aolReplacedBody span.aolmail_Ms= oHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:un= derline;}.aolReplacedBody p.aolmail_aolmailmsonormal,.aolReplacedBody li.ao= lmail_aolmailmsonormal,.aolReplacedBody div.aolmail_aolmailmsonormal {mso-s= tyle-name:aolmail_msonormal; mso-margin-top-alt:auto; margin-right:0cm; mso= -margin-bottom-alt:auto; margin-left:0cm; font-size:12.0pt; font-family:"Ti= mes New Roman",serif; color:black;}.aolReplacedBody p.aolmail_aolmailmsochp= default,.aolReplacedBody li.aolmail_aolmailmsochpdefault,.aolReplacedBody d= iv.aolmail_aolmailmsochpdefault {mso-style-name:aolmail_msochpdefault; mso-= margin-top-alt:auto; margin-right:0cm; mso-margin-bottom-alt:auto; margin-l= eft:0cm; font-size:12.0pt; font-family:"Times New Roman",serif; color:black= ;}.aolReplacedBody p.aolmail_aolmailmsonormal1,.aolReplacedBody li.aolmail_= aolmailmsonormal1,.aolReplacedBody div.aolmail_aolmailmsonormal1 {mso-style= -name:aolmail_msonormal1; margin:0cm; margin-bottom:.0001pt; font-size:12.0= pt; font-family:"Times New Roman",serif; color:black;}.aolReplacedBody span= .aolmail_aolmailmsohyperlink {mso-style-name:aolmail_msohyperlink;}.aolRepl= acedBody span.aolmail_aolmailmsohyperlinkfollowed {mso-style-name:aolmail_m= sohyperlinkfollowed;}.aolReplacedBody span.aolmail_aolmailestilocorreo17 {m= so-style-name:aolmail_estilocorreo17;}.aolReplacedBody span.aolmail_aolmail= estilocorreo18 {mso-style-name:aolmail_estilocorreo18;}.aolReplacedBody spa= n.aolmail_aolmailestilocorreo19 {mso-style-name:aolmail_estilocorreo19;}.ao= lReplacedBody span.aolmail_aolmailestilocorreo20 {mso-style-name:aolmail_es= tilocorreo20;}.aolReplacedBody span.aolmail_aolmailmsohyperlink1 {mso-style= -name:aolmail_msohyperlink1; mso-style-priority:99; color:blue; text-decora= tion:underline;}.aolReplacedBody span.aolmail_aolmailmsohyperlinkfollowed1 = {mso-style-name:aolmail_msohyperlinkfollowed1; mso-style-priority:99; color= :purple; text-decoration:underline;}.aolReplacedBody span.aolmail_EstiloCor= reo28 {mso-style-type:personal; font-family:"Calibri",sans-serif; color:#1F= 497D;}.aolReplacedBody span.aolmail_EstiloCorreo29 {mso-style-type:personal= ; font-family:"Calibri",sans-serif; color:#1F497D;}.aolReplacedBody span.ao= lmail_EstiloCorreo30 {mso-style-type:personal; font-family:"Calibri",sans-s= erif; color:#1F497D;}.aolReplacedBody span.aolmail_EstiloCorreo31 {mso-styl= e-type:personal; font-family:"Calibri",sans-serif; color:#1F497D;}.aolRepla= cedBody span.aolmail_EstiloCorreo32 {mso-style-type:personal; font-family:"= Calibri",sans-serif; color:#1F497D;}.aolReplacedBody span.aolmail_EstiloCor= reo33 {mso-style-type:personal-reply; font-family:"Calibri",sans-serif; col= or:#1F497D;}.aolReplacedBody .aolmail_MsoChpDefault {mso-style-type:export-= only; font-size:10.0pt;}@page WordSection1 {size:612.0pt 792.0pt; margin:70= .85pt 3.0cm 70.85pt 3.0cm;}.aolReplacedBody div.aolmail_WordSection1 {page:= WordSection1;}=20 Hi Stefan, Markus, EbNaut =20 Sorry. Still no results. I keep dumming L =20 Have tried different messages in 4K19A, down to one character and 3 sec per= symbol Tx and Rx run on the same PC, so timing must be the same. Anyway, if there = is any delay between Tx and Rx I tested the decoder with different shifts in steps of 0.1 s from -3 to +3 s around the calculat= ed timeshift =20 I=E2=80=99m seeing the signal getting wider when modulated at 1 s per symbo= l, but the next step will be to take the Tx side back to check if proper phase shift happens. The Tx runs continous carrier from a G= PS source and I=E2=80=99m using an XOR gate driven by the DTR levels (at 5V= TTL)=20 from a FT232RL USB/COM converter and the software is ebnaut_tx for windows =20 Using the =E2=80=9Ctest=E2=80=9D option in ebnaut_tx I can produce a contin= ous phase change of the signal at different rates. I can see phase changes = in SLab using the =E2=80=9CWatch List and Plotter window=E2=80=9D, but not absolute= phase values. Maybe I have something wrong in the configuration using expresion: pam0.abs_phase =20 Attached is the FFT file, SR config file and WAV produced. The file starts = at 07:55:39.310 I=E2=80=99m using a 120KHz LO converter from GPS. The transmission frequenc= y is 137.485KHz so SLab center frequency is 17485Hz =20 Transmission started at 08:00:00 4K19A CRC16 Symbol period: 3s Message length: 1 Letter: Y =20 Calculated start offset is 260.69 List length used: 16714 =20 73 de Luis EA5DOM =20 De: owner-rsgb_lf_group@blacksheep.org [mailto:owner-rsgb_lf_group@blackshe= ep.org] En nombre de DK7FC Enviado el: martes, 11 de septiembre de 2018 20:53 Para: rsgb_lf_group@blacksheep.org Asunto: Re: LF: The return of EbNaut for Dummies =20 Good luck Luis,=20 Later, for a QSO mode, i would suggest rather to use 8K19A than 4K19A. As = far as i understand this will have more 'coding gain'. As soon as it all works, it becomes quite easy. In Linux one could even run a script doing all the file preparation and de= coding automatically, as demonstrated by Domenico. You just need to watch t= he screen, like in FT8 ;-) 73, Stefan Am 11.09.2018 18:47, schrieb VIGILANT Luis Fern=C3=A1ndez:=20 Hi Markus =20 Noted Very interesting. So I can reduce the interval between generated files just= changing the =E2=80=9CWaterfall scroll interval=E2=80=9D at a fixed value = as 5 minutes for example I had it configured automatic at 75% overlap, so that was changing dependin= g on FFT values and then always getting different interval between files =20 Good to see the =E2=80=9Clight=E2=80=9D J =20 Let=E2=80=99s see if I=E2=80=99m able to get a decode now =20 73 de Luis EA5DOM =20 De: owner-rsgb_lf_group@blacksheep.org [mailto:owner-rsgb_lf_group@blackshe= ep.org] En nombre de Markus Vester Enviado el: martes, 11 de septiembre de 2018 18:13 Para: rsgb_lf_group@blacksheep.org Asunto: Re: LF: The return of EbNaut for Dummies =20 Yes Luis that scheme should work. The 10 minute interval for file generation is not hardwired but simply the= scroll interval, as chosen in the "options - Spectrum display settings" me= nu. Each column in the spectrogram produces one file. You can set faster sc= rolling (at the cost of more data written to the disk), possibly allowing y= ou to decode and answer sooner in a QSO setting.=20 Whether an EbNaut transmission is completely contained in a file also depe= nds on the time when SpecLab was started up, initiating the sequence of fil= es. If the transmission duration is shorter than file duration minus scroll= interval (e.g. 38-10 =3D 28 minutes), there will be at least one file cont= aining the full transmission. But the EbNaut decoder will also work well wi= th recordings which have been truncated at either or both ends, albeit with= some loss of sensitivity. Best 73, Markus =20 =20 -----Urspr=C3=BCngliche Mitteilung-----=20 Von: VIGILANT Luis Fern=C3=A1ndez An: rsgb_lf_group Verschickt: Di, 11. Sept 2018 17:54 Betreff: RE: LF: The return of EbNaut for Dummies Hi Stefan, Markus, EbNaut =20 Thank you for the detailed explanations. Now I really understand the config= uration and how is related to bandwith and length of the recorded files. There is also a fixed time between files recorded and it is= always 10 minutes. But, files are overlapped, so there you can record a file to contain longer than 10 minute transmission =20 So, let=E2=80=99s see which would be a good configuration to perform a real= QSO. Lets say in LF with some S/N and not al VLF levels At the same time can be a good exercise to check if I finally understood al= l this stuff ;-) =20 Tx at 4K19A/CRC16/1 sec symbol rate would take 9 min and 4 sec to transmit = 17 characters messages Assume 15 minutes periods. Lets say first (even) transmitting at the hour = and 30 min pass the hour Second (odd) transmits at minute 15 and 45 =20 Rx at 44100 sample rate, using a 65536 FFT length, and 1536 decimation, fil= e will contain 38 minutes of recorded signal. Looks more than enough as we are using about 9 minutes transmissions. Then bandwidth of the record= ed files will be =E2=80=9CSample rate / decimation=E2=80=9D 44100 / 1536 =3D 28.71 and then divided by two as SLab generates the file, = ending with 14.35Hz. Which is enough bandwith for a 1 sec symbol rate (10/= 1=3D10Hz) =20 So, assume both stations had Rx running previously and SL already producing= files every 10 minutes. Files will contain 38 minutes of recorded signal =20 A file recorded by windows just after transmission end (lets say) 22:10 wo= uld contain a record of 38minutes, so starting time will be really 21:32 This file will contain the message transmited by the station calling in fir= st period (CQ). To decode it we will select a timeshift from 21:32 to 22:00= =3D 28 minutes So there will be time enough to decode the message and then prepare the tra= nsmitter to answer in second period, 15 minutes pass the hour, 22:15 answering the CQ of the station calling first =20 The station calling in first period should have to check for files recorded= at about 22:25 to try to decode an answer And then prepare the corresponding transmission for next even period at 22= :30 =20 Should this timing schem work for QSOs ? Assuming there is enough S/N to wo= rk at this Tx rate of course =20 73 de Luis EA5DOM =20 De: owner-rsgb_lf_group@blacksheep.org [mailto:owner-rsgb_lf_group@blackshe= ep.org] En nombre de DK7FC Enviado el: martes, 11 de septiembre de 2018 15:13 Para: rsgb_lf_group@blacksheep.org Asunto: Re: LF: The return of EbNaut for Dummies =20 Hi Luis,=20 As Markus mentioned... And see the attachment. In the example i set the sample rate to 44100 Hz. = If you have a downconverter with an LO of 120 kHz, and expect a message on = 137 kHz exactly, set the internal frequency shift to a center frequency of = 17 kHz, like shown in the image. Also remember that the number of exported FFT bins in the FFT export regis= ter card should be set to the half of the FFT input size shown in the FFT r= egister card.=20 Keep us informed about the success :-) I'm waiting for your first message to receive here. I'm monitoring permane= ntly, however only in the range 137.5 kHz +- 50 Hz and only about 30 minute= s message length. Other parameters would work too, but i need to prepare a = special SL instance then... 73, Stefan Am 11.09.2018 13:40, schrieb VIGILANT Luis Fern=C3=A1ndez:=20 Hi Stefan =20 Thank you for the detailed explanation. I prefer to understand the process = rather than getting a working .usr So, excuse me again for dumming again J =20 All understood about the length and relation to FFT windows time (length) i= n SL. Width was un unknown parameter for me And I=E2=80=99m afraid the problem is about the width: =20 >> Choose the FFT width and length to suit your settings. The width is mayb= e 10 * 1/(symbol length) or more Lets say 1Hz minimum for a 10 sec symbol leght, right ? =20 So, in the FFT configuration window the only way to get >1Hz(1.3Hz) for =E2= =80=9CWidth of one FFT-bin=E2=80=9D is to reduce decimation to 1 and then set FFT length to 32768 to get some =E2=80=9CFFT window time (leng= th)=E2=80=9D. But then, the indows time is just 743ms which will not cover the length of the message at all =20 I=E2=80=99m stucked here. Can=E2=80=99t get >width with 30 minutes FFT leng= hts. I=E2=80=99m using 44.100Hz sample rate L =20 The FFT input type is =E2=80=9CComplex ith internal frequency shift=E2=80= =9D. But even using =E2=80=9CReal FFT starting at 0Hz=E2=80=9D doesn=E2=80= =99t improve much Decimation at 1536 and FFT length 65535 produces =E2=80=9CWidth of one FFT= =E2=80=9D at 438uHz and FFT windows time 38 min. So this time good length but small width What I=E2=80=99m doing wrong ? =20 73 de Luis EA5DOM =20 De: owner-rsgb_lf_group@blacksheep.org [mailto:owner-rsgb_lf_group@blackshe= ep.org] En nombre de DK7FC Enviado el: lunes, 10 de septiembre de 2018 18:57 Para: rsgb_lf_group@blacksheep.org Asunto: Re: LF: The return of EbNaut for Dummies =20 Hi Luis,=20 Am 10.09.2018 17:47, schrieb VIGILANT Luis Fern=C3=A1ndez:=20 The fact of getting windows timestamped files which really start at a different time and no aparent indication of when they end =E2=80=A6.. doesn= =C2=B4t help at all Well, the FFT settings must be so that you cover enough width (in Hz) and l= ength (in seconds). The necessary width depends on your symbol length. The = length is mentioned in the FFT settings register card (FFT window time). Ch= oose a rectangular window for EbNaut decodes. Convert the txt files into wav using Markus tools. Load the wav file in th= e EbNaut decoder and press RUN. Then you will see the start time of the fil= e. The end is start time + length. Simple, isn't it? :-) A new txt file is generated in the interval of the scroll time (Spectrum (= 1) ) register card. Usually 30 minutes is fine, or even 1 hour on VLF. Then= you get a file each 30 minutes. If the FFT length is longer than 30 minute= s. Your FFT length should be 30 minutes longer than the transmission length= , just to avoid an incomplete set of data in a txt file.=20 Choose the FFT width and length to suit your settings. The width is maybe = 10 * 1/(symbol length) or more. Is there any way of =E2=80=9Cfast=E2=80=9D EbNaut when signals are strong ? I think there are no limits, you can run 0.1 second symbol length. But usua= lly it is used for weak signals and stable paths. =20 I really don=E2=80=99t know what to test next. Send me your .usr file and the EbNaut settings you want to try. 73, Stefan May be to run ebnaut_tx in test mode, which just changes the phase every sy= mbol length And then, analyze the recorded file with a different tool to determine if t= his phase changes are there ? Can this be easily done ? =20 73 de Luis EA5DOM =20 PS: Congratulations for your amazing test with the guard rails. And yes, th= is is much much harder than EME ! J =20 De: owner-rsgb_lf_group@blacksheep.org [mailto:owner-rsgb_lf_group@blackshe= ep.org] En nombre de DK7FC Enviado el: viernes, 07 de septiembre de 2018 22:10 Para: rsgb_lf_group@blacksheep.org Asunto: Re: LF: EbNaut transmission test in LF =20 Hello Luis,=20 Another hint: Try to use 4K19A and a shorter message, like EA5 or so. Use = long symbols, like 10 seconds or longer. Then, timing is less critical and = you may get a decode and can tune to the best Eb/N0 and find out what the t= iming offset it. It would guess it is a timing problem. 73 Stefan Am 07.09.2018 13:36, schrieb VIGILANT Luis Fern=C3=A1ndez:=20 Hi Domenico =20 Sorry, I=E2=80=99m not transmitting this weekend. Very stormy weather here,= so the wires are down I will notice in the reflector any transmission in advance. But first want = to confirm that all is working ok So that was the goal of yesterday test =20 Yes, the XOR is AFTER the 1/10 divider, and working at the final frequency = 137485 Hz =20 Your auto-decoder is a great tool. EbNaut is quite tricky for average use a= nd needs a lot of details to care about Of course the reward is great when you get decodes with miserable signal le= vels. There is never free lunch ! ;-) =20 73 de Luis EA5DOM =20 De: owner-rsgb_lf_group@blacksheep.org [mailto:owner-rsgb_lf_group@blackshe= ep.org] En nombre de Domenico IZ7SLZ Enviado el: viernes, 07 de septiembre de 2018 13:18 Para: rsgb_lf_group@blacksheep.org Asunto: Re: LF: EbNaut transmission test in LF =20 Hello Luis, =20 thanks for sharing your experiment. My auto-decoder https://www.qsl.net/iz= 7slz/ is already retuned for your transmissions. =20 BTW QRM is large here in the morning time (urban location). I will try to c= atch your signal later in the night. =20 At least the decoder is detecting the carrier but may be there is no proper= phase modulation or probably other failures What I=E2=80=99m doing wrong ? Can anybody decode the message from the file= ? =20 I also suspect some issues on modulator circuit. Of course the XOR gate is= following the /10 divider, is it? =20 Good luck. =20 73 all,=20 Domenico/IZ7SLZ =20 =20 =20 On Fri, 7 Sep 2018 at 11:38, VIGILANT Luis Fern=C3=A1ndez wrote: Hi LF EbNauters =20 I have been building a disciplined Rx for LF, based in a GPS LO at 120KHz a= nd a NE602 downconverter to 17KHz Then feeding the signal to the soundcard, also disciplined with 1pps from t= he same GPS =20 At Tx side a GPS LO at 1374850 Hz divided by 10 provides 0.1Hz steps at LF.= Then an XOR gate is used for EbNaut modulation from the DTR of a COM port under Windows. The PA is just= a mosfet driver (mic4452 AT 12v) Just about 100mW to antenna but good enough to get a 20dB S/N in my Rx 7Km = away =20 Stability looks pretty good and also phase modulation as seen in SL spectro= gram. Also monitoring phase changes with the SL plot display window. So, yesterday I tried an EbNaut transmissi= on with the following setup =20 Coding: 8K19A CRC 16 Symbol period: 1s Characters: 6 Transmission time: 9.3 minutes Transmitting at minute 00 and 30 every hour =20 I got the FFT files from SL and converted them to WAV files. The configurat= ion file (SR) included the corrected sample rate of the soundcard as well as decimation , FFT length and center frequency =20 Attached is a WAV file starting at 16:22 which should contain the transmiss= ion started at 16:30 untill about 16:40 =20 The rawsym graphic shows a clear peak centered in frequency, but I haven=E2= =80=99t been able to get a decode other than =E2=80=9C******=E2=80=9D At least the decoder is detecting the carrier but may be there is no proper= phase modulation or probably other failures What I=E2=80=99m doing wrong ? Can anybody decode the message from the file= ? BTW, I have used a list length of 47274 and also 141823, but nill L =20 73 de Luis EA5DOM ------=_Part_316_1561956319.1536836062508 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes these look like dB's instead of I and Q pairs. = I think you have to go to FFT settings and select "FFT Output Type: co= mplex (real+imaginary)".

73, Markus

-----Urspr=C3=BCngliche M= itteilung-----
Von: DK7FC <selberdenken@posteo.de>
An: rsgb_lf= _group <rsgb_lf_group@blacksheep.org>
Verschickt: Do, 13. Sept 201= 8 12:12
Betreff: Re: LF: The return of EbNaut for Dummies

Luis,

The numbers in the exported FFT data look different here. Not sure if this is the reason. Thus i asked for the usr file of your SL RX instance. I could compare it to mine and may find a difference.
Another way could be just to transmit the message on your antenna, with some power, and i try to decode it from here.

What was your TX power in that test?

73, Stefan

Am 13.09.2018 11:47, schrieb VIGILANT Luis Fern=C3=A1ndez:
=20 =20

Hi Stefan, Markus, EbNaut

 

Sorry. St= ill no results. I keep dumming L

 

Have trie= d different messages in 4K19A, down to one character and 3 sec per symbol

Tx and Rx= run on the same PC, so timing must be the same. Anyway, if there is any delay between Tx and Rx I tested the decoder=

with diff= erent shifts in steps of 0.1 s from -3 to +3 s around the calculated timeshift

 

I=E2=80= =99m seeing the signal getting wider when modulated at 1 s per symbol, but the next step will be to take the Tx side back to

check if = proper phase shift happens. The Tx runs continous carrier from a GPS source and I=E2=80=99m using an XOR gate drive= n by the DTR levels (at 5V TTL)

from a FT= 232RL USB/COM converter and the software is ebnaut_tx for windows

 

Using the= =E2=80=9Ctest=E2=80=9D option in ebnaut_tx I can produce a continous phase change of the signal at different rates. I can see phase changes in SLab

using the= =E2=80=9CWatch List and Plotter window=E2=80=9D, but not absolute phase values. Maybe I have something wrong in the configuration

using exp= resion: pam0.abs_phase

 

Attached = is the FFT file, SR config file and WAV produced. The file starts at 07:55:39.310

I=E2=80= =99m using a 120KHz LO converter from GPS. The transmission frequency is 137.485KHz  so SLab center frequency is 17485Hz

 

Transmiss= ion started at 08:00:00

4K19A

CRC16

Symbol pe= riod: 3s

Message l= ength: 1 Letter: Y

 

Calculate= d start offset is 260.69

List leng= th used: 16714

 

73 de Lui= s

EA5DOM

 

De: owner-rsgb_lf_group@blacksheep.org [mailto:owner-rsgb= _lf_group@blacksheep.org] En nombre de DK7FC
Enviado el: martes, 11 de septiembre de 2018 20:53
Para:  

Good luck Luis,

Later, for a QSO mode, i would suggest rather to use 8K19A than 4K19A. As far as i understand this will have more 'coding gain'.
As soon as it all works, it becomes quite easy.

In Linux one could even run a script doing all the file preparation and decoding automatically, as demonstrated by Domenico. You just need to watch the screen, like in FT8 ;-)

73, Stefan

Am 11.09.2018 18:47, schrieb VIGILANT Luis Fern=C3=A1ndez:

Hi Markus

 

Noted

Very interesting. So I can reduce the interval be= tween generated files just changing the =E2=80=9CWaterfall scroll interval=E2=80=9D at a fixed value a= s 5 minutes for example

I had i= t configured automatic at 75% overlap, so that was changing depending on FFT values and then always getting different interval between files

 <= /span>

Good to= see the =E2=80=9Clight=E2=80=9D J

 <= /span>

Let=E2= =80=99s see if I=E2=80=99m able to get a decode now

 <= /span>

73 de L= uis

EA5DOM<= /span>

 <= /span>

De: owner-rsgb_lf_group@blacksheep.org [mailto:owner-rsgb_lf_group@blacksheep.org] En nombre de Markus Vester
Enviado el: martes, 11 de septiembre de 2018 18:13
Para: rsgb_lf_group@blacksheep.org
Asunto: Re: LF: The return of EbNaut for Dummies

 

Yes Luis that scheme should work.

The 10 minute interval for file generation is not hardwired but simply the scroll interval, as chosen in the "options - Spec= trum display settings" menu. Each column in the spectrogram produces one file. You can set faster scrolling (at the cost of more data=  written to the disk), possibly allowing you to decode and answer sooner in a QSO setting. 

Whether an EbNaut transmission is completely contained in a file also depends on the time when SpecLab was started up, initiating the sequence of files. If the transmission duration is shorter th= an file duration minus scroll interval (e.g. 38-10 =3D 28 minutes), there will be at least one file containing the full transmission. But the EbNaut decoder will also work well with recordings which have= been truncated at either or both ends, albeit with some loss of sensitivity= .

Best 73,
Markus  

  

-----Urspr=C3=BCngliche Mitteilung-----
Von: VIGILANT Luis Fern=C3=A1ndez <luis@vigilant.es>
An: rsgb_lf_group <rsgb_lf_group@blacksheep.org&g= t;
Verschickt: Di, 11. Sept 2018 17:54
Betreff: RE: LF: The return of EbNaut for Dummies

Hi Stefan, Markus, EbNaut

 

Thank you for the detailed explanations. Now I really understand the configuration and how is related to bandwith and length of the

recorded files. There is also a fixed time between files recorded and it is always 10 minutes. But, files are overlapped, so there you can

record a file to contain longer than 10 minute transmission

 

So, let=E2=80=99s see which would be a good configuration to perform a real QSO. Lets say in LF with some S/N and not al VLF levels

At the same time can be a good exercise to check if I finally understood all this stuff ;-)

 

Tx at 4K19A/CRC16/1 sec symbol rate would take 9 min and 4 sec to transmit 17 characters messages

Assume 15 minutes periods. Lets say first (even)  transmitting at the hour and 30 min pass the hour

Second (odd) transmits at minute 15 and 45

 

Rx at 44100 sample rate, using a 65536 FFT length, and 1536 decimation, file will contain 38 minutes of recorded signal. Looks more than enough

as we are using about 9 minutes transmissions. Then bandwidth of the recorded files will be =E2=80=9CSample rate / decimation= =E2=80=9D

44100 / 1536 =3D 28.71 and then divided by two as SLab generates the file, ending with 14.35Hz. Which is enough bandwith for a 1 sec symbol rate  (10/1=3D10Hz)

 

So, assume both stations had Rx running previously and SL already producing files every 10 minutes. Files will contain 38 minutes of recorded signal

 

A file recorded by windows just after transmission end (lets say)  22:10 would contain a record of 38minutes, so starting tim= e will be really 21:32

This file will contain the message transmited by the station calling in first period (CQ). To decode it we will select a timeshift from 21:32 to 22:00 =3D 28 minutes

So there will be time enough to decode the message and then prepare the transmitter to answer in second period, 15 minutes pass the hour, 22:15

answering the CQ of the station calling first

 

The station calling in first period should have to check for files recorded at about 22:25 to try to decode an answer

And then prepare the corresponding transmission for next even period at  22:30

 

Should this timing schem work for QSOs ? Assuming there is enough S/N to work at this Tx rate of course

 

73 de Luis

EA5DOM

 

De= : owner-rsgb_lf_gr= oup@blacksheep.org [mailto:owner-rsgb_lf_group@blacksheep.<= span style=3D'color: windowtext; font-family: "Calibri",sans-serif; font-si= ze: 11pt;'>org] En nombre de DK7FC
Enviado el: martes, 11 de septiembre de 2018 15:13
Para: rsgb_lf_group@blacksheep.org
Asunto: Re: LF: The return of EbNaut for Dummies

 

Hi Luis,
As Markus mentioned...
And see the attachment. In the example i set the sample rate to 44100 Hz. If you have a downconverter with an LO of 120 kHz, and expect a message on 137 kHz exactly, set the internal frequency shift to a center frequency of 17 kHz, like shown in the image.

Also remember that the number of exported FFT bins in the FFT export register card should be set to the half of the FFT input size shown in the FFT register card.

Keep us informed about the success :-)

I'm waiting for your first message to receive here. I'm monitoring permanently, however only in the range 137.5 kHz +- 50 Hz and only about 30 minutes message length. Other parameters would work too, but i need to prepare a special SL instance then...

73, Stefan



Am 11.09.2018 13:40, schrieb VIGILANT Luis Fern=C3=A1ndez:

Hi Stefan

 

Thank you for the detailed explanation. I prefer to understand the process rather than getting a working .usr

So, excuse me again for dumming again  J

 

All understood about the length and relation to FFT windows time (length) in SL. Width was un unknown parameter for me

And I=E2=80=99m afraid the problem is about the width:

 

>> Choose the FFT width and leng= th to suit your settings. The width is maybe 10 * 1/(symbol length) or more

Lets say 1Hz minimum for a 10 sec symbol leght, right ?

 

So, in the FFT configuration window the only way to get >1Hz(1.3Hz) for =E2=80=9CWidth of one FFT-bin=E2=80=9D is to reduce deci= mation to 1

and then set FFT length to 32768 to get some =E2=80=9CFFT window time (length)=E2=80=9D. But then, the indows time is just 743ms

which will not cover the length of the message at all

 

I=E2=80=99m stucked here. Can=E2=80=99t get >width with 30 minutes FF= T lenghts. I=E2=80=99m using 44.100Hz sample rate L

 

The FFT input type is =E2=80=9CComplex ith internal frequency shift=E2=80=9D. But even using =E2=80=9CReal FFT starting at 0Hz=E2=80=9D d= oesn=E2=80=99t improve much

Decimation at 1536 and FFT length 65535 produces =E2=80=9CWidth of one FFT=E2=80=9D at 438uHz and FFT windows time 38 min. So this time

good length but small width

What I=E2=80=99m doing wrong ?

 

73 de Luis

EA5DOM

 

De:<= span style=3D'color: windowtext; font-family: "Calibri",sans-serif; font-si= ze: 11pt;'> owner-rsgb_l= f_group@blacksheep.org [mailto:owner-rsgb_lf_group@blacksheep.org= ] En nombre de DK7FC
Enviado el: lunes, 10 de septiembre de 2018 18:57
Para: rsgb_lf_group@blacksheep.org
Asunto: Re: LF: The return of EbNaut for Dummies

 

Hi Luis, =

Am 10.09.2018 17:47, schrieb VIGILANT Luis Fern=C3=A1ndez:

The fact of getting windows timestamped files which really start at a

different time and no aparent indication of when they end =E2=80=A6.. doesn=C2=B4t help at all

Well, the FFT settings must be so that you cover enou= gh width (in Hz) and length (in seconds). The necessary width depends on your symbol length. The length is mentioned in the FFT settings register card (FFT window time). Choose a rectangular window for EbNaut decodes.
Convert the txt files into wav using Markus tools. Load the wav file in the EbNaut decoder and press RUN. Then you will see the start time of the file. The end is start time + length. Simple, isn't it? :-)

A new txt file is generated in the interval of the scroll time (Spectrum (1) ) register card. Usually 30 minutes is fine, or even 1 hour on VLF. Then you get a file each 30 minutes. If the FFT length is longer than 30 minutes. Your FFT length should be 30 minutes longer than the transmission length, just to avoid an incomplete set of data in a txt file.

Choose the FFT width and length to suit your settings. The width is maybe 10 * 1/(symbol length) or more.



Is there any way of =E2=80=9Cfast=E2=80=9D EbNaut when signals are s= trong ?

I think there are no limits, you can run 0.1 second symbol length. But usually it is used for weak signals and stable paths.

 

I really don=E2=80=99t know what to test next.

Send me your .usr file and the EbNaut settings you wa= nt to try.

73, Stefan



May be to run ebnaut_tx in test mode, which just changes the phase every symbol length

And then, analyze the recorded file with a different tool to determine if this phase changes are there ? Can this be easily done ?

 

73 de Luis

EA5DOM

 

PS: Congratulations for your amazing test with the guard rails. And yes, this is much much harder than EME ! J

 

De: owner-rsgb_l= f_group@blacksheep.org [mailto:owner-rsgb_lf_group@blacksheep.org= ] En nombre de DK7FC
Enviado el: viernes, 07 de septiembre de 2018 22:10
Para: rsgb_lf_group@blacksheep.org=
Asunto: Re: LF: EbNaut transmission test in LF

 

Hello L= uis,

Another hint: Try to use 4K19A and a shorter message, like EA5 or so. Use long symbols, like 10 seconds or longer. Then, timing is less critical and you may get a decode and can tune to the best Eb/N0 and find out what the timing offset it. It would guess it is a timing problem.

73 Stefan

Am 07.09.2018 13:36, schrieb VIGILANT Luis Fern=C3=A1ndez:

Hi Domenico

 

Sorry, I=E2=80=99m not transmitting this weekend. Very stormy weather here, so the wires are down

I will notice in the reflector any transmission in advance. But first want to confirm that all is working ok

So that was the goal of yesterday test

 

Yes, the XOR is AFTER the 1/10 divider, and working at the final frequency 137485 Hz

 

Your auto-decoder is a great tool. EbNaut is quite tricky for average use and needs a lot of details to care about

Of course the reward is great when you get decodes with miserable signal levels. There is never free lunch ! ;-)

 

73 de Luis

EA5DOM

 

De: owner-rsgb= _lf_group@blacksheep.org [mailto:owner-rsgb_l= f_group@blacksheep.org] En nombre de Domenico IZ7SLZ
Enviado el: viernes, 07 de septiembre de 2018 13:18
Para: rsgb_lf_group@blacksheep.o= rg<= br> Asunto: Re: LF: EbNaut transmission test in LF

 

Hello= Luis,

 = ;

thank= s for sharing your experiment. My auto-decoder  https://www.qsl.net/iz7slz/  is already retuned for your transmissions.

 = ;

BTW Q= RM is large here in the morning time (urban location). I will try to catch your signal later in the night.

 = ;

At= least the decoder is detecting the carrier but may be there is no proper phase modulation or probably other failures

Wh= at I=E2=80=99m doing wrong ? Can anybody decode the message from the file ?

 = ;

 = ;I also suspect some issues on modulator circuit. Of course the XOR gate is following the /10 divider, is it?

 = ;

Good = luck.

 = ;

73 al= l,

Domen= ico/IZ7SLZ

 = ;

 = ;

 = ;

On Fr= i, 7 Sep 2018 at 11:38, VIGILANT Luis Fern=C3=A1ndez <luis@vigilant= .es> wrote:

Hi = LF EbNauters

&nb= sp;

I h= ave been building a disciplined Rx for LF, based in a GPS LO at 120KHz and a NE602 downconverter to 17KHz

The= n feeding the signal to the soundcard, also disciplined with 1pps from the same GPS

&nb= sp;

At = Tx side a GPS LO at 1374850 Hz divided by 10 provides 0.1Hz steps at LF. Then an XOR gate is used for

EbN= aut modulation from the DTR of  a COM port under Windows. The PA is just a mosfet driver (mic4452 AT 12v)

Jus= t about 100mW to antenna but good enough to get a 20dB S/N in my Rx 7Km away=

&nb= sp;

Sta= bility looks pretty good and also phase modulation as seen in SL spectrogram. Also monitoring phase changes

wit= h the SL plot display window. So, yesterday I tried an EbNaut transmission with the following setup

&nb= sp;

Cod= ing: 8K19A

CRC= 16

Sym= bol period: 1s

Cha= racters: 6          Transmission time: = 9.3 minutes

Tra= nsmitting at minute 00 and 30 every hour

&nb= sp;

I g= ot the FFT files from SL and converted them to WAV files. The configuration file (SR) included the corrected sample rate

of = the soundcard as well as decimation , FFT length and center frequency

&nb= sp;

Att= ached is a WAV file starting at 16:22 which should contain the transmission started at 16:30 untill about 16:40

&nb= sp;

The= rawsym graphic shows a clear peak centered in frequency, but I haven=E2=80=99t bee= n able to get a decode other than =E2=80=9C******=E2=80=9D

At = least the decoder is detecting the carrier but may be there is no proper phase modulation or probably other failures

Wha= t I=E2=80=99m doing wrong ? Can anybody decode the message from the file ?

BTW= , I have used a list length of 47274 and also 141823, but nill L=

&nb= sp;

73 = de Luis

EA5= DOM

------=_Part_316_1561956319.1536836062508--