Eric Blossom on GNU Radio 56
1) Hardware requirements
by wowbagger
The GNU radio page is a little thin on the hardware requirements to run
the code - could you spell them out?
I realize this might be complex, and that the answer might be of the form:
"to demodulate a 16QAM signal at 115.2kBaud, you would need an XYZ
digitizer card reading the 455 kHz IF and a AAA GHz Athlon CPU. To
recover standard multplex FM, you would need a 123 digitizer reading the
455 kHz IF and a BBB GHz Athlon. To decode GSM you need a FFF digitizer
reading the 10.7 MHz IF and a quad Athlon."
But as both a ham and one who designs SDRs, I'd like to know where this
resides on the Home Hacking Scale....
Eric: There are two basic paths down the software radio path. One I'll call
"narrow band", and this corresponds to most of what you're seeing sold
as "DSP enhanced" transceivers. The TAPR DSP-10 kit would fall in
this category. In effect, these are conventional radios which are down converting to baseband, or near baseband, and have an IF bandwidth in the 20 kHz range.
For narrow band work with GNU Radio, you'll need some kind of RF
tuner/transverter. Someone pointed out that in one of the latest
issues of QEX magazine there's an article about a kit that is designed
to be the RF front end for a software radio that connects to a sound
card. I haven't seen the article so I can't comment. The TAPR DSP-10
would also work. Just leave out the Analog Devices DSP and plug the
kit into your sound card. You could wiggle the control lines using
the parallel port.
To summarize, for narrow band software radio work, you'll need your
sound card and some kind of RF front end. Pretty much any
contemporary Pentium/Athlon machine will have plenty of horsepower.
The other path I'll call "wide band". This is personally the area
that I find most interesting because it is with wide band that you are
able to do things that you can't do with a conventional radio. Chief
among these is the ability to concurrently receive (or transmit)
multiple channels/stations/frequencies. In the examples directory of
the GNU Radio code, you'll find an example that receives and
demodulates 2 FM broadcast stations and puts one out the left channel
and one out the right. Matt Ettus, another GNU Radio developer, has
built a demo that receives 4 narrow band FM channels concurrently.
These demos run fine on a 1800+ Athlon, or 1.7 GHz P4.
For the wide band stuff our "standard configuration" is a TV tuner
module designed for cable modems that tunes from 50MHz to 890MHz with
an IF of 5.75 MHz. The module is a Microtune 4937 DI5. We connect
the output of the tuner directly to a 20M sample/second 12-bit A/D
converter. The converter we're using is the Measurement Computing PCI
DAS4020/12. It'll do 4 channels at 10M sample/sec or 2 channels at
20M sample/second. From the hobbyist's point of view, it's not cheap,
about $1300, but it is the cheapest, fastest off the shelf solution
that we found.
With our "standard configuration" we ought to be able to handle
IS-136. GSM would be possible if our RF front end would cover the
1.9 GHz range. Vanu, Inc has a GSM receiver running on a 1GHz pentium
laptop, so we know it's possible.
2) Re:Hardware requirements
by d.valued
Tangential to this.. is there any talk amongst the GNU Radio folks on
building a piece of hardware that complements this software project, or
is supposed to work with whatever devices the user has on hand/will build?
Eric: This question comes up frequently. Mostly we've got our hands full
with the software and are hoping that some other folks will chip in
on the hardware. From our software point of view, we'll talk to any
hardware that you can provide a driver for. Fundamentally all we need
is a way to get samples into and out of memory.
We do have some ideas about our ideal hardware. See ettus.com/sdr/.
The key items are:
- 14-bit A/D converter 40-100 Msamples/sec (e.g., AD6645 or AD9244)
- 14-bit D/A converter 40-100 Msamples/sec
- FPGA (digital downconverter / upconverter / bus interface)
- some kind of bus interface, either 64-bit PCI or USB-2
There are also a few threads in the mailing list archives about ideal hardware.
3) Sounds familiar
by FreshMeat-BWG
As in WinModems doing the modulation/demodulation. These devices were a nightmare. After trying several I went back to a good old hardware-based-modulation modem.
Are there parallels to this technology? and if so, how will GNU Radio avoid those pitfalls?
Eric: Part of the problem with WinModems is the "Win" part of the equation. Modems place pretty substantial hard real time demands on the OS. It's not necessarily the total amount of CPU that's a problem. It's that it the code needs to be run on time or it's no good at all.
So far most of our work has been receive only, and we dodge the bullet by using the Measurement Computing A/D card which combined with the driver I wrote DMAs directly into user space. Given say, 16 MB of buffer, you can cover all sorts of non-real time problems. The driver is written so that it only needs service about once every 10ms, no problem on today's hardware, and will sustain 80 MB / second across the PCI bus.
When we attempt a TDMA transceiver, we may need hardware that will support time stamps so that we can synchronize our input and output streams. See above for ideal hardware with FPGA.
4) What external hardware?
by Consul
I read through the GNU Radio website, and even though I found it informative in terms of the basic idea and examples, I couldn't find anything relating to what extra hardware is needed. (Maybe I just didn't look long enough?)
What extra hardware is needed in addition to a computer? Are we talking DSP chips and boards, or something a little more exotic?
Thank you for a potentially exciting project, though. This makes me want to renew my ham radio license.:o)
Eric: See above. No DSP chips or boards. Today's commodity PC hardware kicks ass on just about all DSPs as long as you're not worried about power consumption. You'll need some kind of RF to IF transverter and A/D & D/A converters (either a sound card, or something with more bandwidth, depending on your interest and budget.)
5) Describe your dream hardware for a software radio
by geirt
I want a feature list containing all the geeky details:
Frequency range.
Eric: 30 MHz up to about 2.5 GHz.
Coverage in the 5 GHz unlicensed band would be nice too.
Bandwidth (do you want to sample the whole FM band (or GSM/GPS/CB/ham bands), or just a single channel/station).
Eric: Whole swaths of the RF spectrum!
12.5 MHz would be nice.
Sample frequency and depth (ie, fast and few bits, and do decimation in software or slow and many bits with less CPU overhead)
Eric: For 12.5 MHz we'll need about 31M samples/sec, call it 40M samples/sec. 14-bits. More is better.
Necessary spurious free dynamic range, or some other dynamic range specification.
Eric: More is better. The best part I know of is the AD6645, and they're claiming 100 dB multitone SFDR.
Interface to the PC (PCI, firewire, USB...).
Eric: 64-bit PCI would work, but it's a lousy interface for a laptop. Maybe USB-2. Firewire would be OK, but I think it's got more hair on both ends. We've also thought about Gig ethernet.
Antenna connector (OK, I know that one: BNC)
Eric: BNC.
6) Convergence Devices
by Nomad7674
This technology sounds like the kind of thing which could greatly add to the convergence of devices that clutter the electronic life. You could extend convergence not only as a Smartphone but have in one device (though perhaps not simultaneously):
1. Cell phone
2. Computing power (PDA)
3. FRS radio device
4. 802.11x network device
5. Police scanner
6. Television reciever
7. etc.
Eric: I believe that convergence is ultimately where we're headed. We're a way off, mostly with respect to power consumption, but I believe that that will take care of itself eventually. The MIPS/Watt of programmable hardware is unlikely to beat that of dedicated ASICs, but ultimately, if my universal reconfigurable communication device runs all day on a single charge, who cares?
Have you been approached by police departments, FedEx, etc. to develop devices to allow their people to do more stuff in fewer packages?
Eric: We haven't. I can see a scenario where somebody else is building the hardware and we're providing the software.
7) As a college student, how do I get involved? by McCart42
If I'm interested in doing research in this field someday, and I'm currently a computer engineering major, what are some good electives that I might take? Aside from general programming necessities, what sort of signal processing courses are necessary to understand the underlying aspects of software-defined radio?
Eric::
- DSP fundamentals, filtering, FFT, freq-vs-time domain, etc.
- Basic RF might be useful; you don't need to be a specialist
- Digital comms. Builds on the DSP stuff, but adds specifics for communications. Coding theory, ideal receiver design, channel capacity, phase lock loops, etc.
- Anything about protocols in general. Once you get up above the raw bits, software radios don't look that much different than any other layered communication protocol.
8) FCC vs. Software Radio
by minddog
I was recently at H2K2 and heard this forum which right away made me ecstatic(sp?). An issue that was brought up was how this can impact the DMCA, FCC, and the big corps. You guys were saying Sony, and the other conglomerates were forming a committee that would do a digital signature to say what was allowed to be copied, and not through a dual channel checking...My question is what is the status of digital radio and its rights in the present world? To my understanding you can have a very high number of digital channels inside a single band which makes licensed analog frequencies just a waste of money to corporations if they use GNURadio as a means to transmit data long distances. Anyways, looking forward to some feedback and goodwork, I'll be joining this revolution soon, just got the dual server built;)
Eric: Here are three subtopics under the "FCC vs Software Radio" flag:
(1) General prohibition on receiving certain signals
The FCC, throwing a bone to cell phone operators, banned the reception of certain frequency bands used by cellular phones. In addition, the Electronic Communication Privacy Act (ECPA) expanded the ban to include other communications such as pagers. These provisions have been called by others "The Foreign Intelligence Empowerment Act". That is, they ban the interception of signals that are trivially interceptable, as if making it illegal would "keep the customers safe". In fact, this same sham extends into the world of digital cellular, where the signals are still effectively in the clear, and are vulnerable to eavesdropping.
Free software has no problem complying with such regulations as the code below illustrates:
#ifdef IM_IN_THE_USA
if (freq >= 825e6 && freq throw "Forbidden Frequency";
#endif
(2) ATSC Digital TV "Broadcast Flag" MPAA/CPTWG/BPDG
Alphabet soup:
ATSC: Advanced Television Standards Committee (digital broadcast TV)
MPAA: Motion Picture Association of America (Disney, Fox, et al)
CPTWG: Copy Protection Technology Working Group (www.cptwg.org)
BPDG: Broadcast Protection Discussion Group.
Short form: Certain content providers (MPAA) want TV broadcasters to set a bit, called the "Broadcast Flag", in the MPEG transport stream that TV stations are broadcasting in the clear (i.e., no crypto). The flag is intended to mean "Don't copy me". The MPAA/CPTWG/BPDG folks are then trying to convince the consumer electronics manufacturers that it is in their best interest to build crippled devices that honor the bit, and finally, since it's not obvious than any consumer would buy such a damaged device, they want to ban non-compliant receivers.
After conversations with MPAA/CPTWG/BPDG, we have been unable to find any solution where open source or free software can comply with their proposed "Robustness Requirements". Hence, open source and free software implementations of ATSC receivers, VSB demodulators and VSB modulators would be banned under their proposals. Several fundamental issues are at stake: freedom of choice, freedom to innovate, and software as protected first amendment speech.
The FCC has issued a "Notice of Proposed Rule Making" about the Broadcast Flag. In addition, it is rumored that a bill is being drafted in case the FCC won't play along.
The EFF has a wonderful blog covering this topic in detail.
(3) SDR upgrades and FCC
Recognizing the importance of SDR, the FCC, in its First Report and Order dated September 14, 2001, created a new class of equipment and associated authorization procedures. In its Report the Commission stated, "We anticipate that software defined radio technology will allow manufacturers to develop reconfigurable transmitters or transceivers that can be multi-service, multi-standard and multi-band." Continuing, the FCC stated, "These changes will facilitate the deployment and use of this promising new technology, which we believe will facilitate more efficient use of the spectrum."
From the free software point of view, what remains to be seen is what kind of "authorization procedures" will be approved. What is envisioned is some kind of digitally signed configuration or executable that can be loaded into the existing hardware. In an free software/hardware world with no clear administrative hierarchy, it's not evident who gets to say what signatures the hardware will accept. This looks like a ruling that "software radio is OK for the incumbents", but doesn't really spell out what the situation is for the free software / open source / open spectrum point of view.
9) Re:Interference
by Louis_Wu
"This is one project where hacking the code can kill people or land you in jail. Don't broadcast on the wrong frequency! Keep this away from radio telescopes!"
Eric: OK.
That brings up a good question. Are there going to be some software restrictions on which frequencies you can use? Would those restrictions be in the source or options you can change on the fly?
Eric: Ultimately the frequency range that can be transmitted depends on the RF hardware, not the software. The vast majority (all?) of the code in a software radio has no idea of the final RF frequency. It's doing its processing at some IF frequency, which is ultimately up converted once the samples leave the CPU.
It seems like a good idea to put at least one barrier between users and transmitting on police frequencies. But what kind of barrier? Should any restrictions prevent listening as well? What about military transmissions? Or air traffic control frequencies? Or the band the Secret Service uses?
Eric: In general, my philosophy is that if people don't want their communications listened to they should encrypt them. This has been standard practice for thousands of years (see Kahn, "The Codebreakers").
I agree the that hardware should be designed such that accidents are minimized. One possible route for hobbyists would be to design the RF hardware such that it would only transmit on one of the unlicensed bands. There are still requirements about transmitted power, and these requirements vary depending on the band and the modulation strategy, but that would at least reduce the chances of accidental interference.
Note however, if you're building a software radio that bridges between different public safety networks, you'd certainly want to be able to transmit.
Where should the line be drawn? What does the law say?
Eric: Do no evil? The law of what land?
For another perspective on "interference" and who "owns" spectrum, I heartily recommend the "Open Spectrum Resource Page".
10) Hardware patents?
by cornice
Up until now, free software has mostly threatened closed commercial software. GNU Radio, however, might make some hardware manufacturers squirm a bit. If I can use a generic device along with GNU Radio to emulate a range of devices how will this impact the makers of those devices and are you (or users of GNU Radio) possibly violating patents for some of those devices? It seems that GNU Radio will stir up more mud in the IP and DRM debates. What are your thoughts on this?
Eric: Since the hardware manufacturers make their money selling hardware, and we want to buy hardware I don't really see a problem. I'd just like them to build some nice, inexpensive, fully documented hardware on which I can run my free software.
Yes, we will be able to emulate a bunch of devices, and it might cause some heart burn for certain folks. For example, I don't generally want to be carrying around a GPS receiver, but in the moment that I want to know where I am, it would be handy for my universal communication device to configure itself as one and figure out where we are. I'm not sure of the patent specifics on that particular application, but I understand your point nevertheless.
I think the mud will be stirred far and wide. I think that this is a good thing. General purpose hardware keeps getting more useful and powerful, and hence valuable to the end user. At the same time, in certain situations, dedicated devices clearly win over the general purpose in areas of convenience, size and ease of use. I think this tension is good, and better products will emerge from it.
11) Plans for UWB
by wfrp01
Will GNU Radio support Ultra Wide Band? Soon, someday, never?
Great project. Thanks.
Eric: We currently don't support Ultra Wide Band. GNU Radio is a signal processing toolbox. If you had the appropriate UWB RF front end, you could use GNU Radio for the signal processing.
See aetherwire.com for background info on ultra-wideband technology.
Use GNU Radio for digital OGG broadcasts (Score:1, Interesting)
Ofcourse, after that, "Open TV" won't be far behind.
Re:Use GNU Radio for digital OGG broadcasts (Score:1)
One question remains. (Score:1)
Re:One question remains. (Score:2, Insightful)
GNU are a bunch of hypocrites (Score:2, Funny)
However, while the GNU wants everyone to call Linux by a new name to respect GNU's contributions, GNU themselves ignore the parts that make up their radio system.
- tar and unzip are required to get the source to the software.
- a digitizer is required to receive the signals, Eric Blossom keeps harping on about a kit from TAPR
- Marconi invented radio waves.
- Lots of components are also used in the interfaces and a CPU is used to run the software.
- Audio is used.
- Windows are used to display the app.
Therefore I recommend GNU Radio be renamed to:GNU/tar/windows/audio/TAPR/CPU/unzip/Marconi
Or GNU/TwatCum for short.
It's only fair.
Re:GNU are a bunch of hypocrites (Score:2)
If you run a system that uses the Linux kernel, then almost certainly the tar that you run is GNU tar, developed mostly by John Gilmore, who at the time was so dedicated to the GNU project that he used "gnu" as his login.
And Marconi did not invent radio waves, you dork.
Marconi didn't invent radio waves or even discover (Score:2)
How will this benefit Joe and Mary User? (Score:2)
What's the purpose of a software radio? (Score:2, Insightful)
Re:What's the purpose of a software radio? (Score:2, Informative)
One practical problem is that instead of having multiple hardware for different uses (AM/FM, cell phone, GSP, police, weather, garage door opener, keyless entry, etc.) you could have a single device that could theoretically handle them all. And as new bands or methods were developed it could be updated by software to handle those also.
One device to rule them all.
And if you get into applications requiring multiple channel decoding, e.q. a cable set top box that could serve multiple TV channels, it might be cheaper than duplicating tuner hardware.
Military (Score:3, Interesting)
Re:What's the purpose of a software radio? (Score:1)
Bull.
Re:What's the purpose of a software radio? (Score:1)
Some thoughts (Score:5, Informative)
802.11 and other stuff as my real job.
Software defined radio is a big research topic in the commerical RF world. There are currently two big problems that people are trying
to overcome. The first is the ADC requirements and the second is the MIPs requirements for any two way system are really beyond the ability of most current general purpose technolgy. It will get
there but not yet.
I want to add my own thoughts to the questions and answers people asked. They are meant to point out how much work there is to do, and also some
of the legal implications of trying to do them.
1) Hardware requirements
For GSM you will need about 13800ks/s if all the channel filtering is implemented in the radio. If not, reckon on about 16bits and 13MHz.
3) Winmodems etc.
Eric raises a hugly important point about the real time nature of many RF systems. For example, 802.11a requires that turn around time on ACKing packets is in the order of a few micro-seconds. This includes decoding that packet and generating the reply. It is hard enough to do this in custom hardware, and CPU interrupt latencies are just too
high. Many 802.11a chipsets use two ARMs to meet these timing requirements, one running real-time code the other dealing with the protocol.
Oh yeah, a protocol stack for GSM is usually larger than a Linux/FreeBSD kernel in terms of lines of code...
BTW, if you hunt around the net, you can find the signal processing for GSM available as a matlab library. It includes all the vocoders and channel coding and viterbi's.
9) Interference etc.
Eric seems to not have much experience of type approval testing for devices such as cell phones. There is no way it will be legal to develop your own GSM cell phone on a PC and use it in Europe for example.
Every GSM handset must be type approved before it is allowed to be used on a network. This costs a good few kbucks. You must be licensed to transmit in the bands etc.
On the hardware side you have issues like the fact that it takes lots of RF design experience to build a circuit that meets the spurious
emissions requirements, and standard PC hardware will not meet some of the basic timing requirements of 0.5ppm tracking to the BTS and that you must use the same crystal for frequency generation and timing.
10) Patents
Most protocols are covered in patents. GSM is a minefield and every cell phone has royalities paid on them. Qualcomm are the patent owners for IS95.
11) UWB
UWB will need samples rates >10Gs/s to do digitally. At present the Rake receviers are implemented as part of the RF.
Some more thoughts (Score:2, Informative)
But this is baseband signal processing, done on PCs. For real time applications, you need DSP or FPGA. Texas has some "entry" or "student" packs with evaluation boards and Code Composer, but it's not cheap for a hobbyist, and there's a learning curve... (read: you have to debug a lot)
The not-so-nice aspect of software radio is the hardware part. Tx and Rx design for wideband communication systems is not easy and definitely not cheap. Some kit is available on the market (for example from Spectrum) as add-on boards, and antennas can be manufactured or bought.
While both reception and transmission would be nice to have, it is much easier to do the reception part, due to strict regulations for transmitters (as dmlb noted, it is something that can land you in jail very fast - or have a van from the local telco come by and do some measurements
Books on the topic (all with shortcomings, none with magic bullet solutions):
H. Harada, R. Prasad "simulation and software radio for mobile communications" (CD included), Artech House, London, UK, 2002.
W.Tutlebee "software defined radio" Wiley, 2002.
J.H. Reed "software radio" Prentice Hall PTR, 2002.
J. Mitola III, "software radio architecture" Wiley, 2000.
All in all, this is a great hacking project. A collection box for the $10000 needed for the RF and DSP baseband processing should be set up!
Electrical engineer (Score:3, Interesting)
CS's make software for hardware that doesn't really exist yet, but we're supposed to figure it out and also make it cheap.
Seems like this is project that should have started from the hardware end. What if the hardware required is never developed? Then all of their work is useless.
Re:Electrical engineer (Score:2)
There are issues- interference could be an issue, but I suspect that some filters will mostly solve the issues.
I actually think it isn't ambitious enough! He should be working on two-way comms. A software radio with beam-forming is going to be needed in the next few years; there's some theorems that if you do directional antennas, power control, routing algorithms and you can handle multiple frequencies, then the network capacity scales basically proportional to the number of users on the network. i.e. more users doesn't slow the network.
I donno if anyone mentioned about similar project (Score:2, Informative)
ECPA (Score:4, Interesting)
One of the recent modifications to 47CFR15 (FCC part 15 regulations on receiver coverage among other things) concerns making receivers difficult to modify so that they can't receive cellular telephone calls. Specifically see part 15.23, and part 15.121. [gpo.gov]
I don't know how you can call a snippet of code like this a reasonable prevention.
Please don't misunderstand me, I think these regulations are utter balderdash. Unfortunately, I see no reason to think those regulations are unconstitutional, despite the stunning ignorance and stupidity behind them. I don't understand how Eric and company can work on a project of this sort without violating these regulations and thus I don't see how the GNU copyleft can remain in force.
Doesn't anyone see a conflict here? And if not, why?
Re:ECPA (Score:1)
Besides that, when does the government ever got the policies right for the first time?
I'm sure the software radio is going to give some sleepless nights for the FCC and the concerned parties (like cell phone operators)
Re:ECPA (Score:1)
Is it fashionable in government to craft legislation that contradicts 60 years of common sense and technological policy?
How about The Communications Act of 1934? That was the act which created the Federal Communications Commission. It also defined policies which are widely respected today, such as "Radio Secrecy" (not the "Radio Privacy" foolishness you find in the ECPA).
I have very little patience with legislators who craft laws with no basis in common sense, practicality, past policy, or even future trends.
Courts profess that "ignorance is no excuse for the law." Well, in the case of legislators: "Ignorance is no excuse for an impractical or poorly crafted law." If we are to continue building an honorable and productive society, the law needs to make sense, be enforcable, and it needs to respect everyone's rights. Clearly the ECPA fails that smell test on all counts. The DMCA is yet another that fails the smell test.
I don't stand for this kind of treatment from my government and neither should anyone else.
Re:ECPA (Score:2)
If source code is speech (as several courts have ruled), then it's difficult to see how the distribution of the code could be banned. Operation of the code on hardware capable of RF input or output could be banned, as there's no constitutional right to do that.
it looks like this... (Score:1)
Santa, we want one. Obviously, to test some nice sofware on it.
Think about RTP (Score:1)
Consider defining a general-purpose RTP
packetization for IF radio, and running
through the IETF. This would let hardware
folks innovate to a known stack: Gig
etherframes, UDP, RTP w/ your packetization.
You could also spec out a SIP framework,
so the hardware can start up its own sessions.
Re:Think about RTP (Score:2)
It would be nice to not have to do arp or deal with any real buffering, but just build the frame as you go, and stuff the CRC at the end. Send the frame as a broadcast packet. Maybe you could have two single-frame buffers, and fill one while you send the other, etc.
If you can keep the hardware design job really simple, maybe the cost of the ADC and transport cold be kept reasonable. I am thinking, one PLD or FPGA, one or two SRAM's if necessary, one ADC, and one gig-e PHY device. I am thinking that in very small quantities, this could be done for a few hundred dollars in chip costs. Boards, as always, will be a problem.
Actually, I might be willing to work on this. It sounds like fun.
MM
--
Re:Think about RTP (Score:1)
> deal with any real buffering, but just build
> the frame as you go, and stuff
> the CRC at the end. Send the frame as
> a broadcast packet.
I was thinking about going one (very thin)
layer up -- and really making UDP IP packets,
unicast or multicast, in those GB Etherframes,
and have those UDP packets use RTP. This way,
IF radio becomes "just another RTP media type",
along with all the audio and video codecs. If
you define the RTP packetization the right way,
all sorts of radio hardware and applications
could conform to it. Yes, it would be the most
bandwidth-intensive RTP packetization to date,
however, the SMPTE HDTV uncompressed packetization
that's underway in AVT now is moving a fair
number of bits, so 12-bit quantization of a
20Mhz IF is not too far out of the mainstream.
Re:Think about RTP (Score:2)
What is RTP?
As a first step, the UDP packets could be totally hard-wired. That is the source and destination MAC ID's could be stored in a configuration rom, as could all the IP's. This would allow the whole thing to work without ARP. I am trying to stick to total one-way communication and avoid having do an actual TCP/IP stack.
I don't know enough about TCP/IP to do even a minimal implementation in an FPGA. If I need the whole stack I'll have to go to an embedded processor running linux or uClinux or something. For now I want to avoid that.
In the long run, someone (possibly me) could do a standards compliant FPGA, that could at least do ARP, and maybe deal with some ICMP messages if that is required by whatever standards apply.
It is always nice to be able to ping devices on a LAN.
I have basically decided to actually do this. I'll do some mail-list searching and lurking for a bit and then probably make contact with the SDR guys.
MM
--
RTP = Real Time Protocol (Score:1)
media streams (video, audio, etc) get
sent around UDP networks in the IETF
view of the world. See:
http://www.ietf.org/html.charters/avt-charter.htm
RTP scales upwards OK in bandwidth --
there are uncompressed SMPTE packetizations
for HDTV in progress, which is a fair number
of bits moving through the pipe. The
advantage of designing to RTP (as an industry,
if not for your current prototype project) is
that an IF stream is a media stream, and so
a lot of the associated tools RTP offers are
a perfect fit (session management tools,
security tools, etc). So, the standards
writing job in minimized to just the basics
needed to describe the radio-specific stuff.