Re: [Discuss-gnuradio] dive into gnu-radio

[Timothée COCAULT]

Hi,

2016-03-16 20:36 GMT+01:00 Desmond Crozby :

> What I need is:
> 1) understand the blocks, their purpose and what they do
> 2) learn how to create a minimal scenario using grc
> 3) learn how to create blocks of my own
> 4) create more complicated scenario.
>
> I think there is cruel lack of explanation (not documentation) for the GNU
Radio blocks.
The example that struck me is the M clock recovery block.
The resources available are the code, the documentation, and the paper
cited in the documentation (not available for free though).
However, the best resource I found was a blog post [1] giving some notes,
facts and illustration on how this block works.
It's not an in-depth view of the algorithm used, but gives some hints on
how to use the block in practice.

This is really the kind of things I would love to see (and contribute !)
for each block, but AFAIK, there is no place in the gnuradio ecosystem for
such documentation.

[1]
https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/



2016-03-16 22:10 GMT+01:00 Martin Braun :

> Now, there's lots of very good books out there that go into DSP and
> wireless communication. They're usually written to address
> university-level students. But how do we condense them into nice and
> easy tutorials? It's hard.
>

Now concerning learning DSP theory, I feel that "book knowledge" or
tutorials isn't enough for using GNU Radio.
For example, sometimes I can't stay if my signal looks good or if it's just
noise. If my demodulation flowgraph doesn't work, I don't know which step
messed up, how to check if my data makes sense, which parameter I should
change.

This is the kind of things you get by seeing experimented people tackle
real life problems.
I watched a workshop of Balint Seeber (at DEF CON) and learned some great
things on DSP, analysis, and GNU Radio.
These kind of resources are really great, and I'd love to see more of them.

Cheers,

Timothée.

2016-03-16 22:53 GMT+01:00 Tom Coleman :

>
> On Mar 16, 2016, at 3:36 PM, Desmond Crozby  wrote:
>
> …
>
>
> I saw this reading suggestion:
> https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading ,
> but the list is extensive and grouped by topic, basically I don't know
> where to start from.
>
>
> Software Radio in General
> Has anyone bothered to check these links lately?
>
>
>
> ___
> 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] Change frequency in USRP source automatically

[Timothée COCAULT]

I know I had some problems with older versions of GNU Radio with Python
block and message ports breaking my flowgraph. I don't know for sure if
it's the same problem though.
Try to install the latest GNU Radio in a new prefix, or you could re-code
this blocks in C++ in an OOT module.

Cheers,
Timothée.

2016-03-15 18:58 GMT+01:00 Yan Huang <eexy...@nottingham.ac.uk>:

> Hi Timothée,
>
>
>
> Thank you very much, I have built a python block as you suggested and then
> put it between the strobe and the USRP source, but it come up error like:
>
>
>
>  File "/home/mint/Documents/test_sensor/scan/scan.py", line 154, in
> tb = scan()
>
>  File "/home/mint/Documents/test_sensor/scan/scan.py", line 123, in
> __init__
>
> self.msg_connect((self.blocks_message_strobe_0, 'strobe'),
> (self.freq_sweeper_frequency_sweeper_0, 'in'))
>
>  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
> line 60, in wrapped
>
> func(self, src.to_basic_block(), srcport, dst.to_basic_block(),
> dstport)
>
>  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
> line 132, in msg_connect
>
> self.primitive_msg_connect(*args)
>
>  File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line
> 4472, in primitive_msg_connect
>
> return _runtime_swig.top_block_sptr_primitive_msg_connect(self, *args)
>
> RuntimeError: invalid msg port in connect() or disconnect()
>
>
>
>  File "   The GNU Radio version is GNU Radio Companion
> v3.7.6.1-65-g500517ac, do you know where is the problem?
>
>
>
>  Many thanks,
>
> Yan
>
>
>
> *From:* Timothée COCAULT [mailto:timothee.coca...@gmail.com]
> *Sent:* 15 March 2016 16:24
>
> *To:* Yan Huang
> *Cc:* Martin Braun; discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Change frequency in USRP source
> automatically
>
>
>
> The easiest way would be to create a simple Python block between the
> strobe and the USRP source :
>
>
>
> ###
>
>
>
> class frequency_sweeper(gr.sync_block):
>
> def __init__(self, initial_freq=2.37e9, step=2e6):  # only default
> arguments here
>
> gr.sync_block.__init__(
>
> self,
>
> name='Frequency sweeper',
>
> in_sig=[],
>
> out_sig=[]
>
> )
>
> self.message_port_register_in(pmt.intern('clock'))
>
> self.set_msg_handler(pmt.intern('clock'), self.handler)
>
> self.message_port_register_out(pmt.intern('sync'))
>
> self.freq = initial_freq
>
> self.step = step
>
>
>
> def handler(self, pdu):
>
> self.message_port_pub(pmt.intern('sync'),
> pmt.cons(pmt.intern("freq"), pmt.to_pmt(self.freq)))
>
>     self.freq += self.step
>
>
>
> ###
>
>
>
> Cheers,
>
> Timothée.
>
>
>
> 2016-03-15 16:52 GMT+01:00 Yan Huang <eexy...@nottingham.ac.uk>:
>
> Hi Timothée,
>
>
>
> Thank you for your advice. But if I want to change the center frequency
> from 2.37GHz-2.43GHz with each time stepping 2MHz, how can I realize it by”
> Message Strobe”?
>
>
>
> Many thanks,
>
> Yan
>
>
>
> *From:* Timothée COCAULT [mailto:timothee.coca...@gmail.com]
> *Sent:* 15 March 2016 15:44
> *To:* Yan Huang
> *Cc:* Martin Braun; discuss-gnuradio@gnu.org
>
>
> *Subject:* Re: [Discuss-gnuradio] Change frequency in USRP source
> automatically
>
>
>
> Hi Yan,
>
>
>
> You should only pass only one value in the second member. Try :
>
>
>
> pmt.cons(pmt.intern("freq"), pmt.to_pmt(2.4e9))
>
>
>
>
>
> Cheers,
>
> Timothée.
>
>
>
>
>
> 2016-03-15 12:14 GMT+01:00 Yan Huang <eexy...@nottingham.ac.uk>:
>
> Hi Martin,
>
> Thank you, it works well. But I want to change the frequency
> automatically, so I change the frequency to array like:
>
>
> pmt.cons(pmt.string_to_symbol("freq"),pmt.to_pmt(numpy.array([2.4e9,2.45e9],dtype=numpy.float32)))
>
> and I also import numpy in GNU Radio, but it comes up with error :
>
> thread[thread-per-block[10]: ]:
> pmt_to_double: wrong_type : #[2.4e+09 2.4487e+09]
>
> Thanks,
>
> Yan
>
>
> -Original Message-
> From: discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org [mailto:
> discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] On Behalf Of
> Martin Braun
> Sent: 15 March 2016 00:43
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Change frequency in USRP source
>

Re: [Discuss-gnuradio] Change frequency in USRP source automatically

[Timothée COCAULT]

The easiest way would be to create a simple Python block between the strobe
and the USRP source :

###

class frequency_sweeper(gr.sync_block):
def __init__(self, initial_freq=2.37e9, step=2e6):  # only default
arguments here
gr.sync_block.__init__(
self,
name='Frequency sweeper',
in_sig=[],
out_sig=[]
)
self.message_port_register_in(pmt.intern('clock'))
self.set_msg_handler(pmt.intern('clock'), self.handler)
self.message_port_register_out(pmt.intern('sync'))
self.freq = initial_freq
self.step = step

def handler(self, pdu):
self.message_port_pub(pmt.intern('sync'),
pmt.cons(pmt.intern("freq"), pmt.to_pmt(self.freq)))
self.freq += self.step

###

Cheers,
Timothée.

2016-03-15 16:52 GMT+01:00 Yan Huang <eexy...@nottingham.ac.uk>:

> Hi Timothée,
>
>
>
> Thank you for your advice. But if I want to change the center frequency
> from 2.37GHz-2.43GHz with each time stepping 2MHz, how can I realize it by”
> Message Strobe”?
>
>
>
> Many thanks,
>
> Yan
>
>
>
> *From:* Timothée COCAULT [mailto:timothee.coca...@gmail.com]
> *Sent:* 15 March 2016 15:44
> *To:* Yan Huang
> *Cc:* Martin Braun; discuss-gnuradio@gnu.org
>
> *Subject:* Re: [Discuss-gnuradio] Change frequency in USRP source
> automatically
>
>
>
> Hi Yan,
>
>
>
> You should only pass only one value in the second member. Try :
>
>
>
> pmt.cons(pmt.intern("freq"), pmt.to_pmt(2.4e9))
>
>
>
>
>
> Cheers,
>
> Timothée.
>
>
>
>
>
> 2016-03-15 12:14 GMT+01:00 Yan Huang <eexy...@nottingham.ac.uk>:
>
> Hi Martin,
>
> Thank you, it works well. But I want to change the frequency
> automatically, so I change the frequency to array like:
>
>
> pmt.cons(pmt.string_to_symbol("freq"),pmt.to_pmt(numpy.array([2.4e9,2.45e9],dtype=numpy.float32)))
>
> and I also import numpy in GNU Radio, but it comes up with error :
>
> thread[thread-per-block[10]: ]:
> pmt_to_double: wrong_type : #[2.4e+09 2.4487e+09]
>
> Thanks,
>
> Yan
>
>
> -Original Message-
> From: discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org [mailto:
> discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] On Behalf Of
> Martin Braun
> Sent: 15 March 2016 00:43
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Change frequency in USRP source
> automatically
>
> Yan,
>
> simply convert "freq" and your frequency to a PMT before passing into
> cons().
>
> Cheers,
> Martin
>
> On 03/14/2016 03:44 PM, Yan Huang wrote:
> > Hi Martin,
> >
> > Thank you for your kind reply. But I'm still comfused that I already
> have to input in pmt::cons("freq",2.4e9), cause in the manual it said:
> >
> > pmt::cons(KEY, VALUE): This format is useful for commands that take a
> single value. Think of KEY and VALUE as the argument name and value,
> respectively. For the case of the QT GUI Frequency Sink, KEY would be
> "freq" and VALUE would be the new center frequency in Hz.
> >
> > Could you please give me an exmaple about it?
> >
> > Thank you a lot,
> >
> > Yan
> > 
> > From: discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org
> > [discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] on behalf
> > of Martin Braun [martin.br...@ettus.com]
> > Sent: 14 March 2016 17:18
> > To: discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Change frequency in USRP source
> > automatically
> >
> > Yan,
> >
> > check the PMT manuals. cons() takes 2 PMTs as input.
> >
> >
> > Cheers,
> > Martin
> >
> > On 03/14/2016 09:09 AM, Yan Huang wrote:
> >> Hi all,
> >>
> >>
> >>
> >> I want to change the frequency in "USRP source" automatically, for
> >> example 2.37GHz-2.43GHz with each time stepping 2MHz.
> >>
> >>
> >>
> >> 1. As you know, the USRP source has an input message port, so I want
> >> to connect it to a "Message strobe" to control the frequency change.
> >> But  after I see [1][2], I write PMT type commands  in "Message PMT"
> >> in "Message Strobe" as:
> >>
> >> pmt::cons("freq",2.4e9)
> >>
> >> it comes up error "invalid syntax(,line 1)", so I don't know
> >> how to further stepping the frequency.
> >>
> >> 2. If I use the "Message Strobe" to define fre

Re: [Discuss-gnuradio] Change frequency in USRP source automatically

[Timothée COCAULT]

Hi Yan,

You should only pass only one value in the second member. Try :

pmt.cons(pmt.intern("freq"), pmt.to_pmt(2.4e9))


Cheers,
Timothée.


2016-03-15 12:14 GMT+01:00 Yan Huang :

> Hi Martin,
>
> Thank you, it works well. But I want to change the frequency
> automatically, so I change the frequency to array like:
>
>
> pmt.cons(pmt.string_to_symbol("freq"),pmt.to_pmt(numpy.array([2.4e9,2.45e9],dtype=numpy.float32)))
>
> and I also import numpy in GNU Radio, but it comes up with error :
>
> thread[thread-per-block[10]: ]:
> pmt_to_double: wrong_type : #[2.4e+09 2.4487e+09]
>
> Thanks,
>
> Yan
>
> -Original Message-
> From: discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org [mailto:
> discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] On Behalf Of
> Martin Braun
> Sent: 15 March 2016 00:43
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Change frequency in USRP source
> automatically
>
> Yan,
>
> simply convert "freq" and your frequency to a PMT before passing into
> cons().
>
> Cheers,
> Martin
>
> On 03/14/2016 03:44 PM, Yan Huang wrote:
> > Hi Martin,
> >
> > Thank you for your kind reply. But I'm still comfused that I already
> have to input in pmt::cons("freq",2.4e9), cause in the manual it said:
> >
> > pmt::cons(KEY, VALUE): This format is useful for commands that take a
> single value. Think of KEY and VALUE as the argument name and value,
> respectively. For the case of the QT GUI Frequency Sink, KEY would be
> "freq" and VALUE would be the new center frequency in Hz.
> >
> > Could you please give me an exmaple about it?
> >
> > Thank you a lot,
> >
> > Yan
> > 
> > From: discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org
> > [discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] on behalf
> > of Martin Braun [martin.br...@ettus.com]
> > Sent: 14 March 2016 17:18
> > To: discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Change frequency in USRP source
> > automatically
> >
> > Yan,
> >
> > check the PMT manuals. cons() takes 2 PMTs as input.
> >
> >
> > Cheers,
> > Martin
> >
> > On 03/14/2016 09:09 AM, Yan Huang wrote:
> >> Hi all,
> >>
> >>
> >>
> >> I want to change the frequency in "USRP source" automatically, for
> >> example 2.37GHz-2.43GHz with each time stepping 2MHz.
> >>
> >>
> >>
> >> 1. As you know, the USRP source has an input message port, so I want
> >> to connect it to a "Message strobe" to control the frequency change.
> >> But  after I see [1][2], I write PMT type commands  in "Message PMT"
> >> in "Message Strobe" as:
> >>
> >> pmt::cons("freq",2.4e9)
> >>
> >> it comes up error "invalid syntax(,line 1)", so I don't know
> >> how to further stepping the frequency.
> >>
> >> 2. If I use the "Message Strobe" to define frequency, what can I put
> >> in the "frequency" in "USRP source" block? Put it as 0?
> >>
> >>
> >>
> >> [1] https://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
> >>
> >> [2]
> >> https://gnuradio.org/doc/doxygen/page_msg_passing.html#msg_passing_co
> >> mmands
> >>
> >>
> >>
> >> Many thanks ,
> >>
> >>
> >>
> >> Yan
> >>
> >>
> >>
> >>
> >>
> >> This message and any attachment are intended solely for the addressee
> >> and may contain confidential information. If you have received this
> >> message in error, please send it back to me, and immediately delete it.
> >>
> >> Please do not use, copy or disclose the information contained in this
> >> message or in any attachment.  Any views or opinions expressed by the
> >> author of this email do not necessarily reflect the views of the
> >> University of Nottingham.
> >>
> >> This message has been checked for viruses but the contents of an
> >> attachment may still contain software viruses which could damage your
> >> computer system, you are advised to perform your own checks. Email
> >> communications with the University of Nottingham may be monitored as
> >> permitted by UK legislation.
> >>
> >>
> >>
> >> ___
> >> 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
> >
> >
> >
> >
> > This message and any attachment are intended solely for the addressee
> > and may contain confidential information. If you have received this
> > message in error, please send it back to me, and immediately delete it.
> >
> > Please do not use, copy or disclose the information contained in this
> > message or in any attachment.  Any views or opinions expressed by the
> > author of this email do not necessarily reflect the views of the
> > University of Nottingham.
> >
> > This message has been checked for viruses but the contents of an
> > attachment may still contain software viruses 

Re: [Discuss-gnuradio] Moving Average Block

[Timothée COCAULT]

Whoops, just noticed I didn't reply to all when I answered so my message
and Pedro's response were not forwarded to the mailing list :

Le jeu. 7 janv. 2016 à 20:28, Pedro Gabriel Adami <
pedrogabriel.ad...@gmail.com> a écrit :

Dear, Timothée,

Thank you so much. I am doing some tests and I've realized that the results
are a little strange. That is why I asked.

Let me ask you one more thing: Do you know some block that is capable to
retain N samples, so I can use them and after that, it retains the next N
samples? Like a variable where I can "save" the information for a short
period of time, but my Gnuradio does not have a "variable sink".

Thanks in advance.
Em 07/01/2016 17:18, "Timothée COCAULT" <timothee.coca...@gmail.com>
escreveu:

> Hi Pedro,
>
> When you're not sure, the best solution is often to look at the code.
> If you look at the work function in
> gr-blocks/lib/moving_average_XX_impl.cc.t, you see that the block first
> sums the history (of length 100 in your case).
> For each additional input items, it adds the new item and subtracts the
> n-100 item, and outputs the current sum.
>
> So it will first calculate 1+...+100, then 2+...+101 and so on.
>
> Regards,
> Timothée.
>

>


I don't understand exactly your question but you can use a stream to vector
to group your items in packets of size N, and plug it into a probe signal
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] TETRA demodulator advices

[Timothée COCAULT]

Le lun. 7 déc. 2015 à 8:06, Sylvain Munaut <246...@gmail.com> a 
écrit :

Hi,


 I've looked into that but I'm afraid some blocks won't play well 
with the
 constellation class (for example, they expect a constellation to 
have

 2**(bits) points, but PI/4 DQPSK uses 2 bits and has 8 points).
 I think I will stay with the flowgraph approach for now.


I've worked with pi/4 xQPSK signals a bit when doing tetra and gmr
stuff and the approach I took is just to undo the pi/4 rotation using
a complex rotator.

Then it looks like normal QPSK and can be processed as such.


Cheers,

   Sylvain


Hi Sylvain,

I followed your suggestion and modified the PSK (De)Mod blocks, and the 
generic_(de)mod classes to add an optionnal rotation parameter, and a 
Rotator block if needed, and it works great !

It also seems to be more tolerant to noisy channels.

GNU radio maintainers : should I create a pull request to add the 
rotation parameter ? It would allow to have only one block for PI/4 
QPSK (or PI/2 BPSK) demodulation.


Best,

Timothée.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] TETRA demodulator advices

[Timothée COCAULT]

Hi Tom.

First, thank you for your answer.


Le mar. 1 déc. 2015 à 16:33, Tom Rondeau  a écrit :


This is a very open-ended question. It'd take a lot of work for 
someone to go through your receiver and make any suggestions. Your 
best bet is to ask very pointed questions about a behavior or block.


I know that it's a lot of work, I just wanted to know if, at a first 
glance, something looked out of place.
I'm sometimes lost in GNU radio when I have to choose a block among 
several that seem to do the same thing.





Bonus questions :

* using the FLL band edge after the low-pass seems odd because, even 
if it can recover frequency offset, some of the bandwidth will be 
lost.
Should I use the error ouput of the FLL to change the freq used by 
the Freq XLating FIR FIlter ? If yes, is there an example of this 
somewhere ?



That's more like it! This is a question we can actually answer.

Yes, you have the issue that you described. You could think to make a 
block that could pass a message the frequency translating filter that 
would adjust its center frequency, but you won't be able to do that 
very quickly. It would be a slow, very coarse frequency correction.


Instead, I would try to figure out the expected maximum frequency 
offset and make the LPF of the frequency translating filter block 
large enough to accommodate that. This LPF is a channel filter meant 
to reduce noise power from adjacent channels, so there is always a 
tradeoff between that and being able to lock on to your signal. The 
clock sync block performs the actual matched filtering, though, so 
you're not using this LPF to just isolate the signal exactly.


The main purpose of the FLL is to compensate the thermal offset of a 
crappy RTL-SDR device so it doesn't need to be really fast.
I'll try to increase the cutoff frequency first, and see how it reacts 
with the adjacent channels.




* at first I wanted to use the Constellation receiver, but from what 
I understand the constellations in gnuradio work by first 
discretizing the signal, then doing the diff.
This does not work with PI/4 DQPSK because you need to first diff 
the complex samples, then discretize.
Is there any way I could cheat to create a PI/4 DQPSK constellation 
in gnuradio ?


I could see overloading the constellation object to have a child 
class with memory to handle this case.




I've looked into that but I'm afraid some blocks won't play well with 
the constellation class (for example, they expect a constellation to 
have 2**(bits) points, but PI/4 DQPSK uses 2 bits and has 8 points).

I think I will stay with the flowgraph approach for now.

Best,
Timothée.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNUradio DQPSK bit error rate

[Timothée COCAULT]

Le dim. 6 déc. 2015 à 12:50, Marcus Müller 
 a écrit :

Hi Timothée, hi Haaris,

is it OK if I paste the answer to the question on StackOverflow?
http://stackoverflow.com/questions/34096116/gnu-radio-dqpsk-bit-error-rate

Best regards,
Marcus


Hi Marcus,

Yes, of course. You should perhaps add a link to the mailing list 
archive since it's a good resource for people interested in GNU Radio.


Best,
Timothée.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNUradio DQPSK bit error rate

[Timothée COCAULT]

Le sam. 5 déc. 2015 à 20:42, Haaris  a écrit :

Hello
Almost a month ago i started working on a digital communications 
project

which involves GNUradio.
And I am severely struggling to get past some errors or mismatches I 
am

encountering in GNUradio.
I am desperately in need of some expert help.
I made a DQPSK modulator and demodulator using GRC. ( screenshots
provided )
Gave a vector source with bits 0,1,0,1 and repeat on, on the input of
psk modulator.
I also used an error rate block to calculate bit error rate.
Now almost everything that is appearing on the scopes is completely
wrong.

The bit error rate is 0.5, provided that i have added no noise.(which 
is

max considering that we will recover 50 percent bits correctly just by
chance).
The scope at the psk modulator output shows four constellation points
even though i am transmitting only one symbol i.e (0,1).

What am i doing wrong?
Can someone please be kind enough to go through the screenshots and 
tell

me the mistake(s).
Any help will be greatly appreciated.
Thanks in advance.


Hi Haaris,

The documentation of the PSK Mod says : "The input is a byte stream 
(unsigned char), treated as a series of packed symbols. Symbols are 
grouped from MSB to LSB."
You should add an "Unpacked to Packed block" with 2 bits per chunk and 
MSB endianness before.
Likewise, you should add a "Pack K bits" block with K=2 after the PSK 
Demod.


Also, your assumption that you should have one point in the 
constellation sink is wrong.
You're using DQPSK so the (0, 1) symbol will add 90 degrees to the 
phase, and you will cycle through the 4 points of your constellation.


And last, keep in mind that each block has a delay, and you can't 
compare the input and output bits directly.
Try to use a "Scope plot" with 2 inputs, and add a delay block before 
the input bits to synchronise the two.



Timothée.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] transmit file with qpsk on e310

[Timothée COCAULT]

I think you should use differential encoding with DPSK Mod/DPSK Demod 
block because the receiver doesn't know the phase used.


Also, if you want to test the reliability of your flowgraph, you can 
replace your USRP source and sink with a Channel Model and play with 
the frequency, noise, etc...



Timothée.


Le dim. 29 nov. 2015 à 5:53, Ekko <chai18740449...@gmail.com> a écrit 
:

hi
follow your suggestion ,i use the "PSK mod" and "PSK demod",just like


is it clear，if not i will upload my grc file


​now,i set the vector source ,vector="0,1,2,3,4,5,6,7,8,9"

and i transmit it,receive it into a file

i found that in my file,it is not the sequence in vector source
0123456789,just the part of this sequence.i think that some number 
was lose.(is it right?)


i want to know how to Reduced this lost of number,for example some 
block need to be added.

the "psk demod"  got the freq and phase correction itself.

and waht is the delimited messages.

thank you

--Ekko

2015-11-29 1:26 GMT+08:00 Timothée COCAULT 
<timothee.coca...@gmail.com>:

Hi,

First you should have a look at the PSK demodulation tutorial : 
http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_PSK_Demodulation 
.
It uses a Polyphase Clock Sync between the receiver and the 
constellation decoder.


Alternatively, you can use the Constellation Receiver which is a 
Constellation Decoder with freq and phase correction.


But if you want a more simple solution, the DPSK Mod/DPSK Demod 
blocks seems like the best solution.



When your receiver works, you can have a look at the Packet 
Operators to send delimited messages.



Good luck.


Le sam. 28 nov. 2015 à 9:55, Ekko <chai18740449...@gmail.com> a 
écrit :

hello all
i want to transmit a file with the way of  QPSK
this is my send grc

file sourcerepack bits-chunks to symbol-multile 
const--uhd_ink


this is my receive grc


uhd_source-constellation decoder-repack bits-file sink


next is the "qt gui constellation sink" of the oupotput of
chunks to symbol in the send


next is the output of UHD_source in recieve "qt frequence sink""qt 
gui constellation sink"




in this picture ,i think the recieve got the signal,but i do not 
know the constellation mean,


next is the set of my uhd_source and uhd_sink

source



sink

​
​my problem is that my recieve file is completely different with 
the source file


i use simulation way (no uhd),the recieve is same as source,

so i think there is some block needed between the constellation 
coder and uhd_source,for example the sync block


hope someone knows how to solve this sync problem or how to 
transmit a file with QPSK on e310 with the  antenna


thank you
---Ekko​


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] transmit file with qpsk on e310

[Timothée COCAULT]

Hi,

First you should have a look at the PSK demodulation tutorial : 
http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_PSK_Demodulation 
.
It uses a Polyphase Clock Sync between the receiver and the 
constellation decoder.


Alternatively, you can use the Constellation Receiver which is a 
Constellation Decoder with freq and phase correction.


But if you want a more simple solution, the DPSK Mod/DPSK Demod blocks 
seems like the best solution.



When your receiver works, you can have a look at the Packet Operators 
to send delimited messages.



Good luck.


Le sam. 28 nov. 2015 à 9:55, Ekko  a écrit 
:

hello all
i want to transmit a file with the way of  QPSK
this is my send grc

file sourcerepack bits-chunks to symbol-multile 
const--uhd_ink


this is my receive grc


uhd_source-constellation decoder-repack bits-file sink


next is the "qt gui constellation sink" of the oupotput of
chunks to symbol in the send


next is the output of UHD_source in recieve "qt frequence sink""qt 
gui constellation sink"




in this picture ,i think the recieve got the signal,but i do not know 
the constellation mean,


next is the set of my uhd_source and uhd_sink

source



sink

​
​my problem is that my recieve file is completely different with 
the source file


i use simulation way (no uhd),the recieve is same as source,

so i think there is some block needed between the constellation coder 
and uhd_source,for example the sync block


hope someone knows how to solve this sync problem or how to transmit 
a file with QPSK on e310 with the  antenna


thank you
---Ekko​
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] TETRA demodulator advices

[Timothée COCAULT]

Hi,

I am writing a TETRA demodulator with GNU Radio Companion without any 
OOT block.


My flowgraph works but as I don't have a signal processing background, 
I'm not really sure that my choice of the blocks and their parameters 
is the best for my purpose.


The TETRA modulation uses PI/4 DQPSK with a bitrate of 36 kHz (symbol 
rate of 18 kHz), and a RRC filter.


For now, my decoder consists of :

* Freq Xlating FIR Filter : to center and low-pass the signal, and 
lower the sample rate to have about 2 SPS.

* Fractional resampler : to have exactly 2 SPS
* Feed Forward AGC : to normalize the amplitude to 1
* FLL Band Edge : to fine-tune the frequency
* Polyphase Clock Sync : to sample the symbols at the right timing
* Differential Phasor : to get the difference between two symbols
* Constellation decoder : to discretize the symbols
* Unpack K bits : to convert the symbols to bits.

The flowgraph and screenshots can be found at 
https://github.com/Tim---/tetra-toolkit/tree/master/grc .


Do you have any advice on how to improve this flowchart ?


Bonus questions :

* using the FLL band edge after the low-pass seems odd because, even if 
it can recover frequency offset, some of the bandwidth will be lost.
Should I use the error ouput of the FLL to change the freq used by the 
Freq XLating FIR FIlter ? If yes, is there an example of this somewhere 
?


* at first I wanted to use the Constellation receiver, but from what I 
understand the constellations in gnuradio work by first discretizing 
the signal, then doing the diff.
This does not work with PI/4 DQPSK because you need to first diff the 
complex samples, then discretize.
Is there any way I could cheat to create a PI/4 DQPSK constellation in 
gnuradio ?



Thanks in advance,

Timothée.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio