Received-SPF: neutral (google.com: 195.171.43.25 is neither permitted nor denied by best guess record for domain of owner-rsgb_lf_group@blacksheep.org) client-ip=195.171.43.25;
Message-ID: <534AC753.7010800@gmx.net>
Date: Sun, 13 Apr 2014 19:20:19 +0200
From: Tobias DG3LV <DG3LV@gmx.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <53430770.60406@gmail.com> <534319AD.3080900@gmx.net> <5343EEE6.4010708@gmail.com>
In-Reply-To: <5343EEE6.4010708@gmail.com>
Subject: Re:  Re: LF: A question to the experts
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

Hi Stefan, MF !

Thank you for description of the intended remote MF/LF-Rx.

It's all about trade-offs. You can trade bandwidth vs. money/energy, 
trade bandwidth vs. dynamic range, trade money vs. development effort, 
etc. The aim is to get most out of your invested money/effort. The 
necessary decisions are up to the individual opinions.

In this I am exclusively focusing on the link-connection, whereas the 
MF/LF-receiver itself can be of almost any technology. Preferably a 
"zero-IF" receiver is to be used. Just its analog IF is of interest to 
the linking system.

An outline of the remote system is : MF-receiver(-IF) -> 
A/D-converter->microcontroller-> (serial data) -> 
link-connection-device(WLAN/Bluetooth?).

The institut-part is outlined as : 
link-connection-device(WLAN/Bluetooth?) ->  (serial data) -> 
software-converter (Serial-to-SpectrumLab or Serial-to-HDSDR-DLL).

"Serial Data" is the most basic transport protocol for binary data, 
there is a lot of industry-standard equipment and development kits 
available. It does not need any "protocol stack" to work. This will keep 
software/hardware development efforts low.

This is not meant as "the solution", but the guide to a solution or 
starting point of further discussions.

  - - - - - -
The Design-Questions :
1.What datarates are to be transmitted by the link-connection?
2.What technology is available to transmit this datarates?
3.What is the amount of energy needed?
4.What devices/software have still to be developed to get it running?
5.Do we have the experts at hand that could realise the development 
tasks of such an experimental system?

  - - - - - -
Let's try and find some answers :
Q: 1.What datarates are to be transmitted by the link-connection?
A: As you have written, the physical limits are given by clear formulas. 
Mr. Nyquist told us to use at least double the sampling rate of the 
highest frequency to be digitised.
So the formula for the minimum transmitted (netto-)Bitrate of the 
link-connection is :
<minimum bitrate> = <sampling-rate> * <number of sampling-bits>
with <sampling-rate> = 2 * <highest frequency to be digitised>
[units in hertz or 1/sec]
Example :
To transmit a 10 kHz wide IF-bandwidth at 24 Bits we need a minimum 
netto-bitrate of 10000 * 2 * 24 = 480000 bits per second.

This is quite a lot compared to the usual bitrates we use at amateur radio.
A direct-sampling of 0 to 500kHz at 24 bits would result in an enormous 
bitrate of 500000 * 2 * 24 = 24.000.000 = 24 Mega-bit/sec. Possible to 
do, but at high expense of money and energy.

(btw, obeying Nyqusit can be done by either doubling the sample rate or 
the use of 2 separate A/D converters at I/Q-demodulators, the resulting 
datarate is equal.)

-> The anticipated bitrate depends on the restrictions of energy and 
money, that are described in the following. The bitrate has to be 
minimized to the lowest level of acceptable quality.
  - - - - - -
Q: 2.What technology is available to transmit these datarates?
A: The "usual suspects" are wireless LAN and Bluetooth, that can 
transmit at such bitrates and can be buyed as building-block modules. 
There are of course more Standards around, but they may need more effort 
to integrate in a link-connection.
Bitrates :
WLAN 6MBit up to hundreds of MBit.
Bluetooth up to 921 kiloBit (Profile "SPP" = serial data! NOT AUDIO!)
Distance :
WLAN on 2.4 GHz is restricted to 100 mW ERP(!), but directional antennas 
will help.
WLAN on 5.8 GHz is restricted to 1 W ERP(!) for outdoors, directional 
antennas are mandatory.
Bluetooth Class 1 is restricted to 100 mW ERP(!), advertised as "up to 
1500m" distance at 921 kBit/sec.

-> Both standards are suitable for our experiment. It depends on 
distance, energy and money to select the system.
  - - - - - -
Q: 3.What is the amount of energy needed?
A: WLAN : a typical industry-standad WLAN-to-serial bridge is listed 
with a "typical" 1300 milliWatt at 921kBit transport (at 3.3Volt)
A typical industry-standard Bluetooth-to-serial bridge (Class 1) is 
listed with 500mW at 3.3 Volt.

The energy of the "converter-device" described at Q 4 and the energy for 
the MF-LF receiver block have to be added to the overall-system energy bill.

Available energy and system-costs are the main restrictions on the 
system to be specified !

->Bluetooth seems to have an advantage vs. WLAN. (to be verified!)
Solar power can be used to help recharging the accumulator or prolong 
uptime (just seen 5 Watt panel, size DIN A4, 19.- Euros,Reichelt)
  - - - - - -
Q:4.What devices/software have to be developed to get it running?
A: The System-development should use as much readily available 
components as possible. The central devices for the link-connection are 
the WLAN or Bluetooth-to-serial bridges, these can be buyed at costs 
from 15 to 60 Euros each. (No need to develop this from scratch, e.g. 
available from Lantronix.com and Stollman.de)

Software/Hardware development has to be done to build the "converter" 
from analog-IF-input to serial-data-output.
At Wolf DL4YHF's homepage I found a "Serial PIC ADC" that can be used as 
a guideline to develop an upgraded system for the bandwidth and bitrates 
that are anticipated. This will be the central development task. 
Suitable A/D converters and high-speed PIC's are available to be integrated.

On the "institut"-end of the link-connection there has to be a 
counterpart for the remote link-station. A corresponding WLAN or 
Bluetooth device has to be used, that delivers his received serial data 
to a (to be developed) software-converter from serial-data to "<anything 
SpecLab does understand>". This can be developed along Wolf's "Serial 
Input Utility", which shows the principle, but has to be upgraded to 
higher bitrates.
For the SDR alternative program HDSDR an "Ext-IO-DLL" would be 
necessary. (Templates available)
A software-protocol has to be developed to put the 24-bit A/D-data into 
several 8-bit Bytes for the serial data lines. This protocol will add 
some overhead to the netto datarate, so the brutto bitrate will be 
somewhat higher than just the numbers we calculated at Q 1.

-> for this tasks we need some of the experts.

Q: 5.Do we have the experts at hand that could realise the development 
tasks of such an experimental system?
A: By use of the design-data we already have collected, we have a 
description of what the wanted system could look like. There is a good 
chance that we can find experts at our fellow enthusiasts, who are 
interested in developing and building such a remote 
MF-LF-receiver-system. A "concerted action" of different skills would 
help us all.

Summary : Such a system will surely need some more precisation during 
development, but I think the system outlined here could be realized at 
minimum effort and costs. A price-tag of 50 ¤uros seems unrealistic, I 
think it will be in the range of 200 Euros for hardware. (additional 
costs for cases, accus, antennas, powersupply at wish).

73 de dg3lv Tobias


Am 08.04.2014 14:43, schrieb DK7FC:
> Hi Tobias,
>
> Am 07.04.2014 23:33, schrieb Tobias DG3LV:
>> [...]it would be best to first express your design-target in more detail:
>>
>> What minimum audio/IF-bandwith is acceptable for the MF/LF-receiver?
> Well, for MF and LF, 10 kHz would be sufficient. For VLF, 24 or even 48
> kHz would be fine. If it is possible (data rate (meanwhile i think i
> learned to calculate the data rate ;-) )) to use a 1 MHz sample rate
> ADC, then one could directly sample VLF to MF !! That may be the best
> option, because then there is no need to use an extra converter. This
> reduces the complexity of the circuit and the power consumption, i
> assume. So the limiting factor would be the bandwidth of the 2.4 Ghz
> device. I found some with 2 Mbps, also ready to use modules (don't want
> to spend to much time with that GHz stuff). With a ADC covering VLF to
> MF, one just may need a few notch filters for stronger local out of band
> stations.
> OK, the answer to your question: 500 kHz.
>
>> What minimum dynamic range (in dB) is acceptable?
> This has directly to do with the bits of the ADC, i learned. Well, for a
> directy sampling of the 2200m band we have to deal with DCF39 and HGA22
> here. And if the 'far end device' has to be compact and has to deal with
> high temperature differences, we can't use complex high Q coils to get
> an extreme rejection of DCF39... Thus, i think we need at least 100 dB
> of dynamic range. So, from what i saw from the data sheets, we would
> need a 24 bit device. I also learned that it is not possible just to
> connect the 2 SPI ports of the two devices. So it becomes more complex.
>
>> What is the distance to be covered by the link-connection ?
> 2km or 3 km. It all depends of what is possible! I will need high gain
> yagis on both sides. But these are quite cheap avaliable at amazon or ebay.
>
>> Optical sight ?
> Yes.
>
>> Is it possible to erect a (small, DIN A4) solar power module at the
>> MF/LF-receiver site?
> Maybe, if necessary, yes. But it will be more expensive and more risky
> of someone discovers and damages the setup when hanging in a tree in the
> forest. Thus i would like to keep the costs below 50 EUR, the costs of
> the far end system. It is not my private property so it must be hidden
> in a high tree that i can climb.
>
>> Shall the MF/LF-receiver be operated 24/7 ?
> Yes. Ideally VLF to MF. But there can be compromises. Actually MF was
> the main focus. So, 8 kHz of BW and 80 dB dynamic range and 16 bit would
> be ok too. You see, the specifications are not totally fixed. It depends
> on what is possible. The limiting factor will be the data rate and the
> costs and the power consumption of the far end device.
>
>> What program will be used at your site in the institut, spectrum lab
>> or different?
> SpecLab!
> But i don't know, when i would use that 1 MHz sample rate ADC, it may be
> more useful to realise a direct digital link, USB or LAN. This may have
> advantages but then the system becomes not so flexible for others.
>
>>
>> Knowing this (and probably more) could help to design a suitable
>> link-connection between the remote MF/LF-receiver and your windows-PC.
>> The technology to be used cannot be specified without knowing this.
> Yes that is clear of course.
> But as you see there is a wide range of wishes and possibilities and
> limiting factors. Generally it would be nice to play arround with this
> stuff and get a sloution as useful as possible. So what is possible? And
> are there other factors that i don't see yet? Maybe the stability of the
> GHz link over that distance?
> At least i like the idea to learn about this stuff but i am on the first
> small steps. It looks like a completely different world of electronics
> to me! And it looks like all the informations are available in the web.
> The twente web SDR shows what is possible! But i don't need a solution
> reaching up to 30 MHz. 0...500 kHz is fine!
>>
>> 73 de dg3lv Tobias
>> (you have received this text in german language a week ago)
> Did i?
>
> Is that right, 500 kHz BW and 24 bit = 12 Mbps ?
>
> It may appear embrassing to demonstrate my limits of knowledge about
> that digital stuff but i decided to stay self-reliant here. These limits
> can be pushed in one evening i know. It just wasn't necessary so far...
>
>
> 73, Stefan/DK7FC
>
>