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 <jiyajohnso...@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-requ...@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-requ...@gnu.org >> >> You can reach the person managing the list at >> discuss-gnuradio-ow...@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 <wal...@hacktuary.ai> >> To: Adrian Winter <adrian.win...@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-e48b17998...@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 <jiyajohnso...@gmail.com> >> To: GNURadio Mailing List <discuss-gnuradio@gnu.org> >> Subject: Modulation and demodulation issues >> Message-ID: >> < >> canaw2ut_zla-siaerzb1xf78qteogrmeosdxvaadwwwo4h4...@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 <mmuel...@gnuradio.org> >> To: discuss-gnuradio@gnu.org >> Subject: Re: Modulation and demodulation issues >> Message-ID: <a02a33e4-e5a8-412a-9be0-e620a14d8...@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 >> ************************************************* >> >
