[USRP-users] spectrum analyzer USRP N210

Ivan Zahartchuk adray0001 at gmail.com
Thu Nov 16 06:48:49 EST 2017


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.168.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/20171116/17cd1d68/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ?????? ?????? ?? 2017-11-16 13:42:18.png
Type: image/png
Size: 58788 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171116/17cd1d68/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ?????? ?????? ?? 2017-11-16 13:42:49.png
Type: image/png
Size: 68066 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171116/17cd1d68/attachment-0001.png>


More information about the USRP-users mailing list