[USRP-users] Re: N300 device not found

2024-12-16 Thread joerg.hofrichter--- via USRP-users
Hi,

you could check if MPM (the daemon on the USRP which UHD connects to) reports 
any error during initialization. Log onto the device via ssh (ssh 
root@192.168.10.2) and execute the following command:

journalctl -b -u usrp-hwd --no-pager

Kind regards,\
Jörg
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] N300 device not found

2024-12-16 Thread yibindeng66
Hi all,

I encountered some issues while configuring the N300. The N300 responds to my 
ping requests, but the host cannot find the device using uhd_find_devices while 
correctly detecting b210 devices. 

I referred to this post on StackOverflow 
(https://stackoverflow.com/questions/33304828/when-trying-to-use-my-usrp-in-gnu-radio-i-get-a-no-devices-found-for?rq=1)
 but adding parameters and modifying the firewall settings did not resolve the 
issue. 

Configurations: MTU is manually set to 1500 bytes, IP address is 192.168.10.2, 
netmask is 255.255.255.0, and my UHD version is 4.7.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] Re: Fw: Re: Issue with Starting Transmitter on USRP N300 without Using Streamers

2024-12-16 Thread Rob Kossler via USRP-users
Hi Nidhi,
It seems you are connecting things correctly - I'm not sure why you are
getting that error.
Rob

On Fri, Dec 13, 2024 at 4:48 AM Nidhi Panda 
wrote:

>
> --
> *From:* Nidhi Panda 
> *Sent:* Friday, December 13, 2024 11:14 AM
> *To:* Rob Kossler 
> *Cc:* usrp-users@lists.ettus.com 
> *Subject:* [USRP-users] Re: Issue with Starting Transmitter on USRP N300
> without Using Streamers
>
> Hello Rob and Martin,
>
> Thank you for responding. We tried that, and got error related to edge
> property. We have also played around by making different combination of
> edges as " true or false" but ended up with same error message. I have
> attached a screenshot of connection and error message.
>
> Regards,
>
> Nidhi
> --
> *From:* Rob Kossler 
> *Sent:* Thursday, December 12, 2024 9:25 PM
> *To:* Nidhi Panda 
> *Cc:* Martin Braun ; usrp-users@lists.ettus.com <
> usrp-users@lists.ettus.com>
> *Subject:* Re: [USRP-users] Re: Issue with Starting Transmitter on USRP
> N300 without Using Streamers
>
> As a test case, perhaps try a graph where the Tx and Rx channels are not
> the same.
>
> On Thu, Dec 12, 2024 at 7:04 AM Nidhi Panda 
> wrote:
>
> Tried the way you suggested. Still getting same error. Please check if
> it's correct.
>
>
> --
> *From:* Martin Braun 
> *Sent:* Thursday, December 12, 2024 6:08 PM
> *Cc:* usrp-users@lists.ettus.com 
> *Subject:* [USRP-users] Re: Issue with Starting Transmitter on USRP N300
> without Using Streamers
>
> I don't have access to an N300, so I can't test it for you.
>
> One thing you can do is to generate the flow graph (don't run it!) and
> open the generated Python code in an editor.
> You will find a section like this:
>
> ##
> # Connections
> ##
> self.msg_connect((self.blocks_var_to_msg_0, 'msgout'),
> (self.uhd_rfnoc_rx_radio_0, 'command'))
> self.rfnoc_graph.connect(self.uhd_rfnoc_ddc_0.get_unique_id(), 0,
> self.uhd_rfnoc_duc_0.get_unique_id(), 0, False)
> self.rfnoc_graph.connect(self.uhd_rfnoc_duc_0.get_unique_id(), 0,
> self.uhd_rfnoc_tx_radio_0.get_unique_id(), 0, rx_slot == tx_slot)
>
> self.rfnoc_graph.connect(self.uhd_rfnoc_rx_radio_0.get_unique_id(), 0,
> self.uhd_rfnoc_ddc_0.get_unique_id(), 0, False)
> self.connect((self.blocks_null_source_0, 0),
> (self.blocks_throttle2_0, 0))
> self.connect((self.blocks_throttle2_0, 0),
> (self.blocks_null_sink_0, 0))
>
> Where we have the rfnoc_graph.connect() calls, you can see the back-edge
> argument towards the end. If you've set tx_slot and rx_slot to 0 (for an
> N300), then this should evaluate to True. You could try manually setting
> this to true, then running the Python code directly (not from GRC, or it
> will overwrite your code unless you copy the generated code to the side)
>
> --M
>
> On Thu, Dec 12, 2024 at 12:38 PM Nidhi Panda 
> wrote:
>
> Hello Martin,
>
> Thank you for your prompt reply. I have updated ' dev_addr' for N300 and
> tested the example. It failed by giving  error :
>
> *RuntimeError: RfnocError: Adding edge without disabling is_forward_edge
> will lead to unresolvable graph!. * between RX radio and DDC chain.
>
> I have updated the sample rate and bandwidth parameters as per N300
> specifications i.e. SR = 125 Mhz and  BW = 100 Mhz. Is there any way you
> can check this example for N300 at your end?
>
> Regards,
> Nidhi
>
> --
> *From:* Martin Braun 
> *Sent:* Thursday, December 12, 2024 4:59 PM
> *Cc:* usrp-users@lists.ettus.com 
> *Subject:* [USRP-users] Re: Issue with Starting Transmitter on USRP N300
> without Using Streamers
>
> On Thu, Dec 12, 2024 at 11:21 AM Nidhi Panda 
> wrote:
>
> Yes, I am currently testing with this example (rfnoc_radio_loopback.grc
> )
> only. However, the example was for x300 and I am testing in n300 board.
> The example works only if rx and tx streamer is present i.e. for the
> following chain.
>
>
> Hi Nidhi,
>
> the example has no Tx or Rx streamers, nor does it require them. If you
> update the `dev_addr` variable as explained in the comment, I would expect
> this example to work out of the box with an N310 device.
>
> Note that the N310 does not support a 200 Msps rate, so you will need to
> change that also (e.g., to 125 Msps).
>
> [image: image.png]
>
>
> --M
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
> ___
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
___
USRP-users mailing list -- usrp-users@lists.e

[USRP-users] Sampling channels at different rates

2024-12-16 Thread Christophe Grimault

Dear users,

I'm using python wrappers with UHD >= 4.5 and a X300 with 2 twinRx.

I would like to know if it is possible to create a streamer, for more 
than N channels, with a sampling rate which different for each channel.


As for now, when I try this, I get all my 4 channels with the same 
sampling rate, which is the one of the last channel added.


Is it just possible to do it ? Say, for example,  have a streamer with 2 
channels :


 * chan 0 on fc = 140 Mhz, rx_rate=20 MS/s
 * chan 1 on fc = 140 MHz, rx_rate=1 MS/s

Thanks in advance

Chris


--
Christophe Grimault
NovaGrid SAS
Les Jardins de la Teillais
3, allée de la grande égalonne
35740 Pacé, France
Tel : (33)2 23 41 37 97
Mob: (33)6 82 22 46 93
www.novagrid.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] Re: Sampling channels at different rates

2024-12-16 Thread Christophe Grimault

Hello Brian,

Thank you for this quick answer.

So I guess this is not a limitation related to using Python vs C++/boost 
? Right ?


I understand that using the same streamer is tricky. Concerning your 
advice to go with 2 streamers, you think this a totally fine way to go ?


Otherwise, I was trying to use a single streamer because I wanted to 
have zero delay between the start time of the 2 streams.


Chris

Christophe Grimault
NovaGrid SAS
Les Jardins de la Teillais
3, allée de la grande égalonne
35740 Pacé, France
Tel : (33)2 23 41 37 97
Mob: (33)6 82 22 46 93
www.novagrid.com

Le 16/12/2024 à 15:27, Brian Padalino a écrit :
On Mon, Dec 16, 2024 at 9:15 AM Christophe Grimault 
 wrote:


Dear users,

I'm using python wrappers with UHD >= 4.5 and a X300 with 2 twinRx.

I would like to know if it is possible to create a streamer, for
more than N channels, with a sampling rate which different for
each channel.

As for now, when I try this, I get all my 4 channels with the same
sampling rate, which is the one of the last channel added.

Is it just possible to do it ? Say, for example,  have a streamer
with 2 channels :

  * chan 0 on fc = 140 Mhz, rx_rate=20 MS/s
  * chan 1 on fc = 140 MHz, rx_rate=1 MS/s

Thanks in advance


I don't think this is possible, but if it is I don't think it's 
advisable.  You should use 2 different streamers.  The timestamps 
associated with them should be the same so on the host you can still 
align them, but the streamers itself I think would be weird trying to 
receive the same N samples over the 2 channels.


Is there any particular reason you don't want to use 2 streamers?

Brian

___
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-le...@lists.ettus.com___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] Re: Sampling channels at different rates

2024-12-16 Thread Brian Padalino
On Mon, Dec 16, 2024 at 9:15 AM Christophe Grimault <
christophe.grima...@novagrid.com> wrote:

> Dear users,
>
> I'm using python wrappers with UHD >= 4.5 and a X300 with 2 twinRx.
>
> I would like to know if it is possible to create a streamer, for more than
> N channels, with a sampling rate which different for each channel.
>
> As for now, when I try this, I get all my 4 channels with the same
> sampling rate, which is the one of the last channel added.
>
> Is it just possible to do it ? Say, for example,  have a streamer with 2
> channels :
>
>- chan 0 on fc = 140 Mhz, rx_rate=20 MS/s
>- chan 1 on fc = 140 MHz, rx_rate=1 MS/s
>
> Thanks in advance
>

I don't think this is possible, but if it is I don't think it's advisable.
You should use 2 different streamers.  The timestamps associated with them
should be the same so on the host you can still align them, but the
streamers itself I think would be weird trying to receive the same N
samples over the 2 channels.

Is there any particular reason you don't want to use 2 streamers?

Brian
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] Re: Sampling channels at different rates

2024-12-16 Thread Marcus D. Leech

On 16/12/2024 09:44, Christophe Grimault wrote:


Hello Brian,

Thank you for this quick answer.

So I guess this is not a limitation related to using Python vs 
C++/boost ? Right ?


I understand that using the same streamer is tricky. Concerning your 
advice to go with 2 streamers, you think this a totally fine way to go ?


Otherwise, I was trying to use a single streamer because I wanted to 
have zero delay between the start time of the 2 streams.


Chris

You'll HAVE to use two different streamers if you want them at different 
sample rates.  It's a fairly deep

  architectural limitation.



Christophe Grimault
NovaGrid SAS
Les Jardins de la Teillais
3, allée de la grande égalonne
35740 Pacé, France
Tel : (33)2 23 41 37 97
Mob: (33)6 82 22 46 93
www.novagrid.com
Le 16/12/2024 à 15:27, Brian Padalino a écrit :
On Mon, Dec 16, 2024 at 9:15 AM Christophe Grimault 
 wrote:


Dear users,

I'm using python wrappers with UHD >= 4.5 and a X300 with 2 twinRx.

I would like to know if it is possible to create a streamer, for
more than N channels, with a sampling rate which different for
each channel.

As for now, when I try this, I get all my 4 channels with the
same sampling rate, which is the one of the last channel added.

Is it just possible to do it ? Say, for example, have a streamer
with 2 channels :

  * chan 0 on fc = 140 Mhz, rx_rate=20 MS/s
  * chan 1 on fc = 140 MHz, rx_rate=1 MS/s

Thanks in advance


I don't think this is possible, but if it is I don't think it's 
advisable.  You should use 2 different streamers.  The timestamps 
associated with them should be the same so on the host you can still 
align them, but the streamers itself I think would be weird trying to 
receive the same N samples over the 2 channels.


Is there any particular reason you don't want to use 2 streamers?

Brian

___
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-le...@lists.ettus.com


___
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] Re: Sampling channels at different rates

2024-12-16 Thread Brian Padalino
On Mon, Dec 16, 2024 at 9:44 AM Christophe Grimault <
christophe.grima...@novagrid.com> wrote:

> Hello Brian,
>
> Thank you for this quick answer.
>
> So I guess this is not a limitation related to using Python vs C++/boost ?
> Right ?
>
> I understand that using the same streamer is tricky. Concerning your
> advice to go with 2 streamers, you think this a totally fine way to go ?
>
> Otherwise, I was trying to use a single streamer because I wanted to have
> zero delay between the start time of the 2 streams.
>

I think using two streamers and the timestamp functionality is good.  Check
the Streamed Commands here for how to tell a stream to start at a specific
time:

  https://files.ettus.com/manual/page_timedcmds.html#timedcmds_stream_cmds

Brian
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] Re: N300 device not found

2024-12-16 Thread Marcus D. Leech

On 16/12/2024 03:18, yibinden...@outlook.com wrote:


Hi all,

I encountered some issues while configuring the N300. The N300 
responds to my ping requests, but the host cannot find the device 
using uhd_find_devices while correctly detecting b210 devices.


I referred to this post on StackOverflow 
(https://stackoverflow.com/questions/33304828/when-trying-to-use-my-usrp-in-gnu-radio-i-get-a-no-devices-found-for?rq=1) 
but adding parameters and modifying the firewall settings did not 
resolve the issue.


Configurations: MTU is manually set to 1500 bytes, IP address is 
192.168.10.2, netmask is 255.255.255.0, and my UHD version is 4.7.




___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
Rather than using uhd_find_devices, which requires that broadcast 
processing be allowed as an ordinary user, try:


uhd_usrp_probe --args "type=n3xx,product=n300,addr=192.168.10.2"

___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] Re: Sampling channels at different rates

2024-12-16 Thread Marcus D. Leech

On 16/12/2024 13:47, Christophe Grimault wrote:


I followed your advice and I'm getting closer !-)

I tried this :

usrp = uhd.usrp.MultiUSRP(f"addr=192.168.30.2")
duration =10.0 start_time_spec = 
uhd.libpyuhd.types.time_spec(usrp.get_time_now().get_real_secs() +1.0)

rx_rates = [390625.0*2,390625.0]

# --- # Craft commands # --- # Start with chan 
0 ... usrp.set_rx_rate(rx_rates[0],chan=0)

rx_tune_request0 = uhd.types.TuneRequest(1100.0e6)
usrp.set_rx_freq(tune_request=rx_tune_request0,chan=0)
usrp.set_rx_gain(45.0,chan=0)
num_samps0 = math.ceil(int(usrp.get_rx_rate(chan=0)) * duration)

rx_streamer_args0 = uhd.usrp.StreamArgs("fc32","sc16")
rx_streamer_args0.channels = [0]
rx_streamer0 = usrp.get_rx_stream(rx_streamer_args0)
max_samps_per_packet = rx_streamer0.get_max_num_samps()
L0 = math.ceil(num_samps0 / max_samps_per_packet) * max_samps_per_packet
recv_buffer0 = np.zeros(L0,dtype=np.complex64)
stream_cmd0 = uhd.types.StreamCMD(uhd.types.StreamMode.start_cont)#num_done) 
stream_cmd0.stream_now =False stream_cmd0.num_samps = num_samps0
stream_cmd0.time_spec = start_time_spec

# Then chan 1, which is 2 times slower. usrp.set_rx_rate(rx_rates[1],chan=1)
rx_tune_request1 = uhd.types.TuneRequest(1100.0e6)
usrp.set_rx_freq(tune_request=rx_tune_request1,chan=1)
usrp.set_rx_gain(35.0,chan=1)
num_samps1 = math.ceil(int(usrp.get_rx_rate(chan=1)) * duration)

rx_streamer_args1 = uhd.usrp.StreamArgs("fc32","sc16")
rx_streamer_args1.channels = [1]
rx_streamer1 = usrp.get_rx_stream(rx_streamer_args1)
max_samps_per_packet = rx_streamer1.get_max_num_samps()
L1 = math.ceil(num_samps1 / max_samps_per_packet) * max_samps_per_packet
recv_buffer1 = np.zeros(L1,dtype=np.complex64)
stream_cmd1 = uhd.types.StreamCMD(uhd.types.StreamMode.start_cont)#num_done) 
stream_cmd1.stream_now =False stream_cmd1.num_samps = num_samps1
stream_cmd1.time_spec = start_time_spec

# -- # Launch sampling 
on both streamers, i.e. channels # 
-- rx_streamer0.issue_stream_cmd(stream_cmd0)

rx_streamer1.issue_stream_cmd(stream_cmd1)

metadata0 = uhd.types.RXMetadata()
nb_samples0 = rx_streamer0.recv(recv_buffer0, metadata0,3.0)

metadata1 = uhd.types.RXMetadata()
nb_samples1 = rx_streamer1.recv(recv_buffer1, metadata1,3.0)

metadata0.time_spec.get_real_secs() - metadata1.time_spec.get_real_secs()

And got the attached figures.

Over the 10 s of capture, I switch of the signal at the same time on 
both channels (exact same time because the switch is before the RF 
coupler). Both capture are roughly aligned in time, but when I zoom, I 
see 26 us of delay (which is roughly 10 samples at rx_rate_1 of 
390625). Am I wrong expecting a "perfect timing" ? And when I compute :


metadata0.time_spec.get_real_secs() - metadata1.time_spec.get_real_secs()

still I get 0.0 us.

What am I doing wrong ? Shall I launch threads ?

Any thoughts ?

Thanks in advance

Chris

A cursory inspection of your code doesn't indicate any glaring errors, 
but your start-time is only 1 second ahead of when
  you get the time from the device.  That MAY not be enough to get both 
streamers set-up so that they'll "trigger" at the

  same time.

What device type is this?




Christophe Grimault
NovaGrid SAS
Les Jardins de la Teillais
3, allée de la grande égalonne
35740 Pacé, France
Tel : (33)2 23 41 37 97
Mob: (33)6 82 22 46 93
www.novagrid.com
Le 16/12/2024 à 15:15, Christophe Grimault a écrit :


Dear users,

I'm using python wrappers with UHD >= 4.5 and a X300 with 2 twinRx.

I would like to know if it is possible to create a streamer, for more 
than N channels, with a sampling rate which different for each channel.


As for now, when I try this, I get all my 4 channels with the same 
sampling rate, which is the one of the last channel added.


Is it just possible to do it ? Say, for example,  have a streamer 
with 2 channels :


  * chan 0 on fc = 140 Mhz, rx_rate=20 MS/s
  * chan 1 on fc = 140 MHz, rx_rate=1 MS/s

Thanks in advance

Chris


--
Christophe Grimault
NovaGrid SAS
Les Jardins de la Teillais
3, allée de la grande égalonne
35740 Pacé, France
Tel : (33)2 23 41 37 97
Mob: (33)6 82 22 46 93
www.novagrid.com

___
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-le...@lists.ettus.com


___
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-le...@lists.ettus.com
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] Re: Sampling channels at different rates

2024-12-16 Thread Brian Padalino
On Mon, Dec 16, 2024 at 1:57 PM Marcus D. Leech 
wrote:

> On 16/12/2024 13:47, Christophe Grimault wrote:
>
> I followed your advice and I'm getting closer !-)
>
> I tried this :
>
> usrp = uhd.usrp.MultiUSRP(f"addr=192.168.30.2")
> duration = 10.0start_time_spec = 
> uhd.libpyuhd.types.time_spec(usrp.get_time_now().get_real_secs() + 1.0)
>
> rx_rates = [390625.0*2, 390625.0]
> # ---# Craft commands# ---# Start with chan 0 
> ...usrp.set_rx_rate(rx_rates[0], chan=0)
> rx_tune_request0 = uhd.types.TuneRequest(1100.0e6)
> usrp.set_rx_freq(tune_request=rx_tune_request0, chan=0)
> usrp.set_rx_gain(45.0, chan=0)
> num_samps0 = math.ceil(int(usrp.get_rx_rate(chan=0)) * duration)
>
> rx_streamer_args0 = uhd.usrp.StreamArgs("fc32", "sc16")
> rx_streamer_args0.channels = [0]
> rx_streamer0 = usrp.get_rx_stream(rx_streamer_args0)
> max_samps_per_packet = rx_streamer0.get_max_num_samps()
> L0 = math.ceil(num_samps0 / max_samps_per_packet) * max_samps_per_packet
> recv_buffer0 = np.zeros(L0, dtype=np.complex64)
> stream_cmd0 = uhd.types.StreamCMD(uhd.types.StreamMode.start_cont)  
> #num_done)stream_cmd0.stream_now = Falsestream_cmd0.num_samps = num_samps0
> stream_cmd0.time_spec = start_time_spec
> # Then chan 1, which is 2 times slower.usrp.set_rx_rate(rx_rates[1], chan=1)
> rx_tune_request1 = uhd.types.TuneRequest(1100.0e6)
> usrp.set_rx_freq(tune_request=rx_tune_request1, chan=1)
> usrp.set_rx_gain(35.0, chan=1)
> num_samps1 = math.ceil(int(usrp.get_rx_rate(chan=1)) * duration)
>
> rx_streamer_args1 = uhd.usrp.StreamArgs("fc32", "sc16")
> rx_streamer_args1.channels = [1]
> rx_streamer1 = usrp.get_rx_stream(rx_streamer_args1)
> max_samps_per_packet = rx_streamer1.get_max_num_samps()
> L1 = math.ceil(num_samps1 / max_samps_per_packet) * max_samps_per_packet
> recv_buffer1 = np.zeros(L1, dtype=np.complex64)
> stream_cmd1 = uhd.types.StreamCMD(uhd.types.StreamMode.start_cont)  
> #num_done)stream_cmd1.stream_now = Falsestream_cmd1.num_samps = num_samps1
> stream_cmd1.time_spec = start_time_spec
> # --# Launch sampling on both 
> streamers, i.e. channels# 
> --rx_streamer0.issue_stream_cmd(stream_cmd0)
> rx_streamer1.issue_stream_cmd(stream_cmd1)
>
> metadata0 = uhd.types.RXMetadata()
> nb_samples0 = rx_streamer0.recv(recv_buffer0, metadata0, 3.0)
>
> metadata1 = uhd.types.RXMetadata()
> nb_samples1 = rx_streamer1.recv(recv_buffer1, metadata1, 3.0)
>
> metadata0.time_spec.get_real_secs() - metadata1.time_spec.get_real_secs()
>
> And got the attached figures.
>
> Over the 10 s of capture, I switch of the signal at the same time on both
> channels (exact same time because the switch is before the RF coupler).
> Both capture are roughly aligned in time, but when I zoom, I see 26 us of
> delay (which is roughly 10 samples at rx_rate_1 of 390625). Am I wrong
> expecting a "perfect timing" ? And when I compute :
>
> metadata0.time_spec.get_real_secs() - metadata1.time_spec.get_real_secs()
>
> still I get 0.0 us.
>
> What am I doing wrong ? Shall I launch threads ?
>
> Any thoughts ?
>
> Thanks in advance
>
> Chris
>
> A cursory inspection of your code doesn't indicate any glaring errors, but
> your start-time is only 1 second ahead of when
>   you get the time from the device.  That MAY not be enough to get both
> streamers set-up so that they'll "trigger" at the
>   same time.
>
> What device type is this?
>

My guess is that you're going through another Halfband FIR filter
somewhere, so there is group delay that isn't being accounted for in the
digital filters.

What is the lag (in samples) of the lower rate sampled signal?

Brian
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com


[USRP-users] Re: Sampling channels at different rates

2024-12-16 Thread Marcus D. Leech

On 16/12/2024 14:24, Brian Padalino wrote:



My guess is that you're going through another Halfband FIR filter 
somewhere, so there is group delay that isn't being accounted for in 
the digital filters.


What is the lag (in samples) of the lower rate sampled signal?

Brian
That was my other thought, assuming that the streams really are starting 
at the same time--different group delay

  due to the different sample rates.

___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com