Please do not reply to digest messages. It makes it really hard to keep conversations straight.
On Tue, Apr 16, 2024 at 1:56 AM Jiya Johnson <jiyajohnson10@gmail.com> wrote:
Hi Marcus Müller,Please find the attached file for your reference, I think this will work.On Sat, Apr 13, 2024 at 9:32 PM <discuss-gnuradio-request@gnu.org> wrote:Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
discuss-gnuradio-request@gnu.org
You can reach the person managing the list at
discuss-gnuradio-owner@gnu.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Re: Determining number of dropped samples from USRP Sink in
TX chain (walter)
2. Modulation and demodulation issues (Jiya Johnson)
3. Re: Modulation and demodulation issues (Marcus Müller)
----------------------------------------------------------------------
Message: 1
Date: Fri, 12 Apr 2024 15:42:41 -0700
From: walter <walter@hacktuary.ai>
To: Adrian Winter <Adrian.Winter@sintef.no>
Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
Subject: Re: Determining number of dropped samples from USRP Sink in
TX chain
Message-ID: <7926F395-F024-44DE-A6C5-E48B1799841A@hacktuary.ai>
Content-Type: text/plain; charset="utf-8"
Hi Adrian -
You wrote:
> I'm wondering if there is any possibility to programmatically check how long an underrun event in a flowgraph that uses a USRP sink lasted.
I believe the usrp/uhd attempts to treat each underrun as a one-sample event, and report accordingly. There's a cogent definition in the Ettus Driver Manual, see the section header "Underrun notes":
https://files.ettus.com/manual/page_general.html#:~:text=has space again.-,Underrun notes,mean the host machine can't keep up with the requested rates.,-Threading Notes <https://files.ettus.com/manual/page_general.html#:~:text=has%20space%20again.-,Underrun%20notes,mean%20the%20host%20machine%20can't%20keep%20up%20with%20the%20requested%20rates.,-Threading%20Notes>
If we define dt = 1/samp_rate ... then (ignoring buffering and queueing), one underrun event means:
1. the usrp started waiting for a sample from your program at time t=t0, but
2. no sample was provided after dt seconds had elapsed, and
3. at time t=t0+dt the usrp issued a timestamped message (asynchronously) about the event. SO ...
> I do get messages from the sink when and that an underrun happened, but I can't see if that was for 1 ms or 20 seconds.
NOTE: the 'event' is a point-in-time, rather than an interval of time. It takes place at a time t0 + 1/samp_rate as described above, and - although it's printed in a format that looks weird in trace output - you have all the info you need:
> > message_debug :warning: Message: (uhd_async_msg (channel . 0) (time_spec 1333 . 0.277859) (event_code underflow))
> > Umessage_debug :warning: Message: (uhd_async_msg (channel . 0) (time_spec 1333 . 0.280334) (event_code underflow))
What you're seeing above are two underruns being reported about 2ms apart ...
- the U on the second line is stderr - you'll always see one U for each underrrun (or a summary, depending on config)
- the Message:... is because you're routing the message output of the USRP to a Message Debug block.
- the time_spec_t object tuple(int, double) contains whole seconds (1333) and fractional seconds (0.280334) since the USRP 'started'.
- Rule of thumb re t=0: a B200/B210 finishes initializing (messages like '[INFO] [B200] Actually got clock rate 16.777216 MHz') at around (time_spec 2 , 0.1000).
What to do??
The event 'duration' of each underrun is 1/samp_rate, and those stamps should be accurate - time deltas to be computed between two time_spec_t objects.
You probably care most about the average time between events.
Pro tip: a better way to monitor those messages is to send them to a ZMQ Message Sink block and process them in a separate flowgraph or python script that subscribes or pulls the messages. You can then consume them as numbers at your leisure. This adds minimal blocking / backpressure to your flowgraph.
> Is there any way to query the USRP for further information on the event?
Yes there is:
1. You're already getting the 'cue' of when to look by subscribing to the message source.
2. To dig into the details, have a look at the 'answer to my own question' posted under this subject earlier this week:
Re: How to get UHD 'rx_time' / 'rx_freq' after 'tune'? (Python)
The post includes (poorly edited) code examples, I'm happy to answer questions (or to be corrected by those more knowledgeable :-)
Cheers,
W .--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240412/0f1470a5/attachment.htm>
------------------------------
Message: 2
Date: Sat, 13 Apr 2024 14:23:50 +0530
From: Jiya Johnson <jiyajohnson10@gmail.com>
To: GNURadio Mailing List <discuss-gnuradio@gnu.org>
Subject: Modulation and demodulation issues
Message-ID:
<CANaw2Ut_zLA-siAErzb1xF78QTeoGRMeoSdXvaAdWwWo4H4gXQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Greetings everyone,
Done with BPSK,PM modulation with some doppler effects but not able to the
effective demodulation back with the gnuradio not able to trace back ASM
after decoding the data bits are completely different.
[image: image.png]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240413/855bb935/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 168035 bytes
Desc: not available
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240413/855bb935/attachment.png>
------------------------------
Message: 3
Date: Sat, 13 Apr 2024 16:29:32 +0200
From: Marcus Müller <mmueller@gnuradio.org>
To: discuss-gnuradio@gnu.org
Subject: Re: Modulation and demodulation issues
Message-ID: <a02a33e4-e5a8-412a-9be0-e620a14d855f@gnuradio.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Jiya,
that image is too small. I can't read anything. You could use the "Screen Capture" Feature
of GRC to export an arbitrary zoomable PDF document.
Best regards,
Marcus
On 13.04.24 10:53, Jiya Johnson wrote:
> Greetings everyone,
> Done with BPSK,PM modulation with some doppler effects but not able to the effective
> demodulation back with the gnuradio not able to trace back ASM after decoding the data
> bits are completely different.
> image.png
>
------------------------------
Subject: Digest Footer
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
End of Discuss-gnuradio Digest, Vol 258, Issue 10
*************************************************
No comments:
Post a Comment