Comment Some thoughts (Score 5, Informative) 56
First off, I'll just mention that for the past seven years I've been designing RF chips for a variety of systems such as GSM, Bluetooth,
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.
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.
