discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Trying to use the complex int16 option of the UHD blo


From: Nazmul Islam
Subject: [Discuss-gnuradio] Trying to use the complex int16 option of the UHD blocks
Date: Sun, 22 Jul 2012 16:14:49 -0400

Hello,

 I am trying to use the complex int16 option of the UHD (source/sink) blocks in my GRC generated python codes. I am doing wide band spectral analysis in my experiments. Therefore, 50 MS/s will be very helpful for me.

I currently have a working transmitter and receiver that use the complex float32 option of the UHD blocks. I am getting 25 MS/s rate at this point. The images of the transmitter and the receiver flow graphs are attached as "Original_Float_32_transmitter.png" and "Original_Float_32_receiver.png". I used the "Reconstructed_int16_transmitter.png" and "Reconstructed_int16_receiver.png" as the new transmitter and the receiver with the complex int16 option. However, I am finding difficulty to connect the signal processing blocks with the UHD (complex int16) block at this point. I have the following issues:

1. In my original transmitter flow-graph, the real part of the complex input to UHD is coming from a GLFSR->RRC float source. The imaginary part is coming from a null source. I don't see any int option in the RRC block and an int->complex block in GRC. Therefore, I am not sure how I can transmit GLFSR as the real part & null as the imaginary part with the Complex Int16 option.

2. In my original receiver, the complex float32 output is going through a polyphase clock synchronizer that provides a complex -> complex conversion. However, when I use complex int16 in the transmitter, I have to use float->float in polyphase clock sync to ensure type matching in GRC window. Firstly, I don't know if the polyphase synchronization is working on the real & imaginary part in the desired manner at this point. Secondly, when I run this receiver, I get the following error:

TypeError: pfb_clock_sync_fff() takes at most 6 arguments (7 given)


Overall, I want to use the complex int16 option in my original transmitter + receiver flow graph so that I can achieve 50 MS/s rate. Any suggestion will be appreciated.


Thanks,

Nazmul





--
Muhammad Nazmul Islam

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.

Attachment: Original_Float32_transmitter.png
Description: PNG image

Attachment: Original_float32_receiver.png
Description: PNG image

Attachment: Reconstructed_int16_transmitter.png
Description: PNG image

Attachment: Reconstructed_int16_receiver.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]