Hi, I'd like to receive a BPSK signal (recovering the phase/freq and timing synchronism), not differential coded and in particular not shaped by a srrc filter (rect pulse). I guess that psk_demod.py supports only srrc shaped signal and that digital_mpsk_receiver_cc supports only differential coded signal. Any suggestions ? Thank you. -- View this message in context: http://gnuradio.4.n7.nabble.com/Receiving-BPSK-sig... Sent from the GnuRadio mailing list archive at Nabble.com.
on 2013-01-10 11:47
on 2013-01-10 16:39
Hi luca, check out the examples in gr-digital/examples/demod. You can set the filter taps as you wish, and do the same with the modulation used. MB On Thu, Jan 10, 2013 at 02:45:43AM -0800, luca wrote: > > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association
on 2013-01-11 16:42
Hi Martin, thank you.. but it seems to me that no example allows a not-Differential coding scheme and not-srcc filter (excess Bw is required). Maybe only the pam_sync.grc is the most suitable for my purpose... I find the synchronism recover by means of a FLL Band-Edge (frequency error), a Polyphase Clock Sync (for timing error) and a Costas (for phase and frequency remaining error)..and I can edit the filter taps. It sounds good.. but actually,.. I've got some doubts.. -) In the Polyphase Clock Sinc I expected to find the same taps used in the tx side (Polyphase Resampler). But other taps are used.. Why ? and according to which approach are they generated ? -) then..in case of rect pulse, the taps should be a ones vector.. do you agree ? -) in any case, the FLL requires the excess bandwidth, so it seems it doesn't support no-srrc modulation. Regards Luca -- View this message in context: http://gnuradio.4.n7.nabble.com/Receiving-BPSK-sig... Sent from the GnuRadio mailing list archive at Nabble.com.
on 2013-01-11 16:58
Using rect pulse shapes is generally not a good idea. Why do you want that? ...but let's assume you have a good reason: On Fri, Jan 11, 2013 at 07:41:29AM -0800, luca wrote: > -) In the Polyphase Clock Sinc I expected to find the same taps used in the > tx side (Polyphase Resampler). But other taps are used.. Why ? and > according to which approach are they generated ? They are the same (RRC filter on both Tx an Rx). > -) then..in case of rect pulse, the taps should be a ones vector.. do you > agree ? Yes. > -) in any case, the FLL requires the excess bandwidth, so it seems it > doesn't support no-srrc modulation. That's how the FLL works. In theory, you need a different freq sync for rectangular pulse shape. The way it's implemented, it might even work, though, if you leave the rolloff at .35. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association
on 2013-01-11 17:19
>Using rect pulse shapes is generally not a good idea. Why do you want >that? >...but let's assume you have a good reason: yes ...in my case.. low data rate telemetry-data from satellite are transmitted without filtering. >They are the same (RRC filter on both Tx an Rx). Are you sure ? I find out the following taps [firdes.root_raised_cosine(32, 32, 1.0, 0.35, 44*32)] in the Polyphase Resampler while [firdes.root_raised_cosine(nfilts,1.0,1.0/(spb*nfilts), rolloff, int(11*spb*nfilts))] are used in Polyphase Clock Sync. >The way it's implemented, it might even work, though, if you leave the >rolloff at .35. ok. -- View this message in context: http://gnuradio.4.n7.nabble.com/Receiving-BPSK-sig... Sent from the GnuRadio mailing list archive at Nabble.com.
on 2013-01-13 16:59
On Fri, Jan 11, 2013 at 11:17 AM, luca <luca.cucchi@gmail.com> wrote: > >They are the same (RRC filter on both Tx an Rx). > > Are you sure ? > I find out the following taps [firdes.root_raised_cosine(32, 32, 1.0, 0.35, > 44*32)] in the Polyphase Resampler while > [firdes.root_raised_cosine(nfilts,1.0,1.0/(spb*nfilts), rolloff, > int(11*spb*nfilts))] are used in Polyphase Clock Sync. Yes, they are the same. The second implementation is better, though, since it uses the proper variables to set things up. But in the end, if nfilts=32, rolloff=0.35, and spb=4, they are the same filters. Tom
on 2013-01-14 09:28
Hi Tom, thank you ..but I'm sorry ..I'm not convinced... ;) I try to replace the two terms by usign just one of them.. well if I use rrctaps for both, the signal is not tracked, while if I use the firdes.root_raised_cosine(32, 32, 1.0, 0.35, 44*32), it works but it is noisier. Luca -- View this message in context: http://gnuradio.4.n7.nabble.com/Receiving-BPSK-sig... Sent from the GnuRadio mailing list archive at Nabble.com.
on 2013-01-14 10:05
On Mon, Jan 14, 2013 at 12:27:25AM -0800, luca wrote: > Hi Tom, > thank you ..but I'm sorry ..I'm not convinced... ;) > I try to replace the two terms by usign just one of them.. > well if I use rrctaps for both, the signal is not tracked, while if I use > the firdes.root_raised_cosine(32, 32, 1.0, 0.35, 44*32), it works but it is > noisier. Luca, both blocks have different sampling rates at the input. This is reflected in the taps calculation. Otherwise, they're identical. Creating taps for PFB blocks is not exactly the same as doing so for their non-PFB counterparts. You should definitely read this: http://gnuradio.org/doc/doxygen/page_pfb.html http://gnuradio.org/doc/doxygen/classgr__pfb__arb_... These might also help: http://gnuradio.org/doc/doxygen/classgr__firdes.html http://gnuradio.org/doc/doxygen/classgr__pfb__cloc... MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association
Enable email notification
Enable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.