LF: Re: [rsgb_lf_group] Coherent receivers and EbNaut

[Andy Talbot <andy.g4jnt@gmail.com>]

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üscher dl4yhf@freenet.de [rsgb_lf_group] <rsgb_lf_group@yahoogroups.co.uk> 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" =
sampling rate and "rf" = radio frequency, and -I think- "ut"= unix
timestamp.

>>>
* sr=* precise sampling rate (samples per second), "measured" or
"calibrated".
*rf=* radio frequency (useful if the recording contains downconverted,
decimated I/Q samples).
*ut=* Unix timestamp (seconds elapsed since 1970-01-01 00:00:00 UTC)
*glat=* geographic latitude in degrees, positive north, negative south.
*glon=* geographic longitude in degrees, positive east, negative west.
*masl=* GPS height in meters above sea level. Only valid (and non-zero)
if a GPS receiver is connected and operating .
*kmh=* 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: =?UTF-8?Q?Wolfgang_B=c3=bcscher?= <dl4yhf@freenet.de>

---

Reply via web post

•

Reply to sender

•

Reply to group

•

Start a new topic

•

Messages in this topic (2)

Visit Your Group

• New Members 2

• Privacy • Unsubscribe • Terms of Use

.

__,_._,___