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 <adray0...@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.wro...@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 <adray0...@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.wro...@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 <adray0...@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.wro...@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 <adray0...@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.wro...@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 <adray0...@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 <adray0...@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.wro...@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@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@lists.ettus.com
>>>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ett
>>>>>>>>>>>> us.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
