Weixian, Here is a temp solution, not sure it works or not:
In the csma_mac.main_loop() of your tunnel.py, add a time_sleep(fixed_delay) right after the payload is read from the OS. You can set fixed_delay as 0.01 to 0.1 and test the result. And also, please set the CSMA threshold carefully to avoid possible collision. Alex On Mon, Jun 18, 2012 at 10:10 AM, Weixian Zhou <idea...@gmail.com> wrote: > The following is the messages of the transmitter after I ping. The > packages of len(payload)=42 failed CRC check, but other packages succeed. > *URx: ok = True len(payload) = 101* > *Tx: len(payload) = 90* > *Tx: len(payload) = 54* > *UTx: len(payload) = 220* > *UTx: len(payload) = 326* > *URx: ok = False len(payload) = 326* > *Tx: len(payload) = 81* > *UTx: len(payload) = 326* > *UTx: len(payload) = 326* > *UTx: len(payload) = 302* > *URx: ok = False len(payload) = 302* > *Tx: len(payload) = 78* > *UTx: len(payload) = 220* > *URx: ok = False len(payload) = 220* > *Tx: len(payload) = 81* > *UTx: len(payload) = 302* > *URx: ok = False len(payload) = 302* > *Tx: len(payload) = 70* > *UTx: len(payload) = 110* > *UTx: len(payload) = 240* > *URx: ok = False len(payload) = 240* > *Tx: len(payload) = 404* > *Tx: len(payload) = 201* > *UTx: len(payload) = 101* > *UTx: len(payload) = 404* > *Tx: len(payload) = 201* > *Tx: len(payload) = 54* > *UTx: len(payload) = 404* > *Tx: len(payload) = 201* > *Tx: len(payload) = 114* > *UTx: len(payload) = 380* > *Tx: len(payload) = 189* > *Rx: ok = False len(payload) = 380* > *UTx: len(payload) = 240* > *UTx: len(payload) = 101* > *UTx: len(payload) = 318* > *UTx: len(payload) = 81* > *UTx: len(payload) = 380* > *Tx: len(payload) = 189* > *Rx: ok = False len(payload) = 380* > *URx: ok = False len(payload) = 189* > *Tx: len(payload) = 302* > *UTx: len(payload) = 90* > *UTx: len(payload) = 350* > *UTx: len(payload) = 101* > *UTx: len(payload) = 380* > *Tx: len(payload) = 189* > *Rx: ok = False len(payload) = 380* > *UTx: len(payload) = 70* > *UTx: len(payload) = 81* > *UTx: len(payload) = 101* > *UTx: len(payload) = 70* > *UTx: len(payload) = 42* > *UTx: len(payload) = 42* > *UTx: len(payload) = 42* > *URx: ok = True len(payload) = 81* > *Tx: len(payload) = 42* > *UTx: len(payload) = 42* > *URx: ok = True len(payload) = 101* > *Tx: len(payload) = 42* > *UTx: len(payload) = 81* > *UTx: len(payload) = 42* > *URx: ok = False len(payload) = 42* > *Tx: len(payload) = 101* > *UTx: len(payload) = 42* > *URx: ok = False len(payload) = 42* > *Tx: len(payload) = 42* > *URx: ok = False len(payload) = 42* > *Tx: len(payload) = 42* > *URx: ok = False len(payload) = 42* > *Tx: len(payload) = 42* > *URx: ok = False len(payload) = 42* > *Tx: len(payload) = 42* > *UTx: len(payload) = 42* > *URx: ok = False len(payload) = 42* > *Tx: len(payload) = 42* > *UTx: len(payload) = 42* > *UTx: len(payload) = 42* > *URx: ok = False len(payload) = 42* > *Tx: len(payload) = 42* > *UTx: len(payload) = 42* > *UTx: len(payload) = 42* > *UTx: len(payload) = 42* > *URx: ok = False len(payload) = 42* > *Tx: len(payload) = 42* > *URx: ok = False len(payload) = 42* > *Tx: len(payload) = 81* > *UTx: len(payload) = 101* > *URx: ok = True len(payload) = 81* > *Rx: ok = True len(payload) = 101* > > > On Mon, Jun 18, 2012 at 11:01 AM, Weixian Zhou <idea...@gmail.com> wrote: > >> Hi Alex, >> After tried many times I found that the transmitter actually received >> packages of len(payload)=42 from the receiver, but the the packages failed >> CRC check (ok=false). I think some parameters need to be tuned, maybe >> bitrate? >> >> On Mon, Jun 18, 2012 at 10:21 AM, Weixian Zhou <idea...@gmail.com> wrote: >> >>> Hi Alex, >>> I tried it. The problem is the same. The transmitter only showed tx >>> message of len(payload) = 42, and the receiver showed both tx/rx messages >>> of len(payload) = 42. >>> >>> >>> On Fri, Jun 15, 2012 at 6:43 PM, Alex Zhang <cingular.a...@gmail.com>wrote: >>> >>>> Weixian, >>>> >>>> Could you please try the ping command like this (if you are working on >>>> linux): >>>> >>>> *sudo ping 192.168.200.2 -i 0.01* >>>> >>>> -i 0.01 means the time interval between pings is 0.01 second. And tell >>>> me what happened. >>>> You can try different time intervals. >>>> >>>> >>>> On Fri, Jun 15, 2012 at 5:37 PM, Alex Zhang <cingular.a...@gmail.com>wrote: >>>> >>>>> I did the test by myself, and the most of the time ARP queries >>>>> failed.... I met this problem when I do the OFDM link test, but that is >>>>> because the physical layer is not robust. But for this narrow band (GMSK) >>>>> modulation, I am not sure what the problem is. >>>>> >>>>> May Josh knows... :) >>>>> >>>>> >>>>> On Fri, Jun 15, 2012 at 3:05 PM, Alex Zhang >>>>> <cingular.a...@gmail.com>wrote: >>>>> >>>>>> Something like discarded. >>>>>> >>>>>> >>>>>> On Fri, Jun 15, 2012 at 11:59 AM, Weixian Zhou <idea...@gmail.com>wrote: >>>>>> >>>>>>> What do you mean by "it may be consumed"? >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 15, 2012 at 12:44 PM, Alex Zhang < >>>>>>> cingular.a...@gmail.com> wrote: >>>>>>> >>>>>>>> Did you see RX False at the receiver for the ARP reply? If that is >>>>>>>> not seen, it could be due to some reason causing the ARP reply is not >>>>>>>> sent >>>>>>>> out at all. Although you see the log for the TX packet in the CSMA >>>>>>>> mainloop, but it may be consumed before or when it goes to the >>>>>>>> transmitting path... >>>>>>>> >>>>>>>> On Fri, Jun 15, 2012 at 10:49 AM, Weixian Zhou >>>>>>>> <idea...@gmail.com>wrote: >>>>>>>> >>>>>>>>> Yes, the ARP is replied. But another machine did not received and >>>>>>>>> showed "Destination Host Unreachable". >>>>>>>>> >>>>>>>>> On Fri, Jun 15, 2012 at 11:19 AM, Alex Zhang < >>>>>>>>> cingular.a...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Do you check the ARP reply is sent out or not? >>>>>>>>>> I am not sure if there are some flow control issues for the >>>>>>>>>> networking. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Jun 15, 2012 at 10:02 AM, Weixian Zhou <idea...@gmail.com >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> Thanks for responses. The problem that confused me is that when I >>>>>>>>>>> on machine A: >>>>>>>>>>> *sudo ./tunnel.py --tx-freq=2.51G --rx-freq=2.515G -c 50 -r >>>>>>>>>>> 0.5M * >>>>>>>>>>> then >>>>>>>>>>> *sudo ifconfig gr0 192.168.200.1* >>>>>>>>>>> >>>>>>>>>>> on machine B: >>>>>>>>>>> *sudo ./tunnel.py --tx-freq=2.515G --rx-freq=2.51G -c 50 -r >>>>>>>>>>> 0.5M * >>>>>>>>>>> then >>>>>>>>>>> *sudo ifconfig gr0 192.168.200.2* >>>>>>>>>>> >>>>>>>>>>> I can see packages tx/rx succeed on both machines. But the ping >>>>>>>>>>> failed and one machine did not rx. Why is that? >>>>>>>>>>> >>>>>>>>>>> On Thu, Jun 14, 2012 at 4:38 PM, Alex Zhang < >>>>>>>>>>> cingular.a...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Most likely you did not set the freq and gain properly. >>>>>>>>>>>> Unstable physical layer communications cause the ARP routing >>>>>>>>>>>> failure. >>>>>>>>>>>> Please use different frequencies for tx and rx. >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jun 14, 2012 at 1:51 PM, Weixian Zhou < >>>>>>>>>>>> idea...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I was testing with tunnel.py and following the instructions in >>>>>>>>>>>>> README located in gnuradio/gr-digital/examples/narrwoband. >>>>>>>>>>>>> I found that when I input* ifconfig gr0 192.168.200.1* on >>>>>>>>>>>>> machine A, and input* ifconfig gr0 192.168.200.2* on machine >>>>>>>>>>>>> B at the same time, both machines showed Tx and Rx packages. >>>>>>>>>>>>> But when I* ping 192.168.200.2* from machine A ( or *ping >>>>>>>>>>>>> 192.168.200.1* from machine B respectively), one window of >>>>>>>>>>>>> machine A only showed Tx packages and another window showed >>>>>>>>>>>>> "Destination >>>>>>>>>>>>> Host Unreachable". Machine B showed both Rx/Tx packages. >>>>>>>>>>>>> It means that machine B can successfully received packages >>>>>>>>>>>>> from machine A but A failed to receive replied packages from >>>>>>>>>>>>> machine B. It >>>>>>>>>>>>> confused me that the packages tx/rx were succeed before the ping. >>>>>>>>>>>>> Anyone >>>>>>>>>>>>> has idea? >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Weixian Zhou >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Discuss-gnuradio mailing list >>>>>>>>>>>>> Discuss-gnuradio@gnu.org >>>>>>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> Alex, >>>>>>>>>>>> *Dreams can come true – just believe.* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Regards, >>>>>>>>>>> Weixian Zhou >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> Alex, >>>>>>>>>> *Dreams can come true – just believe.* >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Regards, >>>>>>>>> Weixian Zhou >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Alex, >>>>>>>> *Dreams can come true – just believe.* >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Weixian Zhou >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Alex, >>>>>> *Dreams can come true – just believe.* >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Alex, >>>>> *Dreams can come true – just believe.* >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Alex, >>>> *Dreams can come true – just believe.* >>>> >>>> >>> >>> >>> -- >>> Regards, >>> Weixian Zhou >>> >>> >>> >> >> >> -- >> Regards, >> Weixian Zhou >> >> >> > > > -- > Regards, > Weixian Zhou > > > -- Alex, *Dreams can come true – just believe.*
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
