[linrad] Network bug, linrad-02.37
Hi All,
Joe, N6KK wrote:
> I've been experimenting with the Linrad Network. All seems well using
> options 4, 5, 6, or 7, but when I turn on option 8 (Send timf2) or option 9
> (send fft2 transforms) the AFC graph and S meter graphs become very slow and
> jerky and the main spectrum and high resolution graphs seem to slow down
> some. If I try to "X" out, the screen freezes and I have to close the
> window and restart Linrad.
There are two bugs.
line 303 in network.c is:
sc[SC_SHOW_FFT1]++;
after this line there has to be a statement like this:
lir_sem_post(SEM_SCREEN);
Without this statement, the screen thread will not update
the screen even though the processing is running correctly
all the time.
The other error, no response to the X command, needs a statement
like this:
if(thread_command_flag[THREAD_LIR_SERVER] != THRFLAG_ACTIVE)return;
inserted at line 257 in network.c
while(sc[SC_SHOW_FFT1]!=sd[SC_SHOW_FFT1])
{
lir_sleep(1);
}
(before or after lir_sleep)
Without it the network server thread will sleep for ever
because the screen thread is already closed and will never
update sd[].
Linrad-02.37 has these corrections but it is somewhat
restructured as compared to 02.35 so it is not (yet?)
on the Linrad Home Page as a stable version.
Download from here:
http://www.sm5bsz.com/linuxdsp/lintx.htm
If you find bugs, please report them (and make the above
corrections to network.c in 02.35)
73
Leif / SM5BSZ
#
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: Linrad Network
Hello Joe, > I've been experimenting with the Linrad Network. All seems well using > options 4, 5, 6, or 7, but when I turn on option 8 (Send timf2) or option 9 > (send fft2 transforms) the AFC graph and S meter graphs become very slow and > jerky and the main spectrum and high resolution graphs seem to slow down > some. If I try to "X" out, the screen freezes and I have to close the > window and restart Linrad. CPU utilization is low, so I'm wondering if > something is causing a conflict in the network processing thread for options > 8 and 9? I'm using WinXP on a P4 with 1.5G RAM and Linrad 2.35. OK. I tested for this and I can reproduce the error. > Consistent > results on my laptop as well. I haven't checked how it behaves under Linux > yet, but I have a hunch it's the same. No, I can not see this problem under Linux. The network is complicated because each time a big FFT has been completed a lot of data is released in a big chunk. Linrad has to send the data in small packets that are evenly distributed in time because the network does not like to be heavily loaded some times and idle in between. I have forgotten the exact details, but packet losses was the problem. Maybe it was the switches in my network that required this complication. I will look for the error. In the meantime you might run a first instance of Linrad that sends raw data to the network as well as timf2. You can then use a second instance of Linrad in which you hopefully will be able to click on signals and see normal behaviour of S-meter and AFC. 73 Leif / SM5BSZ # 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] Linrad Network
I've been experimenting with the Linrad Network. All seems well using options 4, 5, 6, or 7, but when I turn on option 8 (Send timf2) or option 9 (send fft2 transforms) the AFC graph and S meter graphs become very slow and jerky and the main spectrum and high resolution graphs seem to slow down some. If I try to "X" out, the screen freezes and I have to close the window and restart Linrad. CPU utilization is low, so I'm wondering if something is causing a conflict in the network processing thread for options 8 and 9? I'm using WinXP on a P4 with 1.5G RAM and Linrad 2.35. Consistent results on my laptop as well. I haven't checked how it behaves under Linux yet, but I have a hunch it's the same. I'd like to get option 8 working well since it's used for MAP65 :-) . Anyone have any ideas? joe n6kk PS. I have Linrad and MAP65 working on the same computer and happily decoding a stored "S" file. The SDR1000/transverter/2x5WL/1500w station is ready for EME (single polarization, however), but I may not be able to be in the shack when the moon is up for a few days. I'll also try the SDR-IQ and see how it compares to the SDR1000. # 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: MAP65 and Linrad Network
Hi Joe, > > It may be necessary to add a call to Sleep(0) under Windows > > or to sched_yield() under Linux at regular intervals in all > > routines that might lock up the CPU for a too long time. > > > > Those calls are effected by lir_sched_yield() in the OS independent > > code of Linrad and I found it necessary to place about 45 such > > calls within Linrad. > > Hmmm, I may have trouble doing the equivalent. For example, > MAP65 does some very long FFTs using tthe FFFTW3 library. I > can't very well put calls to relinquish CPU control inside these > tasks. No, but just before and just after;-) In Linrad such calls are issued inside the computation of the second fft in case the size is above 32768. > On the other hand, there is a "threads" version of > FFTW3, which might be what's needed. Probably, on a single core computer. On a dual core (or more) it should be OK to have one thread locking up one core for long times provided that the other core never has to do an "endless" task simultaneously:-) > Right now such issues are not a top priority, though. Oooh! I do understand that:-) 73 Leif / SM5BSZ # 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: MAP65 and Linrad Network
Hi Leif, The combination works OK, and but a significant number of packets (around 400 in each minute, or slightly more than 1% of the data) are dropped during MAP65's most compute-intensive parts of each minute. Since plrs does no significant computing, I imagine that the problem may be worse when running Linrad + MAP65. It could also be the other way around. Indeed, it could. In that case I will be surprised, but it will hardly be the first time I have been similarly surprised. It may be necessary to add a call to Sleep(0) under Windows or to sched_yield() under Linux at regular intervals in all routines that might lock up the CPU for a too long time. Those calls are effected by lir_sched_yield() in the OS independent code of Linrad and I found it necessary to place about 45 such calls within Linrad. Hmmm, I may have trouble doing the equivalent. For example, MAP65 does some very long FFTs using tthe FFFTW3 library. I can't very well put calls to relinquish CPU control inside these tasks. On the other hand, there is a "threads" version of FFTW3, which might be what's needed. Right now such issues are not a top priority, though. -- 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: MAP65 and Linrad Network
Hi Leif, One of the nuisances of using the original data file is that Linrad's raw data are not time-stamped. Oooh! But they are:-) Your file is stamped 1163231107.413487 which was the output of the routine current_time() at the start of the recording. FB! This is good to know. I do not know how to interpret the MAP65 screen. The polarisation data of AA1YN seems odd to me. They change very rapidly: 0746: 90 0748: 135 0750: 135 0752: 135 0754: 0 0756: 45 The MAP65 screen shot on my web page http://physics.princeton.edu/pulsar/K1JT/MAP65_1.JPG is from a very early version of the program. Polarization information shown for AA1YN in the main text window is incorrect, but you can find the correct data in the window at lower right. In that panel the columns of numbers are frequency in kHz (above 144.000 MHz), additional frequency increment "DF" in Hz, polarization angle in degrees, and UTC. For AA1YN, therefore, the measured polarization angles over this block of time were UTC Pol --- 0746: 73 0748: 65 0750: 70 0752: 68 0754: 66 0756: 71 0758: 60 In normal operation with a fully working MAP65, the main text window is used for the current QSO. New text appears there at about t=55 seconds in the receive interval. Decoding of the remainder of the bandpass takes place subsequently, and on my development computer finishes at about t=12 s into the next minute. Which signal on the screen that has this behaviour is not obvious to me. The processing screen says Freq 128 and DF=0 (or very close.) When I look at the file, I find the weak signal at the center of the lower waterfall to start at 144.129823 and drift down to 144.129814. JT65 users conventionally use a "quasi-channelized" approach for specifying frequencies. The frequencies correspond to that of the suppressed carrier of the generated SSB signal. Calibrations on the MAp65 screen follow these conventions. MAP65 reports the "channel frequency" as 144.128, as shown by the "128" at the beginning of the lines in the main text window and also in the panel at lower right. Owing to a combination of Doppler shift and calibration errors, the actual received frequency was higher by about +222 Hz at 0746 UTC, drifting slowly downward to +216 Hz at 0758. The JT65 sync tone is at 1270.5 Hz. MAP65 has also subtracted 330 Hz to correct for an apparent fixed calibration error (at 144.125) in my WSE converters. Therefore, with normal Linrad calibration you should expect to see the AA1YN signal at the frequency 144.128 +0.0002220 +0.0012705 +0.0003300 144.1298225 at 0746 UTC. You measured 144.129823 MHz, so we are in almost perfect agreement. That is a 1.818 Hz frequency shift as compared to the MAP65 screen??? In this case the shift is 1270.5 + 330 + DF = 1822.5 Hz at 0746 UTC. There is some info "Options" in the upper waterfall, but that does not fit. In that early version of MAP65, the information there is meaningless. The signal at 144.12982 is right hand circular in Linrad and it does not change polarisation during the 10 minutes. I don't pay attention to the V (circular) Stokes parameter in MAP65. However, there seems to be plenty of linear polarization in the AA1YN signal, certainly enough to establish its angle pretty well. The linear polarization (major axis of the ellipse) is at about 70 degrees, perhaps rotating slightly downward over the 12 minutes. The strong signal at -880 Hz in the lower waterfall is at 144.12894 in Linrad. This signal is elliptic, about 50% left hand. Polarisation does not change with time on this signal either. This big signal is KB8RQ. MAP65 reports the linear polarization angle to be around 90 degrees, increasing somewhat during the 12 minutes. Don't hold me too much to these polarization-angle numbers. They came from a very early MAP65 version; I was still playing with the algorithms then, and I don't recall exactly at what stage the screen-dump was made. -- 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: MAP65 and Linrad Network
Hi Joe, > OK, I tried it with both programs running on the same > (Linux) computer. In this case the two programs were "plrs" > (my "pseudo-Linrad send" program) and MAP65. The Linux > computer has two Xeon CPUs at 2.4 GHz, each with 512 kB L2 > cache, and 1 GB memory. > > The combination works OK, and but a significant number of > packets (around 400 in each minute, or slightly more than 1% > of the data) are dropped during MAP65's most > compute-intensive parts of each minute. Since plrs does no > significant computing, I imagine that the problem may be > worse when running Linrad + MAP65. It could also be the other way around. > Of course it should be possible to improve this situation; I > have not yet tried to address it. In the meantime, I shall > continue to test with Linrad (or plrs) running on one > computer, MAP65 on another. OK. It may be necessary to add a call to Sleep(0) under Windows or to sched_yield() under Linux at regular intervals in all routines that might lock up the CPU for a too long time. Those calls are effected by lir_sched_yield() in the OS independent code of Linrad and I found it necessary to place about 45 such calls within Linrad. 73 Leif / SM5BSZ # 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: MAP65 and Linrad Network
Hi Joe,
> I have the original raw data file and have placed it at
> http://physics.princeton.edu/pulsar/K1JT/06_0744.raw.bz2
Excellent:-)
> One of the nuisances of using the original data file is that
> Linrad's raw data are not time-stamped.
Oooh! But they are:-) Your file is stamped 1163231107.413487 which
was the output of the routine current_time() at the start of
the recording.
double current_time(void)
{
struct timeval t;
gettimeofday(&t,NULL);
return 0.01*t.tv_usec+t.tv_sec;
}
This is the time in seconds with six decimals since Epoch
and if you run Linrad on the file with a fast waterfall
you will see the time on the waterfall starting at 07.45.08
Unfortunately I have missed to put the correct time in the
time variable of the network packets. Currently the time
is the time when data was read from the hard disk and not
when it was stored there. I will correct for the next version:-)
The 'S' file only has a single time stamp for when write was
started. With Delta 44 soundcards, the sampling rate is
pretty accurately 96 kHz (96014 Hz with the card in this
particular computer.) I think one can safely assume that
the error is well below 0.05% so in a 1 hour recording
the time error at the end should stay well below 2 seconds.
> As you know, JT65
> transmissions must start at the top of a UTC minute. To use
> the raw data file effectively with MAP65 you will need to do
> something to ensure that the multicast packets contain times
> that are close to being "correct" with respect to the
> original time (modulo 60 seconds).
OK. I hope that you have found the time to be correct when
receiving timf2 data from Linrad in real time.
> > Surely, for MAP65 testing and development I agree that your
> > strategy is more convenient - but from my point of view the
> > original file is far more interesting
>
> Yes. It probably will be far more interesting, for you
> especially. You will find plenty of birdies and other junk
> in the test file!! See
> http://physics.princeton.edu/pulsar/K1JT/MAP65_1.JPG .
Fine!
I do not know how to interpret the MAP65 screen. The polarisation
data of AA1YN seems odd to me. They change very rapidly:
0746: 90
0748: 135
0750: 135
0752: 135
0754: 0
0756: 45
Which signal on the screen that has this behaviour is not obvious to me.
The processing screen says Freq 128 and DF=0 (or very close.)
When I look at the file, I find the weak signal at the center of the
lower waterfall to start at 144.129823 and drift down to 144.129814.
That is a 1.818 Hz frequency shift as compared to the MAP65 screen???
There is some info "Options" in the upper waterfall, but that does not
fit. The signal at 144.12982 is right hand circular in Linrad and it
does not change polarisation during the 10 minutes.
The strong signal at -880 Hz in the lower waterfall is at 144.12894
in Linrad. This signal is elliptic, about 50% left hand. Polarisation
does not change with time on this signal either.
How do I compute the true frequency of the sync tone from the data
in the MAP65 screen?
73
Leif / SM5BSZ
#
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: MAP65 and Linrad Network
Hi Leif, Yes, it should be possible to run everything on a single fast computer with plenty of memory. I have not yet established that the necessary CPU-sharing during time-critical parts of each program is handled adequately for this to work without glitches. Neither Linrad nor Windows is a very good real-time O/S, and one must work around their limitations in this area. I do not think there would be any problems:-) OK, I tried it with both programs running on the same (Linux) computer. In this case the two programs were "plrs" (my "pseudo-Linrad send" program) and MAP65. The Linux computer has two Xeon CPUs at 2.4 GHz, each with 512 kB L2 cache, and 1 GB memory. The combination works OK, and but a significant number of packets (around 400 in each minute, or slightly more than 1% of the data) are dropped during MAP65's most compute-intensive parts of each minute. Since plrs does no significant computing, I imagine that the problem may be worse when running Linrad + MAP65. Of course it should be possible to improve this situation; I have not yet tried to address it. In the meantime, I shall continue to test with Linrad (or plrs) running on one computer, MAP65 on another. -- 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: MAP65 and Linrad Network
Hi Leif, Moreover, one will almost certainly want separate screens for Linrad and MAP65 -- both of which generally use most or all of a normal-size screen. Yes, I agree - but those who have only one standard computer should know it is possible - if it really is;-) When MAP65 is available, I will be sure to document how it can best be used, and what the hardware requirements will be. Hmmm, I would have liked a file that allows me to play with Linrad on the data that are sent to MAP65. Presumably you have a couple of spurs and perhaps other "interesting" interference that MAP65 (or at least the waterfall graph) would benefit from not getting. This will not be a problem. I have the original raw data file and have placed it at http://physics.princeton.edu/pulsar/K1JT/06_0744.raw.bz2 It is 263 MB in size. One of the nuisances of using the original data file is that Linrad's raw data are not time-stamped. As you know, JT65 transmissions must start at the top of a UTC minute. To use the raw data file effectively with MAP65 you will need to do something to ensure that the multicast packets contain times that are close to being "correct" with respect to the original time (modulo 60 seconds). Surely, for MAP65 testing and development I agree that your strategy is more convenient - but from my point of view the original file is far more interesting Yes. It probably will be far more interesting, for you especially. You will find plenty of birdies and other junk in the test file!! See http://physics.princeton.edu/pulsar/K1JT/MAP65_1.JPG . -- 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: MAP65 and Linrad Network
Hi Joe, > Yes, it should be possible to run everything on a single > fast computer with plenty of memory. I have not yet > established that the necessary CPU-sharing during > time-critical parts of each program is handled adequately > for this to work without glitches. Neither Linrad nor > Windows is a very good real-time O/S, and one must work > around their limitations in this area. I do not think there would be any problems:-) > Moreover, one will almost certainly want separate screens > for Linrad and MAP65 -- both of which generally use most or > all of a normal-size screen. Yes, I agree - but those who have only one standard computer should know it is possible - if it really is;-) > For testing MAP65 when real signals are not available, and > anyway so that I can get 100% repeatable results, I solved > this problem in a slightly different way. I saved some data > by using the Linrad "S" command during the ARRL EME contest > last November. With a slightly modified Linrad I converted > the data to 16-bit TIMF2 format, and wrote it to a file. A > simple program that I call "plrs" (for "pseudo-Linrad send") > can read this file and multicast it in the same way that > Linrad would do, so that MAP65 can receive it. The data > file, 11 minutes of original data, amounts to 507 MB. After > compression with bzip2 it is 228 MB. I will make the data > file available soon, together with plrs and MAP65, to anyone > who wants to participate in testing MAP65. Hmmm, I would have liked a file that allows me to play with Linrad on the data that are sent to MAP65. Presumably you have a couple of spurs and perhaps other "interesting" interference that MAP65 (or at least the waterfall graph) would benefit from not getting. Surely, for MAP65 testing and development I agree that your strategy is more convenient - but from my point of view the original file is far more interesting 73 Leif / SM5BSZ # 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: MAP65 and Linrad Network
Hi Leif, Thanks for your message. ... The number of lost packets is normally small (say 1-5), and since there are some 33000 packets in a one-minute data block, the losses are probably negligible. I will watch it, and probably put in a warning flag or something. Yes, but as long as you fill zeroes in the corresponding locations so there is no time shift, small drop-outs will not have any effect on S/N at all under normal circumstances. Yes, this is exactly what I have done. If anyone is interested in testing an early version of MAP65, please let me know. I can probably make one available fairly soon. You will need two computers with a network connection between them. The MAP65 computer should have 1 GB or more of memory. Hmmm, on a good computer you could run Linrad under Windows on the same computer that you use for MAP65:-) Yes, it should be possible to run everything on a single fast computer with plenty of memory. I have not yet established that the necessary CPU-sharing during time-critical parts of each program is handled adequately for this to work without glitches. Neither Linrad nor Windows is a very good real-time O/S, and one must work around their limitations in this area. Moreover, one will almost certainly want separate screens for Linrad and MAP65 -- both of which generally use most or all of a normal-size screen. I do not presently have a "two-headed" computer, so I am doing initial testing of Linrad/MAP65 with a two-computer setup. Currently I have no antenna so I can not play with the software. Perhaps you could press "S" in Linrad to record the raw data for perhaps 20 minutes and then upload the file on the Internet? For testing MAP65 when real signals are not available, and anyway so that I can get 100% repeatable results, I solved this problem in a slightly different way. I saved some data by using the Linrad "S" command during the ARRL EME contest last November. With a slightly modified Linrad I converted the data to 16-bit TIMF2 format, and wrote it to a file. A simple program that I call "plrs" (for "pseudo-Linrad send") can read this file and multicast it in the same way that Linrad would do, so that MAP65 can receive it. The data file, 11 minutes of original data, amounts to 507 MB. After compression with bzip2 it is 228 MB. I will make the data file available soon, together with plrs and MAP65, to anyone who wants to participate in testing MAP65. -- 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: MAP65 and Linrad Network
Hello Joe, > I've noticed one interesting thing while playing with MAP65 > today. Even though I have assigned its "recvpkt" thread an > "ABOVE_NORMAL" priority, I can cause it to drop UDP packets > by having Windows do various things. (For example, starting > up the Windows Task Manager.) The number of lost packets is > normally small (say 1-5), and since there are some 33000 > packets in a one-minute data block, the losses are probably > negligible. I will watch it, and probably put in a warning > flag or something. Yes, but as long as you fill zeroes in the corresponding locations so there is no time shift, small drop-outs will not have any effect on S/N at all under normal circumstances. Only if you have a VERY strong signal present, a drop-out will create a pair of keying clicks when the signal disappears and when it comes back again. On the Windows computer this is totally impossible if the input comes from Linrad with the noise blanker in 16 bit format. There can not be any strong signals!! > If anyone is interested in testing an early version of > MAP65, please let me know. I can probably make one > available fairly soon. You will need two computers with a > network connection between them. The MAP65 computer should > have 1 GB or more of memory. Hmmm, on a good computer you could run Linrad under Windows on the same computer that you use for MAP65:-) Currently I have no antenna so I can not play with the software. Perhaps you could press "S" in Linrad to record the raw data for perhaps 20 minutes and then upload the file on the Internet? If you use the Delta 44 soundcards in 32 bit mode, the file will contain 18 bits per sample and if you select 16 bits, the file will (of course) contain 16 bits per sample. The file will contain the calibration functions of your system to allow an identical processing with what you can do while recording. 96000*4*2*60*20=922 megabytes for 20 minutes of 16 bit data which could perhaps be compressed with bzip2 since 50% of the data is 0 or -1 while there is no strong signal present and 8 bits would have been sufficient (I do not know whether bzip2 actually can utilize this). In 18 bit mode the file would be 1037 megabytes that can not be compressed. 73 Leif / SM5BSZ > > -- 73, 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]> > # 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: MAP65 and Linrad Network
HI Leif and all, Many thanks for your most helpful response. I had more or less figured out your explanation of userx_no, and now I understand that I *do* have a high-side LO in the RX10700. Well and good. I should have remembered that FFT Version 5 is floating point. I will use it in future for FFT1, since my computer supports the SSE instructions. I will try setting up the amplitude margins for the downstream processing as you describe. I've noticed one interesting thing while playing with MAP65 today. Even though I have assigned its "recvpkt" thread an "ABOVE_NORMAL" priority, I can cause it to drop UDP packets by having Windows do various things. (For example, starting up the Windows Task Manager.) The number of lost packets is normally small (say 1-5), and since there are some 33000 packets in a one-minute data block, the losses are probably negligible. I will watch it, and probably put in a warning flag or something. If anyone is interested in testing an early version of MAP65, please let me know. I can probably make one available fairly soon. You will need two computers with a network connection between them. The MAP65 computer should have 1 GB or more of memory. -- 73, 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: MAP65 and Linrad Network
Hello Joe, > I have now established the necessary network connection > between Linrad and MAP65. So far, I have found nothing to > prevent a happy marriage! > > MAP65 receives a full 90 kHz of xpol signal from Linrad, > finds all the JT65 signals in that bandwidth, matches the > linear polarization angle of each one, decodes the messages, > and provides the operator with a "band map" showing > callsigns, operating frequencies, polarization angles, and > message contents over the past 15 minutes or so. The > program provides a full-width waterfall display and another > one "zoomed in" on the frequency of the station currently > being worked. Excellent!! > > > Questions about Linrad's TIMF2 Multicast Data > - > > Header information accompanying Linrad's multicast TIMF2 > data includes two single-byte parameters, "userx_no" and > "passband_direction", about which I have questions. I > understand that userx_no should correspond to the number of > RF channels, with negative sign indicating floating format. > I would have expected the value -4 for my system using > xpol antennas and the WSE converters (I and Q for each of > two polarizations), but in fact I see -2. Is this as it > should be? Yes. You have two RF channels only. You might have used the hardware described here: http://www.sm5bsz.com/pcdsp/hware.htm This uses two audio channels to receive two RF channels but the output from timf2 would have the same format as you have with the WSE units. The difference is that the sampling speed of timf2 is the same as the audio sampling speed with WSE units, but half the audio sampling speed for the other solution. There is no need for MAP65 to know whether the 96kHz timf2 data originates in a hardware using two audio channels with a sampling rate of 192 kHz or four channels sampling at 96 kHz. > Similarly, I would have expected passband_direction=1 as I > have no LO's on the high side and the spectrum is not > inverted. However, Linrad sends passband_direction=-1. Is > this correct? You have the RX10700 with LO=13.175, 13.200, 13.225 or 13.250 MHz which is above 10.7. All the other LOs are below so -1 is correct. > Linrad FFT Versions > --- > > I have been using FFT Version 0 for the first forward, first > backward, and second forward FFTs. This produces > floating-point TIMF2 data on the multicast network. On a modern computer you can use version 5 for the first forward fft. It uses the SIMD instructions (single instruction multiple data, now called sse I think) and computes the floating point fft quite a bit faster. > To save on memory usage in MAP65 it may be desirable to use > 16-bit data for TIMF2. I have effected this by setting > first forward FFT to version 5, The first fft is always floating point. It must be because the dynamic range of 16 bits is by far not adequate for the unprocessed A/D input. Version 5 is always a good choice on a computer that will allow it. Pentium II and older do not have the SIMD instructions so they have to use another version and it differs a little which one will run fastest depending on architecture. On old machines it might be desireable to actually try all versions and pick the one that runs fastest since old machines may be CPU limited. > first backward FFT to > version 1, and second forward FFT to version 2. Are these > good choices? Yes. > Is there any downside to their use that I > might not have thought about? Also, with these settings I > notice that the signal in the high resolution graph (red dB > lines) is higher than it was with FFT versions 0. Should I > adjust some other parameter to bring this level down be > several dB? When the floating point data from fft1 is truncated to 16 bits there will be quantization noise. You should place the system noise floor at least 20 dB above this extra source of noise to make the loss of NF smaller than 0.043 dB. Press "A" on the keyboard to see the amplitude margins. In case you place the noise floor too high you might find that there is saturation somewhere. The shift parameters for the FFTs will allow you to set the noise floor at the correct level. http://www.sm5bsz.com/linuxdsp/install/dlevel.htm There are many possible sources of rounding errors (quantization noise) and Linrad does not set levels automatically since the criteria for what will be optimum are non-trivial. I hope the above link will be helpful. Under "normal" circumstances you will not need the maximum dynamic range in the second FFT. Only if you have a carefully calibrated system and want to use the smart blanker saturation on noise pulses will be a problem. Narrowband signals are automatically attenuated to fit within the dynamic range of 16 bits. In case you want a very large size for the second fft and a small size for the first fft, the narrowband signals have to be attenuated to a pretty low level. A perfect sinewav
[linrad] Re: MAP65 and Linrad Network
Joe Taylor wrote: In response to questions I have been getting: MAP65 could run with Winrad or with various SDR's if their software is modified to provide the necessary multicasting capability. In itself, this would not be too difficult. Joe, the latest version of Winrad has an hook such that an external DLL can be written with a callback routine which is invoked each time Winrad receives a new audio buffer from the sound card. The audio data passed to the DLL are raw, time-domain data, no processing done on them. Two buffers are passed, 512 samples each (I and Q), integer format normalized to 24 bits even if the sound card is capable of 16 bits only. The document that describes how to write such a DLL meant to be used with Winrad is here : http://www.weaksignals.com/bin/Winrad_Extio.pdf From inside that DLL, once received the data, one could decide to send them via UDP packets, or the likes. However, one of the most important MAP65 features is its automatic Rx-polarization-matching capability. That requires a receiver with full xpol processing, which (as far as I know) is not now provided by Winrad, SDR-1000, SDR-14, or SDR-IQ. Correct, at least for Winrad. Though xpol processing is among the things that eventually will get implemented, it is not present in the current version. 73 Alberto I2PHD # 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] MAP65 and Linrad Network
MAP65 Status I have now established the necessary network connection between Linrad and MAP65. So far, I have found nothing to prevent a happy marriage! MAP65 receives a full 90 kHz of xpol signal from Linrad, finds all the JT65 signals in that bandwidth, matches the linear polarization angle of each one, decodes the messages, and provides the operator with a "band map" showing callsigns, operating frequencies, polarization angles, and message contents over the past 15 minutes or so. The program provides a full-width waterfall display and another one "zoomed in" on the frequency of the station currently being worked. Questions about Linrad's TIMF2 Multicast Data - Header information accompanying Linrad's multicast TIMF2 data includes two single-byte parameters, "userx_no" and "passband_direction", about which I have questions. I understand that userx_no should correspond to the number of RF channels, with negative sign indicating floating format. I would have expected the value -4 for my system using xpol antennas and the WSE converters (I and Q for each of two polarizations), but in fact I see -2. Is this as it should be? Similarly, I would have expected passband_direction=1 as I have no LO's on the high side and the spectrum is not inverted. However, Linrad sends passband_direction=-1. Is this correct? Linrad FFT Versions --- I have been using FFT Version 0 for the first forward, first backward, and second forward FFTs. This produces floating-point TIMF2 data on the multicast network. To save on memory usage in MAP65 it may be desirable to use 16-bit data for TIMF2. I have effected this by setting first forward FFT to version 5, first backward FFT to version 1, and second forward FFT to version 2. Are these good choices? Is there any downside to their use that I might not have thought about? Also, with these settings I notice that the signal in the high resolution graph (red dB lines) is higher than it was with FFT versions 0. Should I adjust some other parameter to bring this level down be several dB? MAP65 with Windows, Linux, FreeBSD, Winrad, SDRxxx ... ? Like WSJT, MAP65 runs on both Windows and Linux. (It should also run on FreeBSD and Macintosh, but I can't test those here.) In my station I will probably run Linrad under Linux and MAP65 on Windows, on a second computer. In response to questions I have been getting: MAP65 could run with Winrad or with various SDR's if their software is modified to provide the necessary multicasting capability. In itself, this would not be too difficult. However, one of the most important MAP65 features is its automatic Rx-polarization-matching capability. That requires a receiver with full xpol processing, which (as far as I know) is not now provided by Winrad, SDR-1000, SDR-14, or SDR-IQ. -- 73, 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: Using the Linrad Network
Hi Leif and all, Joe Taylor wrote: Looks like I need a new hub, or at least a simple crossover cable between the two computers. I will report further, fairly soon I hope, on my effort to connect Linrad to MAP65. I'm back from a long weekend of wilderness canoeing. Made a simple crossover cable, and now the Linrad network works OK. I hope to test the Linrad + MAP65 combination soon. -- 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: Using the Linrad Network
Leif and all, It turns out that my network speed problem had a simple cause. The computer running Linrad is connected to the LAN through a rather old 10 Mbit/s hub/repeater. Therefore it maxes out around 1.2 MByte/s, too slow for 4 channels at 96 kHz in any of Linrad's network modes except mode 4. Looks like I need a new hub, or at least a simple crossover cable between the two computers. I will report further, fairly soon I hope, on my effort to connect Linrad to MAP65. -- 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: Using the Linrad Network
Hi Leif, Thanks for the reply. Something is wrong. Presumably the reason is the same as for the other errors you observe. ... Check for memory usage first. No swapping is taking place, so I don't think it's a memory issue. I will study the problem more and report back if I learn anything useful. -- 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: Using the Linrad Network
Hello Joe,
> Today I made my first tests of Linrad's network broadcasting
> capability. I installed Linrad 02.34 and checked it out. All
> seemed to be well. I selected "N" on the main menu to
> initialize networking parameters, and then selected "format 4"
> (16-bit raw data) for output. After toggling network write ON,
> I found that the program continued to run correctly in Weak CW mode.
Ok.
> Unfortunately, I did not have good luck with any of the other
> data formats. In particular, formats 7, 8, and 9 caused the
> program to produce broken sound output -- that is, frequent gaps
> in the Rx background noise when an active frequency is selected
> with the mouse.
>
> Hitting "T" while receiving, so as to display timing
> information, shows an apparent A/D sampling rates as follows:
>
> Format A/D
> ---
> 4 96 kHz
> 7~30
> 8~73
> 9~49
>
> Obviously, something is seriously wrong!
Yes.
While writing this mail on my single Pentium 2.66 MHz machine,
I have one issue of Linrad running two RF channels at 96 kHz
from the WSE units sending fft1 data to the network. I also
have two more issues of Linrad receiving the fft1 transforms.
All three issues are sending data to the loudspeakers
simultaneously. I notice no problems of any kind.
This is under Debian with kernel 2.6.18-4-686-bigmem
and oss-linux_v4.0-1002_i386.deb
When I start the system monitor I get a short break just when
the program opens. All three Linrad issues have the second FFT
enabled and the total CPU load according to the system monitor
is about 40% with occasional peaks up to 70%.
When I start a fourth issue of Linrad that reads 154 kHz from
an SDR-14 and also sends data (16 bit raw) to the network,
things still work fine with a total CPU load of 60% using
1.2 gigabytes of RAM. In this situation, the USB driver
for SDR-14 crashes in case I try click on any other window
because there is not an appropriate error handeling when
data is lost from the USB device. This does not affect
the other three issues of Linrad.
It seems to me that the problems you see could be caused by
excessive RAM allocation that would cause active data areas
of Linrad to be swapped on the hard disk. It could also
be a problem due to interrupt sharing.
I noticed a bug. In case I press T when Linrad runs from
fft1 input, the A/D rate becomes 192 kHz and an error message
is displayed. This does not affect the processing however.
> I did notice that when using Format 9, although the audio on the
> master computer has frequent interruptions, watzo running on a
> second computer displays waterfall data that looks more or less
> correct.
>
> I tried to use one instance of xlinrad to broadcast "format 4"
> data, and a second instance of xlinrad on the same computer
> receiving the raw 16-bit data. This failed with error #1272
> ("Write to network socket returned an error") on the master and
> error #1274 ("Network read failed") on the slave.
Something is wrong. Presumably the reason is the same as for
the other errors you observe.
> Can you help me to understand what may be wrong in my setup?
> The computer on which Linrad is running is reasonably fast (2.7
> GHz P4, 0.5 MB cache, 1.25 GB memory), and is around 20% busy
> when running xlinrad.
Check for memory usage first.
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] Using the Linrad Network
He Leif and all,
Today I made my first tests of Linrad's network broadcasting
capability. I installed Linrad 02.34 and checked it out. All
seemed to be well. I selected "N" on the main menu to
initialize networking parameters, and then selected "format 4"
(16-bit raw data) for output. After toggling network write ON,
I found that the program continued to run correctly in Weak CW mode.
Unfortunately, I did not have good luck with any of the other
data formats. In particular, formats 7, 8, and 9 caused the
program to produce broken sound output -- that is, frequent gaps
in the Rx background noise when an active frequency is selected
with the mouse.
Hitting "T" while receiving, so as to display timing
information, shows an apparent A/D sampling rates as follows:
Format A/D
---
4 96 kHz
7~30
8~73
9~49
Obviously, something is seriously wrong!
I did notice that when using Format 9, although the audio on the
master computer has frequent interruptions, watzo running on a
second computer displays waterfall data that looks more or less
correct.
I tried to use one instance of xlinrad to broadcast "format 4"
data, and a second instance of xlinrad on the same computer
receiving the raw 16-bit data. This failed with error #1272
("Write to network socket returned an error") on the master and
error #1274 ("Network read failed") on the slave.
Can you help me to understand what may be wrong in my setup?
The computer on which Linrad is running is reasonably fast (2.7
GHz P4, 0.5 MB cache, 1.25 GB memory), and is around 20% busy
when running xlinrad.
-- 73, 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] Network and bits
Hi all, The network is now working fine although several things are still missing. I have decided to abandon the idea of using 1024 byte fixed block size because the network in itself is too much CPU load to make it attractive on old computers at high data rates. As it turns out the size of the packet does not matter at all for the CPU load and it does not matter when two computers are tied directly to each other. When the packets have to pass a switch it is different however. At high rates the network does not work through the switch if the packet size is a little above 1500 bytes, but it works well when the size is a little below. Besides allowing MAP65 and other external softwares the Linrad network is intended to encourage experimentation. I have decided to not freeze the protocol at an early stage. With routines that copy data from a buffer of an arbitrary size (it has to be a multiple of 12 however) the size can be adjusted in case there will be future needs. The current payload is 1404 bytes plus a 24 byte header. One of the obvious experiments is to process the data with different number of bits simultaneously. The result is presented here: http://www.sm5bsz.com/linuxdsp/run/network.htm There is also some more info about the network on this page. 73 Leif / SM5BSZ # 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] AW: [linrad] Network speed problems.
Hello, here is what we found when we had some network performance problems in the office: se a "well known search engine" and look for the phrase "net.core.rmem_default" for example described in http://wwwx.cs.unc.edu/~sparkst/howto/network_tuning.php Please do not ask me any special details, I only read it and took it. During some earlier network optimizations we also found that just looking at the raw amount of data beeing transfered is only partly correct. Some network stacks reach the limit first by the number of packets, not the amount of data. So it might be useful to make transport blocks as large as possible. Just like a Layer4, just inverse. 73, Günter, DL4MEA -Ursprüngliche Nachricht- Von: Linrad mailinglist [mailto:[EMAIL PROTECTED] Im Auftrag von Leif Asbrink Gesendet: 07 January 2007 00:28 An: Linrad mailinglist Betreff: [linrad] Network speed problems. Hi all, Having been sucessful with raw data at speeds up to 96000*4*(16+18+24)=22 Mb/s I sort of believed it was possible to run at rates reasonably near 100 Mb/s when only sendind data in one direction since the machine says: "Link is up at 100Mbps, full duplex" Now, as it turns out I did the above test with only one RF channel so the speed was only 11 Mb/s. What is more of a problem is that the maximum throughput through one socket is actually just a little below 96000*4*16 = 6.1 MB/s. It is perfectly ok to send 5MB/s through four sockets simultaneously but sending fft1 transforms through a single socket is impossible. Presumably this is well known, I an just a newcomer to networking and I could not guess it would behave this way. Is there some settings I should change? One possibillity seems to be to open several sockets on different ports simultaneously to increase the throughput. I can not send even 16 bit noise-blanked time domain data from Linrad to MAP65 over the network on a single socket. 14 bit data will be fine however because the Linrad processing removes all strong signals when the MMX routines are selected. Is there something wrong in what I do? Does Windows behave the same way? To be able to run at 96 khz with fft1 transfer it seems I will have to use at least 6 sockets in parallel with different port numbers. It is interesting to note that the old Pentium MMX at 200 MHz uses very much more CPU (under an old kernel) but that the throughput through one socket does not differ much. It can not send more than a 16 bit channel because there is not enough CPU time available. Trying to find some hints on the Internet I came across this: http://www.ncsa.uiuc.edu/UserInfo/Resources/Hardware/IBMp690/IBM/usr/share/man/info/en_US/a_doc_lib/aixbman/prftungd/2365c93.htm * Do not change the default (and maximum) MTU of 1500 bytes. * Set the application block size in multiples of 4096 bytes. * Keep socket space settings at the default values. * If the workload includes extensive use of services that use UDP, such as NFS or RPC, increase sb_max to allow for the fact that each 1500-byte MTU uses a 4096-byte buffer. It seems to indicate that I should send much larger packets??? (a multiple of 4096 bytes 'header' included) 73 Leif / SM5BSZ # 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]> # 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] Network speed problems.
Hi all, Having been sucessful with raw data at speeds up to 96000*4*(16+18+24)=22 Mb/s I sort of believed it was possible to run at rates reasonably near 100 Mb/s when only sendind data in one direction since the machine says: "Link is up at 100Mbps, full duplex" Now, as it turns out I did the above test with only one RF channel so the speed was only 11 Mb/s. What is more of a problem is that the maximum throughput through one socket is actually just a little below 96000*4*16 = 6.1 MB/s. It is perfectly ok to send 5MB/s through four sockets simultaneously but sending fft1 transforms through a single socket is impossible. Presumably this is well known, I an just a newcomer to networking and I could not guess it would behave this way. Is there some settings I should change? One possibillity seems to be to open several sockets on different ports simultaneously to increase the throughput. I can not send even 16 bit noise-blanked time domain data from Linrad to MAP65 over the network on a single socket. 14 bit data will be fine however because the Linrad processing removes all strong signals when the MMX routines are selected. Is there something wrong in what I do? Does Windows behave the same way? To be able to run at 96 khz with fft1 transfer it seems I will have to use at least 6 sockets in parallel with different port numbers. It is interesting to note that the old Pentium MMX at 200 MHz uses very much more CPU (under an old kernel) but that the throughput through one socket does not differ much. It can not send more than a 16 bit channel because there is not enough CPU time available. Trying to find some hints on the Internet I came across this: http://www.ncsa.uiuc.edu/UserInfo/Resources/Hardware/IBMp690/IBM/usr/share/man/info/en_US/a_doc_lib/aixbman/prftungd/2365c93.htm * Do not change the default (and maximum) MTU of 1500 bytes. * Set the application block size in multiples of 4096 bytes. * Keep socket space settings at the default values. * If the workload includes extensive use of services that use UDP, such as NFS or RPC, increase sb_max to allow for the fact that each 1500-byte MTU uses a 4096-byte buffer. It seems to indicate that I should send much larger packets??? (a multiple of 4096 bytes 'header' included) 73 Leif / SM5BSZ # 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] Network
Hi All,
Linrad will again have a network. A master computer,
one that receives its signal from its own hardware while
using its own calibration functions will send data
to the network (if enabled) in one of several formats.
Thanks to Xtof, ON4IY, I have suitable code that reliably
sends UDP packages that can be picked up by any number of
computers on the network.
Linrad contains a server when running as a master. This
server listens to the network like this:
setup()
{
memset(&slave_addr,0,sizeof(slave_addr));
slave_addr.sin_family = AF_INET;
slave_addr.sin_addr.s_addr = htonl(INADDR_ANY);
slave_addr.sin_port = htons(CONNPORT);
if( (netfd.any_slave = socket(AF_INET, SOCK_STREAM, 0)) < 0)
{
lirerr(1249);
return;
}
bind(netfd.any_slave, (struct sockaddr *)&slave_addr, sizeof(slave_addr));
listen(netfd.any_slave, 5);
FD_ZERO(&master_readfds);
FD_SET(netfd.any_slave, &master_readfds);
}
server()
.
.
.
testfds=master_readfds;
if( select(FD_SETSIZE, &testfds, (fd_set *)0, (fd_set *)0, &timeout) > 0)
{
for(fd = 0; fd < FD_SETSIZE; fd++)
{
if(FD_ISSET(fd,&testfds))
{
if(fd == netfd.any_slave)
{
if(no_of_netslaves == MAX_NETSLAVES)
{
lirerr(1270);
goto netserver_error_exit;
}
client_len = sizeof(client_address);
client_sockfd = accept(netfd.any_slave,
(struct sockaddr *)&client_address, (void*)&client_len);
FD_SET(client_sockfd, &master_readfds);
netfd.slaves[no_of_netslaves]=client_sockfd;
no_of_netslaves++;
ip=(void*)&client_address.sin_addr.s_addr;
sprintf(s,"adding client [%d] %d.%d.%d.%d on fd %d",
no_of_netslaves, ip[0], ip[1], ip[2], ip[3] , client_sockfd);
.
.
.
from what I can read in man pages this should give sockets SOCK_STREAM
(Provides sequenced, reliable, two-way, connection-based byte
streams. An out-of-band data transmission mechanism may be supported.)
In real life it does not work too well. Not on elderly computers.
It is ok on Pentium III and above, but it doers not work
on Pentium MMX or Pentium I when the CPU load is above about 50%.
(Sending UDP is fine, but SOCK_STREAM is not)
I have tried to split data in small packages (1500 bytes) while
using select to make sure I am allowed to write to the socket.
It does not matter whether I use write or send, when computers
are under heavu load packets are lost occasionally.
>From the documentation I infer that the protocol takes care of
hand-shaking and resending: "reliable, two-way, connection-based
byte streams."
I could solve this problem by adding my own hand-shaking. The
purpose of the SOCK_STREAM connection is to allow a slave to ask
the master for calibration functions and also for the slave
to tell the master what frequency he is currently listening to.
There may be other things one would like to send in a reliable
but totally time-uncritical fashion.
Presumably I have misunderstood something. Any comments?
73
Leif / SM5BSZ
#
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]>
