[USRP-users] B210 power saving

[Sylvain Munaut via USRP-users]

Hi,

Does anyone here have any tips to reduce the power of a B210 (both
when running and also when idle).

Deconfiguring the FPGA and FX2 when it does nothing does save a whole
lot of power but it takes a significant amount of time to go back to
running mode unfortunately.
Also seems the radio clock is left running at whatever frequency was
last used and so setting it to a very low value before exiting also
saves quite a bit of power when it's idle.

Any other tips ?

cheers,

Sylvain

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 witn TwinRX: master_clock_rate issue

[Devin Kelly via USRP-users]

So when i I try to set the master clock rate to 100 MHz directly I get an
error and when I don't set it I get a warning.

Can I just disregard the warning or is there something else going on here?

$ uhd_rx_cfile -r 10e6 -f 850e6 -g 10 -a
'args=192.168.40.2,master_clock_rate=100e6'
tmp.dat

[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36);
Boost_105300; UHD_3.12.0.heads-v3.12.0.0-0-gec786351
Traceback (most recent call last):
  File "/test/bin/bin/uhd_rx_cfile", line 263, in 
tb = rx_cfile_block(options, filename)
  File "/test/bin/bin/uhd_rx_cfile", line 77, in __init__
channels=self.channels,
  File "/test/bin/lib64/python2.7/site-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
return old_constructor(*args)
  File "/test/bin/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
line 2334, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError: RuntimeError: Invalid master clock rate: 100.00 MHz.
Valid master clock rates when using a 10.00 MHz reference clock are:
120 MHz, 184.32 MHz and 200 MHz.


$ uhd_rx_cfile -r 10e6 -f 850e6 -g 10 -a 'args=192.168.40.2'
tmp.dat

[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36);
Boost_105300; UHD_3.12.0.heads-v3.12.0.0-0-gec786351
[WARNING] [X300] Cannot update master clock rate! X300 Series does not
allow changing the clock rate during runtime.
[WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 200
MHz. Actual rate is: 100 MHz.
[WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 200
MHz. Actual rate is: 100 MHz.
^C


On Tue, May 14, 2019 at 3:08 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 05/14/2019 11:26 AM, Devin Kelly via USRP-users wrote:
>
> Does anyone have any ideas on this?  Is uhd_rx_cfile not the right tool to
> be using?
>
> Devin
>
> The TwinRX *MUST* run with a master clock of effectively 100MHz, because
> of the way the ADCs are shared, and the DDC structure in the
>   FPGA.  Further, the fixed analog filtering is designed for a 100MHz
> clock frequency, and the synthesizers on the board require a 100MHz
>   clock (AFAIR).
>
> Simply don't specify the master clock rate when using uhd_rx_cfile, and
> the correct default *should* happen.
>
>
>
>
> On Thu, May 9, 2019 at 10:39 AM Devin Kelly  wrote:
>
>>
>> Sorry to revive an old post but I'm having the same problem with UHD
>> 3.12.0.0.  Am I doing something wrong with uhd_rx_cfile or should I just
>> upgrade to a newer UHD?
>>
>> $ uhd_rx_cfile -r 10e6 -f 850e6 -a
>> 'args=192.168.40.2,master_clock_rate=200e6' tmp.dat
>> [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36);
>> Boost_105300; UHD_3.12.0.heads-v3.12.0.0-0-gec786351
>> [WARNING] [X300] Cannot update master clock rate! X300 Series does not
>> allow changing the clock rate during runtime.
>> [WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 200
>> MHz. Actual rate is: 100 MHz.
>> [WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 200
>> MHz. Actual rate is: 100 MHz.
>> [UHD_RX] Defaulting to mid-point gains:
>> [UHD_RX] Channel 0 gain: 49.5 dB
>> ^C
>>
>> Thanks,
>> Devin
>>
>> On Thu, Jan 17, 2019 at 12:48 PM Rigney, Kevin E via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> I’m working with the TwinRX and am having the same results as Emanuel. I
>>> was ignoring the warning about the sample rate but you said that it must
>>> run at 200MHz. Can you explain why UHD sets the sample rate to 100MHz if
>>> 200 is required?
>>>
>>> Thanks,
>>>
>>> -Kevin
>>>
>>> On Mon, 14 Jan 2019 at 7:06 AM Emanuel via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>> Dear Martin,
>>>
>>> thank you for clarification. Yes, please add this to the manual. We
>>> bought those TwinRX for some phase-coherent LTE signal reception, and now
>>> they seem to be not useful at all (without effort spent in sample rate
>>> conversion in post-processing etc.)
>>>
>>> I'm still wondering about the master clock rate though: I tried the
>>> benchmark with the following settings: ./benchmark_rate --args
>>> "master_clock_rate=200e6" --rx_subdev A:0 --rx_rate 10e6
>>> The TwinRX is mounted on slot A and a CBX-120 is mounted on slot B. I
>>> simply wanted a streaming test on the first TwinRX channel.
>>> During device initialization I get the following warnings, see below.
>>> Can you please comment on them?
>>>
>>> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
>>> [WARNING] [X300] Cannot update master clock rate! X300 Series does not
>>> allow changing the clock rate during runtime.
>>> [WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 200
>>> MHz. Actual rate is: 100 MHz.
>>> Using Device: Single USRP:
>>>   Device: X-Series Device
>>>   Mboard 0: X310
>>>   RX Channel: 0
>>> RX DSP: 0
>>> RX Dboard: A
>>> RX Subdev: TwinRX RX0
>>>   TX Channel: 0
>>>

[USRP-users] x310 gpsdo get_time_now()

[Ilay Nissim via USRP-users]

Hi
I have an x310 connected to gpsdo UHD ver14.0
I sync to gpsdo at start of bringup
Than use get_time_now() to follow usrp time
It look like usrp time is2x slow
Meaning if 100 seocnds should have passed - 50 seconds pass


For example
Using clock source - gpsdo time source gpsdo
 if on  init gps time is
1558028200
And usrp is
1558028200

After 100 seconds
Usrptime is
1558028250
And gps time is
1558028300

Would be happy to get feedback
Regards,
Ilay Nissim
RT Embedded Team Leader
Netline Communications Technologies Ltd
Tel: + (972) 36068171
Fax: + (972) 36068101
http://www.netlinetech.com/
Azrieli Circular Tower , Menachem Begin 132, Tel-Aviv 67021, ISRAEL


This email and the associated attachments may contain information that is 
proprietary, privileged, confidential or otherwise protected from disclosure. 
If you are not the intended recipient or otherwise have received this message 
in error, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you are not the intended recipient or 
otherwise have received this message in error, please notify me immediately, 
destroy any paper copies and delete all electronic files of the message.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 witn TwinRX: master_clock_rate issue

[Marcus D. Leech via USRP-users]

On 05/16/2019 01:34 PM, Devin Kelly via USRP-users wrote:
So when i I try to set the master clock rate to 100 MHz directly I get 
an error and when I don't set it I get a warning.


Can I just disregard the warning or is there something else going on here?
Yes, you can disregard the warning.   That's just internal UHD 
machinations not properly accounting for one another and

  producing a warning that you can ignore.

A more recent UHD wil likely fix this.




$ uhd_rx_cfile -r 10e6 -f 850e6 -g 10 -a 
'args=192.168.40.2,master_clock_rate=100e6' tmp.dat
[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36); 
Boost_105300; UHD_3.12.0.heads-v3.12.0.0-0-gec786351

Traceback (most recent call last):
  File "/test/bin/bin/uhd_rx_cfile", line 263, in 
tb = rx_cfile_block(options, filename)
  File "/test/bin/bin/uhd_rx_cfile", line 77, in __init__
channels=self.channels,
  File 
"/test/bin/lib64/python2.7/site-packages/gnuradio/uhd/__init__.py", 
line 122, in constructor_interceptor

return old_constructor(*args)
  File 
"/test/bin/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py", 
line 2334, in make

return _uhd_swig.usrp_source_make(*args)
RuntimeError: RuntimeError: Invalid master clock rate: 100.00 MHz.
Valid master clock rates when using a 10.00 MHz reference clock are:
120 MHz, 184.32 MHz and 200 MHz.


$ uhd_rx_cfile -r 10e6 -f 850e6 -g 10 -a 'args=192.168.40.2' tmp.dat
[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36); 
Boost_105300; UHD_3.12.0.heads-v3.12.0.0-0-gec786351
[WARNING] [X300] Cannot update master clock rate! X300 Series does not 
allow changing the clock rate during runtime.
[WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 
200 MHz. Actual rate is: 100 MHz.
[WARNING] [X300 RADIO] Requesting invalid sampling rate from device: 
200 MHz. Actual rate is: 100 MHz.

^C


On Tue, May 14, 2019 at 3:08 PM Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


On 05/14/2019 11:26 AM, Devin Kelly via USRP-users wrote:

Does anyone have any ideas on this?  Is uhd_rx_cfile not the
right tool to be using?

Devin


The TwinRX *MUST* run with a master clock of effectively 100MHz,
because of the way the ADCs are shared, and the DDC structure in the
  FPGA.  Further, the fixed analog filtering is designed for a
100MHz clock frequency, and the synthesizers on the board require
a 100MHz
  clock (AFAIR).

Simply don't specify the master clock rate when using
uhd_rx_cfile, and the correct default *should* happen.





On Thu, May 9, 2019 at 10:39 AM Devin Kelly mailto:dwwke...@gmail.com>> wrote:


Sorry to revive an old post but I'm having the same problem
with UHD 3.12.0.0.  Am I doing something wrong with
uhd_rx_cfile or should I just upgrade to a newer UHD?

$ uhd_rx_cfile -r 10e6 -f 850e6 -a
'args=192.168.40.2,master_clock_rate=200e6' tmp.dat
[INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat
4.8.5-36); Boost_105300; UHD_3.12.0.heads-v3.12.0.0-0-gec786351
[WARNING] [X300] Cannot update master clock rate! X300 Series
does not allow changing the clock rate during runtime.
[WARNING] [X300 RADIO] Requesting invalid sampling rate from
device: 200 MHz. Actual rate is: 100 MHz.
[WARNING] [X300 RADIO] Requesting invalid sampling rate from
device: 200 MHz. Actual rate is: 100 MHz.
[UHD_RX] Defaulting to mid-point gains:
[UHD_RX] Channel 0 gain: 49.5 dB
^C

Thanks,
Devin

On Thu, Jan 17, 2019 at 12:48 PM Rigney, Kevin E via
USRP-users mailto:usrp-users@lists.ettus.com>> wrote:

I’m working with the TwinRX and am having the same
results as Emanuel. I was ignoring the warning about the
sample rate but you said that it must run at 200MHz. Can
you explain why UHD sets the sample rate to 100MHz if 200
is required?

Thanks,

-Kevin

On Mon, 14 Jan 2019 at 7:06 AM Emanuel via USRP-users
mailto:usrp-users@lists.ettus.com>>> wrote:

Dear Martin,

thank you for clarification. Yes, please add this to the
manual. We bought those TwinRX for some phase-coherent
LTE signal reception, and now they seem to be not useful
at all (without effort spent in sample rate conversion in
post-processing etc.)

I'm still wondering about the master clock rate though: I
tried the benchmark with the following settings:
./benchmark_rate --args "master_clock_rate=200e6"
--rx_subdev A:0 --rx_rate 10e6
The TwinRX is mounted on slot A and a CBX-120 is mounted
on slot B. I simply wanted a streaming test on th

Re: [USRP-users] x310 gpsdo get_time_now()

[Marcus D. Leech via USRP-users]

On 05/16/2019 01:47 PM, Ilay Nissim via USRP-users wrote:


Hi

I have an x310 connected to gpsdo UHD ver14.0

I sync to gpsdo at start of bringup

Than use get_time_now() to follow usrp time

It look like usrp time is2x slow

Meaning if 100 seocnds should have passed – 50 seconds pass

For example

Using clock source – gpsdo time source gpsdo

 if on  init gps time is

1558028200

And usrp is

1558028200

After 100 seconds

Usrptime is

1558028250

And gps time is

1558028300

Would be happy to get feedback

Regards,
Ilay Nissim
RT Embedded Team Leader

Netline Communications Technologies Ltd
Tel: + (972) 36068171 
Fax: + (972) 36068101 
http://www.netlinetech.com/
Azrieli Circular Tower , Menachem Begin 132, Tel-Aviv 67021, ISRAEL



What version of UHD are you using?  Is this resolved with a newer UHD?


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] problem with fftw_plan_dft_2d

[Koyel Das (Vehere) via USRP-users]

Hi,


Following is a snapshot of my code using fftw_plan_dft_2d. I am getting all 
zeros in the imaginary part of fft (in the printf command of the following 
code:last line). The real part is correct.Could you please tell where am I 
going wrong?


 fftw_complex *imageOutputPlane=VDDSAlgorithm::imageOutPlane;

fftw_complex *imageInputPlane=VDDSAlgorithm::imageInputPlane;
unsigned char*imageData=VDDSAlgorithm::imageData;
unsigned char*imageDataFinal=VDDSAlgorithm::imageDataFinal;


memset(imageInputPlane,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION*sizeof(fftw_complex));

memset(imageOutputPlane,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION*sizeof(fftw_complex));
memset(imageData,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION);

for(size_t count=0;counthttp://www.vehere.com/>

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] problem with fftw_plan_dft_2d

[Marcus D. Leech via USRP-users]

On 05/16/2019 11:52 PM, Koyel Das (Vehere) via USRP-users wrote:


Hi,


Following is a snapshot of my code using fftw_plan_dft_2d. I am 
getting all zeros in the imaginary part of fft (in the printf command 
of the following code:last line). The real part is correct.Could you 
please tell where am I going wrong?



 fftw_complex *imageOutputPlane=VDDSAlgorithm::imageOutPlane;

fftw_complex *imageInputPlane=VDDSAlgorithm::imageInputPlane;
unsigned char*imageData=VDDSAlgorithm::imageData;
unsigned char*imageDataFinal=VDDSAlgorithm::imageDataFinal;

memset(imageInputPlane,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION*sizeof(fftw_complex));
memset(imageOutputPlane,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION*sizeof(fftw_complex));
memset(imageData,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION);

for(size_t count=0;countfftw_plan 
 planeX=fftw_plan_dft_2d(IMAGE_DIMENSION,IMAGE_DIMENSION, 
imageInputPlane, imageOutputPlane, FFTW_FORWARD, FFTW_ESTIMATE);

fftw_execute(planeX);
fftw_destroy_plan(planeX);
fftLock.unlock();


double max=0;
for(size_t row=0;rowM: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com //

I'm having a hard time seeing how this is related to UHD and USRPs.

There's probably a support forum for FFTW out there that would be more 
helpful than here.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] problem with fftw_plan_dft_2d

[Koyel Das (Vehere) via USRP-users]

Hi Marcus,


I emailed to f...@fftw.org but got no response so I 
thought some USRP users might also be using this library and hence I may get a 
response. That is why.


Regards,

Koyel Das

Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.


From: USRP-users  on behalf of Marcus D. 
Leech via USRP-users 
Sent: Friday, May 17, 2019 9:27:34 AM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] problem with fftw_plan_dft_2d

On 05/16/2019 11:52 PM, Koyel Das (Vehere) via USRP-users wrote:

Hi,


Following is a snapshot of my code using fftw_plan_dft_2d. I am getting all 
zeros in the imaginary part of fft (in the printf command of the following 
code:last line). The real part is correct.Could you please tell where am I 
going wrong?


 fftw_complex *imageOutputPlane=VDDSAlgorithm::imageOutPlane;

fftw_complex *imageInputPlane=VDDSAlgorithm::imageInputPlane;
unsigned char*imageData=VDDSAlgorithm::imageData;
unsigned char*imageDataFinal=VDDSAlgorithm::imageDataFinal;


memset(imageInputPlane,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION*sizeof(fftw_complex));

memset(imageOutputPlane,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION*sizeof(fftw_complex));
memset(imageData,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION);

for(size_t count=0;counthttp://www.vehere.com/>
I'm having a hard time seeing how this is related to UHD and USRPs.

There's probably a support forum for FFTW out there that would be more helpful 
than here.


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] problem with fftw_plan_dft_2d

[Samuel Prager via USRP-users]

From a cursory glance it looks like you are creating (hermetian) symmetry in 
your data with phy [whatever][whatever]

I would suggest reviewing the properties of the discrete Fourier transform.
On May 16, 2019, 9:11 PM -0700, Koyel Das (Vehere) via USRP-users 
, wrote:
> Hi Marcus,
>
> I emailed to f...@fftw.org but got no response so I thought some USRP users 
> might also be using this library and hence I may get a response. That is why.
>
> Regards,
> Koyel Das
> Senior – Product Engineer
> Vehere | Proactive Communications Intelligence & Cyber Defence
> M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: www.vehere.com
>
>
>
> Vehere is the proud recipient of the Fastest Growing Technology Company 
> Awards in India & Asia since 2012!
>
> The content of this e-mail is confidential and intended solely for the use of 
> the addressee. The text of this email (including any attachments) may contain 
> information, which is proprietary and/or confidential or privileged in nature 
> belonging to Vehere Interactive Pvt Ltd and/or its associates/ group 
> companies/ subsidiaries. If you are not the addressee, or the person 
> responsible for delivering it to the addressee, any disclosure, copying, 
> distribution or any action taken or omitted to be taken in reliance on it is 
> prohibited and may be unlawful. If you have received this e-mail in error, 
> please notify the sender and remove this communication entirely from your 
> system. The recipient acknowledges that no guarantee or any warranty is given 
> as to completeness and accuracy of the content of the email. The recipient 
> further acknowledges that the views contained in the email message are those 
> of the sender and may not necessarily reflect those of Vehere Interactive Pvt 
> Ltd. Before opening and accessing the attachment please check and scan for 
> virus. WARNING: Computer viruses can be transmitted via email. The recipient 
> should check this email and any attachments for the presence of viruses. The 
> company accepts no liability for any damage caused by any virus transmitted 
> by this email.
> From: USRP-users  on behalf of Marcus D. 
> Leech via USRP-users 
> Sent: Friday, May 17, 2019 9:27:34 AM
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] problem with fftw_plan_dft_2d
>
> On 05/16/2019 11:52 PM, Koyel Das (Vehere) via USRP-users wrote:
> > Hi,
> >
> > Following is a snapshot of my code using fftw_plan_dft_2d. I am getting all 
> > zeros in the imaginary part of fft (in the printf command of the following 
> > code:last line). The real part is correct.Could you please tell where am I 
> > going wrong?
> >
> >  fftw_complex *imageOutputPlane=VDDSAlgorithm::imageOutPlane;
> >     fftw_complex *imageInputPlane=VDDSAlgorithm::imageInputPlane;
> >     unsigned char*imageData=VDDSAlgorithm::imageData;
> >     unsigned char*imageDataFinal=VDDSAlgorithm::imageDataFinal;
> >
> >     
> > memset(imageInputPlane,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION*sizeof(fftw_complex));
> >     
> > memset(imageOutputPlane,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION*sizeof(fftw_complex));
> >     memset(imageData,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION);
> >
> >     for(size_t count=0;count >        
> > imageInputPlane[(int)round(IMAGE_DIMENSION/2+diffX[count])*IMAGE_DIMENSION+(int)round(IMAGE_DIMENSION/2-diffY[count])][0]=phy[count][0];
> >        
> > imageInputPlane[(int)round(IMAGE_DIMENSION/2+diffX[count])*IMAGE_DIMENSION+(int)round(IMAGE_DIMENSION/2-diffY[count])][1]=-(phy[count][1]);
> >        
> > imageInputPlane[(int)round(IMAGE_DIMENSION/2-diffX[count])*IMAGE_DIMENSION+(int)round(IMAGE_DIMENSION/2+diffY[count])][0]=phy[count][0];
> >        
> > imageInputPlane[(int)round(IMAGE_DIMENSION/2-diffX[count])*IMAGE_DIMENSION+(int)round(IMAGE_DIMENSION/2+diffY[count])][1]=phy[count][1];
> >     }
> >
> >     fftLock.lock();
> >     fftw_plan  planeX=fftw_plan_dft_2d(IMAGE_DIMENSION,IMAGE_DIMENSION, 
> > imageInputPlane, imageOutputPlane, FFTW_FORWARD, FFTW_ESTIMATE);
> >     fftw_execute(planeX);
> >     fftw_destroy_plan(planeX);
> >     fftLock.unlock();
> >
> >
> >     double max=0;
> >     for(size_t row=0;row >         for(size_t col=0;col >             if(col==0)printf("\n");
> >             if(col<100){
> >                 
> > printf("(%lf,%lf)",imageOutputPlane[row*IMAGE_DIMENSION+col][0],imageOutputPlane[row*IMAGE_DIMENSION+col][1]);
> >             }
> >
> >         }
> >     }
> >
> > Regards,
> > Koyel Das
> > Senior – Product Engineer
> > Vehere | Proactive Communications Intelligence & Cyber Defence
> > M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
> > www.vehere.com
> I'm having a hard time seeing how this is related to UHD and USRPs.
>
> There's probably a support forum for FFTW out there that would be more 
> helpful than here.
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus

Re: [USRP-users] problem with fftw_plan_dft_2d

[Koyel Das (Vehere) via USRP-users]

Hi Samuel,


I have checked 2d FFT for the same data in MATLAB and there the imaginary are 
non zero. So its not due to property of DFT.


Regards,

Koyel Das
Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.


From: Samuel Prager 
Sent: Friday, May 17, 2019 11:01:00 AM
To: Koyel Das (Vehere)
Cc: Marcus D. Leech via USRP-users
Subject: Re: [USRP-users] problem with fftw_plan_dft_2d

>From a cursory glance it looks like you are creating (hermetian) symmetry in 
>your data with phy [whatever][whatever]

I would suggest reviewing the properties of the discrete Fourier transform.
On May 16, 2019, 9:11 PM -0700, Koyel Das (Vehere) via USRP-users 
, wrote:

Hi Marcus,


I emailed to f...@fftw.org but got no response so I 
thought some USRP users might also be using this library and hence I may get a 
response. That is why.


Regards,

Koyel Das

Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed]
 [unnamed (1)] 

  [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interac