Re: [Discuss-gnuradio] CC1101 GFSK packet decode with variable length
But this would only work well if there is enough gap time and/or preamble bits and/or fill bytes between the packets. Otherwise, you will consume and discard the beginning of the next packet. @(^.^)@ Ed Sent from my iPhone > On Dec 31, 2018, at 4:52 AM, Daniel Estévez wrote: > > Hi, > > Besides using the Header Payload Demuxer as Julian suggested, a simple > trick when the packet size is unknown but limited to a (not very large) > maximum size is to cut a PDU with the maximum packet size and then throw > away everything you don't need. > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question regarding convolutional decoder usage in FEC extended decoder API
Correction, I should have said entire 4 bit range instead of 128 bit range, but I hope you got the picture. Regards, Adrian On 12/31/18, Adrian Musceac wrote: > Hi, > > I'm sorry I didn't have much time to research the intricacies of the > convolutional decoder implementation, but I have a question coming > more from the user perspective regarding the optimal way of using the > API. > > In the default implementation of the extended decoder ( > https://github.com/gnuradio/gnuradio/blob/master/gr-fec/python/fec/extended_decoder.py > ) the canonical way seems to be to multiply the input (which is > assumed to be symbols scaled close to -1, 1 range) with 48, and then > to add 128 to bring into unsigned char 128 bit per symbol range. > This works fine, except it exhibits what seems like a very abrupt > cliff at about 3 db Eb/N0. > > I had the idea that comparatively large momentary noise amplitudes at > this treshhold might cause a char overflow, so I modified this a > little: instead of passing the unaltered symbol into the decoder, I > clipped it to (-1, 1) with a rail_ff block and multiplied with 128 in > an attempt to reserve the full 128 bit range of the decoder to the > most ambiguous symbols while avoiding the char overflow. This seems to > cause a more gentle degradation of the BER instead of the abrupt slope > from before and maybe a little improvement in BER (not verified, could > be bogus). > > I thought that either this is a good idea and might benefit more > people, or I'm ignoring some subtleties of the Viterbi algorithm and I > should be corrected because I'm doing something wrong. > > Thanks, > Adrian > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question regarding convolutional decoder usage in FEC extended decoder API
Hi, I'm sorry I didn't have much time to research the intricacies of the convolutional decoder implementation, but I have a question coming more from the user perspective regarding the optimal way of using the API. In the default implementation of the extended decoder ( https://github.com/gnuradio/gnuradio/blob/master/gr-fec/python/fec/extended_decoder.py ) the canonical way seems to be to multiply the input (which is assumed to be symbols scaled close to -1, 1 range) with 48, and then to add 128 to bring into unsigned char 128 bit per symbol range. This works fine, except it exhibits what seems like a very abrupt cliff at about 3 db Eb/N0. I had the idea that comparatively large momentary noise amplitudes at this treshhold might cause a char overflow, so I modified this a little: instead of passing the unaltered symbol into the decoder, I clipped it to (-1, 1) with a rail_ff block and multiplied with 128 in an attempt to reserve the full 128 bit range of the decoder to the most ambiguous symbols while avoiding the char overflow. This seems to cause a more gentle degradation of the BER instead of the abrupt slope from before and maybe a little improvement in BER (not verified, could be bogus). I thought that either this is a good idea and might benefit more people, or I'm ignoring some subtleties of the Viterbi algorithm and I should be corrected because I'm doing something wrong. Thanks, Adrian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to set signal bandwidth to 5KHz
Dear Suresh, we're the GNU Radio mailing list, and there's truly not only Sirs on here, but also Ladies; I've pointed this out before to you. So, this flow graph is essentially impossible to save: you rely on blks2_packet_decoder. It's broken, and hence for good in the "Deprecated" category. I've told you this before. You didn't react by changing anything. Twice. If you don't incorporate feedback, I don't think we can, or even should, invest time to help you. Good luck. I think you don't considering you wrote to quite a bunch of people, it's not quite clear who you wanted to address. It's usually desirable to not take multiple mailing list into your recipients list; especially, we'll have a hard time solving things for you if we feel like you're essentially slightly spamming people without even reading their replies. Respectfully, Marcus Müller On Mon, 2018-12-31 at 10:57 +, tadikondasuresh wrote: > Dear sir, > I am Suresh, I am working on BPSK Modulation in gnuradio by using > USRP N210 radio module > now I able to set signal bandwidth is 10KHz, 25KHz, 50KHz but I am > not able to set exact signal bandwidth to 5KHz > Please help me and please find out attached grc file > then I found one runtime error, pls solve it... > > sched: is requesting more input data > then we can provide. > ninput_items_required = 11760 > max_possible_items_available = 8191 > If this is a filter, consider reducing the number of taps. > > > Thanks & Regards, > Suresh T, > Navstar Integrated Systems Pvt ltd, > 9866212494 > ___ > 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] How to set signal bandwidth to 5KHz
Dear sir,I am Suresh, I am workingon BPSK Modulation in gnuradioby using USRP N210 radio modulenow I able to set signal bandwidthis 10KHz, 25KHz, 50KHz but I am not able to set exact signal bandwidth to 5KHzPlease help me and please find out attached grcfilethen I found one runtime error, pls solve it...sched: block pfb_clock_sync_ccf (8) is requesting more input data then we can provide. ninput_items_required = 11760 max_possible_items_available = 8191 If this is a filter, consider reducing the number of taps.Thanks Regards,Suresh T,Navstar Integrated Systems Pvt ltd,9866212494 VHF_BPSK_NORMAL_RX_pkt.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CC1101 GFSK packet decode with variable length
Hi, Besides using the Header Payload Demuxer as Julian suggested, a simple trick when the packet size is unknown but limited to a (not very large) maximum size is to cut a PDU with the maximum packet size and then throw away everything you don't need. I have a CC1101 decoder in gr-satellites that does variable length packets using this trick. See https://destevez.net/2018/12/decoding-reaktor-hello-world/ Best regards, Daniel. El 31/12/18 a las 01:28, Julian Arnold escribió: > Hey Bob, > > there is plenty of documentation on this topic you can check out under > [1,2]. > Especially, the Header Payload Demuxer (HPD) [3] should be worth a look > if you are dealing with packetized variable length data. > > Hope those pointer can get you started. If you have further questions > after going through those pages, let me know. > > Cheers, > Julian > > [1] https://www.gnuradio.org/doc/doxygen/page_packet_data.html > [2] https://www.gnuradio.org/doc/doxygen/page_packet_comms.html > [3] > https://www.gnuradio.org/doc/doxygen/classgr_1_1digital_1_1header__payload__demux.html > > > On 31.12.18 01:00, Alban Meffre wrote: >> Hi >> I would like to decode a simple GFSK packet >> >> here is the packet structure : >> preamble : AAh x 4 >> sync word : D391h >> length byte : 1 byte >> payload : 1 to 64 bytes >> CRC : 2 bytes >> >> TX : arduino + CC1101 module, 2GFSK, 100kbps, excursion 50kHz, carrier >> 433 MHz >> RX : RTLSDR >> >> until now i was able to demodulate the signal and add a "sync" tag >> using the correlate access code. >> >> my goal is to extract the payload and send it to a file or a socket. >> is there a simple way to do that without writing my own block ? >> >> i can't go further, because i do not manage to find the info i need >> i do not know where to start : stream, tagged stream, PDU, messages, >> etc.. >> i do not figure out how to use these tag for variable length. nothing >> clear in the doc >> >> i'd be glad if someone helps me >> best regards >> bob >> >> >> >> ___ >> 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
