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 > ************************************************* >
TELEMETRY_FLOW.pdf
Description: Adobe PDF document
