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/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. Oooh! Now I understand this point:-) 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. If there will be a common standard for Linrad, Winrad and MAP65 I suppose others will make software for other platforms that conform to IA32 formats (the integer ones, but not the float). ############################################################# 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]>
