Send USRP-users mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."


Today's Topics:

   1. Re: Pulse Radar (Dan CaJacob)
   2. WG: How do I transmit and receive signals on two B210
      simultaneously with MATLAB? (Sebastian M. Richter)
   3. Burst Tx and Underrun ([email protected])
   4. Re: Pulse Radar (Martin Braun)
   5. Re: Multiple B210s firmware update issue (Martin Braun)
   6. Re: UBX can not transmit signal (Michael West)
   7. Re: WG: How do I transmit and receive signals on two B210
      simultaneously with MATLAB? (Ethem Sozer)
   8. Re: Pulse Radar (avinash kalyanaraman)
   9. Re: WG: How do I transmit and receive signals on two B210
      simultaneously with MATLAB? (Sebastian M. Richter)
  10. Confusion over data formatting for a waveform in QT GUI Time
      Sink, File Sink, and RFNoC noc_block_moving_avg (Swanson, Craig)
  11. Re: WG: How do I transmit and receive signals on two B210
      simultaneously with MATLAB? (Ethem Sozer)
  12. Resetting N210 & X310 Remotely (Dave NotTelling)
  13. Re: Burst Tx and Underrun (Marcus M?ller)
  14. Re: Pulse Radar (Marcus M?ller)
  15. Re: WG: How do I transmit and receive signals on two B210
      simultaneously with MATLAB? (Sebastian M. Richter)
  16. Re: Confusion over data formatting for a waveform in QT GUI
      Time Sink, File Sink, and RFNoC noc_block_moving_avg (Ian Buckley)
  17. How do timed commands work? (Dave NotTelling)
  18. Re: How do timed commands work? (Marcus D. Leech)
  19. Re: UBX can not transmit signal (liu Jong)
  20. UBX Tx-to-Rx interference,        Performance and Power-Save modes
      (hanwen)
  21. Re: How do timed commands work? (Ian Buckley)
  22. Re: Confusion over data formatting for a waveform in QT GUI
      Time Sink, File Sink, and RFNoC noc_block_moving_avg (Swanson, Craig)
  23. Data formatting questions for gnuradio complex to Q16     in
      RFNOC (Swanson, Craig)


----------------------------------------------------------------------

Message: 1
Date: Wed, 18 May 2016 17:06:37 +0000
From: Dan CaJacob <[email protected]>
To: avinash kalyanaraman <[email protected]>,
        [email protected]
Subject: Re: [USRP-users] Pulse Radar
Message-ID:
        <camomjobffofx1qti2--_7d1vez6jn5mz+6ftcs4r9lxw2d-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I am not an expert at radar, but there is an OOT module called gr-radar
that should be a good start for you.  It implements many types of radar
systems.

On Wed, May 18, 2016 at 11:56 AM avinash kalyanaraman via USRP-users <
[email protected]> wrote:

> Hi all,
>
> I have a couple of USRP N210s with the WBX-daughter boards, and I want to
> build a simple pulse radar with them- i.e.  I want to be able to generate
> and receive a pulse between them, and calculate the time delay. In this
> regard I have a couple of questions:
>
> (i) How do I generate a pulse? Is multiplying square waves my best option
> in generating a pulse ? What would be the smallest pulse width I might be
> able to get?
>
> (ii) To get the two USRPs to synchronize in time so that the time of
> flight can be calculated, I plan to use the GPSDO. What is the accuracy of
> the GPSDO unit? I.e. what's the difference in absolute timestamps that I
> can expect ?
>
> Am I missing anything else here in getting this setup running ?
>
> Please let me know,
>
> Thanks,
>
> --
> Avinash
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-- 
Very Respectfully,

Dan CaJacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/186593c6/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 18 May 2016 16:40:09 +0000
From: "Sebastian M. Richter" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] WG: How do I transmit and receive signals on two
        B210 simultaneously with MATLAB?
Message-ID:
        
<blupr03mb1380b6260e2b4f6cd6d80f4490...@blupr03mb1380.namprd03.prod.outlook.com>
        
Content-Type: text/plain; charset="iso-8859-1"

Hello,


currently I am using two Ettus B210 and MATLAB 2015b on a Win7. Working with a 
single board I can receive and transmit signals without problems. Now I want to 
transmit a signal from both Tx ports on one board and receive these signals 
from both Rx ports on  another board. For transmitting and receiving signals I 
am using the 'step'-command. From my way of thinking, one possible way would be 
to send the transmit and receive commands for both boards simultaneously. I 
have tried this by using one worker for transmitting and another for receiving. 
I have started both workers and when they have reached their step-commands at 
the same time, I got the error that one of the boards could not be found or is 
not connected. Therefore, I think MATLAB cannot send the step-command to two 
different USB-ports simultaneously.


I was also thinking of starting the transmitting board first and then the 
receiving board. With the code in the attachment I can see a part of the 
transmitted signal. Furthermore, the transmitter just transmits single frames 
but not a continuous signal. My aim is to transmit for 6 seconds without a 
break and receive 5 seconds of this (at the first samples the signal shows a 
settle behavior, I do not want to receive).

I have also tried to work by enabling the burst mode but then MATLAB send one 
step-command and waits until the board finishes transmitting and starts the 
following step-command for the other board then. In that way I cannot receive 
any part of the transmitted signal.


Is there a possibility to transmit from one board and receive this signal on 
another B210 simultaneously (with one computer)? How do I implement this in 
MATLAB? I am looking forward to get some new ideas I can try.


Best,


Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/40fbc45d/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: B210_transmit_and_receive_on_two_boards.m
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/40fbc45d/attachment-0001.m>

------------------------------

Message: 3
Date: Wed, 18 May 2016 11:31:01 +0200
From: [email protected]
To: [email protected]
Subject: [USRP-users] Burst Tx and Underrun
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed

Hi Everyone,

I'm currently trying to implement a burst 2-FSK data transmitter which 
fulfill these parameters :
- Bit_rate : 32768
- FSK_deviation : 50k
- Center Freq : 868MHz

Here my simple flowgraph : http://i.imgur.com/u6LOK5m.png


The very precise baud_rate was a problem at first, because the USRP 
sample rate was a multiple of baud_rate and was not supported (UHD 
Warning: "expect CIC rolloff" & "The hardware does not support the 
requested TX sample rate" ), so i inserted a Rational Resampler and it 
solved this issue quite well.

With this Tx chain, i can recover the data with a 60% sucess ratio. For 
the 40% failed data, I see a "hole" in my recovered data, as if the USRP 
stoped transmitting for a very short period of time (randomly in the 
body of the message)

I think the problem is linked to the "Under run" warning observed at 
each burst (only a single one).
- I first tried to use the "length tag" ( but the number of samples for 
my burst has changed after the modulation chain (and of course, after 
the resampling) .. so i didn't find any way to recalculate it precisely 
to modify the tag before the USRP sink.
- I then tried to use the couple tx_sob / tx_eob with a custom block 
(which is quite fun after all) after the PDU to Tagged stream block. 
Length tag is removed (to enable tx_sob/tx_eob parsing), tx_sob is 
inserted at the first sample and tx eob is inserted at the last sample. 
After resampling, another custom block is shifting tx_eob tag to the 
last sample of the sample set.

None of these tries removed the "U" warning, but i achieved to get 85% 
receive success by sending quite a big padding before any packet ... 
It's better but it's a dirty fix, i don't like it :)


I'm running out of ideas and blocks coding experiments .. Anyone has any 
ideas ?

Thanks !

-JM




------------------------------

Message: 4
Date: Wed, 18 May 2016 10:28:19 -0700
From: Martin Braun <[email protected]>
To: avinash kalyanaraman <[email protected]>,
        [email protected]
Subject: Re: [USRP-users] Pulse Radar
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252

On 05/18/2016 08:54 AM, avinash kalyanaraman via USRP-users wrote:
> Hi all,
> 
> I have a couple of USRP N210s with the WBX-daughter boards, and I want
> to build a simple pulse radar with them- i.e.  I want to be able to
> generate and receive a pulse between them, and calculate the time delay.
> In this regard I have a couple of questions:
> 
> (i) How do I generate a pulse? Is multiplying square waves my best
> option in generating a pulse ? What would be the smallest pulse width I
> might be able to get? 

Pulses are difficult. If you're driving this in a standard UHD/Ethernet
fashion (i.e., no FPGA mods) you can get a max sampling rate of 25 Msps,
so not very short pulses. With some kind of *pulse compression* (i.e.,
correlation) you can get much better results though. Or you use any kind
of radar scheme that doesn't require high bandwidths.

> (ii) To get the two USRPs to synchronize in time so that the time of
> flight can be calculated, I plan to use the GPSDO. What is the accuracy
> of the GPSDO unit? I.e. what's the difference in absolute timestamps
> that I can expect ?  

Is this a bistatic setup, or are are your USRPs in the same spot? If so,
just use MIMO cable. You will get sample-accurate synchronization this
way. With a GPSDO, your mileage will vary, but I doubt you'd be good
enough for radar. And I'm less worried about the timing: Note that even
small drifts in the clock frequency provided by the GPSDOs can translate
to big Doppler differences. Ideally, you really want the same LO on both
tx and rx components. Sharing the actual reference clock is the closest
you can get with N210s.

Cheers,
Martin

> Am I missing anything else here in getting this setup running ?
> 
> Please let me know,
> 
> Thanks,
> 
> -- 
> Avinash
> 
> 
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




------------------------------

Message: 5
Date: Wed, 18 May 2016 10:30:16 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Multiple B210s firmware update issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252

Joshua,

which OS is this?

-- Martin

On 05/18/2016 04:25 AM, Joshua Sendall via USRP-users wrote:
> Hi Everyone,
> 
> I have found an issue upon trying to use multiple create multiple B210s.
> The issue arises when the second multi_usrp object is created (I have to
> use 2, because 2 B210s are not supported on a single multi_usrp object).
> After searching for the  GPSDO a libusb error is thrown (see the
> attached screenshot). The issue arose upon updating UHD to version
> 3.9.x, but the program continues to work with previous versions.
> 
> Has anyone else had success running multiple board configurations with
> the newer software, or have any suggestions for a solution? 
> 
> Kind regards,
> Joshua Sendall
> 
> 
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




------------------------------

Message: 6
Date: Wed, 18 May 2016 10:45:31 -0700
From: Michael West <[email protected]>
To: liu Jong <[email protected]>
Cc: "[email protected]" <[email protected]>,  Ettus
        Research Support <[email protected]>
Subject: Re: [USRP-users] UBX can not transmit signal
Message-ID:
        <cam4xkrrt2k+qjommxfywiraeaonaj1coj16ms3xj0gbmjuy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Jon,

I just tested on N210+UBX and it worked fine for me (previous tests were
X310+UBX).  I don't know what to say about your UBX boards.  I recommend
contacting Ettus support ([email protected]) for an RMA.

Regards,
Michael

On Tue, May 17, 2016 at 6:43 PM, liu Jong <[email protected]> wrote:

> Hi,Michael,
> I uesd N210+UBX?and just transmit a sine signal.i tred the gain from 0 to
> 38 and the frequency 10M to 6GHz.i receive the signal when i used 158277B-01L
> ,but with 158277A-01L can not.
> is it possible that there is some thing wrong with hardware?
> thank you
> best regards
> Jon
>
> 2016-05-18 6:23 GMT+08:00 Michael West <[email protected]>:
>
>> Hi Jon,
>>
>> I was able to use UHD 3.9.4 and a 158277A-02L UBX board to transmit just
>> fine.  Please provide more information about your set up.  What type of
>> USRP are you using?  What are your frequency and gain settings?  What are
>> you using to transmit?  What are you using to verify transmission?
>>
>> Regards,
>> Michael
>>
>> On Mon, May 16, 2016 at 5:57 PM, liu Jong <[email protected]> wrote:
>>
>>> Hi,Michael,
>>> there is no error information,and the TX/RX port is also lighting.But
>>>  it can not transmit signal.
>>> thank you.
>>> Jon
>>>
>>>
>>> 2016-05-16 21:56 GMT+08:00 Michael West <[email protected]>:
>>>
>>>> Hi Jon,
>>>>
>>>> There is no firmware on the UBX and there is no difference in software
>>>> for the different versions.  What is the exact error you are seeing?
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> On Sun, May 15, 2016 at 10:54 PM, liu Jong <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Michael,
>>>>> thank you for your davices.i tried it,but no use.But if i change to 
>>>>> 158277B-01L
>>>>> UBX,it works ok.Can UBX be flashed firmware,or some other measures i 
>>>>> should
>>>>> take?
>>>>> best regards
>>>>> Jon
>>>>>
>>>>> 2016-05-13 22:42 GMT+08:00 Michael West <[email protected]>:
>>>>>
>>>>>> Hi Jon,
>>>>>>
>>>>>> There is an issue with some components on the bottom side of the UBX
>>>>>> being too close to the mounting holes and shorting out to the 
>>>>>> daughterboard
>>>>>> standoffs on the X300/X310.  You can rotate the existing standoffs so 
>>>>>> they
>>>>>> provide more clearance for the components or install thinner standoffs.
>>>>>>
>>>>>> I'm not sure, but I thought the UBX shipped with the thinner
>>>>>> standoffs.  If not, you can  contact [email protected] to request
>>>>>> them.
>>>>>>
>>>>>> Regards,
>>>>>> Michael
>>>>>>
>>>>>> On Thu, May 12, 2016 at 11:58 PM, liu Jong via USRP-users <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Dear all,
>>>>>>>          We have  3 pieces of UBX-40 board?one of which the part
>>>>>>> number is 158277B-01L and it send and receive signals normally.the 
>>>>>>> others
>>>>>>> of part number are all 158277A-01L and they only received signal, but
>>>>>>> couldn't send out a signal. We  tested this on  the uhd3.9.4 . 
>>>>>>> According to
>>>>>>> different part number,  need we to do some special settings?
>>>>>>>
>>>>>>> thank you
>>>>>>> best regards
>>>>>>> Jon
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/5e4a2248/attachment-0001.html>

------------------------------

Message: 7
Date: Wed, 18 May 2016 18:24:47 +0000
From: Ethem Sozer <[email protected]>
To: "Sebastian M. Richter" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] WG: How do I transmit and receive signals on
        two B210 simultaneously with MATLAB?
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="us-ascii"

Hi Sebastian,
MATLAB 2015b USRP Support Package uses UHD version 3.8.2. This version of UHD 
has a bug that prevents more than one B210 radio to be connected on a Windows 
machine. Since the step command uses UHD underneath, you cannot call step on 
two radios on a single Windows machine. It works on Linux or Mac.
Regards,
Ethem


From: USRP-users [mailto:[email protected]] On Behalf Of 
Sebastian M. Richter via USRP-users
Sent: Wednesday, May 18, 2016 12:40 PM
To: [email protected]
Subject: [USRP-users] WG: How do I transmit and receive signals on two B210 
simultaneously with MATLAB?

Hello,



currently I am using two Ettus B210 and MATLAB 2015b on a Win7. Working with a 
single board I can receive and transmit signals without problems. Now I want to 
transmit a signal from both Tx ports on one board and receive these signals 
from both Rx ports on  another board. For transmitting and receiving signals I 
am using the 'step'-command. From my way of thinking, one possible way would be 
to send the transmit and receive commands for both boards simultaneously. I 
have tried this by using one worker for transmitting and another for receiving. 
I have started both workers and when they have reached their step-commands at 
the same time, I got the error that one of the boards could not be found or is 
not connected. Therefore, I think MATLAB cannot send the step-command to two 
different USB-ports simultaneously.



I was also thinking of starting the transmitting board first and then the 
receiving board. With the code in the attachment I can see a part of the 
transmitted signal. Furthermore, the transmitter just transmits single frames 
but not a continuous signal. My aim is to transmit for 6 seconds without a 
break and receive 5 seconds of this (at the first samples the signal shows a 
settle behavior, I do not want to receive).

I have also tried to work by enabling the burst mode but then MATLAB send one 
step-command and waits until the board finishes transmitting and starts the 
following step-command for the other board then. In that way I cannot receive 
any part of the transmitted signal.



Is there a possibility to transmit from one board and receive this signal on 
another B210 simultaneously (with one computer)? How do I implement this in 
MATLAB? I am looking forward to get some new ideas I can try.



Best,



Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/66bc3271/attachment-0001.html>

------------------------------

Message: 8
Date: Wed, 18 May 2016 14:54:40 -0400
From: avinash kalyanaraman <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Pulse Radar
Message-ID:
        <cajpbu_faxhczxhhulpeeomwtleimsimb-xep3hbfyd5vhlm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thanks.

It's a bistatic setup.

Would there be an issue if I have a GPSDO connecting to a receiver array of
USRPs, so that I can calculate the angle of arrival (via the phase
difference) ? With a Octoclock, can I be guaranteed sample time alignment
between the receiver USRPs ?

If so, does the Octoclock give me sample-time alignment out of the box (or)
would I need to make any changes for that ?

Thanks,

On Wed, May 18, 2016 at 1:28 PM, Martin Braun <[email protected]>
wrote:

> On 05/18/2016 08:54 AM, avinash kalyanaraman via USRP-users wrote:
> > Hi all,
> >
> > I have a couple of USRP N210s with the WBX-daughter boards, and I want
> > to build a simple pulse radar with them- i.e.  I want to be able to
> > generate and receive a pulse between them, and calculate the time delay.
> > In this regard I have a couple of questions:
> >
> > (i) How do I generate a pulse? Is multiplying square waves my best
> > option in generating a pulse ? What would be the smallest pulse width I
> > might be able to get?
>
> Pulses are difficult. If you're driving this in a standard UHD/Ethernet
> fashion (i.e., no FPGA mods) you can get a max sampling rate of 25 Msps,
> so not very short pulses. With some kind of *pulse compression* (i.e.,
> correlation) you can get much better results though. Or you use any kind
> of radar scheme that doesn't require high bandwidths.
>
> > (ii) To get the two USRPs to synchronize in time so that the time of
> > flight can be calculated, I plan to use the GPSDO. What is the accuracy
> > of the GPSDO unit? I.e. what's the difference in absolute timestamps
> > that I can expect ?
>
> Is this a bistatic setup, or are are your USRPs in the same spot? If so,
> just use MIMO cable. You will get sample-accurate synchronization this
> way. With a GPSDO, your mileage will vary, but I doubt you'd be good
> enough for radar. And I'm less worried about the timing: Note that even
> small drifts in the clock frequency provided by the GPSDOs can translate
> to big Doppler differences. Ideally, you really want the same LO on both
> tx and rx components. Sharing the actual reference clock is the closest
> you can get with N210s.
>
> Cheers,
> Martin
>
> > Am I missing anything else here in getting this setup running ?
> >
> > Please let me know,
> >
> > Thanks,
> >
> > --
> > Avinash
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>


-- 
Avinash Kalyanaraman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/511263d5/attachment-0001.html>

------------------------------

Message: 9
Date: Wed, 18 May 2016 19:55:21 +0000
From: "Sebastian M. Richter" <[email protected]>
To: Ethem Sozer <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] WG: How do I transmit and receive signals on
        two B210 simultaneously with MATLAB?
Message-ID:
        
<blupr03mb1380e791ab197656fa28916090...@blupr03mb1380.namprd03.prod.outlook.com>
        
Content-Type: text/plain; charset="us-ascii"

Hi Ethem,


thank you very much for your answer. If I got it right, MATLAB 2016a uses UHD 
3.9.1. Is the bug described by your previous mail fixed with that version?



Best,


Sebastian

________________________________
Von: Ethem Sozer <[email protected]>
Gesendet: Mittwoch, 18. Mai 2016 20:24:47
An: Sebastian M. Richter
Cc: [email protected]
Betreff: RE: [USRP-users] WG: How do I transmit and receive signals on two B210 
simultaneously with MATLAB?

Hi Sebastian,
MATLAB 2015b USRP Support Package uses UHD version 3.8.2. This version of UHD 
has a bug that prevents more than one B210 radio to be connected on a Windows 
machine. Since the step command uses UHD underneath, you cannot call step on 
two radios on a single Windows machine. It works on Linux or Mac.
Regards,
Ethem


From: USRP-users [mailto:[email protected]] On Behalf Of 
Sebastian M. Richter via USRP-users
Sent: Wednesday, May 18, 2016 12:40 PM
To: [email protected]
Subject: [USRP-users] WG: How do I transmit and receive signals on two B210 
simultaneously with MATLAB?

Hello,



currently I am using two Ettus B210 and MATLAB 2015b on a Win7. Working with a 
single board I can receive and transmit signals without problems. Now I want to 
transmit a signal from both Tx ports on one board and receive these signals 
from both Rx ports on  another board. For transmitting and receiving signals I 
am using the 'step'-command. From my way of thinking, one possible way would be 
to send the transmit and receive commands for both boards simultaneously. I 
have tried this by using one worker for transmitting and another for receiving. 
I have started both workers and when they have reached their step-commands at 
the same time, I got the error that one of the boards could not be found or is 
not connected. Therefore, I think MATLAB cannot send the step-command to two 
different USB-ports simultaneously.



I was also thinking of starting the transmitting board first and then the 
receiving board. With the code in the attachment I can see a part of the 
transmitted signal. Furthermore, the transmitter just transmits single frames 
but not a continuous signal. My aim is to transmit for 6 seconds without a 
break and receive 5 seconds of this (at the first samples the signal shows a 
settle behavior, I do not want to receive).

I have also tried to work by enabling the burst mode but then MATLAB send one 
step-command and waits until the board finishes transmitting and starts the 
following step-command for the other board then. In that way I cannot receive 
any part of the transmitted signal.



Is there a possibility to transmit from one board and receive this signal on 
another B210 simultaneously (with one computer)? How do I implement this in 
MATLAB? I am looking forward to get some new ideas I can try.



Best,



Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/c7208f3c/attachment-0001.html>

------------------------------

Message: 10
Date: Wed, 18 May 2016 19:56:31 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>, Martin Braun
        <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] Confusion over data formatting for a waveform in
        QT GUI Time Sink, File Sink, and RFNoC noc_block_moving_avg
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

Jonathon and Martin,

I am running a simple passthrough test from waveform generation in 
gnuradio-companion, then through RFNoC, and then verified with 
gnuradio-companion.  Here are my steps and questions:


  1.  ?Generate a waveform in gnuradio-companion.
  2.  View the waveform in QT GUI Time Sink and verify the waveform is between 
-1 and 1.  The IO Type is Complex.
  3.  Send the waveform to File Sink.
  4.  View the file in an editor such as Ultraedit.  Here is my first line of 
code that is supposed to represent a waveform between -1 and 1  I am only 
showing what I believe is the first two sets of 32-bit real and imaginary 
values in IEEE 754 Format.
  5.  C3 08 41 B8 C3 08 41 B8 D4 76 A1 38 D4 76 A1 38
  6.  Here is my first question:  Are the first 32 bits real or imaginary? 
(0xC30841B8)
  7.  Let's look at the first number: C3 08 41 B8.  When I plug this into an 
IEEE 754 Converter such as 
http://www.h-schmidt.net/FloatConverter/IEEE754.html, I get 
0xC30841B8=-136.25671.  Why isn't it between -1 and 1 just like QT GUI Time 
Sink?
  8.  Once I can agree that my 32 bit real and imaginary numbers are making 
sense in QT GUI Time Sink and File Sink, then I have to convert that 32 bit hex 
value into Q16 format which RFNoC noc_block_moving_avg is expecting to be sent 
to i_tdata (64 bits=two sets of real and imag) and then m_axis_data_tdata(32 
bits=one set of real and imag, sent twice=64 bits)?
  9.  How do I convert the 32 bit IEEE 754 data (gnuradio) into Q16 (RFNoC)?

Craig


Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/ab7e141a/attachment-0001.html>

------------------------------

Message: 11
Date: Wed, 18 May 2016 20:01:39 +0000
From: Ethem Sozer <[email protected]>
To: "Sebastian M. Richter" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] WG: How do I transmit and receive signals on
        two B210 simultaneously with MATLAB?
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="us-ascii"

Hi Sebastian,

I am told that UHD version 3.9.4 is going to fix this issue but it is not 
released yet.

Do you absolutely need to use two radios on the same Windows computer? Is Mac 
or Linux an option? If you describe your use case, we may be able to come up 
with an alternative structure.

Regards,
Ethem

From: Sebastian M. Richter [mailto:[email protected]]
Sent: Wednesday, May 18, 2016 3:55 PM
To: Ethem Sozer <[email protected]>
Cc: [email protected]
Subject: AW: [USRP-users] WG: How do I transmit and receive signals on two B210 
simultaneously with MATLAB?


Hi Ethem,



thank you very much for your answer. If I got it right, MATLAB 2016a uses UHD 
3.9.1. Is the bug described by your previous mail fixed with that version?





Best,



Sebastian

________________________________
Von: Ethem Sozer <[email protected]<mailto:[email protected]>>
Gesendet: Mittwoch, 18. Mai 2016 20:24:47
An: Sebastian M. Richter
Cc: [email protected]<mailto:[email protected]>
Betreff: RE: [USRP-users] WG: How do I transmit and receive signals on two B210 
simultaneously with MATLAB?

Hi Sebastian,
MATLAB 2015b USRP Support Package uses UHD version 3.8.2. This version of UHD 
has a bug that prevents more than one B210 radio to be connected on a Windows 
machine. Since the step command uses UHD underneath, you cannot call step on 
two radios on a single Windows machine. It works on Linux or Mac.
Regards,
Ethem


From: USRP-users [mailto:[email protected]] On Behalf Of 
Sebastian M. Richter via USRP-users
Sent: Wednesday, May 18, 2016 12:40 PM
To: [email protected]<mailto:[email protected]>
Subject: [USRP-users] WG: How do I transmit and receive signals on two B210 
simultaneously with MATLAB?

Hello,



currently I am using two Ettus B210 and MATLAB 2015b on a Win7. Working with a 
single board I can receive and transmit signals without problems. Now I want to 
transmit a signal from both Tx ports on one board and receive these signals 
from both Rx ports on  another board. For transmitting and receiving signals I 
am using the 'step'-command. From my way of thinking, one possible way would be 
to send the transmit and receive commands for both boards simultaneously. I 
have tried this by using one worker for transmitting and another for receiving. 
I have started both workers and when they have reached their step-commands at 
the same time, I got the error that one of the boards could not be found or is 
not connected. Therefore, I think MATLAB cannot send the step-command to two 
different USB-ports simultaneously.



I was also thinking of starting the transmitting board first and then the 
receiving board. With the code in the attachment I can see a part of the 
transmitted signal. Furthermore, the transmitter just transmits single frames 
but not a continuous signal. My aim is to transmit for 6 seconds without a 
break and receive 5 seconds of this (at the first samples the signal shows a 
settle behavior, I do not want to receive).

I have also tried to work by enabling the burst mode but then MATLAB send one 
step-command and waits until the board finishes transmitting and starts the 
following step-command for the other board then. In that way I cannot receive 
any part of the transmitted signal.



Is there a possibility to transmit from one board and receive this signal on 
another B210 simultaneously (with one computer)? How do I implement this in 
MATLAB? I am looking forward to get some new ideas I can try.



Best,



Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/29843fe5/attachment-0001.html>

------------------------------

Message: 12
Date: Wed, 18 May 2016 16:20:32 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Resetting N210 & X310 Remotely
Message-ID:
        <CAK6GVuMhWBJ__XXiUCk2hz09=2s_jmepw99xnrpji9a4ah5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Is it possible to reset the N210 and X310 radios remotely?  Hopefully some
API command that can trigger something like an FPGA reset / bit file reload?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/58b32032/attachment-0001.html>

------------------------------

Message: 13
Date: Wed, 18 May 2016 22:22:44 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Burst Tx and Underrun
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"

Hi JM,

Two things:
First, it seems you're resampling to 1MS/s, but you use 2MS/s in your
sink. That doesn't lead to any Underruns, but will make everything in
your baseband signal be interpreted at twice the sampling rate. Is that
a typo?

Secondly, generally, I recommend the rational resampler ? because it's
very efficient at what it does. However,

  * you should configure it with interpolation and decimations that
    don't share any prime factors, and 1,000,000 and 655360 share one
    prime factor of five and six prime factors of 2, and
  * it's only an efficient solution if the resulting factors aren't very
    large ? 15625 and 1024 (that being the reduced
    interpolation/decimation factors) are very large, so the resulting
    resampling filter will need to be very harsh.

This might really be the case where an arbitrary resampler might work
better. As it is now, the resampling filter probably eats up all your
CPU. Try the PFB resampler, or try something different than 1 or 2 MS as
sampling rate for the USRP ? the B-series USRPs are very flexible in
terms of possible rates, and the USRP2/N2xx series can take most integer
factors of 100MS/s, and the X3xx series integer factors of 200, 184.32
and 120 MS/s.

Best regards,
Marcus


On 18.05.2016 11:31, JM via USRP-users wrote:
> Hi Everyone,
>
> I'm currently trying to implement a burst 2-FSK data transmitter which
> fulfill these parameters :
> - Bit_rate : 32768
> - FSK_deviation : 50k
> - Center Freq : 868MHz
>
> Here my simple flowgraph : http://i.imgur.com/u6LOK5m.png
>
>
> The very precise baud_rate was a problem at first, because the USRP
> sample rate was a multiple of baud_rate and was not supported (UHD
> Warning: "expect CIC rolloff" & "The hardware does not support the
> requested TX sample rate" ), so i inserted a Rational Resampler and it
> solved this issue quite well.
>
> With this Tx chain, i can recover the data with a 60% sucess ratio.
> For the 40% failed data, I see a "hole" in my recovered data, as if
> the USRP stoped transmitting for a very short period of time (randomly
> in the body of the message)
>
> I think the problem is linked to the "Under run" warning observed at
> each burst (only a single one).
> - I first tried to use the "length tag" ( but the number of samples
> for my burst has changed after the modulation chain (and of course,
> after the resampling) .. so i didn't find any way to recalculate it
> precisely to modify the tag before the USRP sink.
> - I then tried to use the couple tx_sob / tx_eob with a custom block
> (which is quite fun after all) after the PDU to Tagged stream block.
> Length tag is removed (to enable tx_sob/tx_eob parsing), tx_sob is
> inserted at the first sample and tx eob is inserted at the last
> sample. After resampling, another custom block is shifting tx_eob tag
> to the last sample of the sample set.
>
> None of these tries removed the "U" warning, but i achieved to get 85%
> receive success by sending quite a big padding before any packet ...
> It's better but it's a dirty fix, i don't like it :)
>
>
> I'm running out of ideas and blocks coding experiments .. Anyone has
> any ideas ?
>
> Thanks !
>
> -JM
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/1aa0cc59/attachment-0001.html>

------------------------------

Message: 14
Date: Wed, 18 May 2016 22:30:05 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Pulse Radar
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252

Hi Avinash,


On 18.05.2016 20:54, avinash kalyanaraman via USRP-users wrote:
> Thanks.
>
> It's a bistatic setup. 
>
> Would there be an issue if I have a GPSDO connecting to a receiver
> array of USRPs, so that I can calculate the angle of arrival (via the
> phase difference) ?
> With a Octoclock, can I be guaranteed sample time alignment between
> the receiver USRPs ?
The octoclock can distribute a single clock&PPS source (e.g. from the
integrated GPSDO of a Octoclock-G model variant) to up to eight USRPs.
With the common 10MHz clock, frequency coherency is achieved, with the
PPS, a common absolute time is established, which can be used to
reliably tune your daughterboards.
With one Caveat: the WBX tunes reliably to the same LO phase, every
tune, so that works, but that phase has a +-180? (i.e. sign) ambiguity.
The general process is described in [1].
>
> If so, does the Octoclock give me sample-time alignment out of the box
> (or) would I need to make any changes for that ? 
>
The Octoclock only distrubitues clock and PPS signals ? but with that,
the N210 is able to tell the WBX exactly when to tune the LO, and so,
this works.
You don't need to modify anything, but your application needs to make
sure the necessary steps (ie. timed tuning) are done.

Best regards,
Marcus

[1] http://files.ettus.com/manual/page_sync.html#sync_phase



------------------------------

Message: 15
Date: Wed, 18 May 2016 20:33:28 +0000
From: "Sebastian M. Richter" <[email protected]>
To: Ethem Sozer <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] WG: How do I transmit and receive signals on
        two B210 simultaneously with MATLAB?
Message-ID:
        
<blupr03mb138035a74e40fd24ca11b15b90...@blupr03mb1380.namprd03.prod.outlook.com>
        
Content-Type: text/plain; charset="us-ascii"

Hi Ethem,


thank you for answering my questions.


My aim is to transmit from one board and receive data on 8 other B210. I want 
to transmit a signal and measure it on different positions simultaneously.


Using two computers would be acceptable but 9 computers is too much. Apart from 
that, I am planning to call the MATLAB code from labview. The labview version, 
I have, is for windows and it also calls other windows-based software, in my 
case. Therefore, running MATLAB in windows would be optimal. In general, I can 
also prepare a second computer with linux (and MATLAB) and try to build a 
communication between the windows and linux computers.



Best,


Sebastian

________________________________
Von: Ethem Sozer <[email protected]>
Gesendet: Mittwoch, 18. Mai 2016 22:01:39
An: Sebastian M. Richter
Cc: [email protected]
Betreff: RE: [USRP-users] WG: How do I transmit and receive signals on two B210 
simultaneously with MATLAB?

Hi Sebastian,

I am told that UHD version 3.9.4 is going to fix this issue but it is not 
released yet.

Do you absolutely need to use two radios on the same Windows computer? Is Mac 
or Linux an option? If you describe your use case, we may be able to come up 
with an alternative structure.

Regards,
Ethem

From: Sebastian M. Richter [mailto:[email protected]]
Sent: Wednesday, May 18, 2016 3:55 PM
To: Ethem Sozer <[email protected]>
Cc: [email protected]
Subject: AW: [USRP-users] WG: How do I transmit and receive signals on two B210 
simultaneously with MATLAB?


Hi Ethem,



thank you very much for your answer. If I got it right, MATLAB 2016a uses UHD 
3.9.1. Is the bug described by your previous mail fixed with that version?





Best,



Sebastian

________________________________
Von: Ethem Sozer <[email protected]<mailto:[email protected]>>
Gesendet: Mittwoch, 18. Mai 2016 20:24:47
An: Sebastian M. Richter
Cc: [email protected]<mailto:[email protected]>
Betreff: RE: [USRP-users] WG: How do I transmit and receive signals on two B210 
simultaneously with MATLAB?

Hi Sebastian,
MATLAB 2015b USRP Support Package uses UHD version 3.8.2. This version of UHD 
has a bug that prevents more than one B210 radio to be connected on a Windows 
machine. Since the step command uses UHD underneath, you cannot call step on 
two radios on a single Windows machine. It works on Linux or Mac.
Regards,
Ethem


From: USRP-users [mailto:[email protected]] On Behalf Of 
Sebastian M. Richter via USRP-users
Sent: Wednesday, May 18, 2016 12:40 PM
To: [email protected]<mailto:[email protected]>
Subject: [USRP-users] WG: How do I transmit and receive signals on two B210 
simultaneously with MATLAB?

Hello,



currently I am using two Ettus B210 and MATLAB 2015b on a Win7. Working with a 
single board I can receive and transmit signals without problems. Now I want to 
transmit a signal from both Tx ports on one board and receive these signals 
from both Rx ports on  another board. For transmitting and receiving signals I 
am using the 'step'-command. From my way of thinking, one possible way would be 
to send the transmit and receive commands for both boards simultaneously. I 
have tried this by using one worker for transmitting and another for receiving. 
I have started both workers and when they have reached their step-commands at 
the same time, I got the error that one of the boards could not be found or is 
not connected. Therefore, I think MATLAB cannot send the step-command to two 
different USB-ports simultaneously.



I was also thinking of starting the transmitting board first and then the 
receiving board. With the code in the attachment I can see a part of the 
transmitted signal. Furthermore, the transmitter just transmits single frames 
but not a continuous signal. My aim is to transmit for 6 seconds without a 
break and receive 5 seconds of this (at the first samples the signal shows a 
settle behavior, I do not want to receive).

I have also tried to work by enabling the burst mode but then MATLAB send one 
step-command and waits until the board finishes transmitting and starts the 
following step-command for the other board then. In that way I cannot receive 
any part of the transmitted signal.



Is there a possibility to transmit from one board and receive this signal on 
another B210 simultaneously (with one computer)? How do I implement this in 
MATLAB? I am looking forward to get some new ideas I can try.



Best,



Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/fb601aa6/attachment-0001.html>

------------------------------

Message: 16
Date: Wed, 18 May 2016 13:43:46 -0700
From: Ian Buckley <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: Jonathon Pendlum <[email protected]>,      Martin Braun
        <[email protected]>,       "[email protected]"
        <[email protected]>
Subject: Re: [USRP-users] Confusion over data formatting for a
        waveform in QT GUI Time Sink, File Sink, and RFNoC
        noc_block_moving_avg
Message-ID:
        <CAM_0ocGyMExxTmLx=g3Ody+U+qzCXjUu4a=fixrygokadpx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Craig,
Real then imaginary in the file. On Intel you probably need to byte
exchange within 32bits to do an endian swap to plug the values into your
website.
The attached flowgraph should help you confirm to yourself which is real
and which is imaginary.
-ian


On Wed, May 18, 2016 at 12:56 PM, Swanson, Craig via USRP-users <
[email protected]> wrote:

> Jonathon and Martin,
>
> I am running a simple passthrough test from waveform generation in
> gnuradio-companion, then through RFNoC, and then verified with
> gnuradio-companion.  Here are my steps and questions:
>
>
>
>    1. ?Generate a waveform in gnuradio-companion.
>    2. View the waveform in QT GUI Time Sink and verify the waveform is
>    between -1 and 1.  The IO Type is Complex.
>    3. Send the waveform to File Sink.
>    4. View the file in an editor such as Ultraedit.  Here is my first
>    line of code that is supposed to represent a waveform between -1 and 1  I
>    am only showing what I believe is the first two sets of 32-bit real and
>    imaginary values in IEEE 754 Format.
>    5. C3 08 41 B8 C3 08 41 B8 D4 76 A1 38 D4 76 A1 38
>    6. Here is my first question:  Are the first 32 bits real or
>    imaginary? (0xC30841B8)
>    7. Let's look at the first number: C3 08 41 B8.  When I plug this into
>    an IEEE 754 Converter such as
>    http://www.h-schmidt.net/FloatConverter/IEEE754.html, I get
>    0xC30841B8=-136.25671.  Why isn't it between -1 and 1 just like QT GUI Time
>    Sink?
>    8. Once I can agree that my 32 bit real and imaginary numbers are
>    making sense in QT GUI Time Sink and File Sink, then I have to convert that
>    32 bit hex value into Q16 format which RFNoC noc_block_moving_avg is
>    expecting to be sent to i_tdata (64 bits=two sets of real and imag) and
>    then m_axis_data_tdata(32 bits=one set of real and imag, sent twice=64
>    bits)?
>    9. How do I convert the 32 bit IEEE 754 data (gnuradio) into
>    Q16 (RFNoC)?
>
> Craig
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/26ec8066/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iq_filetest.grc
Type: application/octet-stream
Size: 9105 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/26ec8066/attachment-0001.grc>

------------------------------

Message: 17
Date: Wed, 18 May 2016 22:07:09 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] How do timed commands work?
Message-ID:
        <CAK6GVuMdtYhC=zwy8i0w0kl389oooy0a83cnm9xhwprknmt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I've been poking around the UHD host library trying to figure out how the
timed commands actually work.  I see that the tree is getting updated, but
I can't seem to figure out what happens after that.  Is there some async
thread that picks up values from the tree?  At what point do the commands
actually get sent to the radio?  Is there a buffer on the radio for storing
up to X timed commands?

Also, what things can be changed via the timed command interface?  I
remember seeing a webpage that listed all of them, but I cannot seem to
find it anymore.  I think it was a page that listed information about the
PMT interface for GNU Radio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/be921e9c/attachment-0001.html>

------------------------------

Message: 18
Date: Wed, 18 May 2016 22:15:43 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How do timed commands work?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

On 05/18/2016 10:07 PM, Dave NotTelling via USRP-users wrote:
> I've been poking around the UHD host library trying to figure out how 
> the timed commands actually work.  I see that the tree is getting 
> updated, but I can't seem to figure out what happens after that.  Is 
> there some async thread that picks up values from the tree?  At what 
> point do the commands actually get sent to the radio?  Is there a 
> buffer on the radio for storing up to X timed commands?
There's a (not very deep) queue in the radio that is handled by the 
FPGA.  The tree architecture allows for "publishers" and "subscribers",
   so the "top half" publishes updates to the tree, and underlying 
device-specific code "subscribes" to updates to the tree.  I believe this
   is a standard boost::property_tree thingy.

So, the timed commands are picked from the queue in-order, and the FPGA 
uses the device time to process commands.

Off the top of my head:

tuning
gain setting
stream start/stop
...probably others...

The whole "timed commands" thing was originally invented to allow 
time-synchronized setting of tuning parameters for daughtercards that
   have a phase-resynch feature in them (SBX, WBX, UBX, CBX), said 
feature only works properly if all synthesizers (all daughtercards) tune
   their VFOs at precisely the same time, because the phase-reset pulse 
has to happen at precisely the same time for all synthesizers.

But, once you have the goop in-place on the FPGA, you might as well 
generalize for other hardware-setting commands.

B2xx doesn't support timed commands, but  N2xx and X3xx do.


>
> Also, what things can be changed via the timed command interface?  I 
> remember seeing a webpage that listed all of them, but I cannot seem 
> to find it anymore.  I think it was a page that listed information 
> about the PMT interface for GNU Radio.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/9aafe53c/attachment-0001.html>

------------------------------

Message: 19
Date: Thu, 19 May 2016 11:37:34 +0800
From: liu Jong <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>,  Ettus
        Research Support <[email protected]>
Subject: Re: [USRP-users] UBX can not transmit signal
Message-ID:
        <caeui2n0c4ruxff4w6_fwtmp0nmzh0dumgmy5_-gbs3qhq+0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Michael,
thank you for help.
best regards
Jon

2016-05-19 1:45 GMT+08:00 Michael West <[email protected]>:

> Hi Jon,
>
> I just tested on N210+UBX and it worked fine for me (previous tests were
> X310+UBX).  I don't know what to say about your UBX boards.  I recommend
> contacting Ettus support ([email protected]) for an RMA.
>
> Regards,
> Michael
>
> On Tue, May 17, 2016 at 6:43 PM, liu Jong <[email protected]> wrote:
>
>> Hi,Michael,
>> I uesd N210+UBX?and just transmit a sine signal.i tred the gain from 0 to
>> 38 and the frequency 10M to 6GHz.i receive the signal when i used 158277B-01L
>> ,but with 158277A-01L can not.
>> is it possible that there is some thing wrong with hardware?
>> thank you
>> best regards
>> Jon
>>
>> 2016-05-18 6:23 GMT+08:00 Michael West <[email protected]>:
>>
>>> Hi Jon,
>>>
>>> I was able to use UHD 3.9.4 and a 158277A-02L UBX board to transmit just
>>> fine.  Please provide more information about your set up.  What type of
>>> USRP are you using?  What are your frequency and gain settings?  What are
>>> you using to transmit?  What are you using to verify transmission?
>>>
>>> Regards,
>>> Michael
>>>
>>> On Mon, May 16, 2016 at 5:57 PM, liu Jong <[email protected]> wrote:
>>>
>>>> Hi,Michael,
>>>> there is no error information,and the TX/RX port is also lighting.But
>>>>  it can not transmit signal.
>>>> thank you.
>>>> Jon
>>>>
>>>>
>>>> 2016-05-16 21:56 GMT+08:00 Michael West <[email protected]>:
>>>>
>>>>> Hi Jon,
>>>>>
>>>>> There is no firmware on the UBX and there is no difference in software
>>>>> for the different versions.  What is the exact error you are seeing?
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>> On Sun, May 15, 2016 at 10:54 PM, liu Jong <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi Michael,
>>>>>> thank you for your davices.i tried it,but no use.But if i change to 
>>>>>> 158277B-01L
>>>>>> UBX,it works ok.Can UBX be flashed firmware,or some other measures i 
>>>>>> should
>>>>>> take?
>>>>>> best regards
>>>>>> Jon
>>>>>>
>>>>>> 2016-05-13 22:42 GMT+08:00 Michael West <[email protected]>:
>>>>>>
>>>>>>> Hi Jon,
>>>>>>>
>>>>>>> There is an issue with some components on the bottom side of the UBX
>>>>>>> being too close to the mounting holes and shorting out to the 
>>>>>>> daughterboard
>>>>>>> standoffs on the X300/X310.  You can rotate the existing standoffs so 
>>>>>>> they
>>>>>>> provide more clearance for the components or install thinner standoffs.
>>>>>>>
>>>>>>> I'm not sure, but I thought the UBX shipped with the thinner
>>>>>>> standoffs.  If not, you can  contact [email protected] to request
>>>>>>> them.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Michael
>>>>>>>
>>>>>>> On Thu, May 12, 2016 at 11:58 PM, liu Jong via USRP-users <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Dear all,
>>>>>>>>          We have  3 pieces of UBX-40 board?one of which the part
>>>>>>>> number is 158277B-01L and it send and receive signals normally.the 
>>>>>>>> others
>>>>>>>> of part number are all 158277A-01L and they only received signal, but
>>>>>>>> couldn't send out a signal. We  tested this on  the uhd3.9.4 . 
>>>>>>>> According to
>>>>>>>> different part number,  need we to do some special settings?
>>>>>>>>
>>>>>>>> thank you
>>>>>>>> best regards
>>>>>>>> Jon
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> USRP-users mailing list
>>>>>>>> [email protected]
>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/457857f8/attachment-0001.html>

------------------------------

Message: 20
Date: Thu, 19 May 2016 06:03:05 +0200
From: hanwen <[email protected]>
To: "[email protected]" <[email protected]>,  Michael
        West <[email protected]>,  Marcus M?ller
        <[email protected]>
Subject: [USRP-users] UBX Tx-to-Rx interference,        Performance and
        Power-Save modes
Message-ID:
        <cabjuse037rzbegx75jcrpq5+bxs-oxytg9malbb7p7fxj-4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Dear USRP users and experts,



Instructed by Michael in:
https://www.mail-archive.com/[email protected]/msg01766.html

I tried the switching between powersave and performance mode for the new
UBX and did some further test.



Basic config: 11.42MS/s, Carrier: 2.6GHz, TDMA mode with 1ms time slot and
one device switches between Tx and Rx every 1ms; UHD and firmware are the
fresh 3.9.4 release.





*Power Save*

*Performance*

*Tx*

The transmitted signal is very weak no matter what Tx gain is chosen

The transmission is fine, but the maximum Tx power is 2~3dB lower than SBX

The device is getting very hot

*Rx*

The noise floor not affected by Tx

Noise floor rising up by c.a. 7dB by setting to higher Tx gain (>21.5),
EVEN WHEN no transmission in Tx slot



In the attachment you could see some screenshots:

?         Tg_1.5~31.5.png: showing the rising Rx noise floor in the default
Performance mode

?         Cst_performance/powersave.png: showing in the Powersave mode: the
constellation demodulated at another device is very poor due to weak
transmit power.



For both powersave and performance mode we observed unacceptable problems
for our system, but using the older SBX-40 and SBX 120 boards we didn?t
observe these problems.



Bests, Hanwen



[image: ???? 7][image: ???? 8][image: ???? 9][image: ???? 10][image: ????
11][image: ???? 12]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/1bc650f4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_21.5.png
Type: image/png
Size: 25015 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/1bc650f4/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_1.5.png
Type: image/png
Size: 24942 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/1bc650f4/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cst_powersave.png
Type: image/png
Size: 31677 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/1bc650f4/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_31.5.png
Type: image/png
Size: 25055 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/1bc650f4/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cst_performance.png
Type: image/png
Size: 21136 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/1bc650f4/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_11.5.png
Type: image/png
Size: 24955 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/1bc650f4/attachment-0011.png>

------------------------------

Message: 21
Date: Wed, 18 May 2016 21:54:32 -0700
From: Ian Buckley <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How do timed commands work?
Message-ID:
        <cam_0ocfaxphpvrgyv4sqz-rjxxkokpqhf5selrhhhrdasew...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

> B2xx doesn't support timed commands, but  N2xx and X3xx do.

B2xx don't support timed commands sent to the radio (gain, VCO tuning,
etc)...they do support timed streaming start/stop, CORDIC adjuctments etc.

On Wed, May 18, 2016 at 7:15 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:

> On 05/18/2016 10:07 PM, Dave NotTelling via USRP-users wrote:
>
> I've been poking around the UHD host library trying to figure out how the
> timed commands actually work.  I see that the tree is getting updated, but
> I can't seem to figure out what happens after that.  Is there some async
> thread that picks up values from the tree?  At what point do the commands
> actually get sent to the radio?  Is there a buffer on the radio for storing
> up to X timed commands?
>
> There's a (not very deep) queue in the radio that is handled by the FPGA.
> The tree architecture allows for "publishers" and "subscribers",
>   so the "top half" publishes updates to the tree, and underlying
> device-specific code "subscribes" to updates to the tree.  I believe this
>   is a standard boost::property_tree thingy.
>
> So, the timed commands are picked from the queue in-order, and the FPGA
> uses the device time to process commands.
>
> Off the top of my head:
>
> tuning
> gain setting
> stream start/stop
> ...probably others...
>
> The whole "timed commands" thing was originally invented to allow
> time-synchronized setting of tuning parameters for daughtercards that
>   have a phase-resynch feature in them (SBX, WBX, UBX, CBX), said feature
> only works properly if all synthesizers (all daughtercards) tune
>   their VFOs at precisely the same time, because the phase-reset pulse has
> to happen at precisely the same time for all synthesizers.
>
> But, once you have the goop in-place on the FPGA, you might as well
> generalize for other hardware-setting commands.
>
> B2xx doesn't support timed commands, but  N2xx and X3xx do.
>
>
>
> Also, what things can be changed via the timed command interface?  I
> remember seeing a webpage that listed all of them, but I cannot seem to
> find it anymore.  I think it was a page that listed information about the
> PMT interface for GNU Radio.
>
>
> _______________________________________________
> USRP-users mailing 
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160518/222212d9/attachment-0001.html>

------------------------------

Message: 22
Date: Thu, 19 May 2016 06:21:38 +0000
From: "Swanson, Craig" <[email protected]>
To: Ian Buckley <[email protected]>
Cc: Jonathon Pendlum <[email protected]>, Martin Braun
        <[email protected]>, "[email protected]"
        <[email protected]>
Subject: Re: [USRP-users] Confusion over data formatting for a
        waveform in QT GUI Time Sink, File Sink, and RFNoC
        noc_block_moving_avg
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

?Ian,

Yes, thank you.  That cleared up my first question.  I needed to translate from 
little endian to big endian format.


Now on to my second question.   Currently I am using cocotb as a testbench for 
my noc_block_Receiver which currently is just doing a passthrough.  Cocotb 
allows me to use python instead of System Verilog for my testbench.  I know 
that System Verilog is very powerful and that is what Jonathon is using for his 
testbench.  But I am not an expert on it yet and therefore it is difficult for 
me to fully understand how his code works and then to make modifications.


So now that I understand that I need to byte exchange the 32 bits and do an 
endian swap, I want to send this data into my python based cocotb testbench 
which runs in Mentor Modelsim DE 10.4c in VHDL for my noc_block_Receiver_tb.  
The noc_block is expecting me to send a 64-bit set of real and imaginary 16-bit 
pairs.


So do I need to simply truncate the data value for the real as  B8 41 08 C3 as 
B8 41?  I believe the RFNoC operates in Fixed Point Two's Complement Q16 (must 
be a fraction).


Craig


Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>

________________________________
From: Ian Buckley <[email protected]>
Sent: Wednesday, May 18, 2016 4:43 PM
To: Swanson, Craig
Cc: Jonathon Pendlum; Martin Braun; [email protected]
Subject: Re: [USRP-users] Confusion over data formatting for a waveform in QT 
GUI Time Sink, File Sink, and RFNoC noc_block_moving_avg

Craig,
Real then imaginary in the file. On Intel you probably need to byte exchange 
within 32bits to do an endian swap to plug the values into your website.
The attached flowgraph should help you confirm to yourself which is real and 
which is imaginary.
-ian


On Wed, May 18, 2016 at 12:56 PM, Swanson, Craig via USRP-users 
<[email protected]<mailto:[email protected]>> wrote:

Jonathon and Martin,

I am running a simple passthrough test from waveform generation in 
gnuradio-companion, then through RFNoC, and then verified with 
gnuradio-companion.  Here are my steps and questions:


  1.  ?Generate a waveform in gnuradio-companion.
  2.  View the waveform in QT GUI Time Sink and verify the waveform is between 
-1 and 1.  The IO Type is Complex.
  3.  Send the waveform to File Sink.
  4.  View the file in an editor such as Ultraedit.  Here is my first line of 
code that is supposed to represent a waveform between -1 and 1  I am only 
showing what I believe is the first two sets of 32-bit real and imaginary 
values in IEEE 754 Format.
  5.  C3 08 41 B8 C3 08 41 B8 D4 76 A1 38 D4 76 A1 38
  6.  Here is my first question:  Are the first 32 bits real or imaginary? 
(0xC30841B8)
  7.  Let's look at the first number: C3 08 41 B8.  When I plug this into an 
IEEE 754 Converter such as 
http://www.h-schmidt.net/FloatConverter/IEEE754.html, I get 
0xC30841B8=-136.25671.  Why isn't it between -1 and 1 just like QT GUI Time 
Sink?
  8.  Once I can agree that my 32 bit real and imaginary numbers are making 
sense in QT GUI Time Sink and File Sink, then I have to convert that 32 bit hex 
value into Q16 format which RFNoC noc_block_moving_avg is expecting to be sent 
to i_tdata (64 bits=two sets of real and imag) and then m_axis_data_tdata(32 
bits=one set of real and imag, sent twice=64 bits)?
  9.  How do I convert the 32 bit IEEE 754 data (gnuradio) into Q16 (RFNoC)?

Craig


Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>


_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/11f13d25/attachment-0001.html>

------------------------------

Message: 23
Date: Thu, 19 May 2016 08:42:42 +0000
From: "Swanson, Craig" <[email protected]>
To: "[email protected]" <[email protected]>, Ian Buckley
        <[email protected]>, Martin Braun <[email protected]>
Cc: Jonathon Pendlum <[email protected]>,
        "[email protected]" <[email protected]>
Subject: [USRP-users] Data formatting questions for gnuradio complex
        to Q16  in RFNOC
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

Guys,

Sorry for not seeing Martin's response below on the mailing list until now.  
His explanation really helps.


I think it is my confusion over how the axi_wrapper.v works when I run it in 
Modelsim.


For every 64 bit data value sent to i_tdata, I see m_axis_data_tdata toggling 
twice.

input [63:0] i_tdata

output [31:0] m_axis_data_tdata


How is i_tdata related to m_axis_data_tdata?  I am assuming I am sending it a 
single complex value i and q, but what is m_axis_data_tdata sending out on the 
two clock edges?  My guess is that they are i and q.  If so, does it simply 
clock the same values out twice?  That is not what I am seeing.  I wish I could 
send you a snapshot waveform which would quickly explain my confusion.


Craig


Craig,

when we send integer data to the FPGA (sc16 format), the on-the-wire
format (in *little endian*) is 16 bits Q, 16 bits I. This is
unintuitive, and goes back to VITA-49, but the important thing is *you
don't need to care about it*. After the conversion, you'll either have a
valid std::complex<int16_t> (if your software uses sc16) or a valid
std::complex<float> (if your software uses fc32). (Note that the C++
standard defines std::complex<> such that it looks the same in memory as
an array, with index 0 being I, index 1 being Q).

If you want to send *float* data *to the FPGA*, I recommend sending
32-bits I, then 32-bits Q. Remember not only your FPGA will be more
heavily utilized, but also the I/Os will get heavier load.

In your Verilog, the output of the 32-bit output bus of AXI wrapper is
16-bit I, 16-bit Q.

Cheers,
Martin?


Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160519/5af7f343/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


------------------------------

End of USRP-users Digest, Vol 69, Issue 19
******************************************

Reply via email to