Thanks, Ian. I appreciate the explanation.
Certainly I’ve understood the idea of late as it was inevitable that while developing and testing my TDMA MAC I made mistakes and scheduled packets for transmission in the past :0) The underflow is a little more mysterious. At the request of Nate, a sensible person, I’ve created a program to illustrate the problem; see attached. Running it with the X310 connected to an Octoclock G for 1 PPS and 10 MHz, I have it transmit a 20000 sample packet every 10 ms at 20 MSps. It manages to do that for about 1727 seconds before underflow happens and then it basically blocks. Running it with a B200mini and all the same conditions/parameters, it has been going now for more than 8800 seconds. It is purely speculative on my part, but I have to wonder if somehow there is a time problem, say where the clock discipline algorithm of the X310 induces a jump in time. However, I made another test program where I get host and USRP time once every second and compare. Over the course of an hour for the X310 the time difference was pretty much constant, about the difference in time it takes to execute the get_time_now() command for the X310. So, that kind of suggests the clock is pretty stable, or maybe I didn’t wait long enough... I am kind of confident that the B200mini will keep going because, as mentioned below, it ran with the full Tx-Rx version of the program for more than 5 hours before I killed the program. Maybe you will be able to suggest something to help me get to the bottom of this :0) thanks! steven On February 8, 2018 at 23:57:57, Ian Buckley ([email protected]) wrote: Steven Underflow is a TX error phenomena, not an RX one. It is signaled when the local buffering of TX data in the USRP becomes empty whilst the USRP tries to continue to transmit. Late, on the other hand, is signaled when a TX command contains a time that is later than the USRP’s local clock when it is executed. Hope this is helpful, -Ian On Feb 8, 2018, at 1:33 PM, Steven Knudsen via USRP-users <[email protected]> wrote: Hi, I have been scratching my head for a while on this one… I have made a TDMA radio that has a simple 4 slot cycle with a relatively low duty cycle (slots are 40% and the remaining 60% of the cycle the USRP is idle). A radio transmits in it’s “owned” slot and receives in all others (3 of them). The transmit is timed as are the receptions in each slot. Transmit is schedule 10 ms in advance (at the start of a cycle) and the receives are scheduled at least 6 ms in advance (at the end of the last receive slot). When I test with a B200mini connected to an Octoclock G for 1 PPS reference, it runs flawlessly for hours (5 is the longest). When, on the exact same Linux host I run with an X310 connected to the same Octoclock G for 1 PPS and 10 MHz, it stops working after not too long with a slew of ’U’s and ’L’s Trying to narrow things down, I created a version fo the radio that only transmits. Reception is completely disabled and I confirm that no receive commands are ever scheduled and rxStreamer->recv() is never called. So, imagine my surprise when after a fairly long time of transmitting successfully (evidenced by using an oscilloscope to view packets), the transmit-only version fails!?! Below is a copy o the log showing the first evidence of failure, namely ’L’s indicating transmits were too late. But, what is the ‘U’ doing there? As I mentioned, no reception functionality is in the program, so what is going on? Anyone else see this kind of thing? I never see it with the B200mini, but see it consistently with the X310. thanks very much for your time and consideration, steven ULLsendFrame() MPDU #719935 mpdu size = 488 bytes at 1518123481s 890000 us ULLLsendFrame() MPDU #719936 mpdu size = 488 bytes at 1518123481s 900000 us ULLLLsendFrame() MPDU #719937 mpdu size = 488 bytes at 1518123481s 910000 us ULLLLLsendFrame() MPDU #719938 mpdu size = 488 bytes at 1518123481s 920000 us ULLLLLLsendFrame() MPDU #719939 mpdu size = 488 bytes at 1518123481s 930000 us ULLLLLLLsendFrame() MPDU #719940 mpdu size = 488 bytes at 1518123481s 940000 us ULLLLLLLLsendFrame() MPDU #719941 mpdu size = 488 bytes at 1518123481s 950000 us ULLLLLLLLLsendFrame() MPDU #719942 mpdu size = 488 bytes at 1518123481s 960000 us ULLLLLLLLLLsendFrame() MPDU #719943 mpdu size = 488 bytes at 1518123481s 970000 us ULLLLLLLLLLLsendFrame() MPDU #719944 mpdu size = 488 bytes at 1518123481s 980000 us ULLLLLLLLLLLLsendFrame() MPDU #719945 mpdu size = 488 bytes at 1518123481s 990000 us ULLLLLLLLLLLLLsendFrame() MPDU #719946 mpdu size = 488 bytes at 1518123482s 0 us ULLLLLLLLLLLLLsendFrame() MPDU #719947 mpdu size = 488 bytes at 1518123482s 10000 us ULLLLLLLLLLLLLLsendFrame() MPDU #719948 mpdu size = 488 bytes at 1518123482s 20000 us ULLLLLLLLLLLLLLLsendFrame() MPDU #719949 mpdu size = 488 bytes at 1518123482s 30000 us ULLLLLLLLLLLLLLLLsendFrame() MPDU #719950 mpdu size = 488 bytes at 1518123482s 40000 us ULLLLLLLLLLLLLLLLLsendFrame() MPDU #719951 mpdu size = 488 bytes at 1518123482s 50000 us ULLLLLLLLLLLLLLLLLLsendFrame() MPDU #719952 mpdu size = 488 bytes at 1518123482s 60000 us ULLLLLLLLLLLLLLLLLLLsendFrame() MPDU #719953 mpdu size = 488 bytes at 1518123482s 70000 us Steven Knudsen, Ph.D., P.Eng. www. techconficio.ca www.linkedin.com/in/knudstevenknudsen All the wires are cut, my friends Live beyond the severed ends. Louis MacNeice _______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
tx_timed_loop.cpp
Description: Binary data
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
