Re: [Discuss-gnuradio] Run USRP at alternate clock frequency?

[Martin Dvh]

Lee Patton wrote:
>>>Reran my custom dbs program and it worked fine EXCEPT:
>>>The default decimation is 4 so I'm recording at 11 megasamples per 
>>>second. (oddly enough I'm still able to demodulate my 802.11b packets 
>>>fine even though the chip rate is 11 mcps!?) When I try a decimation 
>>>rate of 2 I get the message:
>>
>>Will you be sharing this code?
>>I think more people will be interested in doing 802.11b.
> 
> 
> Count me as interested!
> 
> 
>>>If necessary I will go modify that fpga to just have a halfband so I can 
>>>record at 22 complex megasamples per second which is enough bandwidth to 
>>>support 802.11a/g. Can't beat more bandwidth at less power.:)
>>
>>It will be interesting to see if you will be able to get complex 8 bit 
>>samples over the bus with decimation 2.
>>This will be 44 Mbyte/sec over the usb bus. This is within the theoretical 
>>limits of usb2 but until now I have not heard of anybody being able to 
>>sustain more 
>>then 32 Mbyte/sec over the bus using the usrp.
> 
> 
> Martin, you gave us the -8 option did you not? How about a -6 option so
> we can squeeze the data over the bus?  Think SNR will be degraded too
> much in that case?
I would like to implement the whole 1 to 16 bit range.

This is however not that easy.
4 bits might be doable using a similar trick I am using now for 8 bits.
(Just squeeze 4 sample in the spot which is normally reserved for one)

Anything that is not a power of two would mean the whole way the samples are 
sent in the buffer and over the bus has to be changed.
For example, anything which has a factor 3 in it (like 3, 6, 12) wouldn't fill 
a 512 byte block completely with that.
You then need to send things in blocks with padding and compensate for that on 
the host-PC side.
You are in even more trouble if a block is dropped.

The best approuch for this would be to have a header on each 512 byte block 
which tells you how much samples are in there.
And as you are at it, it would also be a good idea to have a timecode or 
samplenumnber in there as well.
This would mean that you could keep time continuous even if you missed a block.
It would also make linking multiple usrps easier and would also allow odd 
decimation factors.
(Or even fractional decimation factors if you implement a resampler in the fpga)

When you work with packets which include a header and a timestamp it will also 
be easier to make control loops and such which span the
daughterboard, usrp and the host.

For example setting the DDC frequency or the gain from the host. The fpga could 
then set the samplenumber for the frequency change in the
block-header.

The host then knows exactly which samples correspond to which parameters.

This would make a 1000 channels per sec scanner feasable (with a wider freq 
range then 8 Mhz).

(I tried to implement a 1000 channels/sec scanner and found the unknown timelag 
for the freq settings forced me to lower the scanspeed very much.)

So changing the way samples are send over the bus is hard, but it could have 
many benefits.

Unfortunately I am very busy right now and have not much time to experiment 
with this.

I am still behind with integrating my LO-locked multi-usrp code with cvs.
(Which is also a thing which is nice to share with others)

But anybody who really wants this, verilog is not that hard. There are many 
manuals online.
When I wanted the 8 bit feature, I just opened the source and tried to grasp it.
This took me some time, but since then I hack the verilog code to my needs all 
the time.

I have even been working on implementing huffman compression in the fpga.
This would give us upto about a factor two datarate increase.
(Which would give us decimation=1 for 8 bit real samples)

Greetings,
Martin




> 
> Disclaimer: I know nothing about verilog/FPGA, and may have just asked a
> very stupid question. 8 bits sounds like a nice number, and 6 sounds
> less than convenient, but maybe it doesn't matter if it is truly a bit
> stream?
> 
> Cheers,
>  - Lee
> 
>