Re: [Discuss-gnuradio] Packet decoder does not output the last packet
Dear Ms. Williams, I'm sorry you fell into that trap, but: Packet Encoder/Decoder is known to be buggy. That's why it's in the "deprecated" category. Simply don't use them. You'll find a better example in the GNU Radio examples that were shipped in /usr/share/gnuradio/examples/digital, specifically in /usr/share/gnuradio/examples/digital/packet/packet_loopback_hier.grc and the detailed packet_rx.grc and packet_tx.grc. Best regards, Marcus On Sun, 2018-11-11 at 17:44 +, Williams, Diane wrote: > In a very gnuradio simple simulation, flowgraph shown in attached image > simple_udp_simulation, all packets sent to the UDP source are received by the > UDP sink and sent out to a connected UDP socket server program. > > When adding the other processing blocks to the simulation, attached image > udp_packet_encoder_gmsk_simulation, the last packet is received by the UDP > source, but not by the UDP sink. That last packet never is output by the > packet decoder. If I send one extra packet through, a dummy packet of the > same length, then I get my last valid packet. I can do this and handle it in > post-processing, if needed, when later that dummy packet, flows through, but > I would appreciate knowing why the packet decoder hangs onto the last packet. > > I see the packet encoder/decoder deprecation warnings, but have not yet found > a working example for other means of encoding and decoding. > > I am using Ubuntu 18.04 gnuradio packages 3.7.11 > > Thank you. > > > > Diane Williams > Senior Professional Research Assistant, Electrical Engineering > University of Colorado Denver > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Packet decoder does not output the last packet
Dear Marcus, Thank you for your advice. A colleague and I tried working with those examples and found the receiver block only produced zeros in simulation. Google led us to this unanswered post: https://lists.gnu.org/archive/html/discuss-gnuradio/2017-03/msg00211.html We were faced with a demonstration deadline and resorted to the packet encoder. For me, this is a completely new and interesting area of study. I am grateful for the gnuradio community and will return to the examples you have suggested. Best regards, Diane Diane Williams Senior Professional Research Assistant, Electrical Engineering University of Colorado Denver From: Müller, Marcus (CEL) Sent: Monday, November 12, 2018 5:16:31 AM To: Williams, Diane; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Packet decoder does not output the last packet Dear Ms. Williams, I'm sorry you fell into that trap, but: Packet Encoder/Decoder is known to be buggy. That's why it's in the "deprecated" category. Simply don't use them. You'll find a better example in the GNU Radio examples that were shipped in /usr/share/gnuradio/examples/digital, specifically in /usr/share/gnuradio/examples/digital/packet/packet_loopback_hier.grc and the detailed packet_rx.grc and packet_tx.grc. Best regards, Marcus On Sun, 2018-11-11 at 17:44 +, Williams, Diane wrote: > In a very gnuradio simple simulation, flowgraph shown in attached image > simple_udp_simulation, all packets sent to the UDP source are received by the > UDP sink and sent out to a connected UDP socket server program. > > When adding the other processing blocks to the simulation, attached image > udp_packet_encoder_gmsk_simulation, the last packet is received by the UDP > source, but not by the UDP sink. That last packet never is output by the > packet decoder. If I send one extra packet through, a dummy packet of the > same length, then I get my last valid packet. I can do this and handle it in > post-processing, if needed, when later that dummy packet, flows through, but > I would appreciate knowing why the packet decoder hangs onto the last packet. > > I see the packet encoder/decoder deprecation warnings, but have not yet found > a working example for other means of encoding and decoding. > > I am using Ubuntu 18.04 gnuradio packages 3.7.11 > > Thank you. > > > > Diane Williams > Senior Professional Research Assistant, Electrical Engineering > University of Colorado Denver > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Spectrum sensing
Dear all I am working on B200 USRP for sensing the ISM band spectrum. My parameters is 2.4 G - 2.5G, FFT size 1024 (6.4MHz), sampling rate 40e6, taking 832 bins of 1024 from 96th bin to 928th bin, totally 19 subbands, each of 5.2 of 6.4 MHz, and frequency between two bin values is 6250Hz. When I run usrp_spectrum_sense.py code, with default values, I find that the code is running smoothly specifically, yellow LED is not blinking. But when I modify the code to run the parameters of my project, I find that with each change in centre frequency, the yellow LED is blinking. the skeleton of the code is as given below: top block self.freq_step=520 self.min_center_freq = self.min_freq +(520/2) nsteps = 19 self.max_center_freq = self.min_center_freq + ((nsteps-1) * self.freq_step)main program def bin_freq(i_bin, center_freq): freq = center_freq -(640/2)+ (tb.channel_bandwidth * i_bin) return freq ... bin_start= 96 bin_stop =928 ... for i_bin in range(bin_start, bin_stop): center_freq = m.center_freq freq = bin_freq(i_bin, center_freq) #calculate power level #print store etc I want to know the LED blinking - Does it in anyway affect the reading? the health of my USRPB200?Kindly help. thanking you RensiResearch ScholarAnna University,India ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
