Optional Output Custom Python Block
Hello everyone, Using gnuradio3.8 on Mac. I'm trying to write a custom python block (not an embedded python block) with an optional output. I have the "optional" flag set to true in the YAML file, so GRC doesn't complain when it isn't connected. The block is working fine when the second port is connected, but if it isn't it complains: insufficient connected output ports (2 needed, 1 connected) It's an interp block with vector i/o--don't know if that makes a difference. The constructor looks like this: gr.interp_block.__init__(self, name="optional_output", in_sig=[(np.float32, self.vlen)], out_sig=[(np.float32, self.vlen), (np.float32, self.vlen)], interp=self.interp_rate) Thank you, Cameron
Re: N310 Sync With White Rabbit
Hello again,
Can anyone shed some light on this issue? I found a similar reported issue
here that doesn't seemed to have been resolved either:
http://ettus.80997.x6.nabble.com/USRP-users-ERROR-RPC-TDC-Failed-to-reset-td15582.html
Thank you,
Cameron
On Sat, Dec 5, 2020 at 5:28 PM Cameron Matson wrote:
> Hi all,
>
> I'm trying to use the White Rabbit switch to synchronize the acquisition
> across multiple N310s receivers. I'm trying to use the instructions on
> this Ettus article:
>
>
> https://kb.ettus.com/Using_Ethernet-Based_Synchronization_on_the_USRP%E2%84%A2_N3xx_Devices
>
> I'm using the USRP sink block in gnuradio and set the "clock source" to
> "internal" and the "timing source" to "sfp0" as it indicates in the article
>
> [image: image.png]
> However I get the following error
>
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_3.14.0.HEAD-0-g6875d061
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.3.2,
> type=n3xx,product=n310,serial=316A5C2,claimed=False,addr=192.168.3.2
> [INFO] [MPM.main] Launching USRP/MPM, version: 3.14.0.0-g6875d061
> [INFO] [MPM.main] Spawning RPC process...
> [INFO] [MPM.PeriphManager] Device serial number: 316A5C2
> [INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
> [INFO] [MPM.PeriphManager] init() called with device args
> `clock_source=internal,time_source=internal'.
> [INFO] [MPM.RPCServer] RPC server ready!
> [INFO] [MPM.RPCServer] Spawning watchdog task...
> [INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004)
> [INFO] [MPM.PeriphManager] init() called with device args
> `clock_source=internal,product=n310,mgmt_addr=192.168.3.2,time_source=internal'.
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312)
> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2)
> [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0)
> [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0)
> [INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0)
> [INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0)
> [ERROR] [RPC] TDC Failed to reset.
> Traceback (most recent call last):
> File "/home/cmatson/data_lts/muddi_char/test_multi_radio.py", line 206,
> in
> main()
> File "/home/cmatson/data_lts/muddi_char/test_multi_radio.py", line 194,
> in main
> tb = top_block_cls()
> File "/home/cmatson/data_lts/muddi_char/test_multi_radio.py", line 78,
> in __init__
> self.uhd_usrp_source_0.set_time_source('sfp0', 0)
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 3067, in set_time_source
> return _uhd_swig.usrp_source_sptr_set_time_source(self, source, mboard)
> RuntimeError: RuntimeError: Error during RPC call to `set_time_source'.
> Error message: TDC Failed to reset.
> [INFO] [MPM.Magnesium-0] Re-initializing daughter board. This may take
> some time.
> [ERROR] [MPM.Sync-0] TDC Failed to Reset! Check your clocks! Status: 0x0
> [ERROR] [MPM.RPCServer] Uncaught exception in method set_time_source :TDC
> Failed to reset.
> Traceback (most recent call last):
> File "/usr/lib/python3.5/site-packages/usrp_mpm/rpc_server.py", line
> 182, in new_claimed_function
> return function(*args)
> File "/usr/lib/python3.5/site-packages/usrp_mpm/periph_manager/n3xx.py",
> line 626, in set_time_source
> self.set_sync_source(source)
> File "/usr/lib/python3.5/site-packages/usrp_mpm/periph_manager/n3xx.py",
> line 723, in set_sync_source
> skip_rfic=args.get('skip_rfic', None)
> File
> "/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/magnesium.py",
> line 385, in update_ref_clock_freq
> self._reinit(self.master_clock_rate)
> File
> "/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/magnesium.py",
> line 344, in _reinit
> self.init(args)
> File
> "/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/magnesium.py",
> line 293, in init
> args, self._init_args, fast_reinit)
> File
> "/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/mg_init.py", line
> 615, in init
> args
> File
> "/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/mg_init.py", line
> 555, in
N310 Sync With White Rabbit
Hi all,
I'm trying to use the White Rabbit switch to synchronize the acquisition
across multiple N310s receivers. I'm trying to use the instructions on
this Ettus article:
https://kb.ettus.com/Using_Ethernet-Based_Synchronization_on_the_USRP%E2%84%A2_N3xx_Devices
I'm using the USRP sink block in gnuradio and set the "clock source" to
"internal" and the "timing source" to "sfp0" as it indicates in the article
[image: image.png]
However I get the following error
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
UHD_3.14.0.HEAD-0-g6875d061
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.3.2,
type=n3xx,product=n310,serial=316A5C2,claimed=False,addr=192.168.3.2
[INFO] [MPM.main] Launching USRP/MPM, version: 3.14.0.0-g6875d061
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 316A5C2
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[INFO] [MPM.PeriphManager] init() called with device args
`clock_source=internal,time_source=internal'.
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004)
[INFO] [MPM.PeriphManager] init() called with device args
`clock_source=internal,product=n310,mgmt_addr=192.168.3.2,time_source=internal'.
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2)
[INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0)
[INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0)
[INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0)
[INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0)
[ERROR] [RPC] TDC Failed to reset.
Traceback (most recent call last):
File "/home/cmatson/data_lts/muddi_char/test_multi_radio.py", line 206,
in
main()
File "/home/cmatson/data_lts/muddi_char/test_multi_radio.py", line 194,
in main
tb = top_block_cls()
File "/home/cmatson/data_lts/muddi_char/test_multi_radio.py", line 78, in
__init__
self.uhd_usrp_source_0.set_time_source('sfp0', 0)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3067, in set_time_source
return _uhd_swig.usrp_source_sptr_set_time_source(self, source, mboard)
RuntimeError: RuntimeError: Error during RPC call to `set_time_source'.
Error message: TDC Failed to reset.
[INFO] [MPM.Magnesium-0] Re-initializing daughter board. This may take some
time.
[ERROR] [MPM.Sync-0] TDC Failed to Reset! Check your clocks! Status: 0x0
[ERROR] [MPM.RPCServer] Uncaught exception in method set_time_source :TDC
Failed to reset.
Traceback (most recent call last):
File "/usr/lib/python3.5/site-packages/usrp_mpm/rpc_server.py", line 182,
in new_claimed_function
return function(*args)
File "/usr/lib/python3.5/site-packages/usrp_mpm/periph_manager/n3xx.py",
line 626, in set_time_source
self.set_sync_source(source)
File "/usr/lib/python3.5/site-packages/usrp_mpm/periph_manager/n3xx.py",
line 723, in set_sync_source
skip_rfic=args.get('skip_rfic', None)
File
"/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/magnesium.py",
line 385, in update_ref_clock_freq
self._reinit(self.master_clock_rate)
File
"/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/magnesium.py",
line 344, in _reinit
self.init(args)
File
"/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/magnesium.py",
line 293, in init
args, self._init_args, fast_reinit)
File
"/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/mg_init.py", line
615, in init
args
File
"/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/mg_init.py", line
555, in _full_init
args)
File
"/usr/lib/python3.5/site-packages/usrp_mpm/dboard_manager/mg_init.py", line
221, in _sync_db_clock
target_offset=trace_delay_offset)
File "/usr/lib/python3.5/site-packages/usrp_mpm/cores/tdc_sync.py", line
201, in run
self.configure(force=True)
File "/usr/lib/python3.5/site-packages/usrp_mpm/cores/tdc_sync.py", line
254, in configure
raise RuntimeError("TDC Failed to reset.")
RuntimeError: TDC Failed to reset.
I can't seem to find anything about "TDC" online. Once I get this error,
it doesn't seem to recover even if I change the parameters back, and the
only way I have found to fix it is to reset the device.
I believe the white rabbit switch is configured properly because I am able
to synchronize between two daughterboards within a single N310 by setting
the "sync" parameter to "unknown PPS" which then calls the
set_time_next_pps. If I don't set the
Re: [USRP-users] daughter board coherency on N310
Marcus, Yes it was all coming out of the same uhd_source object. I think I was able to resolve the issue for now by setting the "Sync" parameter to "unknown PPS" which I *believe* is using the White Rabbit Ethernet based timing synchronization which we have connected at one of the SFP ports, though I need to dig in a bit more into the API. I agree 20 ms is *HUGE*; is it unexpected even without an external timing source? Should I still be concerned? Thanks, Cameron On Fri, Nov 20, 2020 at 12:43 PM Marcus D. Leech wrote: > On 11/20/2020 11:49 AM, Rob Kossler wrote: > > Hi Cameron, > Yes, this is possible. I'm not too familiar with gnuradio but in the end > you need to use a "timed start" to the receive streams. > Rob > > On Fri, Nov 20, 2020 at 7:34 AM Cameron Matson via USRP-users < > usrp-us...@lists.ettus.com> wrote: > >> Hello all, >> >> I'm trying to implement a MIMO receiver using the 4 RF chains of the >> N310. To test the timing of the system, at the transmitter I'm simply >> sending a short pulse from one transmit antenna of one USRP. At the >> receiver it looks like there is up to a ~20 ms delay/offset between the >> pairs of antennas 0/1 and 2/3 and that this delay changes each time I >> restart my GNURadio flowgraph. I can see the delay both in GNURadio GUI >> Time Sink and in actual samples that I write to file. I've tried various >> pulse widths and sampling rates at both the tx and rx, and it seems >> invariant to these. >> >> I'd really like to be able to synchronize the 4 RF chains in time >> simultaneously. Is that possible? >> >> Thanks >> Cameron Matson >> ___ >> >> Cameron: > > Can you share a simple Gnu Radio flow-graph that displays this behavior? > A 20ms offset is *HUGE*. Are all 4 streams being streamed out > of the same uhd_source object? > > > >
daughter board coherency on N310
Hello all, I'm trying to implement a MIMO receiver using the 4 RF chains of the N310. To test the timing of the system, at the transmitter I'm simply sending a short pulse from one transmit antenna of one USRP. At the receiver it looks like there is up to a ~20 ms delay/offset between the pairs of antennas 0/1 and 2/3 and that this delay changes each time I restart my GNURadio flowgraph. I can see the delay both in GNURadio GUI Time Sink and in actual samples that I write to file. I've tried various pulse widths and sampling rates at both the tx and rx, and it seems invariant to these. I'd really like to be able to synchronize the 4 RF chains in time simultaneously. Is that possible? Thanks Cameron Matson
Re: Tag propagation policy in python
Great! thank you. Cameron On Tue, Nov 17, 2020 at 12:25 PM Jeff Long wrote: > from gnuradio import gr > print(gr.TPP_CUSTOM) > > On Tue, Nov 17, 2020 at 11:06 AM Cameron Matson > wrote: > >> Hello all, >> >> I'm trying to use an embedded python block and would like to change the >> tag propagation policy to TPP_DONT, but I can't seem to correctly qualify >> that enum type. How can I refer to this value? >> >> Thanks, >> Cameron >> >
Tag propagation policy in python
Hello all, I'm trying to use an embedded python block and would like to change the tag propagation policy to TPP_DONT, but I can't seem to correctly qualify that enum type. How can I refer to this value? Thanks, Cameron
Re: [USRP-users] N310 self interference with packet comms and correlation estimator
Johannes, The 140 came from this datasheet https://www.ettus.com/wp-content/uploads/2019/01/USRP_N310_Datasheet_v3.pdf It does indicate that this is probably a worst case scenario, and that UHD software would improve it. My flow graph has two separate parts, one for the TX that goes to a USRP sink and one for RX that begins from a USRP source. It's a little difficult for me to say exactly how the timing works in my setup because I'm using triggers to show the previous two plots. Just to clarify: In your case are you saying that after transmitting on TX/RX the n310 switches to receiving on TX/RX and you receive the sent data 18us later? Thanks, Cameron On Thu, Aug 20, 2020 at 12:30 PM Johannes Demel wrote: > Hi Cameron, > > where did you find this 140us switching time? I'm curious. > > If I recall correctly, my tests with N310s indicate 18us delay between > TX and RX with timed bursts at sample x and corresponding start of burst > in RX at x+18us. The behavior you observe seems to be different. > > How does your flowgraph look like? > > Cheers > Johannes > > On 20.08.20 17:21, Cameron Matson wrote: > > Hello everyone, > > > > An update: I made an attempt to pad the tx signal with 0s to no avail. > > My understanding is that TX/RX handles the switching from TX to RX, and > > is "always RX" unless there's something to TX. The N310 datasheet says > > that the switching time is 140 us. I've tried adding 0s which at my > > sample rate and frequency would be well above that. But it looks like > > the message I'm sending is immediately received in full, with some shift > > in the IQ data (below). It appears it's operating in full-duplex, which > > I don't want--I want TDD. What's strange is that if I set it to send on > > TX/RX and receive on RX2 (which to my understanding /should/ be full > > duplex) it doesn't see the transmitted signal. > > > > Am I doing something wrong? > > image.png > > > > Thanks, > > Cameron > > > > On Tue, Aug 18, 2020 at 2:03 PM Cameron Matson > <mailto:ncmatso...@gmail.com>> wrote: > > > > Forgot to reply to the list. > > > > -- Forwarded message - > > From: *Cameron Matson* > <mailto:ncmatso...@gmail.com>> > > Date: Tue, Aug 18, 2020, 2:01 PM > > Subject: Re: [USRP-users] N310 self interference with packet comms > > and correlation estimator > > To: Jeff Long mailto:willco...@gmail.com>> > > > > > > I'm using one TX/RX port for both. > > > > I'm using the same frequency for transmit and receive because the > > system I'm trying to implement will eventually have multiple > > "transmitter" nodes like I've described trying to communicate to a > > single receiver. The rx part of the transmitter is for collision > > avoidance, so it needs to be on the same frequency as the other > > transmitters so it can sense when the channel is busy. > > > > I'm not sure I fully understand the post you included, with respect > > to the setup/teardown of the different streams. But the zero padding > > seems like it might work. My thoughts are that it's either a buffer > > remnant or reflections off nearby objects or the radio itself. I > > think transmitting empty data after the burst before transitioning > > back to rx might help. > > > > Thanks! > > Cameron > > > > On Tue, Aug 18, 2020, 11:33 AM Jeff Long > <mailto:willco...@gmail.com>> wrote: > > > > Or maybe this is what you're seeing. Except from > > > https://usrp-users.ettus.narkive.com/s4vNkAe9/buffer-reset-or-clear-issue-on-usrp-n200 > > > > """ > > The buffers should clear whenever the device object is > > constructed, also > > when the transmit or receive streamer is constructed. > > > > If you dont want to tear-down and re-construct the rx streamer, > > you can > > simply issue a stop stream command (if this is continuous > > streaming), > > and call recv() until timeout. This will also flush out rx > buffers. > > > > Now the filters in the DSP chains do have history to them. So if > > you are > > having some issue with that, tx streams should be padded out at > > their > > end so the upconversion filters have zeros in their history; > > likewise, > > you an throw out the first several rx samples, which could be rx > >
Fwd: [USRP-users] N310 self interference with packet comms and correlation estimator
Forgot to reply to the list. -- Forwarded message - From: Cameron Matson Date: Tue, Aug 18, 2020, 2:01 PM Subject: Re: [USRP-users] N310 self interference with packet comms and correlation estimator To: Jeff Long I'm using one TX/RX port for both. I'm using the same frequency for transmit and receive because the system I'm trying to implement will eventually have multiple "transmitter" nodes like I've described trying to communicate to a single receiver. The rx part of the transmitter is for collision avoidance, so it needs to be on the same frequency as the other transmitters so it can sense when the channel is busy. I'm not sure I fully understand the post you included, with respect to the setup/teardown of the different streams. But the zero padding seems like it might work. My thoughts are that it's either a buffer remnant or reflections off nearby objects or the radio itself. I think transmitting empty data after the burst before transitioning back to rx might help. Thanks! Cameron On Tue, Aug 18, 2020, 11:33 AM Jeff Long wrote: > Or maybe this is what you're seeing. Except from > > https://usrp-users.ettus.narkive.com/s4vNkAe9/buffer-reset-or-clear-issue-on-usrp-n200 > > """ > The buffers should clear whenever the device object is constructed, also > when the transmit or receive streamer is constructed. > > If you dont want to tear-down and re-construct the rx streamer, you can > simply issue a stop stream command (if this is continuous streaming), > and call recv() until timeout. This will also flush out rx buffers. > > Now the filters in the DSP chains do have history to them. So if you are > having some issue with that, tx streams should be padded out at their > end so the upconversion filters have zeros in their history; likewise, > you an throw out the first several rx samples, which could be rx history > from the last run. > """ > > On Tue, Aug 18, 2020 at 12:07 PM Jeff Long wrote: > >> This is why cell phones use different uplink/downlink frequencies (or >> time slots). Are you using two different USRP ports for TX and RX and >> connecting them to the same antenna? Or are you using a TX/RX port with tx >> and rx streamers attached? >> >> On Tue, Aug 18, 2020 at 11:48 AM Cameron Matson via USRP-users < >> usrp-us...@lists.ettus.com> wrote: >> >>> Hey everyone, >>> >>> I've copied both the gnuradio and usrp lists, since I'm not sure if the >>> question has a software or hardware answer, so I apologize for duplicate >>> emails. >>> >>> I am attempting to set up a wireless transceiver using N310s and the >>> packet tx/rx examples from gnuradio. I combined both the tx and rx chains >>> in one flowgraph with zeromq source/sink blocks like this: >>> >>> [zmq source] -> [packet tx] -> [usrp sink] >>> and >>> [usrp source] -> [packet rx] -> [zmq sink] >>> >>> I have a separate python file running in a separate process. That >>> handles messages from the zmq blocks and controls state changes between >>> "backoff", "listen" and "talk" >>> >>> I'm not sure the specific terminology for the variety of duplex I'm >>> trying to implement, but I want the TX and RX to happen on the same >>> frequency using one antenna. The problem is that if I use the same >>> frequency, my RX chain immediately "hears" the signal that was >>> transmitted. By "hears" I mean that the first part of the [packet rx] >>> block, which is the [correlation estimator] block detects the signal as a >>> valid packet. The problem is that because the amplitude of my desired rx >>> signal is low, I've had to set the threshold of the correlation estimator >>> relatively low--and so the recently transmitted signal, which has a much >>> higher amplitude being right next to the rx antenna, overwhelms the >>> detector. This doesn't happen if I have the TX and RX on different >>> frequencies >>> >>> What I don't quite fully understand is what happens on the N310 when a >>> flow graph with both transmit and receive processes are active. I can see >>> from the LEDs that it is "receiving" most of the time and when it gets a >>> message to transmit it will blink to tx and then back. What happens in >>> this process? One thought is that since its the same antenna, the tx and >>> rx might share a buffer and the tx data is still present there. >>> >>> Is what I'm trying to do even possible? >>> >>> Thanks for your time, >>> >>> Cameron >>> ___ >>> USRP-users mailing list >>> usrp-us...@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>
N310 self interference with packet comms and correlation estimator
Hey everyone, I've copied both the gnuradio and usrp lists, since I'm not sure if the question has a software or hardware answer, so I apologize for duplicate emails. I am attempting to set up a wireless transceiver using N310s and the packet tx/rx examples from gnuradio. I combined both the tx and rx chains in one flowgraph with zeromq source/sink blocks like this: [zmq source] -> [packet tx] -> [usrp sink] and [usrp source] -> [packet rx] -> [zmq sink] I have a separate python file running in a separate process. That handles messages from the zmq blocks and controls state changes between "backoff", "listen" and "talk" I'm not sure the specific terminology for the variety of duplex I'm trying to implement, but I want the TX and RX to happen on the same frequency using one antenna. The problem is that if I use the same frequency, my RX chain immediately "hears" the signal that was transmitted. By "hears" I mean that the first part of the [packet rx] block, which is the [correlation estimator] block detects the signal as a valid packet. The problem is that because the amplitude of my desired rx signal is low, I've had to set the threshold of the correlation estimator relatively low--and so the recently transmitted signal, which has a much higher amplitude being right next to the rx antenna, overwhelms the detector. This doesn't happen if I have the TX and RX on different frequencies What I don't quite fully understand is what happens on the N310 when a flow graph with both transmit and receive processes are active. I can see from the LEDs that it is "receiving" most of the time and when it gets a message to transmit it will blink to tx and then back. What happens in this process? One thought is that since its the same antenna, the tx and rx might share a buffer and the tx data is still present there. Is what I'm trying to do even possible? Thanks for your time, Cameron
Re: ZeroMQ Linger option
I think I came up with something that will work. I'm trying to implement a
carrier sense/collision avoidance scheme for wireless packet transmission.
Whenever the rx chain detects a packet, it pushes it via zmq it to another
process running a controller script which runs a state machine between
"backoff", "listen", and "talk" states. The problem I was having was that
I was only handling zmq messages during the "listen" state and so if I had
two USRPs trying to transmit messages, whichever went first would cause the
other to backoff and then messages would build up in the the receivers
queue (or whatever the buffered memory zmq uses). I was thinking that if I
could somehow programmatically close and reopen the socket only when I was
in the listen state I could prevent this buildup.
I ended up changing the logic of the control program to continuously call
the zmq poller and then handle the message only if the backoff time expired
and it was attempting to transmit, which seems to be working for what I want
There's probably a cleaner and more semantic way of doing this. I am by no
means an expert at gnuradio or sockets, but I think what I have is good
enough for now.
Thanks for your help,
Cameron
On Tue, Aug 11, 2020 at 5:32 AM Jeff Long wrote:
> Not that I can see. What effect are you looking for, though?
>
> On Mon, Aug 10, 2020 at 11:08 PM Cameron Matson
> wrote:
>
>> Ah, thanks for clearing that up. And it looks like there's no way to
>> manually close/reopen the socket that gets created by the flowgraph correct?
>>
>> Cameron
>>
>>
>>
>> On Mon, Aug 10, 2020 at 6:15 PM Jeff Long wrote:
>>
>>> Also, time is always set to 0 for the setsockopt ZMQ_LINGER call, which
>>> would cause immediate shutdown of the socket. This is not related to
>>> timeout, which is used as the polling timeout.
>>>
>>> On Mon, Aug 10, 2020 at 7:06 PM Jeff Long wrote:
>>>
>>>> At socket shutdown, LINGER determines how long close(2) or shutdown(2)
>>>> will block waiting for queue messages to be sent. See man socket(7).
>>>>
>>>> On Mon, Aug 10, 2020 at 7:00 PM Cameron Matson
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Can someone help me understand what's going on with any of the ZMQ
>>>>> Message Sink blocks? The block takes a timeout parameter which is
>>>>> assigned
>>>>> to d_timeout, but ultimately it looks like the zmq.LINGER option (which I
>>>>> believe is how long zmq will block before dropping the frame) is always
>>>>> set
>>>>> to a different variable, time, which is initialized in the constructor to
>>>>> be 0 that is used for the setsockopt call.
>>>>>
>>>>> if (major < 3) {
>>>>> d_timeout = timeout * 1000;
>>>>> }
>>>>> d_context = new zmq::context_t(1);
>>>>> d_socket = new zmq::socket_t(*d_context, ZMQ_REP);
>>>>> int time = 0;
>>>>> d_socket->setsockopt(ZMQ_LINGER, , sizeof(time));
>>>>> Am I missing something?
>>>>>
>>>>> Thanks,
>>>>> Cameron
>>>>>
>>>>>
Re: ZeroMQ Linger option
Ah, thanks for clearing that up. And it looks like there's no way to
manually close/reopen the socket that gets created by the flowgraph correct?
Cameron
On Mon, Aug 10, 2020 at 6:15 PM Jeff Long wrote:
> Also, time is always set to 0 for the setsockopt ZMQ_LINGER call, which
> would cause immediate shutdown of the socket. This is not related to
> timeout, which is used as the polling timeout.
>
> On Mon, Aug 10, 2020 at 7:06 PM Jeff Long wrote:
>
>> At socket shutdown, LINGER determines how long close(2) or shutdown(2)
>> will block waiting for queue messages to be sent. See man socket(7).
>>
>> On Mon, Aug 10, 2020 at 7:00 PM Cameron Matson
>> wrote:
>>
>>> Hi all,
>>>
>>> Can someone help me understand what's going on with any of the ZMQ
>>> Message Sink blocks? The block takes a timeout parameter which is assigned
>>> to d_timeout, but ultimately it looks like the zmq.LINGER option (which I
>>> believe is how long zmq will block before dropping the frame) is always set
>>> to a different variable, time, which is initialized in the constructor to
>>> be 0 that is used for the setsockopt call.
>>>
>>> if (major < 3) {
>>> d_timeout = timeout * 1000;
>>> }
>>> d_context = new zmq::context_t(1);
>>> d_socket = new zmq::socket_t(*d_context, ZMQ_REP);
>>> int time = 0;
>>> d_socket->setsockopt(ZMQ_LINGER, , sizeof(time));
>>> Am I missing something?
>>>
>>> Thanks,
>>> Cameron
>>>
>>>
ZeroMQ Linger option
Hi all,
Can someone help me understand what's going on with any of the ZMQ Message
Sink blocks? The block takes a timeout parameter which is assigned to
d_timeout, but ultimately it looks like the zmq.LINGER option (which I
believe is how long zmq will block before dropping the frame) is always set
to a different variable, time, which is initialized in the constructor to
be 0 that is used for the setsockopt call.
if (major < 3) {
d_timeout = timeout * 1000;
}
d_context = new zmq::context_t(1);
d_socket = new zmq::socket_t(*d_context, ZMQ_REP);
int time = 0;
d_socket->setsockopt(ZMQ_LINGER, , sizeof(time));
Am I missing something?
Thanks,
Cameron
Fwd: errors in packet payload with n310s
Forgot to reply to the list. -- Forwarded message - From: Cameron Matson Date: Mon, Aug 3, 2020 at 10:55 AM Subject: Re: errors in packet payload with n310s To: Michael Carosino Mike, Thanks for taking the time to look at those examples. Your comments make a lot of sense. I'm pretty new to this so I haven't gotten to know all the "well known" problems yet! I will try to incorporate the differential encoding into the flowgraph. Unfortunately, for some reason, the packet tx/rx examples don't use the Constellation Modulator/Demodulator blocks which have an option for differential encoding, so I'll have to tinker with it a bit to incorporate that, but it sounds like that will definitely help. Interesting point about the phase_est tag only going to the header chain. Does anyone have any reasoning behind that? Thanks again, Cameron On Sun, Aug 2, 2020 at 11:40 AM Michael Carosino wrote: > Regarding the 2nd problem you're seeing, that sounds a lot like the well > known 180 degree phase ambiguity of the bpsk costas loop. I'm not super > familiar with the corr_est scheme used in the packet_rx example but AFAIK > if it's working correctly it should generate a tag containing an estimate > of the phase using the preamble and that tag would be used by the costas as > an initial condition. Assuming that the phase estimate is closer to the > true phase (than one at a multiple of pi away), the costas should converge > to the true phase. However - if the phase estimate is closer to one the > pi-multiples (or there is no phase estimate), the costas may lock to a 180 > degree multiple and result in the detected bit sequence being inverted. > > I briefly looked at the packet_rx example and interestingly the header > payload demux block only passes the phase_est tag to the header processing > chain but not the payload processing chain. This means that the header > chain's costas loop is getting an initial phase estimate while the payload > chain's costas is not - in this case I'd expect the payload bits to be > inverted occasionally as you're seeing. One quick check to see if this is > the case would be to enable differential encoding on the payload bits to > resolve the ambiguity. > > I'm not sure why the payload demux block doesn't pass the phase_est tag to > both the header + payload outputs , perhaps someone has some insight there, > wouldn't be surprised if I'm overlooking some issues that makes this more > complicated than I'm imagining. > > Mike > > On Sat, Aug 1, 2020 at 3:48 PM Cameron Matson > wrote: > >> Hi everyone, >> >> This might be more of a general digital communication question, so >> forgive me if this is inappropriate for this list, but I'm hoping you can >> provide some insight w.r.t the implementation. >> >> I'm using the architecture from the packet_tx/rx examples ( >> https://www.gnuradio.org/doc/doxygen-v3.7.13.4/page_packet_comms.html I >> am using 3.7) to send packet data wirelessly between two USRP N310s. I'm >> using the repetition encoder and BPSK for both the header and the payload. >> The receiver is correctly detecting the packets, and the headers match >> exactly to what was transmitted, so I believe detection parts of the >> flowgraph (amplitude, timing, phase estimation and correction) are working >> properly, but there are significant bit errors in the payload. I've >> observed two things happening: >> >> 1. The first 8-9 bytes will be correct and then it appears to "drop" a >> bit, and the remaining bits will be off by one to the tx data. This >> "dropping" could happen a few times per message. >> >> 2. The entire rx payload will be the complement of the tx data. >> >> These two things could happen together or independently. >> >> For the first effect, it seems like the sample rate is not lining up with >> the edges of the symbols, or maybe a slight offset between the true sample >> rates of the tx and rx. But the header is detected and decoded perfectly >> consistently; it's only in the payload that these "drops" occur. I'm not >> sure why the second would happen. >> >> Can you think of anything in the blocks of the packet_tx/rx examples that >> I can adjust to help with either of these problems? Or just in general >> what might be going on? >> >> Thank you for your time, >> >> Cameron >> >
errors in packet payload with n310s
Hi everyone, This might be more of a general digital communication question, so forgive me if this is inappropriate for this list, but I'm hoping you can provide some insight w.r.t the implementation. I'm using the architecture from the packet_tx/rx examples ( https://www.gnuradio.org/doc/doxygen-v3.7.13.4/page_packet_comms.html I am using 3.7) to send packet data wirelessly between two USRP N310s. I'm using the repetition encoder and BPSK for both the header and the payload. The receiver is correctly detecting the packets, and the headers match exactly to what was transmitted, so I believe detection parts of the flowgraph (amplitude, timing, phase estimation and correction) are working properly, but there are significant bit errors in the payload. I've observed two things happening: 1. The first 8-9 bytes will be correct and then it appears to "drop" a bit, and the remaining bits will be off by one to the tx data. This "dropping" could happen a few times per message. 2. The entire rx payload will be the complement of the tx data. These two things could happen together or independently. For the first effect, it seems like the sample rate is not lining up with the edges of the symbols, or maybe a slight offset between the true sample rates of the tx and rx. But the header is detected and decoded perfectly consistently; it's only in the payload that these "drops" occur. I'm not sure why the second would happen. Can you think of anything in the blocks of the packet_tx/rx examples that I can adjust to help with either of these problems? Or just in general what might be going on? Thank you for your time, Cameron
Re: correlation estimator causing flowgraph to hang: Return Code -15
I'll take a look at it, but I don't think the crash is actually originating from zeros coming into the corr_est block. If the header/payload demux block within packet_rx is enabled it will freeze basically right away after the first estimate from the corr_est. If that demux is disabled the flowgraph will run longer, but will eventually crash at the polyphase clock sync block. If that block is disabled, then it seems to run indefinitely. Thanks, Cameron On Fri, Jul 3, 2020 at 7:44 PM Jeff Long wrote: > Divide by zero would crash the block, and likely the whole flowgraph > unless the error is getting caught somewhere. There's probably a thread > hanging around until you manually kill the program, and then the error gets > printed. > > I took a really quick look at uhd_packet_rx and packet_rx and it sure > looks like you'd get zeros into corr_est. I did not take the time to set up > and debug, though. Maybe you could verify that zeros are hitting that > block, and that bypassing the block stops the crash. The flowgraph won't > work right, but it's good info for a bug report if that's what's happening. > > On Fri, Jul 3, 2020 at 9:55 AM Cameron Matson > wrote: > >> Thanks for pointing that out Jeff. The way the usrp_packet_rx example >> works is with a multiply_const block just before the packet_rx (where the >> corr_est block lives) that by default is multiply by zero. So wouldn't we >> automatically get that /0? >> >> Is divide by zero a common cause for flowgraphs to freeze? Is that what >> return code -15 is? >> >> Thanks, >> Cameron >> >> On Thu, Jul 2, 2020 at 4:07 PM Jeff Long wrote: >> >>> If work() can reach this line: >>> >>> >>> https://github.com/gnuradio/gnuradio/blob/maint-3.8/gr-digital/lib/corr_est_cc_impl.cc#L311 >>> >>> with an all-zero signal, there could be a /0 error. >>> >>> On Thu, Jul 2, 2020 at 4:04 PM Cameron Matson >>> wrote: >>> >>>> Hi all, >>>> >>>> An update: I've noticed that when the flowgraph hangs it's usually >>>> because the correlation estimator block is outputting a relatively larger >>>> 'amp_est' tag (in my case this is normally a value < 1 but sometimes up to >>>> around 10. When it freezes it is usually > 50). If I then close the GUI >>>> tab the flowgraph doesn't actually finish until I hit the 'Kill' button in >>>> GRC. Only after that the terminal will print ">>>Done (return code -15)" >>>> I can't find anything on what that code might mean. Does anyone have any >>>> idea? >>>> >>>> Thanks, >>>> Cameron >>>> >>>> On Wed, Jul 1, 2020 at 5:31 PM Cameron Matson >>>> wrote: >>>> >>>>> Hi all, >>>>> I'm trying to send packet data from between two USRPs wirelessly using >>>>> the slightly modified uhd_packet_tx/rx examples (attached). It appears >>>>> that whenever the packet_rx block "finds" a correlation the entire flow >>>>> graph hangs. I say "find" because in order to get any output from the >>>>> correlation estimator block within packet_rx I have to set the threshold >>>>> very low, so I'm not very confident that it's finding what it needs. I've >>>>> tried playing around with the different encodings and header formats that >>>>> are part of the example, but it doesn't seem to change anything. >>>>> >>>>> First question: what could be causing the rx flowgraph to hang? I >>>>> know some of the downstream blocks in the packet_rx hier block use the >>>>> tags >>>>> the correlation estimator outputs. >>>>> >>>>> Second question: what are some things I can try to improve the >>>>> detection in the first place? >>>>> >>>>> Thanks, >>>>> Cameron >>>>> >>>>
Re: correlation estimator causing flowgraph to hang: Return Code -15
Thanks for pointing that out Jeff. The way the usrp_packet_rx example works is with a multiply_const block just before the packet_rx (where the corr_est block lives) that by default is multiply by zero. So wouldn't we automatically get that /0? Is divide by zero a common cause for flowgraphs to freeze? Is that what return code -15 is? Thanks, Cameron On Thu, Jul 2, 2020 at 4:07 PM Jeff Long wrote: > If work() can reach this line: > > > https://github.com/gnuradio/gnuradio/blob/maint-3.8/gr-digital/lib/corr_est_cc_impl.cc#L311 > > with an all-zero signal, there could be a /0 error. > > On Thu, Jul 2, 2020 at 4:04 PM Cameron Matson > wrote: > >> Hi all, >> >> An update: I've noticed that when the flowgraph hangs it's usually >> because the correlation estimator block is outputting a relatively larger >> 'amp_est' tag (in my case this is normally a value < 1 but sometimes up to >> around 10. When it freezes it is usually > 50). If I then close the GUI >> tab the flowgraph doesn't actually finish until I hit the 'Kill' button in >> GRC. Only after that the terminal will print ">>>Done (return code -15)" >> I can't find anything on what that code might mean. Does anyone have any >> idea? >> >> Thanks, >> Cameron >> >> On Wed, Jul 1, 2020 at 5:31 PM Cameron Matson >> wrote: >> >>> Hi all, >>> I'm trying to send packet data from between two USRPs wirelessly using >>> the slightly modified uhd_packet_tx/rx examples (attached). It appears >>> that whenever the packet_rx block "finds" a correlation the entire flow >>> graph hangs. I say "find" because in order to get any output from the >>> correlation estimator block within packet_rx I have to set the threshold >>> very low, so I'm not very confident that it's finding what it needs. I've >>> tried playing around with the different encodings and header formats that >>> are part of the example, but it doesn't seem to change anything. >>> >>> First question: what could be causing the rx flowgraph to hang? I know >>> some of the downstream blocks in the packet_rx hier block use the tags the >>> correlation estimator outputs. >>> >>> Second question: what are some things I can try to improve the detection >>> in the first place? >>> >>> Thanks, >>> Cameron >>> >>
Re: correlation estimator causing flowgraph to hang: Return Code -15
Hi all, An update: I've noticed that when the flowgraph hangs it's usually because the correlation estimator block is outputting a relatively larger 'amp_est' tag (in my case this is normally a value < 1 but sometimes up to around 10. When it freezes it is usually > 50). If I then close the GUI tab the flowgraph doesn't actually finish until I hit the 'Kill' button in GRC. Only after that the terminal will print ">>>Done (return code -15)" I can't find anything on what that code might mean. Does anyone have any idea? Thanks, Cameron On Wed, Jul 1, 2020 at 5:31 PM Cameron Matson wrote: > Hi all, > I'm trying to send packet data from between two USRPs wirelessly using the > slightly modified uhd_packet_tx/rx examples (attached). It appears that > whenever the packet_rx block "finds" a correlation the entire flow graph > hangs. I say "find" because in order to get any output from the > correlation estimator block within packet_rx I have to set the threshold > very low, so I'm not very confident that it's finding what it needs. I've > tried playing around with the different encodings and header formats that > are part of the example, but it doesn't seem to change anything. > > First question: what could be causing the rx flowgraph to hang? I know > some of the downstream blocks in the packet_rx hier block use the tags the > correlation estimator outputs. > > Second question: what are some things I can try to improve the detection > in the first place? > > Thanks, > Cameron >
Re: Packet TX and RX on E312
I moved my setup from e312s to n310s so that I could run the flowgraphs with the gui blocks to help with debugging. It looks like the phase is off at the RX as the constellation gui from the USRP (the one before the Packet Rx block) is rotating. I'm able to adjust the magnitude of the IQ data by playing with the tx and rx gain, but I can't get the phase to lock. What are some of the knobs I can turn to help the Packet Rx block detect the signal given the phase offset? Thanks, Cameron On Wed, Jun 24, 2020 at 8:53 AM Cameron Matson wrote: > Marcus, > Thanks for that information, maybe I'll look more into the FPGA. > > As for the other problem I agree, it's probably setup. The radios are > "connected" via antennae. Both USRPs have VERT900 antennae to the TRX > terminals. > > I've run other experiments successfully transmitting data from one to the > other. For example I've used the (deprecated I know) Packet > Encoder/Decoder block to send a file from one to the other. But nothing > since I started using the Packet TX/RX hier blocks. > > Cameron > > > On Tue, Jun 23, 2020, 2:14 PM Marcus D. Leech > wrote: > >> On 06/23/2020 01:17 PM, Cameron Matson wrote: >> >> I've tried from 125K to 16M (which if I request anything higher is what >> the device seems to cap it at). The lower sample rates on the RX side >> actually do solve the O problem, which I guess makes sense, but the tG and >> U are still there on the TX side, and no packets seem to be decoded. >> >> Cameron >> >> The CPU on the E310 is a dual-core ARM9 CPU clocked at 866MHz. That >> means that it can't move very many samples (particularly full-duplex) >> per second for a "complex" signal flow that involves >> modulaton/demodulation. When doing pretty-much *nothing* to the samples, >> the interface >> can move a few Msps. That goes down quickly as you actually have to do >> anything to the samples. The E310 has a larger FPGA, and the >> "marketted use case" is to do most processing in the FPGA. >> >> Now, as to why, at lower rates, you cannot decode, that's a debugging >> exercise perhaps not related, per se, to the E310, but just >> the experimental setup. >> >> How are the two radios "connected" -- via antennae or a cable? If cable, >> make sure you have plenty of attenuation in-line (30-40dB), >> otherwise you risk damage to the receiver at worst, and at best, >> driving the receive chain into non-linearity, producing distortions and >> unwanted mixing products within the first gain stage(s). >> >> >> >> On Tue, Jun 23, 2020 at 12:03 PM Marcus D Leech >> wrote: >> >>> What sample rate ranges have you tried? >>> >>> Sent from my iPhone >>> >>> On Jun 23, 2020, at 12:57 PM, Cameron Matson >>> wrote: >>> >>> >>> Hello all, >>> >>> I'm new to gnuradio and SDR so I hope there isn't something obvious I'm >>> missing. I'm trying to get a packet based system set up. I'm using >>> gnuradio 3.7 and UHD 3.14 that I cross compiled and loaded onto two E312s. >>> >>> I'm trying to use the uhd_packet_tx and uhd_packet_rx examples as a >>> staring point. I made the necessary modifications to run it as a non-gui >>> flowgraph, but left all the variables untouched. Both the flow graphs run, >>> but: >>> >>>- the Tx flow graph shows an initial tG flag and then a U flag >>>after every burst (which I understand has something to do with tag >>> offsets >>>mismatching https://github.com/gnuradio/gnuradio/issues/1976) >>>- The Rx flow graph immediately starts outputing O flags, and no >>>packets are recieved. >>> >>> I've tried playing around with the frequency and sampling rates without >>> much success. >>> >>> Any help on where to start would be greatly appreciated. >>> >>> Thanks, >>> Cameron >>> >>> >>
Re: Packet TX and RX on E312
Marcus, Thanks for that information, maybe I'll look more into the FPGA. As for the other problem I agree, it's probably setup. The radios are "connected" via antennae. Both USRPs have VERT900 antennae to the TRX terminals. I've run other experiments successfully transmitting data from one to the other. For example I've used the (deprecated I know) Packet Encoder/Decoder block to send a file from one to the other. But nothing since I started using the Packet TX/RX hier blocks. Cameron On Tue, Jun 23, 2020, 2:14 PM Marcus D. Leech wrote: > On 06/23/2020 01:17 PM, Cameron Matson wrote: > > I've tried from 125K to 16M (which if I request anything higher is what > the device seems to cap it at). The lower sample rates on the RX side > actually do solve the O problem, which I guess makes sense, but the tG and > U are still there on the TX side, and no packets seem to be decoded. > > Cameron > > The CPU on the E310 is a dual-core ARM9 CPU clocked at 866MHz. That means > that it can't move very many samples (particularly full-duplex) > per second for a "complex" signal flow that involves > modulaton/demodulation. When doing pretty-much *nothing* to the samples, > the interface > can move a few Msps. That goes down quickly as you actually have to do > anything to the samples. The E310 has a larger FPGA, and the > "marketted use case" is to do most processing in the FPGA. > > Now, as to why, at lower rates, you cannot decode, that's a debugging > exercise perhaps not related, per se, to the E310, but just > the experimental setup. > > How are the two radios "connected" -- via antennae or a cable? If cable, > make sure you have plenty of attenuation in-line (30-40dB), > otherwise you risk damage to the receiver at worst, and at best, driving > the receive chain into non-linearity, producing distortions and > unwanted mixing products within the first gain stage(s). > > > > On Tue, Jun 23, 2020 at 12:03 PM Marcus D Leech > wrote: > >> What sample rate ranges have you tried? >> >> Sent from my iPhone >> >> On Jun 23, 2020, at 12:57 PM, Cameron Matson >> wrote: >> >> >> Hello all, >> >> I'm new to gnuradio and SDR so I hope there isn't something obvious I'm >> missing. I'm trying to get a packet based system set up. I'm using >> gnuradio 3.7 and UHD 3.14 that I cross compiled and loaded onto two E312s. >> >> I'm trying to use the uhd_packet_tx and uhd_packet_rx examples as a >> staring point. I made the necessary modifications to run it as a non-gui >> flowgraph, but left all the variables untouched. Both the flow graphs run, >> but: >> >>- the Tx flow graph shows an initial tG flag and then a U flag after >>every burst (which I understand has something to do with tag offsets >>mismatching https://github.com/gnuradio/gnuradio/issues/1976) >>- The Rx flow graph immediately starts outputing O flags, and no >>packets are recieved. >> >> I've tried playing around with the frequency and sampling rates without >> much success. >> >> Any help on where to start would be greatly appreciated. >> >> Thanks, >> Cameron >> >> >
Re: Packet TX and RX on E312
I've tried from 125K to 16M (which if I request anything higher is what the device seems to cap it at). The lower sample rates on the RX side actually do solve the O problem, which I guess makes sense, but the tG and U are still there on the TX side, and no packets seem to be decoded. Cameron On Tue, Jun 23, 2020 at 12:03 PM Marcus D Leech wrote: > What sample rate ranges have you tried? > > Sent from my iPhone > > On Jun 23, 2020, at 12:57 PM, Cameron Matson wrote: > > > Hello all, > > I'm new to gnuradio and SDR so I hope there isn't something obvious I'm > missing. I'm trying to get a packet based system set up. I'm using > gnuradio 3.7 and UHD 3.14 that I cross compiled and loaded onto two E312s. > > I'm trying to use the uhd_packet_tx and uhd_packet_rx examples as a > staring point. I made the necessary modifications to run it as a non-gui > flowgraph, but left all the variables untouched. Both the flow graphs run, > but: > >- the Tx flow graph shows an initial tG flag and then a U flag after >every burst (which I understand has something to do with tag offsets >mismatching https://github.com/gnuradio/gnuradio/issues/1976) >- The Rx flow graph immediately starts outputing O flags, and no >packets are recieved. > > I've tried playing around with the frequency and sampling rates without > much success. > > Any help on where to start would be greatly appreciated. > > Thanks, > Cameron > >
Packet TX and RX on E312
Hello all, I'm new to gnuradio and SDR so I hope there isn't something obvious I'm missing. I'm trying to get a packet based system set up. I'm using gnuradio 3.7 and UHD 3.14 that I cross compiled and loaded onto two E312s. I'm trying to use the uhd_packet_tx and uhd_packet_rx examples as a staring point. I made the necessary modifications to run it as a non-gui flowgraph, but left all the variables untouched. Both the flow graphs run, but: - the Tx flow graph shows an initial tG flag and then a U flag after every burst (which I understand has something to do with tag offsets mismatching https://github.com/gnuradio/gnuradio/issues/1976) - The Rx flow graph immediately starts outputing O flags, and no packets are recieved. I've tried playing around with the frequency and sampling rates without much success. Any help on where to start would be greatly appreciated. Thanks, Cameron
Handshake and Message Passing with gr-ieee802-11
Hello, I'm trying to implement a handshaking scheme using message passing. I'm starting from the gr-ieee80211 loopback example. My plan was to build a block that buffers (using std::queue) input messages from the Wifi Mac block on one message port, and then when it receives a message on a second message port, pops the first message off the queue and pushes it to an output message port. The output is fed into the WiFi PHY Hier block whose MAC out port is connected to that second "ack" port of the buffer block. The first message is passed through automatically without waiting for an "ack". Here's a image of the flowgraph: https://imgur.com/a/m5w9SHo The idea is that this would be a first step in a handshaking scheme where the tx path would initially send out a kind of rts, and then begin to buffer the message while waiting for an ack/cts from the rx, then it would send its data. The buffer seems to be building up in size as I'd expect, and the first message goes through, but I get no output from the WiFi Phy block, and so the buffer just continues to grow in size without sending out any more messages. Since my block passes the messages through unaltered, why wouldn't the PHY block handle the output of my block the same as if it weren't there? Thanks cameron
