Hi All,

Alberto wrote on the Winrad mailing list:
> The network model is very general, and could allow 
> even to have Winrad and MAP65 on different PCs, 
> maybe one with Linux and the other with Windows. 
> But this could be a long range target. 

Thanks to the assistance from ON4IY Linrad now
has a network that can send data in seven different
formats and number of bits:
raw 16
raw 18
raw 24
fft1 32
timf2 16 or 32
fft2 16 or 32

The first four formats can be used for input to Linrad. 
timf2, the input to fft2 and fft2 will be sent as 16 bit 
integers if the user selected the MMX implmentations of the 
FFT algorithms, otherwise they are 32 bit floating point. 
Besides broadcasting one or more of these formats the computer 
that owns the hardware, the master, has a simple server to 
which slaves can connect and request calibration data as well 
as post what frequency the operator is focussing on for all 
other computers on the network to know.

Right now, only the raw data broadcasts and the client server 
communication with calibration data works. I see no problems 
in adding the remaining things however.

On a "modern" computer, a 2.6GHz Pentium 4, the master can run 
under X11 and put out all raw data formats simultaneously. 
4*96000*(16+18+24)bit/s =22 megabit/s of useful data. To that 
adds several percent of overhead because the payload in each 
packet is fixed to 1024 bit.

On a not so modern computer, a 200MHz Pentium MMX, and presumably 
more importantly running Mandrake 8.0 with a very old Linux kernel 
(2.4.3) the 16 bit data 4*96000*16=6 megabit/s uses up 50% of 
the available CPU time allowing very little time for the actual 
signal processing within Linrad. The time reported by linrad goes 
up from 47% to 98%. Receiving data at the same speed does not load 
the CPU much. (A Pentium 1 at 133 MHz can put out 2*48000*16=1.5 
megabytes/s with 5% cpu load using a modern kernel like 2.6.18)

I post this to the Winrad mailing list because it seems to me
that the network of modern computers is capable of doing what 
we need with a broad margin. It would be fine if Linrad, Winrad,
MAP65 and other softwares to come would use the same standards
for sending data over the network. It means we would have to
agree on a protocol and that is why I would like to see a 
discussion on the mailing lists. 

Currently the broadcasting is like this in Linrad:
// Structure for multicasting receive data on the network.
typedef struct {
double passband_center;
float userx_freq;
unsigned int block_no;
unsigned char userx_no;
char passband_direction;

The contents of the payload is determined by the port address
last digit. Linrad uses the 5 first ones and allows the user to
select a port between 50000 and 65000 in steps of 10.
Multicasting groups are to
I will be happy to change to accomodate to suggestions that
make it easier for Linrad and future SDR softwares to communicate.

Slaves connect to the master and the protocol is extremely simple
at the moment. 
// Structure for messages from slaves.
typedef struct {
int type;
double frequency;

Here type is a 32 bit integer telling the master what the slave
wants (calibration functions etc.) Frequency is the frequency that
the slave currently has in focus. Messages are sent infrequently
so there is no problem adding many more things but presumably the
need for communication between different computers does not need
standardization at this point. In the future the wideband unit
might be a commercial transceiver and not a computer running
Linrad and the two-way communication protocol would probably 
be similar to what is used today over the serial port. 

I have tested to run one instance of Linrad as the master 
sending all three raw formats to the network with three more 
instances of of Linrad receiving each one of them on the 
same computer. The cpu load is about 50%:

 9629 root      17   0  244m 154m 1348 S  9.3  7.6   0:23.93 xlinrad
 9663 root      17   0  138m  15m 1388 S  7.3  0.8   0:07.75 xlinrad
 9487 root      14  -1 99.4m  12m 6664 S  6.3  0.6   0:18.32 Xorg
 9652 root      17   0  109m  27m 1340 S  5.0  1.3   0:09.33 xlinrad
 9641 root      19   0  109m  27m 1340 S  4.0  1.3   0:08.74 xlinrad
 9682 root      15   0 22728  12m 8932 S  2.0  0.6   0:01.93 gnome-system-mo
 9561 root      15   0 33280  14m 9340 R  1.7  0.7   0:02.93 gnome-terminal
 2428 root      18   0  1812  620  536 S  0.3  0.0   0:38.18 hald-addon-stor

This experiment was with the second fft disabled, but it shows 
that the network is pretty good within the same computer. 
(The purpose of the test was to show the significance of using 18 
bits but that 24 bits does not improve over 18.)

I have tested six computers simultaneously on the network, two
different masters and the others an one or more slaves receiving
one or the other or both masters. 
I intend to supply zoom, a tool to zoom in/out waterfall spectra. 
One would be able to study waterfalls that cover say 96 kHz in 
say 131072 points with only 100 Hz or whatever across the screen
(could be a window in Windows or X11 or the full screen on a 
separate scrap computer.)  

Besides for zoom, multi-operator contesting and as a MAP65 frontend
I see no other usage at the moment, but it seems to me others will
invent new things. One obvious extension, a trivial one, is to send
bandwidth-reduced data at whatever sampling rate the user wants.
This could be the input to various decoders and demodulators for 
RTTY, packet, and any narrowband digital mode. If anyone on these 
lists knows whether there are already standards for such things
please post the information. 


Leif  /  SM5BSZ

This message is sent to you because you are subscribed to
  the mailing list <linrad@antennspecialisten.se>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>

Reply via email to