[Discuss-gnuradio] 802.15.4 packet receive using transceiver_OQPSK.grc

[Jaeho]

hello, i am Jaeho.

I am using two USRP X300(one is for transmitter and the other is for
receiver), 
Linux Ubuntu 15.04, gnuradio version 3.7.8,
ieee_802_15_4(https://github.com/bastibl/gr-ieee802-15-4).

And I find a method to transmit packet by broadcasting with
transceiver_OQPSK.grc.

As I know, transceiver means it could role as both transmitter and receiver.

But the problem is, I could not find how can I receive packet using this
code.

If transmitter sends packets through broadcast, then receiver receives
packets and check a message in received packets.

This is my ideal scenario. 

Please teach me how can I receive packets using transceiver_OQPSK.grc.

OR if there are other methods to receive 802.15.4 packets, then let me know.

Thank you.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/802-15-4-packet-receive-using-transceiver-OQPSK-grc-tp56443.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] Problem post installing kit.ce/gr-lte

[Johannes Demel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Daniele,

'MIMO TOP FLOW plots.grc' needed an update. I pushed a new version of
this flowgraph which should work now. I had to substitute some blocks.

Cheers
Johannes

On 09.10.2015 10:19, Daniele Disco wrote:
> Johannes Demel  student.kit.edu> writes:
> 
>> 
>> 
>> Hi Daniele,
>> 
>> Run this script a few times. Some of those hier blocks are
>> nested. The script doesn't care about compiling them in correct
>> order. So after 2 3 times it should have everything. Unless
>> something went wrong.
>> 
>> I recommend you open the 'top_level' flowgraphs and have a look
>> at them. The error messages tell you that some blocks are not
>> connected. You should be able to see how to connect them, though.
>> In case a block is missing, look for the corresponding hier block
>> graph and compile it in GRC. Don't forget to reload/restart GRC.
>> 
>> The whole flowgraph takes quite a lot of computational load. It
>> is intended to make it easy for users to play around with. It's
>> not so much optimized for speed. Though I'd be happy to merge
>> contributions here too. Long story short, I recommend to record
>> samples and do offline processing.
>> 
>> Cheers Johannes
>> 
> 
> Thanks Johannes for your answer.
> 
> Related to run the script several time ok, but this not solve the
> problems.
> 
> I tried to substitute the blocks missing but the same block there
> is not present. Example in "MIMO TOP FLOW plots.grc" is
> lte_mimo_pbch_demux and lte_mimo_pre_decoder What I found similar
> are lte_pbch_demux_vcvc and lte_pre_decoder_vcvc The inputs of
> these blocks are different but searching for similar meaning 
> something can be done
> 
> Looking the original flowgraph  and creating a new one the problems
> are always there.
> 
> Just to give an example the original  'MIMO TOP FLOW plots.grc'
> produce these errors: ===start errors MIMO TOP FLOW
> plots.grc== ['grcc', 'MIMO TOP FLOW plots.grc']
 Error: Block key "lte_mimo_pbch_demux" not found in Platform
 - grc(GNU
> Radio Companion)
 Error: Block key "lte_mimo_pbch_demux" not found in Platform
 - grc(GNU
> Radio Companion)
 Error: Block key "lte_mimo_pbch_demux" not found in Platform
 - grc(GNU
> Radio Companion)
 Error: Block key "lte_mimo_pre_decoder" not found in Platform
 - grc(GNU
> Radio Companion)
 Error: Block key "lte_mimo_pre_decoder" not found in Platform
 - grc(GNU
> Radio Companion) Validation failed:
> 
> Block - lte_mimo_ofdm_rx_0 - LTE MIMO OFDM RX(lte_mimo_ofdm_rx): 
> Source - out1(1): Port is not connected.
> 
> Block - lte_mimo_sss_sync_0 - LTE MIMO SSS
> sync(lte_mimo_sss_sync): Source - out1(1): Port is not connected.
> 
> Block - lte_mimo_sss_sync_0 - LTE MIMO SSS
> sync(lte_mimo_sss_sync): Sink - in1(1): Port is not connected.
> 
> Block - pbch_layer_demapper_vcvc_1 - Layer
> demapper(lte_layer_demapper_vcvc): Sink - in(0): Port is not
> connected.
> 
> Connection ( Block - lte_mimo_sss_sync_0 - LTE MIMO SSS
> sync(lte_mimo_sss_sync) Source - out0(0) Block -
> lte_mimo_decode_pbch_0 - LTE MIMO Decode
> PBCH(lte_mimo_decode_pbch) Sink - in(0) ): Source IO size "4800"
> does not match sink IO size "9600".
> 
> Connection ( Block - lte_mimo_sss_sync_0 - LTE MIMO SSS
> sync(lte_mimo_sss_sync) Source - out0(0) Block -
> lte_mimo_estimator_0 - LTE MIMO estimator(lte_mimo_estimator) Sink
> - in(0) ): Source IO size "4800" does not match sink IO size
> "9600". ===stop errors MIMO TOP FLOW
> plots.grc
> 
> A new version made by me with the blocks reported before: 
> ===start errors MIMO TOP FLOW plots_Daniele== 
> ['grcc', 'MIMO TOP FLOW plots_Daniele.grc'] Validation failed:
> 
> Block - pbch_layer_demapper_vcvc_1_0 - Layer
> demapper(lte_layer_demapper_vcvc): Source - out(0): Port is not
> connected.
> 
> Connection ( Block - lte_mimo_sss_sync_0 - LTE MIMO SSS
> sync(lte_mimo_sss_sync) Source - cell_id(cell_id) Block -
> lte_pbch_demux_vcvc_0 - PBCH Demux(lte_pbch_demux_vcvc) Sink -
> in(0) ): No connection known for domains "gr_message", "gr_stream"
> 
> Connection ( Block - lte_mimo_sss_sync_0 - LTE MIMO SSS
> sync(lte_mimo_sss_sync) Source - cell_id(cell_id) Block -
> lte_pbch_demux_vcvc_0 - PBCH Demux(lte_pbch_demux_vcvc) Sink -
> in(0) ): Source IO size "0" does not match sink IO size "9600".
> 
> Connection ( Block - lte_mimo_sss_sync_0 - LTE MIMO SSS
> sync(lte_mimo_sss_sync) Source - out0(0) Block -
> lte_mimo_decode_pbch_0 - LTE MIMO Decode
> PBCH(lte_mimo_decode_pbch) Sink - in(0) ): Source IO size "4800"
> does not match sink IO size "9600".
> 
> Connection ( Block - lte_mimo_sss_sync_0 - LTE MIMO SSS
> sync(lte_mimo_sss_sync) Source - out0(0) Block -
> lte_mimo_estimator_0 - LTE MIMO estimator(lte_mimo_estimator) Sink
> - in(0) ): Domain "gr_stream" can have only one upstream block
> 
> Connection ( Block - lte_mimo_sss_sync_0 - LTE MIMO SSS
> sync(lte_mimo_sss_sync) Source - out0(0) 

[Discuss-gnuradio] RTL-SDR source for USRP

[Hoang Nguyen Tran]

Hi all,

I have install librtlsdr and now using RTL-SDR source in GNU radio with
USRP1 WBX and Basic RX daughter board (Because I saw it support) . I wonder
how can I change the subdev devices in this source ? Because when I run
flow graph it always choose 'B:0' . Before I used USRP source and easily to
choose subdev and antenna.
RTL-SDR source seem to have higher gain even thought I used the same value
of rf_gain ??
And one more thing, What is maximum rf_gain value that I can set for the
source that WBX and Basic RX can operate ? I read that it's is 31.5dB, is
that correct ? I usually put 20.

Thank you and best regard.

-- 
 -HoangNT-
PhoneNo :  +841654248782
Skype : hoangastro
FB : https://www.facebook.com/kenshin.rorouni
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Decoding constellation (0, 1-1) using gnuradio

[abhinav narain]

This is the grc file if someone would like to run it on their setup.

On Mon, Oct 12, 2015 at 9:00 AM, abhinav narain 
wrote:

> Hi,
>  I am trying to transmit -1,0,1 { [1]+ 100*[0]+[-1] }, basically BPSK lot
> of 0s  filled in between at certain frequency. I have few questions.
> "Constellation object" has 3 symbols ([1+0j,-1+0j,0+0j]) mapped to symbol
> map-> [0,1,2]  respectively. I agree that constellation with size 3 is
> weird but that is what I want. I want the decision boundaries to be at
> -0.5, 0.5 for bits and anything between that to be given symbol=2 which i
> can discard later on. I am currently doing this in baseband, but I will
> eventually trasmit at a some frequency X.
>
>  I have the following baseband setup grc (
> http://postimg.org/image/8k7g1o375/  , grc file is attached).
>  I have few problems which I am unable to fix since yesterday -
>  1) The constellation after channel is stable (as expected) but it goes
> weird
>  after the polyphase clock sync and costas loop (
> http://postimg.org/image/pyg8h2vlh/  , attached image-
> constellation_before_after_costas.png)  and hence I don't get the expected
> output of equally spaced 1, 0 in the decoder  output (
> http://postimg.org/image/a58cc35cj/  , attached image-
> custom_decoder_0_1_2_output.png)
>
>  2) If I set the order of costas loop as 3 (size of constellation) my
> flowgraph doesn't work at all. I have used the parameters after reading
> some example code
>  in gnuradio folders and web and i guess they are correct. Please correct
> me if  I am wrong.
>
> Thanks,
> Abhinav
>


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

Re: [Discuss-gnuradio] Decoding constellation (0, 1-1) using gnuradio

[Marcus Müller]

Hi Abhinav,

the problem is that you're not doing BPSK, really. It's an Amplitude
shift keying, if you want so.
Two things:
* you might want to consider what AGC2 does while you're transmitting
zeros -- it will increase amplification until noise scales up to signal
power. What you're getting after that will more or less be useless,
unless your AGC is really set to be slow (I don't think so, according to
the attack rate of 6/100).
* you're throwing a FLL at your signal -- which would be fine, if there
was definitely a carrier. I don't see how that should work for a signal
that's zero most of the time.
* Assuming the polyphase clock synth did work with such a signal, the
resulting signal would still contain a symbol that was '0', and hence
had random phase (the phase of the additive noise at the sampling time).
Hence, the costas loop can't do anything reasonable about that.

If I understand you correctly, however, you *actually* want to do BPSK,
and the 0 symbol is just a "filler" in between symbols, right? That
might actually work, if you just increase the rolloff duration/samples
per symbol of your pulse shaping filter.

So, I think it might be best to explain what kind of system you're
trying to build, so that we can understand that better!

Best regards,
Marcus

On 10/12/2015 06:00 PM, abhinav narain wrote:
> Hi,
>  I am trying to transmit -1,0,1 { [1]+ 100*[0]+[-1] }, basically BPSK
> lot of 0s  filled in between at certain frequency. I have few
> questions. "Constellation object" has 3 symbols ([1+0j,-1+0j,0+0j])
> mapped to symbol map-> [0,1,2]  respectively. I agree that
> constellation with size 3 is weird but that is what I want. I want the
> decision boundaries to be at -0.5, 0.5 for bits and anything between
> that to be given symbol=2 which i can discard later on. I am currently
> doing this in baseband, but I will eventually trasmit at a some
> frequency X.
>
>  I have the following baseband setup grc
> (http://postimg.org/image/8k7g1o375/  , grc file is attached).
>  I have few problems which I am unable to fix since yesterday -
>  1) The constellation after channel is stable (as expected) but it
> goes weird
>  after the polyphase clock sync and costas loop (
> http://postimg.org/image/pyg8h2vlh/  , attached image-
> constellation_before_after_costas.png)  and hence I don't get the
> expected output of equally spaced 1, 0 in the decoder  output (
> http://postimg.org/image/a58cc35cj/  , attached image-
> custom_decoder_0_1_2_output.png)
>
>  2) If I set the order of costas loop as 3 (size of constellation) my
> flowgraph doesn't work at all. I have used the parameters after
> reading some example code
>  in gnuradio folders and web and i guess they are correct. Please
> correct me if  I am wrong.
>
> Thanks,
> Abhinav
>
>
> ___
> 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] 802.15.4 packet receive using transceiver_OQPSK.grc

[Bastian Bloessl]

Hi Jaeho,

I’m not sure whether I understand you correctly since, actually, the same flow 
graph can be used to send and receive.

Maybe start with a loopback experiment first. When you checkout the project, 
the output of the phy is fed back to it’s input. This flow graph can be run 
without any hardware and hopefully helps to understand the packt flow.

I guess the packets are there but you just don’t see them. Either use Wireshark 
to dump the packets (see the transceiver.sh script in the apps folder to 
understand how to start this), or use a ‘debug message’ block to dump the 
packet content, or feed the packets to a UDP sink and connect via netcat (nc -u 
localhost 52001).

Best,
Bastian


> On 11 Oct 2015, at 23:33, Jaeho  wrote:
> 
> hello, i am Jaeho.
> 
> I am using two USRP X300(one is for transmitter and the other is for
> receiver), 
> Linux Ubuntu 15.04, gnuradio version 3.7.8,
> ieee_802_15_4(https://github.com/bastibl/gr-ieee802-15-4).
> 
> And I find a method to transmit packet by broadcasting with
> transceiver_OQPSK.grc.
> 
> As I know, transceiver means it could role as both transmitter and receiver.
> 
> But the problem is, I could not find how can I receive packet using this
> code.
> 
> If transmitter sends packets through broadcast, then receiver receives
> packets and check a message in received packets.
> 
> This is my ideal scenario. 
> 
> Please teach me how can I receive packets using transceiver_OQPSK.grc.
> 
> OR if there are other methods to receive 802.15.4 packets, then let me know.
> 
> Thank you.
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/802-15-4-packet-receive-using-transceiver-OQPSK-grc-tp56443.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
> 

--
Dipl.-Inform. Bastian Bloessl
Distributed Embedded Systems Group
University of Paderborn, Germany
http://www.ccs-labs.org/~bloessl/


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

Re: [Discuss-gnuradio] 802.15.4 packet receive using transceiver_OQPSK.grc

[Jaeho]

I think my question need to be more detail

I have two USRP X300 and two laptop 

Each USRP connected with laptop through Ethernet cable

One USRP (A) is a transmitter and the other USRP (B) is a receiver

(A) sends a packet (broadcasting), (B) want to receive these packet from (A)

I already saw loopback experiment and transceiver examples

but it seems like run in only one USRP device

I want to know how can I run two USRP devices 

and how can I program (B) receive packets from (A) -> between different
other devices







--
View this message in context: 
http://gnuradio.4.n7.nabble.com/802-15-4-packet-receive-using-transceiver-OQPSK-grc-tp56443p56446.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] Is it possible to export ctrlport measurements to some text formats?

[Tom Rondeau]

On Wed, Sep 30, 2015 at 11:06 AM, Jeon  wrote:

> ControlPort and Performance Monitor are very good tools to measure
> performance of modules.
>
> But one thing that I want is, it would be perfect if I could export
> measurements displayed in either ControlPort or Performance Monitor in some
> text formats, e.g., plain text or CSV.
>
> The reason is simple.
> When we want to keep looking into it detail or to draw a plot with other
> tools,
> measurements in readable, editable formats are needed.
>
> Or, it might be some functionalities to print values in stdout, which I
> can redirect to somewhere.
> And I couldn't find it or enable it...
>
> Regards,
> Jeon.
>


Jeon,

This should be fairly easily to write yourself. There are examples and QA
code for how to get information over ControlPort from a Python program, and
Python has an easy-to-use CSV module for formatting.

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

Re: [Discuss-gnuradio] Mailing list archive looks broken

[Marcus Müller]

For the record:
The Mailing list archive seems to be up again, but all mails between the
first and the fifth of October seem to be filed under the eighth... I
wonder what went wrong on GNU's side...

Best regards,
Marcus

On 10/04/2015 08:24 PM, bob wole wrote:
>
>
>
> The ML archive here looks like it has stopped updating:
>
> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-10/index.html
>
> Regards,
> Andy
>
>
>
> I am also unable to see recent threads. Only one email for this month. 
>
> --
> 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

Re: [Discuss-gnuradio] 802.15.4 packet receive using transceiver_OQPSK.grc

[Bastian Bloessl]

Hi,

you connect the output of the PHY to the USRP source and sink blocks and start 
it. Then it will actually transmit something.
If you do this on two PCs they should receive each others frames.

Best,
Bastian



> On 12 Oct 2015, at 06:48, Jaeho  wrote:
> 
> I think my question need to be more detail
> 
> I have two USRP X300 and two laptop 
> 
> Each USRP connected with laptop through Ethernet cable
> 
> One USRP (A) is a transmitter and the other USRP (B) is a receiver
> 
> (A) sends a packet (broadcasting), (B) want to receive these packet from (A)
> 
> I already saw loopback experiment and transceiver examples
> 
> but it seems like run in only one USRP device
> 
> I want to know how can I run two USRP devices 
> 
> and how can I program (B) receive packets from (A) -> between different
> other devices
> 
> 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/802-15-4-packet-receive-using-transceiver-OQPSK-grc-tp56443p56446.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
> 

--
Dipl.-Inform. Bastian Bloessl
Distributed Embedded Systems Group
University of Paderborn, Germany
http://www.ccs-labs.org/~bloessl/


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

[Discuss-gnuradio] BER calculation using digital_bert_tx.py and digital_bert_rx.py

[Hitesh Kasera]

Hi everyone,
I am trying to calculate BER for bpsk and qpsk using digital_bert_tx.py and
digital_bert_rx.py. i want to compare BER of qpsk and bpsk. At same SNR
around 20db i am getting constant .16 BER for qpsk and for bpsk it is
1e-12. when i change the SNR using gain of Transmitter and Receiving end
there is no change in BER for qpsk, for bpsk its changes. I am not able to
understand why with qpsk its not working. if anyone has any idea or anyone
who has calculated BER previously please help me.

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

Re: [Discuss-gnuradio] Correlation Estimator Over the Air

[Washbourne, Logan]

Rich and others,

I added the AGC block to RX side and after playing with the parameters for
awhile I got a correlation spike! My next step was to confirm that my
output equalled my input (byte-wise). In order to accomplish this, I added
a Constellation Decoder block after the costas loop and used the
constellation object as the input parameter. Then I repacked the bits into
8 bit bytes and saved it to a file. I also saved the input byte stream to a
file. I looked at those files in Matlab and so far I have not been able to
find the preamble in the output byte stream.

After not being able to determine if this communication system was working(
the TX and RX programs utilizing the USRPs), I took a step back and tried
to figure out how to confirm if the test_corr_est.grc had the same output
as its input and I'm running into the same problem, I haven't been able to
find the preamble in the output.

Both programs show a clear correlation spike, I just want to put my mind at
ease and verify if it's working through the actual bytes. One last note,
the packed output byte stream is roughly 5.5 times smaller than the input
byte stream, which I was expecting a really close 1:1 size, this makes me
think I am overlooking a consequence of one of the blocks, namely the
Correlation Estimator, Polyphase Clock Sync, or the Costas Loop.

Does anyone have any suggestions?

I know this thread is getting a little long, but I appreciate everyone's
patience with my questions.



Logan Washbourne
Electrical Engineering Graduate Student
(Electromagnetics)


On Wed, Oct 7, 2015 at 11:26 AM, Richard Bell 
wrote:

> Ah, yes. I suspect you don't have an AGC in your flowgraph? Whenever
> you're thresholding against some static number, you need to be sure your
> input signal is set to a known amplitude, which is what the AGC does for
> you. If you put an AGC in the chain you should see peak values that get
> close to your simulation values. The AGC produces a stable platform for the
> rest of your blocks to sit on.
>
> The AGC parameters can really play havoc with your system. The AGC can be
> the cause of a lot of headache. If you find yourself debugging something
> that makes no sense, often it's the AGC's fault, in my experience. I
> recommend you create a simulation that stresses the AGC and prove it will
> work as best you can before going to over the air.
>
> Rich
>
>
>
> On Wed, Oct 7, 2015 at 9:09 AM, Washbourne, Logan <
> lwas...@ostatemail.okstate.edu> wrote:
>
>> Last time I replied to the mailing list, did it go directly to your
>> email? If so, I will double check next time to make sure it goes to the
>> list.
>>
>> Your explanation makes sense, with the limited knowledge of filtering
>> that I have.
>>
>> I changed the filter length on my RX side for the rrc_taps and nothing
>> seemed to change. But I think what the overarching problem is, is my metric
>> for success. The way I am determining if the communication has been
>> successful is the amplitude of the correlation value coming out of the
>> Correlation Estimator block. Through all of my testing over the air, the
>> correlation value hasn't seemed to have changed. I can register an
>> extremely small value, of .5-1.5 if I set the QT GUI TIME SINK to
>> autoscale, but the non-over the air version outputs a value of roughly 75,
>> which has been causing me to call the communication a failure.
>>
>> Do you have any advice?
>>
>> Logan Washbourne
>> Electrical Engineering Graduate Student
>> (Electromagnetics)
>>
>>
>> On Wed, Oct 7, 2015 at 10:47 AM, Richard Bell 
>> wrote:
>>
>>> Previous email sent without me telling it to. Picking up from "Fuction
>>> coped below:"
>>>
>>> firdes.root_raised_cosine(nfilts, nfilts, 1.0/float(sps), eb,
>>> 5*sps*nfilts)
>>>
>>> The first nfilts is just gain of your filter. The next two paraters
>>> should work out to be the number of samples per symbol of the upsampled
>>> RRC. 1/float(sps) gives you 1/4 if sps = 4. Then to get samp/symb you have
>>> nfilts/(1/4) = 4*nfilts samp_symb, which is in fact the upsampled version
>>> you want. The point I'm trying to make, is you could have filled out the
>>> function this way and got the same result:
>>>
>>> firdes.root_raised_cosine(nfilts, nfilts*sps, 1, eb, 5*sps*nfilts)
>>>
>>> which feels more natural to me.
>>>
>>> The last paramter is the length of the filter in samples. The default
>>> does not match the built in length of the Constellation Modulator filter,
>>> which is hardcoded to 11 if I remember right. So I use, 11*sps*nfilts+1 for
>>> this parameter. The plus 1 is actually handled for you in the constructor
>>> of the RRC (I think it's the constructor, but if not somewhere). If you
>>> feed an even number in, it will get 1 added to it. I like to be explicit
>>> with the +1, but you don't need it.
>>>
>>> Rich
>>>
>>> On Wed, Oct 7, 2015 at 8:41 AM, Richard Bell 
>>> wrote:
>>>
 Logan,

 I 

Re: [Discuss-gnuradio] 802.15.4 packet receive using transceiver_OQPSK.grc

[Jaeho]

Thank you for your comment

And I have one more question.

As I know, instead of IP, 802.15.4 use mac address to communicate between
two nodes.

So, I think, I must setting mac address for 802.15.4 communication, but I
can't find

any setting source code from Loopback experiment and transceiver_OQPSK.grc

How can I set mac address manually?



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/802-15-4-packet-receive-using-transceiver-OQPSK-grc-tp56443p56460.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] 802.15.4 packet receive using transceiver_OQPSK.grc

[Jaeho]

I think I should make my question more specific.

The address 192.168.10.2 is for USRP A and it is used between A and A's
PC(Local Address).

And also address 192.168.10.2 is for USRP B and it is used between B and B's
PC(Local Address).

Both A and B use same address(192.168.10.2), but I think USRP
Source(transmitter) need to know

USRP Sink(receiver)'s address to send packet.

OR USRP Sink(receiver) should know address of USRP Source(transmitter) to
receive packet.

How can I know AND setting this address for communicating between two USRP?



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/802-15-4-packet-receive-using-transceiver-OQPSK-grc-tp56443p56458.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] 802.15.4 packet receive using transceiver_OQPSK.grc

[Bastian Bloessl]

Hi,

> On 12 Oct 2015, at 18:43, Jaeho  wrote:
> 
> I think I should make my question more specific.
> 
> The address 192.168.10.2 is for USRP A and it is used between A and A's
> PC(Local Address).
> 
> And also address 192.168.10.2 is for USRP B and it is used between B and B's
> PC(Local Address).
> 
> Both A and B use same address(192.168.10.2), but I think USRP
> Source(transmitter) need to know
> 
> USRP Sink(receiver)'s address to send packet.
> 
> OR USRP Sink(receiver) should know address of USRP Source(transmitter) to
> receive packet.
> 
> How can I know AND setting this address for communicating between two USRP?
> 

fortunately, the transceiver sends IEEE 802.15.4 frames that don't use IP. 
Therefore, it doesn’t matter.

 The only part where IP comes into play is when you stream samples to the USRP, 
but if the USRP is detected and there are no problems when starting the flow 
graph you’re good.

I guess you are mixing some things up here.

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