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.
#define NET_MULTICAST_PAYLOAD 1024
typedef struct {
char buf[NET_MULTICAST_PAYLOAD];
double passband_center;
float userx_freq;
unsigned int block_no;
unsigned char userx_no;
char passband_direction;
} NET_RX_STRUCT;
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 239.255.0.0 to 239.255.0.16.
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;
} SLAVE_MESSAGE;
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%:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
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.
73
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]>
