On Wednesday 22 June 2005 21:45, John Gilmore wrote: > Copper GigE is sufficiently cheap and ubiquitous that a DAC/ADC board > should use it. But for the people who want to mount the whole thing > on a tower and run a nonconducting fiber back to their processing > shack, a converter from copper GigE to fiber GigE is small, low power, > and only costs a few hundred dollars.
Put a GBIC slot on the card; best of both worlds. Then you can do short haul multimode SX as well as longwave longhaul (1000Base-LX/LH depending upon the laser can go 40km). And you can get copper GBIC's for UTP runs. Now, there are a few things about the Ethernet interface possibilities that I've not seen addressed. Let's first drop the assumption that a point-to-point ethernet would be the only way such a device would be used; I know for a fact that people would try to use them on a switched network. The next assumption that would need to be dropped is that only one PC could send a packet to the board; in fact, it would be highly desireable for the board to support multiple hosts. After all, it's ethernet, right? So, my first concern would be triple-A (Authentication, Authorization, and Accounting); if we have a transmitter that is ethernet attached we really must make sure that the only signals that are transmitted are authorized to be transmitted. So a 'login' procedure to the board would be required. We can't really lock out to only allow a single client access at any given time (I know that an ethernet-connected SDR here would be needed to be used by multiple client machines; I'd love to attach one machine per input channel to spread the load when needed). So at that point you need an embedded controller with a little more intelligence than the FX2 has; something like an Xscale or StrongARM would be powerful enough to handle, say, an embedded Linux that could handle this. Why rewrite a working TCP/IP implementation when there's a good one already that is getting lots of eyes; uCLinux is quite mature on ARM or MIPS (ARM being the core of things like the Linksys WRV54G (VPN wireless router), and MIPS being at the core of the WRT54G, both of which use Linux). Then, depending upon the data being carried by the interface, you might want the stream to be encrypted; IPsec or SSL (SSH) would be useful. If you have a Linux running on an ARM9 controlling things, you can run a radius server, syslog, etc, on the board to get the pieces of AAA that you need. Intel has network processors that can do this in hardware; unfortunately the library to use the hardware encryption engine is not open source. Support for something like Kerberos would be nice, since that interface is very well defined and works very well. Then I could theoretically have eight clients connected at once; one for each ADC and one for each DAC (not counting auxiliary). The LabJack UE9, for instance, allows multiple machines to query the box, but doesn't do AAA, which, in a control situation on a switched ethernet, is very bad. There are significant non-bandwidth issues to using ethernet, and multiuser operation is one of them. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
