Constellation Modulator delay calculation

2023-01-10 Thread Ali G. Dezfuli
Hi everybody,

I just want to know how the delay of the "Constellation Modulator" block in
GRC is calculated.
In fact, whether you set the block's last parameter "truncate filter
transient" or not, a delay of 86 samples could be generated, no matter how
many points are in the constellation.

This magic number (i.e. 86) also appears in "linear_equalizer_compare.grc"
example (in gr-digital/examples/equalizers in modulated_sync_word variable).

I know this delay depends on the "samples per symbol" (sps) parameter and
comes from the built-in pulse shaping with its default taps equal:
   firdes.root_raised_cosine(32, 32, 1.0, exess_bw, 32*11*sps)
and with the following sps to delay relation:
(sps=2, delay=21)
(sps=4, delay=86)
(sps=8, delay=348)
etc.

my GR version is:   v3.11.0.0git-316-gc11667ef
thank you all!


Re: USRP B210 TX/RX switching between transmitting and receiving

2023-01-10 Thread Daniel Estévez

On 09/01/2023 18:20, Karen young wrote:

Hi,

I want to use the single port (TX/RX) from USRP B210 to switch between 
transmitting and receiving. I have selected "Ch0: Antenna: TX/RX" for 
both the USRP sink and source blocks as shown in the figure. I expect 
the TX/RX port will show orange light. But the USRP hardware still 
transmits through TX/RX port (Red light on), and receives through RX2 
port (Green light on).


What needs to be set if only using a single TX/RX port for switching 
between transmitting and receiving?


Hi Karen,

It seems that you're trying to transmit continuously, since the Signal 
Source is delivering samples to the USRP sink all the time. The TX/RX 
port cannot be used for simultaneous transmit and receive. It can only 
do one at a time (but can switch during the flowgraph execution).


To receive whenever you are not transmitting something, you need to use 
burst transmissions 
(https://wiki.gnuradio.org/index.php/USRP_Sink#Bursty_Transmission). I 
think that if you do this, the USRP will switch to transmit when you 
send it a burst, and will switch to receive whenever it has nothing to 
transmit.


Best,
Daniel.



OpenPGP_signature
Description: OpenPGP digital signature


Re: USRP B210 TX/RX switching between transmitting and receiving

2023-01-10 Thread okan erturk
So TX has a priority over RX, am I right?


On Tue, Jan 10, 2023, 21:54 Daniel Estévez  wrote:

> On 09/01/2023 18:20, Karen young wrote:
> > Hi,
> >
> > I want to use the single port (TX/RX) from USRP B210 to switch between
> > transmitting and receiving. I have selected "Ch0: Antenna: TX/RX" for
> > both the USRP sink and source blocks as shown in the figure. I expect
> > the TX/RX port will show orange light. But the USRP hardware still
> > transmits through TX/RX port (Red light on), and receives through RX2
> > port (Green light on).
> >
> > What needs to be set if only using a single TX/RX port for switching
> > between transmitting and receiving?
>
> Hi Karen,
>
> It seems that you're trying to transmit continuously, since the Signal
> Source is delivering samples to the USRP sink all the time. The TX/RX
> port cannot be used for simultaneous transmit and receive. It can only
> do one at a time (but can switch during the flowgraph execution).
>
> To receive whenever you are not transmitting something, you need to use
> burst transmissions
> (https://wiki.gnuradio.org/index.php/USRP_Sink#Bursty_Transmission). I
> think that if you do this, the USRP will switch to transmit when you
> send it a burst, and will switch to receive whenever it has nothing to
> transmit.
>
> Best,
> Daniel.
>
>


Re: USRP B210 TX/RX switching between transmitting and receiving

2023-01-10 Thread Marcus D. Leech

On 10/01/2023 14:01, okan erturk wrote:

So TX has a priority over RX, am I right?

Not sure what you mean by "priority".

The RX/TX port will be connected to the TX whenever it's transmitting.

The RX chain can either be connected to the RX2 port all the time, or if 
it's configured for
  TX/RX, the ATR (Automatic Transmit Receive) logic in the FPGA will 
switch the RX chain

  between the TX/RX and RX2 ports whenever there's an active transmission.

In the case of Karen's flow-graph, it transmits all the time, so the RX 
chain will be switched
  to the RX2 antenna port, regardless of what its preferred antenna 
setting is.


Now, IN ADDITION to all of this, since the maximum isolation between 
antenna ports is not
  super high, the RX chain WILL SEE YOUR TRANSMISSIONS.   You just need 
to be prepared for

  that.





On Tue, Jan 10, 2023, 21:54 Daniel Estévez  wrote:

On 09/01/2023 18:20, Karen young wrote:
> Hi,
>
> I want to use the single port (TX/RX) from USRP B210 to switch
between
> transmitting and receiving. I have selected "Ch0: Antenna:
TX/RX" for
> both the USRP sink and source blocks as shown in the figure. I
expect
> the TX/RX port will show orange light. But the USRP hardware still
> transmits through TX/RX port (Red light on), and receives
through RX2
> port (Green light on).
>
> What needs to be set if only using a single TX/RX port for
switching
> between transmitting and receiving?

Hi Karen,

It seems that you're trying to transmit continuously, since the
Signal
Source is delivering samples to the USRP sink all the time. The TX/RX
port cannot be used for simultaneous transmit and receive. It can
only
do one at a time (but can switch during the flowgraph execution).

To receive whenever you are not transmitting something, you need
to use
burst transmissions
(https://wiki.gnuradio.org/index.php/USRP_Sink#Bursty_Transmission).
I
think that if you do this, the USRP will switch to transmit when you
send it a burst, and will switch to receive whenever it has
nothing to
transmit.

Best,
Daniel.



Re: USRP B210 TX/RX switching between transmitting and receiving

2023-01-10 Thread Daniel Estévez

On 10/01/2023 20:01, okan erturk wrote:

So TX has a priority over RX, am I right?


I don't now for sure, but I guess that would make sense, because 
typically you would be attempting to RX continuously, while TXing some 
bursts (which would leave gaps in the RX stream). I don't know if the RX 
gaps are missing samples, zeroed-out samples, or something else.


Best,
Daniel.




OpenPGP_signature
Description: OpenPGP digital signature


Re: USRP B210 TX/RX switching between transmitting and receiving

2023-01-10 Thread okan erturk
Okay, we thought that when a TX signal sent, RX will be interrupted. That
was what I meant.

On Tue, Jan 10, 2023, 22:32 Marcus D. Leech  wrote:

> On 10/01/2023 14:01, okan erturk wrote:
>
> So TX has a priority over RX, am I right?
>
> Not sure what you mean by "priority".
>
> The RX/TX port will be connected to the TX whenever it's transmitting.
>
> The RX chain can either be connected to the RX2 port all the time, or if
> it's configured for
>   TX/RX, the ATR (Automatic Transmit Receive) logic in the FPGA will
> switch the RX chain
>   between the TX/RX and RX2 ports whenever there's an active transmission.
>
> In the case of Karen's flow-graph, it transmits all the time, so the RX
> chain will be switched
>   to the RX2 antenna port, regardless of what its preferred antenna
> setting is.
>
> Now, IN ADDITION to all of this, since the maximum isolation between
> antenna ports is not
>   super high, the RX chain WILL SEE YOUR TRANSMISSIONS.   You just need to
> be prepared for
>   that.
>
>
>
>
> On Tue, Jan 10, 2023, 21:54 Daniel Estévez  wrote:
>
>> On 09/01/2023 18:20, Karen young wrote:
>> > Hi,
>> >
>> > I want to use the single port (TX/RX) from USRP B210 to switch between
>> > transmitting and receiving. I have selected "Ch0: Antenna: TX/RX" for
>> > both the USRP sink and source blocks as shown in the figure. I expect
>> > the TX/RX port will show orange light. But the USRP hardware still
>> > transmits through TX/RX port (Red light on), and receives through RX2
>> > port (Green light on).
>> >
>> > What needs to be set if only using a single TX/RX port for switching
>> > between transmitting and receiving?
>>
>> Hi Karen,
>>
>> It seems that you're trying to transmit continuously, since the Signal
>> Source is delivering samples to the USRP sink all the time. The TX/RX
>> port cannot be used for simultaneous transmit and receive. It can only
>> do one at a time (but can switch during the flowgraph execution).
>>
>> To receive whenever you are not transmitting something, you need to use
>> burst transmissions
>> (https://wiki.gnuradio.org/index.php/USRP_Sink#Bursty_Transmission). I
>> think that if you do this, the USRP will switch to transmit when you
>> send it a burst, and will switch to receive whenever it has nothing to
>> transmit.
>>
>> Best,
>> Daniel.
>>
>>
>


Re: USRP B210 TX/RX switching between transmitting and receiving

2023-01-10 Thread Marcus D. Leech

On 10/01/2023 14:11, Daniel Estévez wrote:

On 10/01/2023 20:01, okan erturk wrote:

So TX has a priority over RX, am I right?


I don't now for sure, but I guess that would make sense, because 
typically you would be attempting to RX continuously, while TXing some 
bursts (which would leave gaps in the RX stream). I don't know if the 
RX gaps are missing samples, zeroed-out samples, or something else.


Best,
Daniel.


There's no interruption in the digital side of things.  The RX front-end 
will be connected to RX2 during transmission.  It will
  likely only "see" your transmissions if there isn't an antenna 
connected to the RX2 antenna port.






Updating FPGA image on Ettus N321

2023-01-10 Thread Joseph Maloyan
Hello,

I am currently trying to update the image of the FPGA. I am following the
guide at this link...
https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide

When I try to update through network, I get the following regarding
mismatched compat numbers...


INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100;
UHD_4.3.0.HEAD-0-g1f8fd345
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.1.230,type=n3xx,product=n320,serial=3255102,claimed=False,skip_init=1
[INFO] [MPM.main] Launching USRP/MPM, version: 3.14.1.1-g0347a6d8
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 3255102
[INFO] [MPM.Rhodium-0] Enabling LO distribution board
[INFO] [MPM.Rhodium-0] Successfully loaded all peripherals!
[INFO] [MPM.Rhodium-1] Successfully loaded all peripherals!
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[ERROR] [MPM.PeriphManager] Major compat number mismatch for component
`FPGA': Expected: 5.3 Actual: 8.1
[ERROR] [MPM.PeriphManager] Failed to initialize motherboard: Major compat
number mismatch for component `FPGA': Expected: 5.3 Actual: 8.1
[ERROR] [MPM.PeriphManager] Cannot run init(), device was never fully
initialized!
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[ERROR] [MPM.PeriphManager] Error executing `dtc': Command '['dtc',
'--symbols', '-O', 'dtb', '-q', '-o', '/lib/firmware/n320.dtbo',
'/lib/firmware/n320.dts']' returned non-zero exit status 1
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 3255102
[ERROR] [UHD] An unexpected exception was caught in a task loop.The task
loop will now exit, things may not work.rpc::timeout: Timeout of 1ms
while calling RPC function 'reclaim'
[ERROR] [UHD] Exception caught in safe-call.
  in ~mpmd_mboard_impl
  at
/home/mirsl102b/workarea/uhd/host/lib/usrp/mpmd/mpmd_mboard_impl.cpp:320
dump_logs(); _claimer_task.reset(); if (not
rpc->request_with_token("unclaim")) {
uhd::_log::log(uhd::log::warning,
"/home/mirsl102b/workarea/uhd/host/lib/usrp/mpmd/mpmd_mboard_impl.cpp",
322, "MPMD", std::this_thread::get_id()) << "Failure to ack unclaim!";; }
-> rpc::timeout: Timeout of 1ms while calling RPC function 'get_log_buf'
Error: rpc::timeout: Timeout of 12ms while calling RPC function
'update_component'

When I try to update through embedded mode I get the following...

INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100;
UHD_4.3.0.HEAD-0-g1f8fd345
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.1.230,type=n3xx,product=n320,serial=3255102,claimed=False,addr=192.168.1.230,skip_init=1
[INFO] [MPM.main] Launching USRP/MPM, version: 3.14.1.1-g0347a6d8
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 3255102
[ERROR] [MPM.PeriphManager] Failed to initialize motherboard: No device
'e0006000.spi' in 'platform'
[ERROR] [MPM.PeriphManager] Cannot run init(), device was never fully
initialized!
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[ERROR] [MPM.PeriphManager] Error executing `dtc': Command '['dtc',
'--symbols', '-O', 'dtb', '-q', '-o', '/lib/firmware/n320.dtbo',
'/lib/firmware/n320.dts']' returned non-zero exit status 1
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 3255102
[ERROR] [UHD] An unexpected exception was caught in a task loop.The task
loop will now exit, things may not work.rpc::timeout: Timeout of 1ms
while calling RPC function 'reclaim'
[ERROR] [UHD] Exception caught in safe-call.
  in ~mpmd_mboard_impl
  at
/home/mirsl102b/workarea/uhd/host/lib/usrp/mpmd/mpmd_mboard_impl.cpp:320
dump_logs(); _claimer_task.reset(); if (not
rpc->request_with_token("unclaim")) {
uhd::_log::log(uhd::log::warning,
"/home/mirsl102b/workarea/uhd/host/lib/usrp/mpmd/mpmd_mboard_impl.cpp",
322, "MPMD", std::this_thread::get_id()) << "Failure to ack unclaim!";; }
-> rpc::timeout: Timeout of 1ms while calling RPC function 'get_log_buf'
Error: rpc::timeout: Timeout of 12ms while calling RPC function
'update_component'

What is causing this? I currently have the latest version of USRP, and I
have downloaded the latest images through sudo uhd_images_downloader.

Thanks
Joe


Re: Constellation Modulator delay calculation

2023-01-10 Thread Cinaed Simson
Hi Ali - your flowchart has no device and no throttle. You need to add a 
throttle.


And I don't the expertise or the time to look at the source code.

So I'm punting back to the list.

-- Cinaed


On 1/10/23 03:10, Ali G. Dezfuli wrote:

Hi everybody,expertise

I just want to know how the delay of the "Constellation Modulator" 
block in GRC is calculated.
In fact, whether you set the block's last parameter "truncate filter 
transient" or not, a delay of 86 samples could be generated, no matter 
how many points are in the constellation.


This magic number (i.e. 86) also appears in 
"linear_equalizer_compare.grc" example (in 
gr-digital/examples/equalizers in modulated_sync_word variable).


I know this delay depends on the "samples per symbol" (sps) parameter 
and comes from the built-in pulse shaping with its default taps equal:

       firdes.root_raised_cosine(32, 32, 1.0, exess_bw, 32*11*sps)
and with the following sps to delay relation:
(sps=2, delay=21)
(sps=4, delay=86)
(sps=8, delay=348)
etc.

my GR version is:   v3.11.0.0git-316-gc11667ef
thank you all!





Re: Updating FPGA image on Ettus N321

2023-01-10 Thread Marcus D. Leech

On 10/01/2023 18:03, Joseph Maloyan wrote:

Hello,

I am currently trying to update the image of the FPGA. I am following 
the guide at this link...

https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide

When I try to update through network, I get the following regarding 
mismatched compat numbers...



INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; 
UHD_4.3.0.HEAD-0-g1f8fd345
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.1.230,type=n3xx,product=n320,serial=3255102,claimed=False,skip_init=1

[INFO] [MPM.main] Launching USRP/MPM, version: 3.14.1.1-g0347a6d8
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 3255102
[INFO] [MPM.Rhodium-0] Enabling LO distribution board
[INFO] [MPM.Rhodium-0] Successfully loaded all peripherals!
[INFO] [MPM.Rhodium-1] Successfully loaded all peripherals!
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[ERROR] [MPM.PeriphManager] Major compat number mismatch for component 
`FPGA': Expected: 5.3 Actual: 8.1
[ERROR] [MPM.PeriphManager] Failed to initialize motherboard: Major 
compat number mismatch for component `FPGA': Expected: 5.3 Actual: 8.1
[ERROR] [MPM.PeriphManager] Cannot run init(), device was never fully 
initialized!

[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[ERROR] [MPM.PeriphManager] Error executing `dtc': Command '['dtc', 
'--symbols', '-O', 'dtb', '-q', '-o', '/lib/firmware/n320.dtbo', 
'/lib/firmware/n320.dts']' returned non-zero exit status 1

[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 3255102
[ERROR] [UHD] An unexpected exception was caught in a task loop.The 
task loop will now exit, things may not work.rpc::timeout: Timeout of 
1ms while calling RPC function 'reclaim'

[ERROR] [UHD] Exception caught in safe-call.
  in ~mpmd_mboard_impl
  at 
/home/mirsl102b/workarea/uhd/host/lib/usrp/mpmd/mpmd_mboard_impl.cpp:320
dump_logs(); _claimer_task.reset(); if (not 
rpc->request_with_token("unclaim")) { 
uhd::_log::log(uhd::log::warning, 
"/home/mirsl102b/workarea/uhd/host/lib/usrp/mpmd/mpmd_mboard_impl.cpp", 
322, "MPMD", std::this_thread::get_id()) << "Failure to ack 
unclaim!";; } -> rpc::timeout: Timeout of 1ms while calling RPC 
function 'get_log_buf'
Error: rpc::timeout: Timeout of 12ms while calling RPC function 
'update_component'


When I try to update through embedded mode I get the following...

INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; 
UHD_4.3.0.HEAD-0-g1f8fd345
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.1.230,type=n3xx,product=n320,serial=3255102,claimed=False,addr=192.168.1.230,skip_init=1

[INFO] [MPM.main] Launching USRP/MPM, version: 3.14.1.1-g0347a6d8
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 3255102
[ERROR] [MPM.PeriphManager] Failed to initialize motherboard: No 
device 'e0006000.spi' in 'platform'
[ERROR] [MPM.PeriphManager] Cannot run init(), device was never fully 
initialized!

[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[ERROR] [MPM.PeriphManager] Error executing `dtc': Command '['dtc', 
'--symbols', '-O', 'dtb', '-q', '-o', '/lib/firmware/n320.dtbo', 
'/lib/firmware/n320.dts']' returned non-zero exit status 1

[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 3255102
[ERROR] [UHD] An unexpected exception was caught in a task loop.The 
task loop will now exit, things may not work.rpc::timeout: Timeout of 
1ms while calling RPC function 'reclaim'

[ERROR] [UHD] Exception caught in safe-call.
  in ~mpmd_mboard_impl
  at 
/home/mirsl102b/workarea/uhd/host/lib/usrp/mpmd/mpmd_mboard_impl.cpp:320
dump_logs(); _claimer_task.reset(); if (not 
rpc->request_with_token("unclaim")) { 
uhd::_log::log(uhd::log::warning, 
"/home/mirsl102b/workarea/uhd/host/lib/usrp/mpmd/mpmd_mboard_impl.cpp", 
322, "MPMD", std::this_thread::get_id()) << "Failure to ack 
unclaim!";; } -> rpc::timeout: Timeout of 1ms while calling RPC 
function 'get_log_buf'
Error: rpc::timeout: Timeout of 12ms while calling RPC function 
'update_component'


What is causing this? I currently have the latest version of USRP, and 
I have downloaded the latest images through sudo uhd_images_downloader.


Thanks
Joe



This is a fairly USRP-specific question, unrelated to Gnu Radio in 
particular.


This type o

Re: Constellation Modulator delay calculation

2023-01-10 Thread U L
Ali,

I think the example uses the generic_mod block

inside. This block uses the polyphase arb resampler for antialiasing. The
line that computes the rrc delay is here
.
Briefly, for your example with sps = 2, it's (11 x 2 x 2 - 2) / 2 = 21. For
sps = 4, (11 x 4 x 4 - 4) / 2 = 86. I don't know if this helps.

Jared.

On Tue, Jan 10, 2023 at 6:08 PM Cinaed Simson 
wrote:

> Hi Ali - your flowchart has no device and no throttle. You need to add a
> throttle.
>
> And I don't the expertise or the time to look at the source code.
>
> So I'm punting back to the list.
>
> -- Cinaed
>
>
> On 1/10/23 03:10, Ali G. Dezfuli wrote:
> > Hi everybody,expertise
> >
> > I just want to know how the delay of the "Constellation Modulator"
> > block in GRC is calculated.
> > In fact, whether you set the block's last parameter "truncate filter
> > transient" or not, a delay of 86 samples could be generated, no matter
> > how many points are in the constellation.
> >
> > This magic number (i.e. 86) also appears in
> > "linear_equalizer_compare.grc" example (in
> > gr-digital/examples/equalizers in modulated_sync_word variable).
> >
> > I know this delay depends on the "samples per symbol" (sps) parameter
> > and comes from the built-in pulse shaping with its default taps equal:
> >firdes.root_raised_cosine(32, 32, 1.0, exess_bw, 32*11*sps)
> > and with the following sps to delay relation:
> > (sps=2, delay=21)
> > (sps=4, delay=86)
> > (sps=8, delay=348)
> > etc.
> >
> > my GR version is:   v3.11.0.0git-316-gc11667ef
> > thank you all!
>
>
>


Re: Constellation Modulator delay calculation

2023-01-10 Thread Ali G. Dezfuli
thank you, Jared and Cinead!
Sure it helps Jared!

On Wed, Jan 11, 2023 at 7:39 AM U L  wrote:

> Ali,
>
> I think the example uses the generic_mod block
> 
> inside. This block uses the polyphase arb resampler for antialiasing. The
> line that computes the rrc delay is here
> .
> Briefly, for your example with sps = 2, it's (11 x 2 x 2 - 2) / 2 = 21. For
> sps = 4, (11 x 4 x 4 - 4) / 2 = 86. I don't know if this helps.
>
> Jared.
>
> On Tue, Jan 10, 2023 at 6:08 PM Cinaed Simson 
> wrote:
>
>> Hi Ali - your flowchart has no device and no throttle. You need to add a
>> throttle.
>>
>> And I don't the expertise or the time to look at the source code.
>>
>> So I'm punting back to the list.
>>
>> -- Cinaed
>>
>>
>> On 1/10/23 03:10, Ali G. Dezfuli wrote:
>> > Hi everybody,expertise
>> >
>> > I just want to know how the delay of the "Constellation Modulator"
>> > block in GRC is calculated.
>> > In fact, whether you set the block's last parameter "truncate filter
>> > transient" or not, a delay of 86 samples could be generated, no matter
>> > how many points are in the constellation.
>> >
>> > This magic number (i.e. 86) also appears in
>> > "linear_equalizer_compare.grc" example (in
>> > gr-digital/examples/equalizers in modulated_sync_word variable).
>> >
>> > I know this delay depends on the "samples per symbol" (sps) parameter
>> > and comes from the built-in pulse shaping with its default taps equal:
>> >firdes.root_raised_cosine(32, 32, 1.0, exess_bw, 32*11*sps)
>> > and with the following sps to delay relation:
>> > (sps=2, delay=21)
>> > (sps=4, delay=86)
>> > (sps=8, delay=348)
>> > etc.
>> >
>> > my GR version is:   v3.11.0.0git-316-gc11667ef
>> > thank you all!
>>
>>
>>