Re: [Discuss-gnuradio] I&Q on same or separate channels?
Brian Padalino wrote: Looking at the flow, each channel has a fifo1kx16 each, which you are presumably going to make a fifo512x32? I have a feeling you're going to have to modify your packet_builder as well. The packet_builder looks at the channel FIFOs sequentially and builds a packet based on that FIFO. You need to add a state or some extra logic in the FORWARD state that will FORWARD_I then FORWARD_Q from the input chan_fifodata. That seems to be the only place where it's used, so if you make your interface 32 bits instead of 16, and make the change to the FSM, you should be interleaving happily. Good luck with your modification. Taking a look at how the legacy code does it... http://gnuradio.org/trac/browser/gnuradio/branches/developers/gnychis/inband/usrp/fpga/sdr_lib/rx_buffer.v#L137 What do you think about adopting this method? It's using a 16-bit wide FIFO still and just alternating between which channel it is feeding in to the FIFO using a channel counter (store_next). In our case, we would just alternate between channel 0 and channel 1 to have 1 full data channel, for now. Unless there is something different in our case that I'm unaware of. This would prevent us from having to change the megacells and re-write some of the other state machines. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PROBLEMS: INSTALLING GNU Radio
Jonas Gacrama wrote: > I have this persistent problem when installing GNU Radio on my computer. > Below is my computer's description and the nature of the problem. You need to remove the space in 'GNU RADIO'. In general, you'll find that using spaces in file and directory names, while technically allowed, is best avoided. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] I&Q on same or separate channels?
This leads again to my question some time ago about how the USB data stream is organized. With the partial answer from that thread my understanding boils down to the following: Our questions are on completely different waveforms :P I'm talking about way before the FX2. However the last postulate gives me some headache. How do we make sure that the user process always fetches 512 byte blocks. The user application does not worry about this, the lower level interface that Eric has written to the USRP worries about this. If you take a look at some of the code in usrp/host/lib/legacy, it is ensuring that all reads are 512 bytes else it will print an error and return -1, not performing the read. Can a crashing user process manage to read less then 512 bytes? Of course, but when the process is restarted the buffers reset in the USRP and FX2. What if a rogue process reads less then 512 bytes. The low level USRP USB drivers will fail the read. If the user process gets out of sync with the 512 bytes for some reason, is there any way to resynchronize? The user process can "miss" 512-bytes if it's not reading the data fast enough and the buffers become full... this is an overrun. The error will be reported to the host and the host has to live with it and move on with life. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Frontend Hardware which is not USRP
Thanks for the reply ,
The connection of the hardware( lets say hw) with the radio is as usrp does.
Received samples are sent from the FPGA via the FX2 over endpoint 6 using USB
bulk transfers. Endpoint 2 is not yet used since we are testing the receiver
only. The A/D or VCO are configured by the FPGA(Spartan-3E-500) for the 2402
MHz channel @ 48 MHz sampling. The decimation is 12x so the data from EP6 is 4
Ms/sec, each sample is 16 bit I and 16 bit Q as with the USRP. ad9863, fx2lp
are used in the hw.
My question is whether i can use the gnuradio with some simple modifications
like the vendor id,device id and prodcut id for the hw, seen by the gnuradio as
usrp.
Best ,
Fasika
Eric Blossom <[EMAIL PROTECTED]> wrote: On Thu, Dec 13, 2007 at 12:48:24AM
-0800, Fasika Alemayehu wrote:
> Thanks for the reply ,
>
> The receiver front end is similar with the usrp. The data transfer
> to and from the hardware using the usb endpoints is similar with
> that of the usrp that you mentioned. But the problem is when i tried
> to contact the hardware , the response is that there is "failed to
> find usrp[0]". The product id and the vendor id of the usrp and our
> hardware are different. How can I solve this problem ? I read on the
> forum that I should add the device and vendor id to the list in
> usrp_ids.h and get the usrp developers to acknowledge it.
>
> Best ,
> Fasika
Unless you device is identical to the USRP and uses exactly the same
FX2 code and FPGA RBF's, you'll probably have to do some work.
Have you looked at the source code for the host side of the interface
to the USRP? usrp/host/lib/legacy/*.{h,cc}
Do you have a specific question? "How do I get my new hardware that's
sort of like a usrp to work with gnuradio" is a bit open ended.
Eric
-
Looking for last minute shopping deals? Find them fast with Yahoo! Search.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] PROBLEMS: INSTALLING GNU Radio
I have this persistent problem when installing GNU Radio on my computer. Below is my computer's description and the nature of the problem. NATURE OF MY PC: Linux jpgacrama-laptop 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux I'm currently using Ubuntu Gutsy (7.10) as my Operating System PROBLEM: This happens when I "make" the program /bin/sed: can't read RADIO/gnuradio-3.1.1/gnuradio-core/src/lib/libgnuradio- core.la: No such file or directory libtool: link: `RADIO/gnuradio-3.1.1/gnuradio-core/src/lib/libgnuradio- core.la' is not a valid libtool archive make[6]: *** [_gnuradio_swig_py_runtime.la] Error 1 make[6]: Leaving directory `/home/jpgacrama/INSTALLERS/GNU RADIO/gnuradio- 3.1.1/gnuradio-core/src/lib/swig' make[5]: *** [all] Error 2 make[5]: Leaving directory `/home/jpgacrama/INSTALLERS/GNU RADIO/gnuradio- 3.1.1/gnuradio-core/src/lib/swig' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/jpgacrama/INSTALLERS/GNU RADIO/gnuradio- 3.1.1/gnuradio-core/src/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/jpgacrama/INSTALLERS/GNU RADIO/gnuradio- 3.1.1/gnuradio-core/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jpgacrama/INSTALLERS/GNU RADIO/gnuradio- 3.1.1/gnuradio-core' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jpgacrama/INSTALLERS/GNU RADIO/gnuradio- 3.1.1' make: *** [all] Error 2 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] I&Q on same or separate channels?
> "Eric" == Eric Blossom <[EMAIL PROTECTED]> writes: Eric> On Thu, Dec 13, 2007 at 04:35:51PM -0500, George Nychis wrote: ... Eric> I and Q are not on separate channels. They are interleaved, I0, Eric> Q0, I1, Q1... This leads again to my question some time ago about how the USB data stream is organized. With the partial answer from that thread my understanding boils down to the following: - The FX2 has blocks/fifos of 512 bytes - We can put a data stream of interleaved sample in the fifo, but the data must form blocks of 512 bytes - If the fifo is full for some reason, the FX2 will block on a 512 byte boundary - If the FPGA detects a FIFO stall, the FPGA must restart with DATA0 of the datablock - On the PC side, the kernel always always receives 512 byte blocks - If the user process always reads 512 blocks we never get out of sync However the last postulate gives me some headache. How do we make sure that the user process always fetches 512 byte blocks. Can a crashing user process manage to read less then 512 bytes? What if a rogue process reads less then 512 bytes. If the user process gets out of sync with the 512 bytes for some reason, is there any way to resynchronize? Uwe -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
