Re: [Discuss-gnuradio] Demodulation of Intermittent QAM Signal

[Ernest Fardin]

Thanks Kyeong,

Looking into this in a bit more detail I found that the attack and decay
rate settings for the AGC2 block contained within the QAM Demod hier block
affect the ability of the demodulator to recover from a zero-signal
condition. Reducing the attack and decay rates from their default values of
of 6e-2 and 1e-3 to something like 1e-5 allows the demodulator to recover
reliably.

I'm not sure why such a big change is required. Maybe it is related to the
high PAR of a QAM signal, but then the block was designed for QAM in the
first place. Perhaps some changes have been made to the AGC2 block since
the QAM Demod block was originally implemented.

Ernest

On Thu, Oct 19, 2017 at 6:48 PM, E Fardin & P Le 
wrote:

>
>
>
>
> - Original Message -
> From:
> "Kyeong Su Shin" 
>
> To:
> "Ernest Fardin" 
> Cc:
> "GNURadio Discussion List" 
> Sent:
> Wed, 18 Oct 2017 15:11:50 -0700
> Subject:
> Re: [Discuss-gnuradio] Demodulation of Intermittent QAM Signal
>
>
> Hello Ernest Fardin:
>
> As you thought, synchronization loops in the PSK/QAM demod blocks may
> wander off if you input noise into those blocks.
>
> I asked a same question before, and the answer was not to feed in any data
> to the QAM demod block when you think the transmitter is not on. I did not
> try this, but  maybe power squelch block can do the trick.
>
> (Or, alternatively, maybe you can implement your own synchronization
> blocks and use a demod block that does not do synchronizations. I believe
> that you can use a constellation receiver block to do this.)
>
> Regards,
> Kyeong Su Shin
>
> On Tue, Oct 17, 2017 at 10:46 PM, Ernest Fardin  wrote:
>
>> Hi,
>>
>> I have a simple QAM16 loopback (Gray code, diff encoding, 4 sps) working
>> as follows:
>>
>> QAM Mod ---> Throttle ---> QAM Demod
>>
>> This works fine if I have a constant signal level from the Tx. However,
>> if I add a variable gain between the Tx and Rx and drop the Tx level to
>> zero, then restore the Tx signal after a short time, the demod no longer
>> works. I'm guessing a control loop inside the demod has wandered off during
>> the interval with no signal. Is there any way to re-initialise the demod
>> block to help it find its way again?
>>
>> The objective is to simulate a 'bursty' link where the Tx is not
>> permanently keyed.
>>
>> Thanks in advance!
>>
>> Ernest
>>
>> ___
>> 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] TunTap Interace for GNU Radio IEEE 802.11 a/g/p module

[Bastian Bloessl]

Hi,

On 10/19/2017 02:49 AM, Wen Cui wrote:

I followed the nic.sh file and your replies to others in the mail list. I 
really want to know whether it is only related to the TUN/TAP setup thing or it 
is related to the gnuradio code. I don’t know how to figure out the setup 
problem of the transceiver and where is the good place to ask this question. If 
you'd like to give me a hint, I will really appreciate about that.
  
PC1:

//wireless card in PC1
Tap0, IP: 192.168.123.1 MAC: 12:34:56:78:90:ab
wls5, IP: 192.168.123.20 MAC: a8:96:8a:f6:d5:2e

//USRP connected the PC1 through Ethernet cable
enp10s0, IP: 192.168.10.100 MAC: 40:6a:7f:bc:f2:2f
USRP, IP: 192.168.10.5 MAC: 00:80:2f:0a:cf:68

PC2:
//wireless card in PC2
wlp8s0, IP:192.168.123.50 MAC: 74:e7:0f:34:42:ba

I did the same config code as nic.sh does in PC1 but with changed IP and MAC 
address. I also set the arp and route things in PC2.

After I turn the tap0 up in PC1, I cannot PING PC1 anymore through PC2, and 
vice versa. The PC1 can hear the ICMP request from PC2, but cannot reply for 
that.


If both PCs can send a ping, but both don't trigger a reply, it might 
just be that ICMP requests are ignored.


This can be changed with:

echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_all

If that's not the problem, start Wireshark on both sender and receiver 
and monitor the TUN/TAP interface only to better understand what's 
really going on. Maybe a frame is sent, but not received by the SDR or 
something like that.


Best,
Bastian

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

Re: [Discuss-gnuradio] 802.15.4 Frame sync confusion

[Bastian Bloessl]

Hi,

On 10/19/2017 09:00 AM, Sumit Kumar wrote:
Yes but even to get the chip sequences, which are nothing but bits, the 
incoming complex samples have to be decoded i.e. OQPSK demodulation.


I saw MATLAB implementation by Rice University as well in the latest 
release of MATLAB 2017b (they have included a 802.15.4 toolbox)


All of them employ the same technique i.e. first do a OQPSK demodulation 
and then find preambles.


I was wondering why not do auto correlation or cross correlation of 
incoming complex samples as there is a repetition of samples in the 
beginning.


Currently, the receiver looks like this:

IQ -> FM demodulation -> clock recovery (extract chips) -> search for 
the chip sequence of the preamble.


It's only one simple way to do it. I'm sure you could get higher 
performance with more complicated algorithms that consider the signal at 
an earlier stage, i.e., you could work with the baseband signal or the 
signal after FM demodulation. However, both approaches would increase 
(at least) computational complexity. It's a trade-off.


Best,
Bastian





Sumit

On Wed, Oct 18, 2017 at 3:50 PM, Bastian Bloessl > wrote:


Hi,

On 10/18/2017 01:24 PM, sumit kumar wrote:

Hi,


If my understanding is correct, most of the 802.15.4 receiver
implementations perform frame synchronization i.e. find the
start of the frame using the preambles which are nothing but 8
zeros(each of which is further converted to 32 bit chip).

This is done after the OQPSK symbols (complex samples) are
already decoded to bits. Same does the gr-ieee 802.15.4


It's actually working with the chip sequences not the data bits.
When the receiver is not synchronized is searches for the chip
sequence that corresponds to the zero data bits, i.e., the preamble.
Once the sequence is found (when the chip sequence matches
reasonably well), it continues to decode chip sequences with the
known alignment (and looks for the SFD data bits).

That means the algorithm works already on a rather deep layer. I'm
sure it could be much improved. It is just a simple approach that
presents a tradeoff between performance and complexity (in terms of
CPU time and implementation complexity).

Best,


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

Re: [Discuss-gnuradio] XML parameter checking

[Marcus Müller]

Hi Mike,

what's in the  tag just needs to be a valid Python expression, 
afaik. So,


$psize % 8 == 0

would work (notice the double =; this is comparison, not assignment!).

For comparison, see the gr-audio/grc/analog_nbfm_rx.xml, for example.

Best regards,

Marcus


On 2017-10-19 04:02, Mike Rex wrote:
What would be the best way to make sure the user enters a parameter 
that is a multiple of 8 in the GRC XML file?  My first thought is this 
might do the trick, but seems there is no mod function for XML.  Any 
suggestions?


$psize % 8 = 0 or $psize mod 8 = 0

Thanks in advance,
Mike


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





smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] reg "A GNU Radio-based IEEE 802.15. 4 Testbed " GRC

[Rensi Mathew]

Hi all
I was trying to recreate the GNU radio Companion environment in the paper  "A 
GNU Radio-based IEEE 802.15. 4 Testbed ".I have TelosB nodes, but only one USRP 
B200 SDR.
While I am running the corresponding GRC, when I put a WX FFT sink block at the 
receiver, I am able to observe some signals in the receiver(sink) . But I am 
not able to track functioning of any other layer. The Wireshark block is also 
not functioning and my pcap file has nothing. Can anyone please help me to 
troubleshoot?
I also have a doubt regarding the Application layer: Socket PDU. Is there any 
other programming like html file I have to create to observe the functioning?
Hope someone can guide me.
Thanking youRensi Sam MathewResearch Scholar___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] reg "A GNU Radio-based IEEE 802.15. 4 Testbed " GRC

[Marcus Müller]

Hi Rensi,

Well, if the wireshark connector doesn't show any packets, then the PHY 
layer very likely simply doesn't see any packets. That can have a whole 
lot of reasons – you're already doing well, starting to debug by looking 
at the spectrum of the received signal. So, does the spectrum look like 
you'd expect it from your signal? If it does, does the time domain also 
look like expected? Are the amplitudes in a reasonable range, ie. 
solidly below 1.0, but also significantly above 0.05?


Best regards,

Marcus


On 2017-10-19 11:58, Rensi Mathew wrote:

Hi all

I was trying to recreate the GNU radio Companion environment in the 
paper "A GNU Radio-based IEEE 802.15. 4 Testbed ".

I have TelosB nodes, but only one USRP B200 SDR.

While I am running the corresponding GRC, when I put a WX FFT sink 
block at the receiver, I am able to observe some signals in the 
receiver(sink) . But I am not able to track functioning of any other 
layer. The Wireshark block is also not functioning and my pcap file 
has nothing. Can anyone please help me to troubleshoot?


I also have a doubt regarding the Application layer: Socket PDU. Is 
there any other programming like html file I have to create to observe 
the functioning?


Hope someone can guide me.

Thanking you
Rensi Sam Mathew
Research Scholar


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




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Python Block module file location

[Sebastian Koslowski]

The source code of these Python blocks is saved inside a GRC file. The file
in tmp is only for editing, changes are pulled back into GRC on write. Once
you close your editor the file should be considered invalid.

Sebastian

On Wed, Oct 18, 2017, 17:15 Jason Matusiak 
wrote:

> I have been experimenting with the Python Block (in core>misc) for
> something I was trying to gen up quickly.  I have it working, but it seems
> to like creating random file names for the "block" and storing them in /tmp.
>
> Is there anyway to point to a different file in a different location and
> have the block open *that* in its editor?
> ___
> 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] Python Block module file location

[Marcus Müller]

Maybe we have to ask the other way around:

What is it that you want to implement?

Best regards,

Marcus


On 2017-10-19 12:34, Sebastian Koslowski wrote:


The source code of these Python blocks is saved inside a GRC file. The 
file in tmp is only for editing, changes are pulled back into GRC on 
write. Once you close your editor the file should be considered invalid.


Sebastian


On Wed, Oct 18, 2017, 17:15 Jason Matusiak 
mailto:ja...@gardettoengineering.com>> 
wrote:


I have been experimenting with the Python Block (in core>misc) for
something I was trying to gen up quickly.  I have it working, but
it seems to like creating random file names for the "block" and
storing them in /tmp.

Is there anyway to point to a different file in a different
location and have the block open /that/ in its editor?
___
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




smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Project Call Today! (in 30 mins)

[Martin Braun]

Hi all,

this is a very late reminder, but we have a project call at 10 AM
Pacific time, 1 PM Eastern, 19:00 CET.

Go to #gnuradio for info!

Cheers,
Martin

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

Re: [Discuss-gnuradio] XML parameter checking

[Mike Rex]

Thanks Marcus!  That should have been a natural next step for me, but so 
many Google search results for xml operators put "=" as a comparison!  
Knowing it just needs to be a valid Python expression is good to know 
for future needs.


Much appreciated for your assistance once again.

p.s. for anyone who finds this thread in the future, Marcus meant 
gr-/analog//grc/analog_nbfm_rx.xml for an example of a mod in check tag.


On 2017-10-19 2:36 AM, Marcus Müller wrote:

Hi Mike,

what's in the  tag just needs to be a valid Python expression, 
afaik. So,


$psize % 8 == 0

would work (notice the double =; this is comparison, not assignment!).

For comparison, see the gr-audio/grc/analog_nbfm_rx.xml, for example.

Best regards,

Marcus


On 2017-10-19 04:02, Mike Rex wrote:
What would be the best way to make sure the user enters a parameter 
that is a multiple of 8 in the GRC XML file?  My first thought is 
this might do the trick, but seems there is no mod function for XML.  
Any suggestions?


$psize % 8 = 0 or $psize mod 8 = 0

Thanks in advance,
Mike


___
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