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,
>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
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 f
> 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++
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 c
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 wou
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 wou
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 diffic
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 t
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
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 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,
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 blo
// 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
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
h
15 matches
Mail list logo
