I'm just getting back to this after a few months (gotta love funding issues).
Brief recap on what I am trying to do: I am trying to perform some very non-conventional signal processing. To show that our basic approach is viable it is sufficient for us to perform the following tasks: 1) Generate a waveform that we want to transmit. This waveform has data encoded into it. Ideally, the data is just a list of numbers that we want to send to a DAC. We can prepare this well ahead of time. 2) Broadcast the waveform generated in the previous step. 3) Receive the waveform that was broadcast and record it as a time-sampled sequence of numbers that represent the outputs of an ADC. 4) Analyze the data and see if the information we embedded in the waveform is recoverable. This can be done completely off-line via post-processing. The only part that we need GNUradio and/or the USRP for is #2 and #3. -------------------------- Task #3: Previously, Eric recommended the following: > If you want to capture data from the front end and put it into a file, > the easiest way is to use gnuradio-examples/python/usrp/usrp_rx_cfile.py This looks very promising for taking care of Task #3. Playing around with it has generated a few questions: 1) What are the legal values of the decimation factor? I see a comment in the code that the minimum factor is 4 and that the default is 16. By experimentation I also observe that integer powers of two up to and including 256 are legal. What is the maximum decimation allowed? Other factors, such as 192, are permitted, but arbitrary values are not. Are there a certain number of most significant bits in the value that can be chosen? 2) What does the FREQ parameter do? It clearly doesn't set the sampling frequency - that appears to be a fixed 64 MSps divided by the decimation value. 3) I see that the -R option allows be to chose which subdevice on the USRP, but how do I choose (or know which one if I can't choose) which input on, say, the Basic-RX board is being used? BTW: I think the duplicated nomenclature is confusing. On the BasicRX daughterboard the two inputs are labeled RX-A and RX-B, so I thought that the -R option was referring to this selection and was wondering how you tell it which daughterboard to pull the signal from. It wasn't until I looked at an unpopulated USRP (since, with the four daughter boards mounted on the USRP, the RX-A and RX-B labels are hidden) and noticed that the daughterboard slots themselves use the same labels that I realized what the -R option is really referring to. 4) I see in the file that the data is stored (by default) as two single precision floating point numbers that represent a complex number. Clearly, then, this is not simply the output of the ADC. What is it? How do I (assuming I can) recover what the time-sequence of values coming out of the ADC were? 5) What are the input tolerances of the BasicRX daughterboard? I have a function generator that I want to use to send a signal into it, but want to be sure that I don't exceed the input range of the board? Also, what is the input impedance? Is it intended to be driven from a 50 ohm source? 6) Perhaps the most important question: Where do I find the answers to the above questions? These all seem like really basic questions about the details of the interface, but I haven't found anyplace that provides this information. -------------------------- As far as Task #2: 1) Is there any similar program in GNUradio that does the reverse of usrp_rx_cfile? Namely, takes a file of appropriately formatted time-sequence samples and broadcasts that waveform? One issue I know that I need to deal with is what it means to "broadcast" the waveform that was generated in Task #1. Ideally, at least from a conceptual standpoint, the waveform data would represent the actual output at the antenna so that (assuming 1-bit on-off encoding) the sequence 0010001010 would result in three very sharp chirps of energy being broadcast. Given the need for the USRP to perform up-conversion, I know that this level of control is not possible (not to mention the prohibitive bit rates that would be required). We can live with that, but we want to get as close to that as we can. -------------------------- Thanks! _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
