[linrad] Re: Testing MAP65 v0.8
Hello Rick, can you point me to some specific models for managed switches, so I can read up ? Thanks Stan,W1LE Unfortunately neither of the switches you tested with had the horsepower (i.e. were managed switches) to control the multicast traffic, though they will segment the unicast traffic. A managed switch (capable of IGMP snooping) would handle the multicast traffic also and eliminate the swamping of machine A. # 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: Testing MAP65 v0.8
Rick and all, Well, it seems I'm learning more about computer networking than I ever wanted to know... ;-) Why did you use a mask of 224.0.0.0 instead of 240.0.0.0 in your multicast route statement on the Linux box? (Your: # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth1 statement.) My mistake when typing it into the email message. I had it right when the tests were made. Unfortunately neither of the switches you tested with had the horsepower (i.e. were managed switches) to control the multicast traffic, though they will segment the unicast traffic. Yes, this is exactly what I discovered. You asked some more good questions, and I will follow up on them soon. In the meantime, I've realized that there is really no reason to use multicasting for the Linrad --> MAP65 connection. I could just as well "unicast" the UDP data stream between the two machines, using a crossover cable and explicit private-LAN (192.168.x.x) addresses on each end, and have none of the problems I've been worrying about. This solution causes the data go where I want it to go, and nowhere else. The other option that I'm beginning to think very attractive is running both Linrad and MAP65 in a single machine. TIMF2 data could go from Linrad to MAP65 over the loopback (lo) interface -- or by way of shared memory, or ??? -- 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] SDR-IQ and Linrad
Hi Dave, Dave Blaschke wrote: K1JT wrote: In principle, any hardware that can be made to work with Linrad should also be usable with the Linrad-MAP65 combination. At present this is true only if the sampling rate can be set to 96.000 kHz (four channels, two I-Q pairs) or 192.000 kHz (two channels). If you want to try MAP65 and don't have xpol, a simple way to get started would be to put nothing into the Y channel (or perhaps put the X signal into both X and Y inputs). I have tried this in my station and it works -- although of course no polarization information is produced for the received signals. The SDR-IQ can provide effective I-Q sampling rates of 55.555, 111.111, 158.730, and 196.078 kHz for a single polarization. For some reason my post to "Linrad mailinglist" is bouncing. I'm using SDR-IQ. Is it a certainty that the SDR-IQ cannot handle sampling rate values outside those shown above; such as the 96.000 kHz required by MAP65? I would like to test this. (Or am I misunderstanding the requirements?) I don't have an SDR-IQ or any of its documentation, but as I understand it the A/D sampling rate is fixed at 66.667 MHz. Resampling and decimation is then done in a specialized chip (by Analog Devices, I think). I imagine this means that only certain output sampling rates are possible -- ones related to 66.667 MHz by the ratio of small integers. Perhaps someone else with better knowledge of the SDR-IQ can correct me, or otherwise elaborate. I can see how to set the sound output sampling rate under Linrad to 96.000 kHz, but how does one manually set the sound input sampling rate to this value? Or is a pre-programmed value chosen by Linrad whenever SDR-IQ is selected as the input device during setup? When you use the SDR-IQ with Linrad you don't need a Delta44 or any other soundcard for input. A/D conversion takes place in the SDR-IQ, so the input sampling rate is determined there. As I mentioned above, the SDR-IQ also does decimation to provide a smaller bandwidth (190 kHz or less) at its output. The output from SDR-IQ (input to Linrad) is digital, not analog. My second question: Has a revised version of Linrad been released that will detect the SDR-IQ under Linux? I am currrently running the Windows version. I expect Leif will correct me when he returns home, if I am wrong about this. I believe the most recent version of Linrad (both Windows and Linux) can always be found at the bottom of this page http://www.sm5bsz.com/linuxdsp/linroot.htm along with a brief description of changes from previous versions. The most recent (stable, released) version can be found on the Linrad Home Page: http://www.nitehawk.com/sm5bsz/linuxdsp/linrad.htm -- 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: Testing MAP65 v0.8
Rick Kunath wrote: Looks like I missed a few center-click inadvertent pastes in proofreading the previous post, but nothing that shouldn't be obvious :( (Reminds self not to multi-task while replying to email messages.) Rick # 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: Testing MAP65 v0.8
Joe Taylor wrote: Additional information: "ipconfig" on Windows, "ifconfig" on Linux, report the following IP addresses: Computer A:172.16.28.67 Computer B(1): 172.16.28.69 Computer B(2): 192.168.10.13 Computer C(1): 172.16.28.31 Computer C(2): 192.168.10.12 This works fine (but of course, still sends the heavy multicast traffic through the hub). If I remove this routing instruction and instead enter # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth1 Connections to the Hub are assigned dynamic IP addresses; I assume these addresses are in the 192.168.1.x range? No, see above. I was probably wrong to call them dynamic IP addresses. They are assigned by DHCP, but I believe they are always the same. I assigned hard-coded addresses 192.168.10.12 and 192.168.10.13 for the direct inter-machine connection between B and C. I see. These are likely dynamic, but assigned from the ISP IP pool based on the MAC address of the NIC requesting the IP. In a lot of cases, though they are dynamic, they hardly ever change as long as the MAC address of the NIC remains the same. Many cable ISPs do something similar on dynamic IP addresses. Though in your case, the actual Internet IP assigned is unimportant, as long as you get one assigned :) The addresses in the 172.16.0.0 are private addresses as are the 192.168.0.0 addresses. Why did you use a mask of 224.0.0.0 instead of 240.0.0.0 in your multicast route statement on the Linux box? (Your: # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth1 statement.) http://ldp.dsmirror.nl/HOWTO/Multicast-HOWTO-3.html What is in /etc/network-scripts/eth(x).route? Have you considered replacing the hub with a 100 Mbps full-duplex Ethernet switch? There are many advantages in this over a hub. Yes. That was my first attempt at a solution. I tried replacing the 10 Mb/s hub with a 10/100 Mb/s switch. The result was the same: when Computer C was multicasting 16-bit Linrad data at about 0.77 MB/s, Computer A was essentially unable to use the internet. The switch apparently did not prevent multicast traffic from reaching A. This was with a "D-Link 10/100 Desktop Ethernet Switch. I also tried it with a Linksys model EZXS55W "EtherFast 10/100 5-port Workgroup Switch." Same result. I then tried using both the hub and the switch: ADSL 10 Mb/s --> Computer A DSL --> Modem --> Ethernet Hub --> Ethernet --> Computer_B Switch | --> Computer_C Again, no change. This time I checked and confirmed that packets were arriving at A at the correct rate for them to be the multicast packets from C. Unfortunately neither of the switches you tested with had the horsepower (i.e. were managed switches) to control the multicast traffic, though they will segment the unicast traffic. A managed switch (capable of IGMP snooping) would handle the multicast traffic also and eliminate the swamping of machine A. Do you know if your ADSL modem is doing routing? I would guess it is, and likely is ignoring the multicast traffic as it probably can't (and shouldn't) route it to the Internet at large, but I'd check this to make sure. (It's likely OK, though.) I am curious about this because the IP addresses you have DHCP'd to your machines from the ADSL modem are in the private range. So there is network address translation going on somewhere. How configurable is that ADSL modem? I can use the 100 Mb/s direct line for many purposes. I can ping over it in either direction; I can ssh into Linux from Windows; I can use Cygwin/X (as described above) to display Linux X programs on the Windows screen. However, I cannot seem to persuade Windows 2000 Pro to accept multicast packets over the direct line. When I run Linrad on computer C and MAP65 on B, the multicast traffic is always received over the slow line, through the Hub. This uses most of the 10 Mb/s link's bandwidth, and my wife can't read her email when I'm on the air. This is NOT GOOD. Have you set the multicast boundaries on the W2K box? Do you have the Microsoft w2k Resource Kit installed on the W2k box? http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/intwork/inaf_mul_rmrd.mspx?mfr=true It sounds like the w2k box isn't routing the multicast traffic correctly to the direct interface, instead using the interface to the hub. Or am I misunderstanding in that the direct interface is never used for multicast traffic when 2 interfaces are connected to a machine?reserved local If I unplug the crossover cable from the Windows machine and instead plug it into a laptop running Win/XP, the laptop receives the multicast packets without a problem. But in this case there is but one network interface, only the direct interface, right? And is the Linux box then routing Internet traffic over this direct interface also to the XP mach
