Re: [Discuss-gnuradio] GR- IEEE 802.15.4 PHY Issues

[Bastian Bloessl]

Hi,

On 07/08/2017 05:03 AM, Tellrell White wrote:

Hello Guys
I'm currently using the IEEE 802.15.4 PHY. I've added a random source to 
the flow graph and also a qt gui time and constellation sink. I have two 
questions, why does the constellation plot attached show more than the 
usual 4 constellation points seen in O-QPSK constellation?? Is it due to 
the sampling rate I'm using which is 8M in this case.


The default sampling rate is 4M, I don't know what you changed when you 
tried to make it 8M. If you add a constellation sink to the unmodified 
flowgraph you will see constellation points on the unit circle (your 
second screenshot), which is what you would expect, since IEEE 802.15.4 
uses O-QPSK with a half-sine pulse shape (see the standard).




Also, I was curious as to if the vector source added which implements 
the half sine pulse shaping was creating a problem so I disabled it and 
I was able to see the expected 4 constellation points. So, is the source 
of extra constellation points I'm seeing?? I've attached both the .grc 
file and 2 screen shots, one representing both constellation plots 
discussed.


With this you removed the pulse shaping, so you see only the QPSK 
constellations, but it's also not 15.4 anymore. Most standards use some 
kind of pulse shaping, so you don't see only the constellation points 
when you look at the final IQ signal. I don't understand why this is a 
problem for you.



Best,
Bastian

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

Re: [Discuss-gnuradio] TUNTAP PDU with rds example

[Bastian Bloessl]

Hi,

On 07/07/2017 06:06 PM, Markley da Silva Mendes wrote:

Hi all,

I would like to know if there is any example where I have captured the 
data rds (radio data sistem), using an RTL-2832u, and transformed into 
ethernet frames using the TUNTAP PDU block? And if there is any 
documentation explaining how I can use the TUNTAP PDU block with other 
technologies (zigbee, bluetooth, zWave ...)?


I don't know what you would expect from connecting RDS to a TUNTAP 
interface. With TUNTAP you create a virtual Ethernet interface, which 
allows you to connect your transceiver to the Linux network stack.

For RDS, I don't see any benefit from doing this.

What you might want is connect the transceiver to Wireshark to inspect 
and dissect the data. This can be done with RFtap:


https://rftap.github.io/blog/2016/08/27/decoding-rds-with-rftap.html

Best,
Bastian

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

Re: [Discuss-gnuradio] Decoding 2FSK Compensating for carrier jitter/skewing (CFO)

[HLL]

>
>
> > Some extra information:
> > -I Only have access to trigger communication of the device.
> > -All captures taken from very close proximity (~10 cm) the device is
> > intended to work over hundreds of meters outdoors
> > -I Have access to FCC docs, but since I don't live in the US, *I'm not
> > sure what actual* "primary" *freq* of the device is.
>
> Try looking up the FCC Id at
>
>   https://fcc.io/
>
> Would you post the FCC Id? If I have the FCC id I may play with it when
> while I'm commuting.
>

In fact I don't know the specific FCC id of the device, but from it's
function, appearance and capabilities it can be either of these next
products...
MLLSPEEDHPTX450 
MLLSPEEDTXP45-47 
I'm not sure what the difference between the HP and Just "TX" casing looks
the same, I tend to think it's the standard TX.
This is a AMR (Automated Meter Reading) system endpoint device (I.E. Just
the transmitter part)

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

[Discuss-gnuradio] Autogenerate Code Function

[Richard Bell]

Hi all,

I am in a situation where I have a grc flowgraph set to 'NoGUI' mode with
no GUI blocks. I use this to auto-generate python code that is then called
by other python code.

One of the machines I'm working on does support GUIs, everything is through
the terminal, so I can't open grc files. I would like to know how I
programmatically call the 'Generate Code' button via the terminal or via a
python script so I can auto-generate the python code from the NoGUI grc
file. How would I do this?

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

Re: [Discuss-gnuradio] Autogenerate Code Function

[Marcus Müller]

Hi Rich,

I think the executable you're looking for is ´grcc´ :)

Cheers,
Marcus


On 08.07.2017 19:15, Richard Bell wrote:
> Hi all,
>
> I am in a situation where I have a grc flowgraph set to 'NoGUI' mode
> with no GUI blocks. I use this to auto-generate python code that is
> then called by other python code. 
>
> One of the machines I'm working on does support GUIs, everything is
> through the terminal, so I can't open grc files. I would like to know
> how I programmatically call the 'Generate Code' button via the
> terminal or via a python script so I can auto-generate the python code
> from the NoGUI grc file. How would I do this?
>
> v/r,
> Rich
>
>
> ___
> 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] Running gr-ieee 802.11 and gr-ieee 802.15.4 under same flowgraph (interference and co-existence)

[sumitstop]

Wao superb! you cleaned it out also. Yes it works. Thanks much. 

But did you figure out what was the issue at the first place :) 

I have another related question about the wireshark connector in
transceiver_OQPSK.grc. I see that wireshark connector gets input from two
different outputs. 

One from pdu_out of IEEE802.15.4 MAC and another from rxout of IEEE802.15.4
OQPSK PHY 

When I see the output pcap file i..e sensor.pcap, same packet is logged
twice. I realized this by observing their sequence number field, which
repeats two times for every broadcast frame.
 
I have attached the pcap file for your reference. 
sensor.pcap   

I solved the issue by disconnecting one of the connectors but I am not sure
which one is correct. 
pdu_out of IEEE802.15.4 MAC should go to wireshark 
or 
rxout of IEEE802.15.4 OQPSK PHY should go to wireshark

Both of the above dump correct wireshark capture.

Regards
Sumit



 





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Running-gr-ieee-802-11-and-gr-ieee-802-15-4-under-same-flowgraph-interference-and-co-existence-tp64474p64517.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Running gr-ieee 802.11 and gr-ieee 802.15.4 under same flowgraph (interference and co-existence)

[Bastian Bloessl]

Hi,
On 07/08/2017 07:11 PM, sumitstop wrote:

Wao superb! you cleaned it out also. Yes it works. Thanks much.

But did you figure out what was the issue at the first place :)


I'm not sure. Maybe it was related to one of the Packet Pad blocks. 
Since you resampled, you also changed the length of the frame, which 
might have confused the block (the length tag at the start of the frame 
didn't correspond to the length of the frame anymore).




I have another related question about the wireshark connector in
transceiver_OQPSK.grc. I see that wireshark connector gets input from two
different outputs.

One from pdu_out of IEEE802.15.4 MAC and another from rxout of IEEE802.15.4
OQPSK PHY

When I see the output pcap file i..e sensor.pcap, same packet is logged
twice. I realized this by observing their sequence number field, which
repeats two times for every broadcast frame.


Yes, in the loopback configuration it logs all frames twice. Once they 
are sent and once they are received. The setup makes more sense when you 
actually transmit frames over the air. Then you might want to log what 
was sent and what was received.


In your simulations you probably know what you sent and are only 
interested in which frames made it through. In that case, just remove 
the connection from the sender to the Wireshark block.


Best,
Bastian

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

Re: [Discuss-gnuradio] Decoding 2FSK Compensating for carrier jitter/skewing (CFO)

[Cinaed Simson]

Thanks.

Using the FCC Id of either MLLSPEEDHPTX450 or MLLSPEEDTXP45-47 - they
both have the same IC - then from the RF emissions code, i.e., 7K10F1D,
the 7K10 indicates it has a maximum bandwidth of 7.1 kHz, the F
indicates is FM - but the documents on file indicate it's 2FSK, the 1
indicates on-off keying and no modulation, and the D indicates it's
digital.

And it can transmit between 450-470 MHz.

-- Cinaed


On 07/08/2017 09:14 AM, HLL wrote:
> 
> > Some extra information:
> > -I Only have access to trigger communication of the device.
> > -All captures taken from very close proximity (~10 cm) the device is
> > intended to work over hundreds of meters outdoors
> > -I Have access to FCC docs, but since I don't live in the US, *I'm not
> > sure what actual* "primary" *freq* of the device is.
> 
> Try looking up the FCC Id at
> 
>   https://fcc.io/
> 
> Would you post the FCC Id? If I have the FCC id I may play with it when
> while I'm commuting.
> 
> 
> In fact I don't know the specific FCC id of the device, but from it's
> function, appearance and capabilities it can be either of these next
> products...
> MLLSPEEDHPTX450 
> MLLSPEEDTXP45-47 
> I'm not sure what the difference between the HP and Just "TX" casing
> looks the same, I tend to think it's the standard TX.
> This is a AMR (Automated Meter Reading) system endpoint device (I.E.
> Just the transmitter part) 
> 
> HLL.
> 
> 
> ___
> 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] Decoding 2FSK Compensating for carrier jitter/skewing (CFO)

[Andy Walls]

> Date: Fri, 7 Jul 2017 19:50:55 +0300
> From: HLL

> Hi all,
> 
> I'm relatively new to DSP and gnuradio but I tried tons of stuff and
> I couldn't decode a fairly simple FSK data.
> baudrate seems around 600-700 bps and fsk deviation is less then 3k.


Hmmm.  I took a look at your signal and tried building a coherent 2-FSK 
demodulator.  Under the assumption that it was straight 2-FSK, the
signaling tones looked to be at +/- 1200 Hz when properly centered. The
fastest bit rate appeared to be 1880 bits/sec.

But in reality that doesn't work.  I could never get good symbol timing
recovery as the "FSK" signal appeared to have two different baud rates.

After some reflection, the signal you have appears to actually be AFSK
inside of FM.  Zoom out a little on the output of the quad demod, and
your eye can see the two tones.  The two tones appear to be at 350 Hz
and 940 Hz.  The tones are unusual in that they are square wave tones
vs. sine wave.

I haven't worked you the baud rate yet.  I'll hack away at it more
tomorrow. 

Regards,
Andy

> 
> Thanks for the help
> HLL.

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

Re: [Discuss-gnuradio] Autogenerate Code Function

[vamsi krishna]

Thank you Marcus!

Vamsi

Sent from my iPhone

> On Jul 8, 2017, at 10:47, Marcus Müller  wrote:
> 
> Hi Rich,
> 
> I think the executable you're looking for is ´grcc´ :)
> 
> Cheers,
> Marcus
> 
> 
>> On 08.07.2017 19:15, Richard Bell wrote:
>> Hi all,
>> 
>> I am in a situation where I have a grc flowgraph set to 'NoGUI' mode with no 
>> GUI blocks. I use this to auto-generate python code that is then called by 
>> other python code. 
>> 
>> One of the machines I'm working on does support GUIs, everything is through 
>> the terminal, so I can't open grc files. I would like to know how I 
>> programmatically call the 'Generate Code' button via the terminal or via a 
>> python script so I can auto-generate the python code from the NoGUI grc 
>> file. How would I do this?
>> 
>> v/r,
>> Rich
>> 
>> 
>> ___
>> 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

Re: [Discuss-gnuradio] Problems with IEEE802-11 Blocks?

[Bastian Bloessl]

Hi,

I recommend to start with the example flow graph and make sure that it 
works works for you. If that works, just replace the constant message 
source with the data that you want to transmit.
Did you maybe delete the packet pad block and just sent data back to 
back without any space in between?


Best,
Bastian

On 07/08/2017 09:20 PM, Taylor Eisman wrote:
I've been trying to use the IEEE802-11 blocks to simulate Wi-Fi 
environments. I've generated data from the local radio station, tagged 
it, modulated, etc. It is never able to generate a file at the end and 
I've tracked it down to an issue in the WiFi Decode block.


This is the error that the WiFi Decode block generates:

Decode MAC: frame start -- len 250  symbols 29  encoding 3
copy one symbol, copied 0 out of 29
copy one symbol, copied 1 out of 29
copy one symbol, copied 2 out of 29
copy one symbol, copied 3 out of 29
copy one symbol, copied 4 out of 29
copy one symbol, copied 5 out of 29
copy one symbol, copied 6 out of 29
copy one symbol, copied 7 out of 29
copy one symbol, copied 8 out of 29
copy one symbol, copied 9 out of 29
copy one symbol, copied 10 out of 29
copy one symbol, copied 11 out of 29
copy one symbol, copied 12 out of 29
copy one symbol, copied 13 out of 29
copy one symbol, copied 14 out of 29
copy one symbol, copied 15 out of 29
copy one symbol, copied 16 out of 29
copy one symbol, copied 17 out of 29
copy one symbol, copied 18 out of 29
copy one symbol, copied 19 out of 29
copy one symbol, copied 20 out of 29
copy one symbol, copied 21 out of 29
copy one symbol, copied 22 out of 29
copy one symbol, copied 23 out of 29
Decode MAC: input 1
copy one symbol, copied 24 out of 29
Decode MAC: input 25
copy one symbol, copied 25 out of 29
Warning: starting to receive new frame before old frame was complete
Already copied 26 out of 29 symbols of last frame

I've tried changing the source file to something else. I've messed with 
the parameters and noticed that it is always 3 symbols short of a full 
frame, even if there are theoretically 3000 symbols, it would only pass 
2997 symbols.


Any ideas on what could be causing this?

I'm attaching the WiFi Phy Hier graph to give you some idea of the layout
.



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



--
Dipl.-Inform. Bastian Bloessl
CONNECT Center
Trinity College Dublin

GitHub/Twitter: @bastibl
https://www.bastibl.net/

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

Re: [Discuss-gnuradio] GR- IEEE 802.15.4 PHY Issues

[Bastian Bloessl]

The staggering of the imaginary part in combination with the half sine 
pulse shape, makes the constellation point move on the unit circle. 
During a bit period it makes a 90 degree transition to one of the 
neighboring constellations (encoding the 0 and 1). It doesn't actually 
stay at the ideal constellation points, but immediately starts the next 
transition.


Now if the sample rate would be very high, you would see many closely 
spaced points on the unit circle. But the example flow graph uses a 
sample rate of only 4M, i.e., 2 symbols per bit/chip. Therefore, you see 
only one more sample/constellation point when the transition is half way 
through, leading to 8 different points shown in the constellation sink.


Best,
Bastian


On 07/08/2017 09:22 PM, Tellrell White wrote:

Thanks for the response Bastian

I have taken a look at the IEEE 802.15.4 as suggested. I do see that 
half sine pulse shaping is used according to the standard. However,  I 
believe the issue may be with my understanding of O-QPSK. I've attached 
a picture that I use as a reference. I thought the key difference 
between qpsk and o-qpsk is that due to the staggering of the imag 
component by a half a symbol, o-qpsk can only result in 90 degree 
transitions instead of the 180 degree variations seen in qpsk. I'm still 
trying to understand why i'm seeing 8 constellation points from my 
constellation sink and not the usual 4 that you would see in any o-qpsk 
constellation plot. If any one has a good reference on this please share.


Tellrell


On Saturday, July 8, 2017 5:53 AM, Bastian Bloessl  wrote:


Hi,

On 07/08/2017 05:03 AM, Tellrell White wrote:
 > Hello Guys
 > I'm currently using the IEEE 802.15.4 PHY. I've added a random source to
 > the flow graph and also a qt gui time and constellation sink. I have two
 > questions, why does the constellation plot attached show more than the
 > usual 4 constellation points seen in O-QPSK constellation?? Is it due to
 > the sampling rate I'm using which is 8M in this case.

The default sampling rate is 4M, I don't know what you changed when you
tried to make it 8M. If you add a constellation sink to the unmodified
flowgraph you will see constellation points on the unit circle (your
second screenshot), which is what you would expect, since IEEE 802.15.4
uses O-QPSK with a half-sine pulse shape (see the standard).


 >
 > Also, I was curious as to if the vector source added which implements
 > the half sine pulse shaping was creating a problem so I disabled it and
 > I was able to see the expected 4 constellation points. So, is the source
 > of extra constellation points I'm seeing?? I've attached both the .grc
 > file and 2 screen shots, one representing both constellation plots
 > discussed.


With this you removed the pulse shaping, so you see only the QPSK
constellations, but it's also not 15.4 anymore. Most standards use some
kind of pulse shaping, so you don't see only the constellation points
when you look at the final IQ signal. I don't understand why this is a
problem for you.


Best,
Bastian





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



--
Dipl.-Inform. Bastian Bloessl
CONNECT Center
Trinity College Dublin

GitHub/Twitter: @bastibl
https://www.bastibl.net/

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