Return-Path: X-Spam-DCC: paranoid 1290; Body=3 Fuz1=2 Fuz2=2 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on lipkowski.org X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,DNS_FROM_AHBL_RHSBL, HTML_50_60,HTML_MESSAGE,HTML_TINY_FONT autolearn=no version=3.1.3 Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by paranoid.lipkowski.org (8.13.7/8.13.7) with ESMTP id tA8GbBOQ010055 for ; Sun, 8 Nov 2015 17:37:11 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1ZvSui-0006KG-8b for rs_out_1@blacksheep.org; Sun, 08 Nov 2015 16:33:56 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1ZvSuh-0006K6-FQ for rsgb_lf_group@blacksheep.org; Sun, 08 Nov 2015 16:33:55 +0000 Received: from mail-wi0-f181.google.com ([209.85.212.181]) by relay1.thorcom.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1ZvStd-0006nw-Dc for rsgb_lf_group@blacksheep.org; Sun, 08 Nov 2015 16:33:54 +0000 Received: by wikq8 with SMTP id q8so55320744wik.1 for ; Sun, 08 Nov 2015 08:32:35 -0800 (PST) X-DKIM-Result: Domain=gmail.com Result=Good and Known Domain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J9jv4J/dyMUV/QSgeQfDa690YGiWAeF7ptmSaTjOGJY=; b=JgdBX26LhUp+pNsonMrfb5J1nve8ig1nh4B2NWuEA7AUNi6pCVJdeAIxKvxFaFR0Jn leAa0kltX1G9/EEAnPobLQ3ERCVlo3D8WxhygJ/3bj+SZqL7WzP/rn4baiqEbdE6mhEF DzJ6ZbkwrGGIs11EVShtk/Y7FH5VLY6NwW9vVFU3aQkr80FJ1EPOpKhwlJQ//NVbn1sI 7qrtSo8D4PIsC1sQanw5QDzWUMhecjNpIHZmRJLgd8wK/5GOxHYGGgvICJhCQ5kV/c9z hnUlogT+Jk4uXI3BPtm3vAxfE+SNuFUO6Qz7lyvT1Lyx2UcW09R/S8PxTeDkKf/7eU3V Pp9w== MIME-Version: 1.0 X-Received: by 10.194.62.15 with SMTP id u15mr28173695wjr.18.1447000355138; Sun, 08 Nov 2015 08:32:35 -0800 (PST) Received: by 10.28.183.139 with HTTP; Sun, 8 Nov 2015 08:32:35 -0800 (PST) In-Reply-To: <563F7410.20902@freenet.de> References: <563F7410.20902@freenet.de> Date: Sun, 8 Nov 2015 16:32:35 +0000 Message-ID: From: Andy Talbot To: rsgb_lf_group@yahoogroups.co.uk Cc: rsgb_lf_group@blacksheep.org X-Scan-Signature: db2a43c89ae369177baff32e64ab576a Subject: LF: Re: [rsgb_lf_group] Coherent receivers and EbNaut Content-Type: multipart/alternative; boundary=047d7ba9750a28743405240a06f5 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 X-Scanned-By: MIMEDefang 2.56 on 10.1.3.10 Status: O X-Status: X-Keywords: X-UID: 4908 --047d7ba9750a28743405240a06f5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Perfect, thanks. Will work on the file saving bit next. I was initially worried when I saw "Unix time stamp" in the specification, but according to a quick bit of Googling, the VB6 programming language has a built in conversion for this. 'jnt On 8 November 2015 at 16:10, Wolfgang B=C3=BCscher dl4yhf@freenet.de [rsgb_lf_group] wrote: > > > Hello Andy, > > The wave files written by Spectrum Lab are indeed decimate I/Q pairs > (camouflaged as a stereo wave file). Since the sampling rate (etc) in > the header don't allow the required precision (number of decimals), the > file contains an extra 'chunk header' (or whatever they call it in the > file specification). > > http://www.qsl.net/dl4yhf/speclab/wavfiles.htm#extra_wave_header_chunks > > Actually, that extra 'chunk' (header) with the pattern "inf1" is just an > ASCII string which is easily parseable and writeable. Almost all parts > of the string are optional, except (for this application) "sr" =3D > sampling rate and "rf" =3D radio frequency, and -I think- "ut"=3D unix > timestamp. > > >>> > * sr=3D* precise sampling rate (samples per second), "measured" or > "calibrated". > *rf=3D* radio frequency (useful if the recording contains downconverted, > decimated I/Q samples). > *ut=3D* Unix timestamp (seconds elapsed since 1970-01-01 00:00:00 UTC) > *glat=3D* geographic latitude in degrees, positive north, negative south. > *glon=3D* geographic longitude in degrees, positive east, negative west. > *masl=3D* GPS height in meters above sea level. Only valid (and non-zero) > if a GPS receiver is connected and operating . > *kmh=3D* GPS speed in kilometers per hour . > <<< > > Maybe Paul can confirm which of those tokens are really required. The > GPS data certainly not :-) > > Cheers, > Wolf . > > Am 08.11.2015 um 16:57 schrieb Andy Talbot andy.g4jnt@gmail.com > [rsgb_lf_group]: > > > > > > Although my query is specifically with the authors of EbNaut and > > Speclab. posting via the two LF groups so everyone can join in: > > > > I now have a completely locked narrowband digital receiver that > > delivers 12 bit I/Q samples at 1kHz sampling rate on an RS422 > > interface to a PC. The data packets also carry a timestamp carrying > > date / time accurate to 1ms (the sample rate). > > > > PS software is written so far to take this, filter and decimate the > > samples to get to a resulting output sampling rate that can be as low > > as 0.24Hz with a corresponding signal bandwidth of 0.05Hz. > > > > So far all I do is plot them, but now is the time to decide how to > > write them to a .WAV file for reading by EbNaut Rx software. So the > > following questions arise : > > > > How are slow sampling rates stored in a .WAV file? Clearly I/Q > > samples are stored as stereo pairs, but what information is placed in > > the .WAV file header? For example, the sampling rate can't be in > > there as a .WAV header holds that as an integer. Similar arguments > > apply to other values held in the header. > > > > I believe the timestamp of the start of the recording reflects in the > > file name. > > > > And - if I publish the serial protocol, would it be feasible for > > Ebnaut to be modified to accept the data directly? > > > > As for the digital receiver : > > > > It consists of a Finningley Dongle (almost the same as a Softrock) > > operating from 20khz to 500kHz. The LO comes from an AD9852 DDS > > chosen as it has 48 bit registers so allowing more accurate frequency > > setting than the 32 bits of AD9850 type. That is tuned via a rotary > > encoder / LCD in 0.01Hz steps, the DDS clock is 10MHz direct from a > > master reference. The receiver delivers I/Q IF at 1kHz to a > > downcoverting quadrature digitiser via a simple CR phasing network > > > > The digitiser is a 16F819 pic sampling the 1kHz input at 4kHz, then > > generating S! + S2 - S3 - S4 and S1 - S2 - S3 + S4, forming into > > packets and sending via a RS422 driver. At start up the PIC reads > > NMEA data from a GPS, and sets internal clock registers. These are > > then updated by th ePIC firmware itself, and synchronised to the 1 PPS > > signal so the timestamps are applied to the output stream exactly. > > A 1kHz opamp bandpass filter on the input does the anti-aliasing > > necessary. Bandwidth is about 60Hz. > > > > All will be written up in due course.... > > > > The plot below, if it passes though one or both reflector / group, is > > a two hour plot of the MSF60kHz signal. you can see the decimation > > and averaging values on the screen. The upwards phase shift over the > > latter third is either, my VE2ZAZ GPSDO doing a correction. or a > > genuine propagation artefact of the 60kHz signal as dusk falls . I > > suspect the former as, technically, the sun is still up at 1555z as I > > write this! > > > > If it fails to get through, the image can be found at > > http://www.g4jnt.com/DownLoad/MSF_2hours.jpg > > > > Andy G4JNT > > > > Inline images 1 > > > > > > > > > > > > __._,_.___ > ------------------------------ > Posted by: =3D?UTF-8?Q?Wolfgang_B=3Dc3=3Dbcscher?=3D > ------------------------------ > Reply via web post > > =E2=80=A2 Reply to sender > > =E2=80=A2 Reply to group > > =E2=80=A2 Start a new topic > > =E2=80=A2 Messages in this topic > > (2) > Visit Your Group > > > - New Members > > 2 > > [image: Yahoo! Groups] > > =E2=80=A2 Privacy =E2=80=A2 > Unsubscribe > =E2= =80=A2 Terms > of Use > > . > > __,_._,___ > --047d7ba9750a28743405240a06f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Perfect, thanks.
Will work on the file savi= ng bit next.

I was initially worried when I saw &q= uot;Unix time stamp" in the specification, but according to a quick bi= t of Googling, the VB6 programming language has a built in conversion for t= his.

'jnt


<= /div>

On 8 Novembe= r 2015 at 16:10, Wolfgang B=C3=BCscher dl4yhf@freenet.de [rsgb_lf_group] <rsgb_lf_group@yahoog= roups.co.uk> wrote:
=20
=C2=A0
=20 =20

Hello Andy,

The wave files written by Spectrum Lab are indeed decimate I/Q pairs
(camouflaged as a stereo wave file). Since the sampling rate (etc) in
the header don't allow the required precision (number of decimals), the=
file contains an extra 'chunk header' (or whatever they call it in = the
file specification).

http://www.qsl.net/dl4yhf/speclab/wavfiles.htm#e= xtra_wave_header_chunks

Actually, that extra 'chunk' (header) with the pattern "inf1&q= uot; is just an
ASCII string which is easily parseable and writeable. Almost all parts
of the string are optional, except (for this application) "sr" = =3D
sampling rate and "rf" =3D radio frequency, and -I think- "u= t"=3D unix
timestamp.

>>>
* sr=3D* precise sampling rate (samples per second), "measured" = or
"calibrated".
*rf=3D* radio frequency (useful if the recording contains downconverted, decimated I/Q samples).
*ut=3D* Unix timestamp (seconds elapsed since 1970-01-01 00:00:00 UTC)
*glat=3D* geographic latitude in degrees, positive north, negative south. *glon=3D* geographic longitude in degrees, positive east, negative west. *masl=3D* GPS height in meters above sea level. Only valid (and non-zero) <= br> if a GPS receiver is connected and operating .
*kmh=3D* GPS speed in kilometers per hour .
<<<

Maybe Paul can confirm which of those tokens are really required. The
GPS data certainly not :-)

Cheers,
Wolf .

Am 08.11.2015 um 16:57 schrieb Andy Talbot andy.g4jnt@gmail.com
[rsgb_lf_group]:
>
>
> Although my query is specifically with the authors of EbNaut and
> Speclab. posting via the two LF groups so everyone can join in:
>
> I now have a completely locked narrowband digital receiver that
> delivers 12 bit I/Q samples at 1kHz sampling rate on an RS422
> interface to a PC. The data packets also carry a timestamp carrying <= br> > date / time accurate to 1ms (the sample rate).
>
> PS software is written so far to take this, filter and decimate the > samples to get to a resulting output sampling rate that can be as low =
> as 0.24Hz with a corresponding signal bandwidth of 0.05Hz.
>
> So far all I do is plot them, but now is the time to decide how to > write them to a .WAV file for reading by EbNaut Rx software. So the <= br> > following questions arise :
>
> How are slow sampling rates stored in a .WAV file? Clearly I/Q
> samples are stored as stereo pairs, but what information is placed in=
> the .WAV file header? For example, the sampling rate can't be= in
> there as a .WAV header holds that as an integer. Similar arguments <= br> > apply to other values held in the header.
>
> I believe the timestamp of the start of the recording reflects in the =
> file name.
>
> And - if I publish the serial protocol, would it be feasible for
> Ebnaut to be modified to accept the data directly?
>
> As for the digital receiver :
>
> It consists of a Finningley Dongle (almost the same as a Softrock) > operating from 20khz to 500kHz. The LO comes from an AD9852 DDS
> chosen as it has 48 bit registers so allowing more accurate frequency =
> setting than the 32 bits of AD9850 type. That is tuned via a rotary <= br> > encoder / LCD in 0.01Hz steps, the DDS clock is 10MHz direct from a <= br> > master reference. The receiver delivers I/Q IF at 1kHz to a
> downcoverting quadrature digitiser via a simple CR phasing network
>
> The digitiser is a 16F819 pic sampling the 1kHz input at 4kHz, then > generating S! + S2 - S3 - S4 and S1 - S2 - S3 + S4, forming into
> packets and sending via a RS422 driver. At start up the PIC reads > NMEA data from a GPS, and sets internal clock registers. These are > then updated by th ePIC firmware itself, and synchronised to the 1 PPS=
> signal so the timestamps are applied to the output stream exactly.
> A 1kHz opamp bandpass filter on the input does the anti-aliasing
> necessary. Bandwidth is about 60Hz.
>
> All will be written up in due course....
>
> The plot below, if it passes though one or both reflector / group, is =
> a two hour plot of the MSF60kHz signal. you can see the decimation <= br> > and averaging values on the screen. The upwards phase shift over the=
> latter third is either, my VE2ZAZ GPSDO doing a correction. or a
> genuine propagation artefact of the 60kHz signal as dusk falls . I > suspect the former as, technically, the sun is still up at 1555z as I =
> write this!
>
> If it fails to get through, the image can be found at
> http://www.g4jnt.com/DownLoad/MSF_2hours.jpg
>
> Andy G4JNT
>
> Inline images 1
>
>
>
>
>

=20 =20
__._,_.___
=20 =20 =20 =20
Posted by: =3D?UTF-8?Q?Wolfgang_B=3Dc3=3Dbcscher?=3D <dl4yhf@freenet.de> =
Repl= y via web post =E2=80=A2 Reply to sender =E2=80=A2 Reply to group =E2=80=A2 Start a new topic =E2=80=A2 Messages in this topic (2)
=20 =20
3D"Yahoo!
=E2=80=A2 Privacy =E2=80=A2 Unsubscribe =E2=80=A2 Terms of Use

=20 =20 =20 =20
=20
.
=
= =20
__,_._,___
=20

--047d7ba9750a28743405240a06f5--