Hi Jay and Tom,
we too are having similar issues in communicating
between two USRP's using tunnel.py. we fiddled a lot with the gain values,
changed frequencies, modified delay variables in the code but found that
even though there is pretty good full duplex communication of packets
between the USRP's, the ping command is not giving a good output. we tried
and received a minimum ping packet loss of 60%. we couldn't get better than
that with all the modifications we tried. we thought that the ping is not
receiving the icmp back in time so it is showing as a false packet because
the usrp packets reception on both ends is fine.
Any suggestions will be very helpful. Thank You.
On Mon, Jun 10, 2013 at 8:00 PM, Jay Prakash
<jay.prakash.ec...@itbhu.ac.in>wrote:
> Yes I have tested using different frequency.No help.
>
> And while debugging I figured out that PHY layer receives the packet from
> transmitter sent as ping ICMP packets and decodes the sender's address.
> After that it writes to the tun/tap. But tun/tap reply is unavailable.
> Ie there is some problem in tun/tap and PHY layer interface.
>
> How to figure this out?
>
>
> Jay Prakash
> Senior Undergraduate
> Electronics Engineering
> IIT (BHU)
> VARANASI
>
> +91-9559475258
> http://about.me/jay.prakash/
> http://www.linkedin.com/profile/view?id=91120191&trk=hb_tab_pro_top
>
>
>
>
> On Mon, Jun 10, 2013 at 7:13 PM, Tom Rondeau <t...@trondeau.com> wrote:
>
>> On Thu, Jun 6, 2013 at 3:22 PM, Jay Prakash
>> <jay.prakash.ec...@itbhu.ac.in> wrote:
>> > We are working on establishing a tunnel for MAC protocol design using
>> > tunnel.py given as example in GNU Radio but are unable to receive ping
>> reply
>> > from the other node.
>> >
>> > We created tun/tap interface using ./tunnel.py -f 990M and ipconfig
>> > 192.168.200.1 on Machine A connected to N210 series of USRP.
>> > and ./tunnel.py -f 990M and ifconfig 192.168.200.2 on machine B.
>> >
>> > 1. Now on pinging machine B from A we can see ping packets being sent
>> to B
>> > by A using wireshark, but there is no reply on node A.
>> >
>> > 2. We went into details and saw there were ARQ requests from B
>> repetitively.
>> > I manually added the mac address to update the table.
>> > Now ARQ request ceased to exist but still there were no replies on A.
>> >
>> >
>> > 3. Since we knew the Packaging details of ICMP we read the packets being
>> > received by B and found the exact source address of A from the frame. It
>> > means message have been successfully decoded by the destination and it
>> knows
>> > whom to reply for the ping but still I don't find any reception
>> confirmation
>> > on source side.
>> >
>> > What may be the possible problems?USRP antenna gain?Packets collision?
>> >
>> > In short we are unable to use tunnely.py and are seeking for possible
>> > causes.
>> >
>> > Jay Prakash
>> > Senior Undergraduate
>>
>> You could be having gain issues. Test this using the standard
>> uhd_siggen and uhd_fft programs to understand what settings give you
>> the best gain.
>>
>> Also, try using different frequencies for transmit and receive (use
>> the -h on the command line to figure out how to do this).
>>
>> Tom
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
Regards
Karan Talasila
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
