[USRP-users] spectrum analyzer USRP N210

Ivan Zahartchuk adray0001 at gmail.com
Mon Nov 20 07:21:03 EST 2017


Yes, I meant FV. This is what spectrum I get as a result. The only problem
is these carriers.

2017-11-20 13:42 GMT+02:00 Michał Wróbel <michal.a.wrobel at gmail.com>:

> Hey Ivan,
>
> you mean the FW file? No, I didn't try to repair yet. But I think it
> shouldn't make any difference - the description of the bug mentioned only
> precision of calculation in the digital conversion chains which are
> entirely in the FPGA (FW only assists in setting them up, but doesn't
> actually process the data).
>
> Best,
> Michał
>
> 2017-11-20 7:59 GMT+01:00 Ivan Zahartchuk <adray0001 at gmail.com>:
>
>> Hello Michał.
>> Have you tried to compile the firmware for USRP N210 ???
>>
>> 2017-11-16 15:13 GMT+02:00 Michał Wróbel <michal.a.wrobel at gmail.com>:
>>
>>> Ok, this makes things clearer :-).
>>>
>>> Is there any difference in the obtained spectra between the stock and my
>>> compilation of FPGA firmware for the whole original range of frequencies
>>> (i.e. like in the initial screenshots, 400 - 1000 MHz) without the "80%
>>> sewing"?
>>>
>>> 2017-11-16 12:48 GMT+01:00 Ivan Zahartchuk <adray0001 at gmail.com>:
>>>
>>>> I'm sorry that I misled you. The fact is that after the ftft there is
>>>> a constant component that I am removing in the code by zeroing.
>>>> 1)
>>>>
>>>> def reciev():
>>>>     n = int(math.ceil((config.stop_freq - config.start_freq) / config.band*0.8))
>>>>     fft1 = np.array([], dtype=np.complex64)
>>>>     fft2 = np.array([], dtype=np.complex64)
>>>>     for i in range(0, n):
>>>>         usrp.set_rx_freq(lib.types.tune_request(config.start_freq + config.band / 2 + (config.band*0.8) * i), 0)
>>>>         streamer.recv(recv_buff, config.metadata)
>>>>         if config.metadata.error_code == lib.types.rx_metadata_error_code.timeout:
>>>>             print ("ERRROR")
>>>>         elif config.metadata.error_code == lib.types.rx_metadata_error_code.late:
>>>>             print ("ERR1")
>>>>         elif config.metadata.error_code == lib.types.rx_metadata_error_code.broken_chain:
>>>>             print ("ERR2")
>>>>         elif config.metadata.error_code == lib.types.rx_metadata_error_code.overflow:
>>>>             print ("ERR3")
>>>>         elif config.metadata.error_code == lib.types.rx_metadata_error_code.alignment:
>>>>             print ("ERR4")
>>>>         elif config.metadata.error_code == lib.types.rx_metadata_error_code.bad_packet:
>>>>             print ("ERR5")
>>>>         prom1 = np.fft.fft(recv_buff*w)
>>>>
>>>>         prom1=np.fft.fftshift(prom1)
>>>>
>>>>         fft1 = np.hstack((prom1,fft1))
>>>>    )
>>>>         stream_cmd.time_spec = lib.types.time_spec(0)
>>>>         streamer.issue_stream_cmd(stream_cmd)
>>>> 2.
>>>> def reciev():
>>>>     n = int(math.ceil((config.stop_freq - config.start_freq) / config.band*0.8))
>>>>     fft1 = np.array([], dtype=np.complex64)
>>>>
>>>>     for i in range(0, n):
>>>>         usrp.set_rx_freq(lib.types.tune_request(config.start_freq + config.band / 2 + (config.band*0.8) * i), 0)
>>>>         streamer.recv(recv_buff, config.metadata)
>>>>         if config.metadata.error_code == lib.types.rx_metadata_error_code.timeout:
>>>>             print ("ERRROR")
>>>>         elif config.metadata.error_code == lib.types.rx_metadata_error_code.late:
>>>>             print ("ERR1")
>>>>         elif config.metadata.error_code == lib.types.rx_metadata_error_code.broken_chain:
>>>>             print ("ERR2")
>>>>         elif config.metadata.error_code == lib.types.rx_metadata_error_code.overflow:
>>>>             print ("ERR3")
>>>>         elif config.metadata.error_code == lib.types.rx_metadata_error_code.alignment:
>>>>             print ("ERR4")
>>>>         elif config.metadata.error_code == lib.types.rx_metadata_error_code.bad_packet:
>>>>             print ("ERR5")
>>>>
>>>>         prom1 = np.fft.fft(recv_buff*w)
>>>>        * prom1[0:5]=**0*
>>>>         *prom1[num_samps-5:num_samps]=**0*
>>>>         prom1=np.fft.fftshift(prom1)
>>>>         fft1 = np.hstack((prom1,fft1))
>>>>         stream_cmd.time_spec = lib.types.time_spec(0)
>>>>         streamer.issue_stream_cmd(stream_cmd)
>>>>
>>>>
>>>> 2017-11-16 13:35 GMT+02:00 Michał Wróbel <michal.a.wrobel at gmail.com>:
>>>>
>>>>> I mixed the files
>>>>>
>>>>>
>>>>> Context: I sent Ivan my FPGA and FW compilation. My FW didn't work, so
>>>>> I recommended "mixing" the images - taking my FPGA and stock FW.
>>>>>
>>>>> the carriers as they were and remained
>>>>>
>>>>>
>>>>> Do I see correctly that previously you had spikes at DC (-60..-58 dBm)
>>>>> _and_ at some other frequencies (-50..-42 dBm) and now you have only DC
>>>>> spikes (~-40 dBm)? Sorry, it's not very easy to me to read it from the
>>>>> plots.
>>>>>
>>>>> Was this change a result "sewing" or the FPGA image change? It would
>>>>> be helpful to see the effect of each of these actions separately.
>>>>>
>>>>> 2017-11-16 12:10 GMT+01:00 Ivan Zahartchuk <adray0001 at gmail.com>:
>>>>>
>>>>>> I mixed the files and the card was sewn but the carriers as they were
>>>>>> and remained.
>>>>>>
>>>>>> 2017-11-16 12:30 GMT+02:00 Michał Wróbel <michal.a.wrobel at gmail.com>:
>>>>>>
>>>>>>> Hey Derek,
>>>>>>>
>>>>>>>
>>>>>>> Hi Ivan, it's Michał here. ;-)
>>>>>>>
>>>>>>> uhd_image_loader --args="type=usrp2,addr=192.16
>>>>>>>> 8.10.2,overwrite-safe"
>>>>>>>
>>>>>>>
>>>>>>> DON'T use "overwrite-safe" here! It's only for unbricking the
>>>>>>> device. If the firmware I sent you is incorrect - it might do the opposite
>>>>>>> - *brick* the firmware, so that you'll have to use a JTAG to recover it
>>>>>>> afterwards (BTW. do you have it, just in case?)
>>>>>>>
>>>>>>> Just use --args="type=usrp2,addr=192.168.10.2" as described in the
>>>>>>> "Load the Images onto the On-board Flash (USRP-N Series only)" / "Use the
>>>>>>> image loader" section (not the one in "Unbricking an N-Series Device").
>>>>>>>
>>>>>>> Regarding the "The file at path (...) is not a valid firmware image"
>>>>>>> error - indeed the firmware file I sent you is not compatible with
>>>>>>> uhd_image_loader. I'll check that later (maybe today evening).
>>>>>>>
>>>>>>> In the meantime I think you might try to mix stock FW image (i.e.
>>>>>>> from uhd-images package) with my FPGA image. Let me know if that works for
>>>>>>> you.
>>>>>>>
>>>>>>> Best,
>>>>>>> Michał
>>>>>>>
>>>>>>> 2017-11-16 8:31 GMT+01:00 Ivan Zahartchuk <adray0001 at gmail.com>:
>>>>>>>
>>>>>>>> Hey Derek,
>>>>>>>> when the board was flashed, I got an error:
>>>>>>>>
>>>>>>>> uhd_image_loader --args="type=usrp2,addr=192.168.10.2,overwrite-safe"
>>>>>>>> --fw-path=usrp_n210_fw1.bin --fpga-path=usrp_n210_r4_fpga1.bin
>>>>>>>> linux; GNU C++ version 4.8.4; Boost_105400;
>>>>>>>> UHD_003.010.002.heads-release_003_010_002_000-0-gbd6e21dc
>>>>>>>>
>>>>>>>> Unit: USRP N210 r4 (311D7A1, 192.168.10.2)
>>>>>>>> Error: RuntimeError: The file at path "/home/suppression/usrp_n210_fw1.bin"
>>>>>>>> is not a valid firmware image.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>> 2017-11-15 22:12 GMT+02:00 Michał Wróbel <michal.a.wrobel at gmail.com
>>>>>>>> >:
>>>>>>>>
>>>>>>>>> Hey Ivan,
>>>>>>>>>
>>>>>>>>> I compiled the firmware for you. I assumed that you are using USRP
>>>>>>>>> N210 R4. See the attachment. As said before - I didn't check it as I have
>>>>>>>>> no such hardware - it might completely not work (i.e. not even boot up).
>>>>>>>>> Let me know if it works.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Michał
>>>>>>>>>
>>>>>>>>> 2017-11-15 18:12 GMT+01:00 Ivan Zahartchuk <adray0001 at gmail.com>:
>>>>>>>>>
>>>>>>>>>> Hi again.
>>>>>>>>>>
>>>>>>>>>> I've tried everything described in the article you're refering
>>>>>>>>>> to. I'd be extremely grateful if you could try to compile FPGA bitstream
>>>>>>>>>> for USRP N210 and send it to me.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Ivan
>>>>>>>>>>
>>>>>>>>>> 2017-11-15 17:21 GMT+02:00 Michał Wróbel <
>>>>>>>>>> michal.a.wrobel at gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> Hey Ivan,
>>>>>>>>>>>
>>>>>>>>>>> if the problem with the spikes is what I think it is, you'll
>>>>>>>>>>> need a new build of the FPGA bitstream. I can try to compile one with the
>>>>>>>>>>> most fresh version from GitHub, but as I don't have USRP N210 (I only own
>>>>>>>>>>> USRP2), I have no way to confirm that it works properly before I will send
>>>>>>>>>>> it to you. Have you ever flashed your USRP (i.e. like described
>>>>>>>>>>> here
>>>>>>>>>>> <https://files.ettus.com/manual/page_usrp2.html#usrp2_loadflash>
>>>>>>>>>>> )?
>>>>>>>>>>>
>>>>>>>>>>> Also, Derek Kozel's has some other really good advice about
>>>>>>>>>>> spectrum flatness, device calibration, etc. You should definitely try that
>>>>>>>>>>> too.
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>> Michał
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2017-11-15 14:51 GMT+01:00 Ivan Zahartchuk <adray0001 at gmail.com>
>>>>>>>>>>> :
>>>>>>>>>>>
>>>>>>>>>>>> Tell me how to fix this problem. I'm not very versed in the
>>>>>>>>>>>> FPGA
>>>>>>>>>>>>
>>>>>>>>>>>> 2017-11-15 15:51 GMT+02:00 Ivan Zahartchuk <adray0001 at gmail.com
>>>>>>>>>>>> >:
>>>>>>>>>>>>
>>>>>>>>>>>>> Tell me how to fix this problem. I'm not very versed in the
>>>>>>>>>>>>> FIG.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2017-11-15 15:39 GMT+02:00 Michał Wróbel <
>>>>>>>>>>>>> michal.a.wrobel at gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Ivan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> these spikes look similar to what I am experiencing with my
>>>>>>>>>>>>>> USRP2+WBX and what seems to be already fixed in the GitHub repository:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://github.com/EttusResearch/fpga/pull/4
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have asked about that just yesterday:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/
>>>>>>>>>>>>>> 2017-November/027054.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> Michał
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2017-11-15 14:26 GMT+01:00 Ivan Zahartchuk via USRP-users <
>>>>>>>>>>>>>> usrp-users at lists.ettus.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello. I'm trying to make a broadband spectrum analyzer. I
>>>>>>>>>>>>>>> encountered some difficulties with the USRP N210 board. At
>>>>>>>>>>>>>>> certain frequencies, I get such a picture. And there are
>>>>>>>>>>>>>>> problems with the presence of central frequencies. Advise
>>>>>>>>>>>>>>> me how to remove these shortcomings.
>>>>>>>>>>>>>>> My code:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> n = int(math.ceil((config.stop_freq - config.start_freq) / config.band))
>>>>>>>>>>>>>>> fft1 = np.array([], dtype=np.complex64)
>>>>>>>>>>>>>>> for i in range(0, n):
>>>>>>>>>>>>>>>     usrp.set_rx_freq(lib.types.tune_request(config.start_freq + config.band / 2 + config.band * i), 0)
>>>>>>>>>>>>>>>     streamer.recv(recv_buff, config.metadata)
>>>>>>>>>>>>>>>     if config.metadata.error_code == lib.types.rx_metadata_error_code.timeout:
>>>>>>>>>>>>>>>         print ("ERRROR")
>>>>>>>>>>>>>>>     elif config.metadata.error_code == lib.types.rx_metadata_error_code.late:
>>>>>>>>>>>>>>>         print ("ERR1")
>>>>>>>>>>>>>>>     elif config.metadata.error_code == lib.types.rx_metadata_error_code.broken_chain:
>>>>>>>>>>>>>>>         print ("ERR2")
>>>>>>>>>>>>>>>     elif config.metadata.error_code == lib.types.rx_metadata_error_code.overflow:
>>>>>>>>>>>>>>>         print ("ERR3")
>>>>>>>>>>>>>>>     elif config.metadata.error_code == lib.types.rx_metadata_error_code.alignment:
>>>>>>>>>>>>>>>         print ("ERR4")
>>>>>>>>>>>>>>>     elif config.metadata.error_code == lib.types.rx_metadata_error_code.bad_packet:
>>>>>>>>>>>>>>>         print ("ERR5")
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     prom1 = np.fft.fft(recv_buff)
>>>>>>>>>>>>>>>     prom1[0:5] = 0
>>>>>>>>>>>>>>>     prom1[num_samps-5:num_samps] = 0
>>>>>>>>>>>>>>>     prom1= np.fft.fftshift(prom1)*w
>>>>>>>>>>>>>>>     fft1 = np.hstack((fft1,prom1))
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     stream_cmd.time_spec = lib.types.time_spec(0)
>>>>>>>>>>>>>>>     streamer.issue_stream_cmd(stream_cmd)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> dbm = np.array(10 * np.log10(np.abs(fft1))  - 60)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> return dbm,config.start_freq+(config.band/num_samps)*np.arange(dbm.size)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> USRP-users mailing list
>>>>>>>>>>>>>>> USRP-users at lists.ettus.com
>>>>>>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ett
>>>>>>>>>>>>>>> us.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171120/0dccff13/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ?????? ?????? ?? 2017-11-20 14:18:27.png
Type: image/png
Size: 59459 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171120/0dccff13/attachment.png>


More information about the USRP-users mailing list