[linrad] Re: Network standards for SDR
On Sat, 6 Jan 2007 05:59:55 +0100
"J.D. Bakker" <[EMAIL PROTECTED]> wrote:
> typedef struct {
>short header_len; // This field is always present, and always first
>short data_len;// This field is always present, and always second
>[ header contents, including header version, type, etc. goes here ]
>char data[NET_MULTICAST_PAYLOAD];
> } NET_RX_STRUCT;
>
> NET_RX_STRUCT msg;
> rxin_char=(void*)(&timf1_char[timf1p_pa]);
> timf1p_pa=(timf1p_pa+ad_read_bytes)&timf1_bytemask;
> for(j=0; j{
>recvfrom(netfd.rec_rx,&msg,sizeof(NET_RX_STRUCT),0,
> (struct sockaddr *) &rx_addr,&addrlen);
>memcpy(&rxin_char[j], ((void *)&msg) + msg.header_len,
> NET_MULTICAST_PAYLOAD);
>}
OK, now you just added an extra copy operation and the ReadData
does not return a pointer. This was exactly what I referred to
from the start.
> For the time being I kept the data size constant, to not mix the
> issues (variable data size adds 5-6 lines). And yes, there is a
> memcpy. But read below...
>
> By the way, there appears to be an inconsistency in your program. Here:
>
>timf1p_pa=(timf1p_pa+ad_read_bytes)&timf1_bytemask;
>
> you make sure that the address pointer for the circular buffer wraps
> around, but I see no such protection in the for() loop. Or am I
> missing something ?
Yes. ad_read_bytes is a power of two so it always goes even in the buffer.
> An extra memcpy makes little difference in this loop. Note that the
> recvfrom() needs to do the equivalent of a memcpy() anyway. I wrote a
> little test program (see the bottom of this mail) to test the speed
> difference between 1 and 2 copy instructions if the destination
> buffer is larger than the cache.
>
> On a Pentium MMX 166MHz, a Thinkpad laptop with X running, I get:
>
> Single copy: 1000 loops in 129.44 seconds, or 79.11 MiBps.
> Double copy: 1000 loops in 147.21 seconds, or 69.56 MiBps.
Hmmm, actually changing the Linrad code to do the double copy as
you suggest increases the CPU load from 47.5% to 48.5% when
16 bit raw data is received on a 200 MHz Pentium MMX. This makes
me believe that receiving fft1 transforms which will be necessary
for this computer to do meaningful work will lead to an extra
load of 4 percent units and that is not insignificant at all.
(32 bit floats, interleaved transforms)
The fft1 mode does not yet work so I can not test right now, but
I hav reasons to believe that the MMX routines will allow this
computer to work well as a slave with two channels at 96 kHz
bandwidth.
> Is there any way at all that you can avoid that, and process the data
> as it comes in ? My first big multi-threaded program was a real-time
> streaming video encoder for a quad Pentium Pro machine, and switching
> processing from a frame at a time to a macroblock (16x16pixels) at a
> time sped the encoder up tremendously, even though the required
> number of operations almost doubled.
I do not know, but it is going to be difficult if possible at all.
> >The most demanding task is the full bandwidth, full dynamic
> >range FFT. It would be identical in all computers and it does
> >not make any sense to do it in more than one computer.
>
> Why ? Because this one computer would be much faster than the others ?
Yes. Amateurs typically have one modern computer
(running Windows) plus a couple of scrap computers that
would be perfectly adequate as slaves.
> So would it be correct to say that:
>
> (a) if all computers were equally fast, there is little advantage in
> cooked mode over raw mode (other than energy conservation), and
Right now yes, but with future add-ons this might change because
the master might do only front-end processing because it is not
fast enough to do everything. Actually I think it will be possible
to use two Pentium MMX with one doing fft1 and nothing more
while the other is doing fft2 and down conversion. It will be
near the limits for what these computers can do - one of them
is just a little to slow.
At the moment CPU time is no problem at all because we do not
yet have the wideband hardware that modern computers could
serve.
> (b) cooked mode allows slow slaves that would normally not be able to
> keep up with the FFTs to still display the data.
There are many FFTs in Linrad. fft1(forward full bw) -> fft1(backward 2 * full
bw) ->
fft2(forward full bw) -> fft2(backward narrow bw) -> fft3(forward narrow bw) ->
fft3(backward narrow bw)
There is dsp processing alternating between the frequency domain and the
time domain. Only the very first fft needs full dynamic range and uses
float. The remaining wideband processing uses MMX. This was necessary
when a modern computer was Pentium 3. Today floats can be used, but
not if one wants to monitor several microwave bands on the same computer.
Because of the much higher speed of 16 bit MMX routines the first
fft takes as much time as all the other tasks together. Since the
processing of all the other transfo
[linrad] Re: Network standards for SDR
>As for the
> ReceiveData() function, that line can be directly replaced with your
recvfrom() call (I just was too lazy too look up recvfrom() when I
wrote that example).
Well, if you care to write the full code you will find that
this statement is not quite what it looks like.
It's not much different. This is what a modified version of your
program looks like:
typedef struct {
short header_len; // This field is always present, and always first
short data_len;// This field is always present, and always second
[ header contents, including header version, type, etc. goes here ]
char data[NET_MULTICAST_PAYLOAD];
} NET_RX_STRUCT;
NET_RX_STRUCT msg;
rxin_char=(void*)(&timf1_char[timf1p_pa]);
timf1p_pa=(timf1p_pa+ad_read_bytes)&timf1_bytemask;
for(j=0; j memcpy(&rxin_char[j], ((void *)&msg) + msg.header_len,
NET_MULTICAST_PAYLOAD);
}
For the time being I kept the data size constant, to not mix the
issues (variable data size adds 5-6 lines). And yes, there is a
memcpy. But read below...
By the way, there appears to be an inconsistency in your program. Here:
timf1p_pa=(timf1p_pa+ad_read_bytes)&timf1_bytemask;
you make sure that the address pointer for the circular buffer wraps
around, but I see no such protection in the for() loop. Or am I
missing something ?
> even if it
did, it matters very little on modern CPUs (packets this size will
remain entirely within the CPU cache).
Linrad is intended to run on elderly computers and it is also
intended to run at much higher bandwidths on modern ones.
You suggest that the data is put into a buffer to which a
pointer is returned by ReceiveData. The next step would be to
store the payload into a circular buffer. This will cause the data
to become written into memory twice.
An extra memcpy makes little difference in this loop. Note that the
recvfrom() needs to do the equivalent of a memcpy() anyway. I wrote a
little test program (see the bottom of this mail) to test the speed
difference between 1 and 2 copy instructions if the destination
buffer is larger than the cache.
On a Pentium MMX 166MHz, a Thinkpad laptop with X running, I get:
Single copy: 1000 loops in 129.44 seconds, or 79.11 MiBps.
Double copy: 1000 loops in 147.21 seconds, or 69.56 MiBps.
The first copy takes about two cycles per byte, adding a second copy
adds less than 0.3 cycles per byte.
On a Pentium II 350MHz (rescued from the garbage a month ago):
Single copy: 1000 loops in 55.76 seconds, or 183.64 MiBps.
Double copy: 1000 loops in 66.36 seconds, or 154.30 MiBps.
The ratio is similar: first copy just under 2 cycles/byte, second
copy adds 0.36 cycles/byte.
Your scenario will likely be even closer, since the kernel will need
to read the UDP datagrams from main memory, too.
Processing of the data is
in another thread that require hundreds of packages in the circular
buffer. It will fetch its input from memory because other
threads have been using the cash in the meantime.
Is there any way at all that you can avoid that, and process the data
as it comes in ? My first big multi-threaded program was a real-time
streaming video encoder for a quad Pentium Pro machine, and switching
processing from a frame at a time to a macroblock (16x16pixels) at a
time sped the encoder up tremendously, even though the required
number of operations almost doubled.
> Zero-copy architectures make
sense for hi-speed packet switching on slow computers; as soon as you
add any processing on the data, that single extra copy gets lost in
the noise. Cache line/block alignment is much more important for
performance.
Actually this is not in agreement with my observations. It does depend
on how efficcien "processing" is done.
In some cases, yes. I've re-written a fixed-point FFT for ARM so that
reading the first word would trigger the loading of a full cache
line, so that the FFT would never have to wait for its data. But even
that would get lost in the noise once you actually started processing
the data.
The most demanding task is the full bandwidth, full dynamic
range FFT. It would be identical in all computers and it does
not make any sense to do it in more than one computer.
Why ? Because this one computer would be much faster than the others ?
> Do you want to have an exact, synchronized display on
multiple machines ?
This would be the case also if raw data were used.
[snip]
The "innocent" slave does not have to know that a data stream is
"cooked". It can be processed as if it were raw data, but a clever
slave can make use of complex information that it might want to
as for. If you want to compute the noise floor power density
you want to know what percentage of samples that were blanked
out because of noise pulses for example. Normally one would not care
at all.
So would it be correct to say that:
(a) if all comp
[linrad] Re: Network standards for SDR
Hi JDB and all,
> I've never written a single line of C++ in my life. As for the
> ReceiveData() function, that line can be directly replaced with your
> recvfrom() call (I just was too lazy too look up recvfrom() when I
> wrote that example).
Well, if you care to write the full code you will find that
this statement is not quite what it looks like.
ReceiveData returns a pointer. recvfrom fills data into a buffer that
the user passes to the function. It does make a difference.
> I don't see that having a header in front of the
> package needs more copy calls than one after the package;
Just compare the code I supplied with the code you will have to write
to make ReceiveData operational.
> even if it
> did, it matters very little on modern CPUs (packets this size will
> remain entirely within the CPU cache).
Linrad is intended to run on elderly computers and it is also
intended to run at much higher bandwidths on modern ones.
You suggest that the data is put into a buffer to which a
pointer is returned by ReceiveData. The next step would be to
store the payload into a circular buffer. This will cause the data
to become written into memory twice. Processing of the data is
in another thread that require hundreds of packages in the circular
buffer. It will fetch its input from memory because other
threads have been using the cash in the meantime.
> Zero-copy architectures make
> sense for hi-speed packet switching on slow computers; as soon as you
> add any processing on the data, that single extra copy gets lost in
> the noise. Cache line/block alignment is much more important for
> performance.
Actually this is not in agreement with my observations. It does depend
on how efficcien "processing" is done.
> I was assuming that the multicast connection would be used for
> distributing raw data only. Re-reading your earlier posts it looks
> like you want to be able to send both raw *and* cooked (processed)
> data. Why ? Do you expect the slaves to be much slower than the
> master ?
Yes.
The most demanding task is the full bandwidth, full dynamic
range FFT. It would be identical in all computers and it does
not make any sense to do it in more than one computer.
> Do you want to have an exact, synchronized display on
> multiple machines ?
This would be the case also if raw data were used.
> Looking at other network protocols (especially streaming), it has
> historically been a bad idea to combine multiple modes into one
> protocol, for reasons of maintainability, performance and clarity.
> Linrad is your code, and it's completely up to you, but might I
> suggest you consider either splitting the transmission modes in raw
> and cooked, or (better) multicasting only raw, unprocessed data and
> sending all filter parameters over a separate channel ?
???
There are two classes of multicasted data that Linrad will send.
1) Time domain data.
2) Frequency domain data.
Raw data is a special and pretty un-interesting case. I am providing
it because it might be useful for experimentation that others may
want to do. The normal operating mode will be "cooked data". It might
be in the time domain or it might be in the frequency domain.
The "innocent" slave does not have to know that a data stream is
"cooked". It can be processed as if it were raw data, but a clever
slave can make use of complex information that it might want to
as for. If you want to compute the noise floor power density
you want to know what percentage of samples that were blanked
out because of noise pulses for example. Normally one would not care
at all.
> > > [about an ADC-to-Ethernet]
> >Probably it would be better to connect it to a socket on a
> >dedicated ethernet port on one computer, the one which has
> >the controls for the radio hardware connected to this soundcard.
> >The master wants 100% reliable data because I assume you do not
> >want to put the master system clock on the audio-to-Ethernet
> >converter.
>
> Why not ? It has a GPS-controlled OCXO to synchronize all sampling
> clocks and to keep time, isn't that sufficient ?
Oooh! Then it would be a suitable master clock - you would just
have to make it count 24 hours and provide a way to set it correctly.
> Pretty much what I described above: header with header length, data
> length, number of channels, sample size, sample rate, timestamp and a
> few descriptive fields (with a version field, so that -- if truly
> necessary -- upgrades are possible). Nothing that isn't strictly
> required: less is more.
>
> It's what everybody else does. I know that that's not much of an
> argument ('50 million Elvis fans can't be wrong'), but in 15 years of
> working on network protocols, this is pretty much the only way that
> I've seen working reliably for successful sampled AV or radio
> projects (I've seen a similar system used on an antenna array for
> MIMO trials). Conversely, I have never ever seen a combined
> raw/cooked protocol that worked,
[linrad] Re: Network standards for SDR
> This is still easy to parse, since all a user needs to do is something like
struct NET_RX_STRUCT *rx_packet;
char *my_data;
short i, my_data_len;
rx_packet = ReceiveData();
my_data = ((char *) rx_packet) + rx_packet->header_len;
for(i = 0; i < rx_packet->data_len; i++)
DoSomethingWithMyData(my_data[i]);
Yes, but but these modern ways of writing scares off all my
friends who can use old-fashioned C but not C++.
First of all ReceiveData() has to be written, separate
buffers of size NET_RX_STRUCT have to be allocated and
managed etc. I do not currently have such code and I suspect
it involves needless copy operations. I am looking
for bandwidths of 2 MHz and above (for VHF noise blanking
to remove static rain) so needless copy - probably
up and down to main memory is something I want to avoid.
I've never written a single line of C++ in my life. As for the
ReceiveData() function, that line can be directly replaced with your
recvfrom() call (I just was too lazy too look up recvfrom() when I
wrote that example). I don't see that having a header in front of the
package needs more copy calls than one after the package; even if it
did, it matters very little on modern CPUs (packets this size will
remain entirely within the CPU cache). Zero-copy architectures make
sense for hi-speed packet switching on slow computers; as soon as you
add any processing on the data, that single extra copy gets lost in
the noise. Cache line/block alignment is much more important for
performance.
> This is enough for basic decoding of any stream, no ? Even the center
frequency can be seen as superfluous (since it's only for display and
not strictly needed for decoding).
The primary usage of the Linrad network was for the second operator
in a contest station. It is an obvious advantage that the display
is always correct - particularly if several bands are monitored
simultaneously.
I cannot imagine what systems would evolve over the coming five years
that couldn't fit in this framework.
Linrad can also send data in the frequency domain and there is
quite a lot of info that a slave will need. Admittedly those
formats are likely to be used by Linrad only but they carry
many more complications.
OK, I see.
I was assuming that the multicast connection would be used for
distributing raw data only. Re-reading your earlier posts it looks
like you want to be able to send both raw *and* cooked (processed)
data. Why ? Do you expect the slaves to be much slower than the
master ? Do you want to have an exact, synchronized display on
multiple machines ?
Looking at other network protocols (especially streaming), it has
historically been a bad idea to combine multiple modes into one
protocol, for reasons of maintainability, performance and clarity.
Linrad is your code, and it's completely up to you, but might I
suggest you consider either splitting the transmission modes in raw
and cooked, or (better) multicasting only raw, unprocessed data and
sending all filter parameters over a separate channel ?
> [about an ADC-to-Ethernet]
Probably it would be better to connect it to a socket on a
dedicated ethernet port on one computer, the one which has
the controls for the radio hardware connected to this soundcard.
The master wants 100% reliable data because I assume you do not
want to put the master system clock on the audio-to-Ethernet
converter.
Why not ? It has a GPS-controlled OCXO to synchronize all sampling
clocks and to keep time, isn't that sufficient ?
Are you aware of any standard format for streaming unprocessed
audio data?
At my previous job we had a few, but they were paper-only. There is
MADI (digital audio) and SMPTE-259M (digital video) over ATM, but
that doesn't quite apply here. I believe the AES have some, but those
are for-pay documents, and I'm not an AES member anymore.
What data format were you contemplating before this discussion
started?
Pretty much what I described above: header with header length, data
length, number of channels, sample size, sample rate, timestamp and a
few descriptive fields (with a version field, so that -- if truly
necessary -- upgrades are possible). Nothing that isn't strictly
required: less is more.
It's what everybody else does. I know that that's not much of an
argument ('50 million Elvis fans can't be wrong'), but in 15 years of
working on network protocols, this is pretty much the only way that
I've seen working reliably for successful sampled AV or radio
projects (I've seen a similar system used on an antenna array for
MIMO trials). Conversely, I have never ever seen a combined
raw/cooked protocol that worked, or better: that remained working. Or
it evolved into something like WAV: a historical accident that
everyone loves to hate.
JDB.
--
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
--
[linrad] Re: Network standards for SDR
Hi again,
> WAV is an example of a file format where *everyone* added their own
> custom headers/chunks, without any planning. As a result, no program
> can read all existing WAV files; WAV is considered an example how
> *not* to do a file format.
And still we have to use it.
> Would you consider a very simple, easy to parse header like this:
>
> typedef struct {
>short header_len; // This field is always present, and always first
>short data_len;// This field is always present, and always second
>[ header contents, including header version, type, etc. goes here ]
>char data[];
> } NET_RX_STRUCT;
Perhaps. At the moment I do not see any advantage. You want to
add the flexibility of a variable data_len. The cost is that there
are bytes ahead of the data so it is less straightforward to
read directly into the final buffer. One could copy the few bytes
back, but there is an increaced time delay of one buffer. This
is not a big deal.
> This is still easy to parse, since all a user needs to do is something like
>
>struct NET_RX_STRUCT *rx_packet;
>char *my_data;
>short i, my_data_len;
>
>rx_packet = ReceiveData();
>my_data = ((char *) rx_packet) + rx_packet->header_len;
>for(i = 0; i < rx_packet->data_len; i++)
> DoSomethingWithMyData(my_data[i]);
Yes, but but these modern ways of writing scares off all my
friends who can use old-fashioned C but not C++.
First of all ReceiveData() has to be written, separate
buffers of size NET_RX_STRUCT have to be allocated and
managed etc. I do not currently have such code and I suspect
it involves needless copy operations. I am looking
for bandwidths of 2 MHz and above (for VHF noise blanking
to remove static rain) so needless copy - probably
up and down to main memory is something I want to avoid.
In Linrad It is like this now:
NET_RX_STRUCT *msg;
rxin_char=(void*)(&timf1_char[timf1p_pa]);
timf1p_pa=(timf1p_pa+ad_read_bytes)&timf1_bytemask;
for(j=0; j 0
{
if(FD_ISSET(netfd.rec_rx,&testfds))
{
recvfrom(netfd.rec_rx,msg,sizeof(NET_RX_STRUCT),0,
(struct sockaddr *)
&rx_addr,&addrlen);
// รถ fill zeroes and move data if block_no not correct here.
}
}
}
else
{
lir_sleep(10);
goto seltest16;
}
}
This might look like more code, but there is nothing hidden here.
timf1_char is the circular buffer which the fft routines use as input.
Data is transferred directly into this buffer which has a size of
2 to power N. Some extra space is reserved for the header so
writes do not become illegal when the pointer is at its last position.
If it were not for the requirement that the thread has to
exit nicely even if the network is broken the same code
would look like this:
NET_RX_STRUCT *msg;
rxin_char=(void*)(&timf1_char[timf1p_pa]);
timf1p_pa=(timf1p_pa+ad_read_bytes)&timf1_bytemask;
for(j=0; j > > That, too, makes it harder for dedicated hardware receivers; ideally
> >> these would not need _any_ communication from the slave to the
> >> master. As I see it, encoding this information in the header of each
> >> package is a low-overhead way to reduce ambiguity, too.
> >The problem is that there are so many possibillities. I do not
> >want to invent a complicated scheme for describing the myriad
> >of things I can imagine now only to discover in a few years that
> >something entirely different has evolved.
>
> I would suggest keeping it extremely simple. There is not very much
> information that varies between sampled systems:
>
> - sample size
> - sample rate
> - number of channels (could even be fixed to 'always I/Q')
Ooooh! We talk about the wideband output from an SDR. It is far
more complicated. Are noise pulses subtracted? Are some points
blanked out (how many percent ?) Are some carriers (spurs) removed
Is ALC splatter from some SSB transmission processed etc. etc.
There are really many possible wideband processes that serve
the purpose of removing interference of various kinds. Removing
the second harmonic at 1836 kHz of an AM transmitter at 918 kHz
is one recent example. One would like to do it while processing
over 1 MHz bandwidth in order to have access to the fundamental
but already in 90 kHz bandwidth one should be able to do a lot
by use of the knowledge that the modulation sidebands (splatter)
belong to a second harmonic.
> and, for radio systems,
>
> - center frequency
AND phase. Is Q before or after I? (direction of the
frequency scale)
> This is enough for basic decoding of any stream, no ? Even the center
> frequency can be seen as superfluous (since it's only for display and
> not strictly needed for decoding).
The primary usage of the Linrad network was for the second operator
in a contest station. It is an obvious advantage that the display
is always correct - particularly if several bands are monitored
simultaneously.
> I cannot imagine what systems would evolve over the coming
[linrad] Re: Network standards for SDR
Leif and all, Would you agree on milliseconds since midnight? From JDB I learned that a double with seconds since Unix epoch would be a bad idea since conversion may be difficult on non-PC platforms. (It is the internal time format within Linrad however) Yes, milliseconds since UTC would be OK. Maybe you should send BOTH this quantity AND a double with seconds since Unix epoch (which I would actually prefer). I don't see the conversion issue as a big deal; little-endian to big-endian copnversion is trivial, and doesn't nearly everybody use IEEE floating point these days? Pretty hard to fit in a 256-cell CPLD. JDB. -- LART. 250 MIPS under one Watt. Free hardware design files. http://www.lartmaker.nl/ # This message is sent to you because you are subscribed to the mailing list . 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]>
[linrad] Re: Network standards for SDR
Leif and all, Would you agree on milliseconds since midnight? From JDB I learned that a double with seconds since Unix epoch would be a bad idea since conversion may be difficult on non-PC platforms. (It is the internal time format within Linrad however) Yes, milliseconds since UTC would be OK. Maybe you should send BOTH this quantity AND a double with seconds since Unix epoch (which I would actually prefer). I don't see the conversion issue as a big deal; little-endian to big-endian copnversion is trivial, and doesn't nearly everybody use IEEE floating point these days? -- Joe # This message is sent to you because you are subscribed to the mailing list . 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]>
[linrad] Re: Network standards for SDR
The newcomer who wants to write his own software does not have
to know anything about the header, he can just use the 1024
bytes of data and ignore whatever has been appended. Having a
header which has to be properly decoded in order to extract
the data builds a threshold that makes it more difficult to
get started. (Processing simple .wav files has a pretty high
threshold in decoding the header. Common practice between
amateurs has been to just dicard the header and read the actual
data using the information supplied with the file. Those
who worked with the UNKN422 challenge were adviced to do
so for example.)
WAV is an example of a file format where *everyone* added their own
custom headers/chunks, without any planning. As a result, no program
can read all existing WAV files; WAV is considered an example how
*not* to do a file format.
Would you consider a very simple, easy to parse header like this:
typedef struct {
short header_len; // This field is always present, and always first
short data_len;// This field is always present, and always second
[ header contents, including header version, type, etc. goes here ]
char data[];
} NET_RX_STRUCT;
This is still easy to parse, since all a user needs to do is something like
struct NET_RX_STRUCT *rx_packet;
char *my_data;
short i, my_data_len;
rx_packet = ReceiveData();
my_data = ((char *) rx_packet) + rx_packet->header_len;
for(i = 0; i < rx_packet->data_len; i++)
DoSomethingWithMyData(my_data[i]);
> That, too, makes it harder for dedicated hardware receivers; ideally
these would not need _any_ communication from the slave to the
master. As I see it, encoding this information in the header of each
package is a low-overhead way to reduce ambiguity, too.
The problem is that there are so many possibillities. I do not
want to invent a complicated scheme for describing the myriad
of things I can imagine now only to discover in a few years that
something entirely different has evolved.
I would suggest keeping it extremely simple. There is not very much
information that varies between sampled systems:
- sample size
- sample rate
- number of channels (could even be fixed to 'always I/Q')
and, for radio systems,
- center frequency
This is enough for basic decoding of any stream, no ? Even the center
frequency can be seen as superfluous (since it's only for display and
not strictly needed for decoding).
I cannot imagine what systems would evolve over the coming five years
that couldn't fit in this framework.
At 17:47 +0100 04-01-2007, Leif Asbrink wrote (in another mail):
Would you agree on milliseconds since midnight? From JDB I
learned that a double with seconds since Unix epoch
would be a bad idea since conversion may be difficult on
non-PC platforms. (It is the internal time format within
Linrad however)
I would use the same interface that gettimeofday() uses: a long with
seconds since the Epoch (Jan 1 1970), and a long with microseconds.
The formats I intend to use within Linrad will use IA32 little endian
(as well as IA32 float) I have no intention to make Linrad portable
to other platforms and I am pretty sure I will not change my mind
on this point for the next 5 years or more. Probably never.
OK, that's fine, so please document this somewhere so those of us on
non-IA32 can deal with it.
As an example: I'm currently soldering the prototype of an
audio-to-Ethernet converter as part of a portable hard disk recorder.
This design uses the CS5381 ADC, one of the best professional audio
converters on the market with a dynamic range approaching 120dB. This
is an open-hardware system[1], and with a few modifications I could
see it being usable for Linrad. A lot of the limitations (time jitter
on the system clock etc) that are present on a PC platform simply do
not appear for such a dedicated device. How would you like me to
interface such a system to Linrad ? Should it be able to act as a
Linrad master ?
JDB
[1] Converter schematics are here:
http://www.lartmaker.nl/recbox-adc-cs5381-main.png
http://www.lartmaker.nl/recbox-adc-cs5381-power.png
http://www.lartmaker.nl/recbox-adc-cs5381.pdf
--
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lartmaker.nl/
#
This message is sent to you because you are subscribed to
the mailing list .
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]>
[linrad] Re: Network standards for SDR
Hi Joe and all,
> I agree that a timestamp will be useful. For what I am
> thinking about, very high precision and high accuracy are
> not required. JT65 wants to know the UTC of a data block to
> within a second or so. (Relative timing among successive
> blocks is of course maintained by the fixed and nominally
> known sample rate.) Of course the slave computer could use
> its own time, but that will add another level of jitter.
>
> As a minimum, I suggest that each packet include as a 32-bit
> integer the number of seconds since the Unix epoch,
> according to the master computer's system clock. So much
> the better if you include a number of milliseconds as a
> second number, or combine both into a double.
>
> Never mind about jitter; the receiving program would need to
> know that jitter in the time values will exist, and behave
> accordingly.
>
> Together with the block number, these approaches will
> suffice very nicely for JT65, anyway. They will work better
> and more reliably than having the slave computer use its own
> system clock.
OK. This is what it looks like under Windows:
int lir_get_epoch_seconds(void)
{
// Here we have to add a calendar to add the number
// of seconds from todays (year, month, day) to Jan 1 1970.
// The epoch time is needed for moon position computations.
SYSTEMTIME tim;
GetLocalTime(&tim);
return 3600.*tim.wHour+60.*tim.wMinute+tim.wSecond;
}
I can put the number of seconds since the Unix epoch if
someone supplies the code needed in Windows. (It is needed
anyway to make moon computations correct under Windows)
Would it not be more convenient to supply an integer with
the number of milliseconds since midnight? The accuracy
(jitter) might be a few ms and that should allow averaging
to find the sync tone provided that each station has
adequate stability and a correction for his own part of
the doppler shift.
> Please let me know when a broadcast-enabled Linrad version
> is available for testing with MAP65. And if you have some
> example code for use by the receiving program -- or, say, a
> stand-alone "dummy" receiving program that can receive
> broadcast packets, I would be happy to see the code!
Pretty soon, but I will await further comments on the way
it will be implemented. You already talked me into adding
a time stamp. I can see that it should have less time jitter
than the time stamp you can add from the system clock in
MAP65.
The time stamp will not necessarily be the time at which the
samples arrive for each block however. The SDR-14 for example
sends 8192 bytes and all 8 network packages from one read will
then have the same time stamp. (Of course this can be corrected
at a later stage.)
Would you agree on milliseconds since midnight? From JDB I
learned that a double with seconds since Unix epoch
would be a bad idea since conversion may be difficult on
non-PC platforms. (It is the internal time format within
Linrad however)
73
Leif
#
This message is sent to you because you are subscribed to
the mailing list .
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]>
[linrad] Re: Network standards for SDR
Hi JDB and all, > A general point: in virtually all communications protocols the > (descriptive) header comes before the data block, since the receiver > usually needs to decode the header to be sure what to do with the > data. This also makes it possible to vary the length of the data > block, if desired (for instance, to tune to FFT block sizes or > sampling hardware word length). My primary goal is radio and experimenting with radio receivers. Today we can do many things inside computers and I want to make it easy for newcomers to enter radio experimenting from the digital side. That is why I have placed the fixed size data block in front of the header. The newcomer who wants to write his own software does not have to know anything about the header, he can just use the 1024 bytes of data and ignore whatever has been appended. Having a header which has to be properly decoded in order to extract the data builds a threshold that makes it more difficult to get started. (Processing simple .wav files has a pretty high threshold in decoding the header. Common practice between amateurs has been to just dicard the header and read the actual data using the information supplied with the file. Those who worked with the UNKN422 challenge were adviced to do so for example.) > > > - I would want a timestamp in there somewhere. It might be derived > >> from block_no, but why not make it explicit ? > >I do not see what it would be good for. Why do you want the clock > >from the master while there is another one in the slave? > > Array processing. It would be very useful for a situation where you > have multiple masters on one network (either during a contest, or -in > my case- with a few servers each connected to an antenna+receiver). > Time sync is not hard over either GPS/TAC or ntp. Do you mean that the time stamp should be used to combine the signals from separate hardwares so one could build an adaptive antenna by combining them properly? That would mean that local oscillators and sampling clocks have to be phase locked to a common reference and that there is a way for Linrad to find out how many samples reside in the various buffers in the soundcard and the device drivers. This is all impossible with todays hardware. The solution as I see it is a box with a fast ADC and a decimation chip. Something like the SDR14, but with provision to synchronize any number of boxes. It would be natural to add a network interface into each box and make them broadcast their data and the obvious synchronization would be the block number, a counter that is kept synchronous exactly as the counters in the decimation chip. > Even in one-master situations it could be useful: with timestamps, it > is very easy to make something similar to the Time Machine. Please explain what you mean by this. The only Time Machine I know of is a direct conversion receiver with analog output. > > > - how is the sampling rate communicated ? > >The slave(client) asks the server for the meaning of the data. > >Number of channels, nominal sampling rate, whether the format is > >real or complex etc. > > That, too, makes it harder for dedicated hardware receivers; ideally > these would not need _any_ communication from the slave to the > master. As I see it, encoding this information in the header of each > package is a low-overhead way to reduce ambiguity, too. The problem is that there are so many possibillities. I do not want to invent a complicated scheme for describing the myriad of things I can imagine now only to discover in a few years that something entirely different has evolved. Certainly it will be possible to append a couple of bytes to the header to allow each package to define its contents. The beauty of the structure I have suggested is that a user (newcomer) can read 1024 bits of data from each package without knowing the size and meaning of whatever header that comes later in the package. As I see it, the primary usage is just to send the time domain signal in a known standard format just as if it were read from some hardware on the client computer. > > > - if you are not doing so already, please please _please_ use the > >> functions htons() / ntohs() and friends to convert between host byte > >> order and network byte order (or forever determine that linrad > >> communicates with either little endian (IA32) or big endian (Alpha, > >> PowerPC etc) byte order. I would want to be able to use a PC as the > >> server and my PowerBook as the client, for instance. > >I do not see how it matters. Linrad does not put port numbers or > >addresses in the packages, that is done by the operating system > >and the inner workings of Linrad is not visible from the network. > > Byte ordering is not restricted to port numbers or addresses. Every > time you put an integer which is larger than one byte into a packet, > the transmitter and receiver need to agree on the byte order. See > > http://en.wikipedia.org/
[linrad] Re: Network standards for SDR
Hi Leif and all, - I would want a timestamp in there somewhere. It might be derived from block_no, but why not make it explicit ? I do not see what it would be good for. Why do you want the clock from the master while there is another one in the slave? Surely I could add this, but there is a cost to it. The packages are sent out at maybe 1 kHz. The corresponding time resolution is 1 ms. There is an appreciable time jitter however and it is not obvious what time to put into a specific package. Presumably it should be the time when the first sample within the package was taken from the hardware. What would it be good for? It is not trivial to evaluate. I agree that a timestamp will be useful. For what I am thinking about, very high precision and high accuracy are not required. JT65 wants to know the UTC of a data block to within a second or so. (Relative timing among successive blocks is of course maintained by the fixed and nominally known sample rate.) Of course the slave computer could use its own time, but that will add another level of jitter. As a minimum, I suggest that each packet include as a 32-bit integer the number of seconds since the Unix epoch, according to the master computer's system clock. So much the better if you include a number of milliseconds as a second number, or combine both into a double. Never mind about jitter; the receiving program would need to know that jitter in the time values will exist, and behave accordingly. Together with the block number, these approaches will suffice very nicely for JT65, anyway. They will work better and more reliably than having the slave computer use its own system clock. Please let me know when a broadcast-enabled Linrad version is available for testing with MAP65. And if you have some example code for use by the receiving program -- or, say, a stand-alone "dummy" receiving program that can receive broadcast packets, I would be happy to see the code! -- Joe, K1JT # This message is sent to you because you are subscribed to the mailing list . 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]>
[linrad] Re: Network standards for SDR
A general point: in virtually all communications protocols the (descriptive) header comes before the data block, since the receiver usually needs to decode the header to be sure what to do with the data. This also makes it possible to vary the length of the data block, if desired (for instance, to tune to FFT block sizes or sampling hardware word length). > - I would want a timestamp in there somewhere. It might be derived from block_no, but why not make it explicit ? I do not see what it would be good for. Why do you want the clock from the master while there is another one in the slave? Array processing. It would be very useful for a situation where you have multiple masters on one network (either during a contest, or -in my case- with a few servers each connected to an antenna+receiver). Time sync is not hard over either GPS/TAC or ntp. Even in one-master situations it could be useful: with timestamps, it is very easy to make something similar to the Time Machine. > - how is the sampling rate communicated ? The slave(client) asks the server for the meaning of the data. Number of channels, nominal sampling rate, whether the format is real or complex etc. That, too, makes it harder for dedicated hardware receivers; ideally these would not need _any_ communication from the slave to the master. As I see it, encoding this information in the header of each package is a low-overhead way to reduce ambiguity, too. > - if you are not doing so already, please please _please_ use the functions htons() / ntohs() and friends to convert between host byte order and network byte order (or forever determine that linrad communicates with either little endian (IA32) or big endian (Alpha, PowerPC etc) byte order. I would want to be able to use a PC as the server and my PowerBook as the client, for instance. I do not see how it matters. Linrad does not put port numbers or addresses in the packages, that is done by the operating system and the inner workings of Linrad is not visible from the network. Byte ordering is not restricted to port numbers or addresses. Every time you put an integer which is larger than one byte into a packet, the transmitter and receiver need to agree on the byte order. See http://en.wikipedia.org/wiki/Endianness for details. Taking my example, if the master runs on an Intel machine and the slave on my PowerBook, if the master transmits a block_no of 0x01020304, my PowerBook will see that as 0x04030201. Not good. JDB. -- Years from now, if you are doing something quick and dirty, you imagine that I am looking over your shoulder and say to yourself, "Dijkstra would not like this," well that would be immortality for me. -- Edsger Dijkstra, 1930 - 2002 # This message is sent to you because you are subscribed to the mailing list . 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]>
[linrad] Re: Network standards for SDR
On Thu, 4 Jan 2007 04:02:10 +0100
"J.D. Bakker" <[EMAIL PROTECTED]> wrote:
> >// 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;
>
> Very interesting ! A couple of observations:
>
> - I would want a timestamp in there somewhere. It might be derived
> from block_no, but why not make it explicit ?
I do not see what it would be good for. Why do you want the clock
from the master while there is another one in the slave?
Surely I could add this, but there is a cost to it.
The packages are sent out at maybe 1 kHz. The corresponding
time resolution is 1 ms. There is an appreciable time jitter
however and it is not obvious what time to put into
a specific package. Presumably it should be the time
when the first sample within the package was taken from
the hardware. What would it be good for? It is not trivial
to evaluate.
> - how is the sampling rate communicated ?
The slave(client) asks the server for the meaning of the data.
Number of channels, nominal sampling rate, whether the format is
real or complex etc.
The user might know the format of the data and just
set up the slave manually as you would do when reading
data from a soundcard.
> - using float/double makes it much harder for dedicated hardware
> receivers to act as server.
OK. The internal formats of Linrad are floats or 16 bit integers.
I will make provisions to add 32 bit integers if there would
be a need in the future.
> - if you are not doing so already, please please _please_ use the
> functions htons() / ntohs() and friends to convert between host byte
> order and network byte order (or forever determine that linrad
> communicates with either little endian (IA32) or big endian (Alpha,
> PowerPC etc) byte order. I would want to be able to use a PC as the
> server and my PowerBook as the client, for instance.
I do not see how it matters. Linrad does not put port numbers or
addresses in the packages, that is done by the operating system
and the inner workings of Linrad is not visible from the network.
73
Leif
#
This message is sent to you because you are subscribed to
the mailing list .
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]>
[linrad] Re: Network standards for SDR
// 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;
Very interesting ! A couple of observations:
- I would want a timestamp in there somewhere. It might be derived
from block_no, but why not make it explicit ?
- how is the sampling rate communicated ?
- using float/double makes it much harder for dedicated hardware
receivers to act as server.
- if you are not doing so already, please please _please_ use the
functions htons() / ntohs() and friends to convert between host byte
order and network byte order (or forever determine that linrad
communicates with either little endian (IA32) or big endian (Alpha,
PowerPC etc) byte order. I would want to be able to use a PC as the
server and my PowerBook as the client, for instance.
JDB.
--
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lartmaker.nl/
#
This message is sent to you because you are subscribed to
the mailing list .
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]>
[linrad] Re: Network standards for SDR
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 5 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 %MEMTIME+ 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
