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 <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]>
