Guy, Thanks for trying out pre-cog. I am glad you got it working, despite the poor documentation. Its worth mentioning that there's an effort to incorporate some of the functionality of pre-cog into gnuradio.
"sample rate is set to 256000, any other value didn't work, but" What does it mean when it "didn't work? Did the application produce an error? Or did you just never see data transfer between the two radios? Are you seeing any "L's" in the output of the program by any chance? You might also increase the "lead limit", which is the amount of time in advance of the transmission the flowgraph actually sends the data to the USRP. Also, I assume you are actually running two instances of this program. Can copy the command line w/ parameters that you are using into your next e-mail? -John On Mon, Jun 3, 2013 at 12:34 PM, Guy Holtzman <hol...@gmail.com> wrote: > I started to work on making the TDMA work on two B100s with WBX I have. > I have them connected to a common 1 pps (rubidium based clock refrance) > and 10MHz clock > the computer I am working in is a bit old, dell latitude 620, with ubuntu > 12.04 LTS > I have all the latest software installed > the simple mac (without TDMA) from the pre-cog examples dir works fine > with a one exception: > the sample rate is set to 256000, any other value didn't work, but this is > not related to the MAC since even with a simple FM example the default > sample rate (1e6) did not work. > my other problem is that the slot size on 10 ms did not work at all, and > increasing the slot size to 40ms worked, but with many problems. one on > them was underflow occurred almost always. > how can I set the parameters to suit my B100 and my "not state of the art" > computer? > how can I solve the sample rate problem? the problem is not related to the > rate itself since 250000 does not work while 256000 does work (and they > both divide by 64MHz with an even result, the clock I am using) > > Thanks, Guy > > > > > On Wed, Jan 23, 2013 at 10:46 PM, Guy Holtzman <hol...@gmail.com> wrote: > >> Yes, Thanks >> >> >> On Wed, Jan 23, 2013 at 8:33 PM, Josh Blum <j...@ettus.com> wrote: >> >>> >>> >>> On 01/23/2013 12:18 PM, Guy Holtzman wrote: >>> > Hi Again, and thanks for you answer :) . (I was out yesterday, so I >>> did not >>> > see your answer) >>> > >>> > As I understood the lead time is a jitter buffer inside the USRP, which >>> > buffers the samples before it launches them to the air. This buffer is >>> > limited by the FPGA memory. for example, if one configures the lead >>> time >>> > to a too large number, it will cause an over run. >>> > since B100 uses a smaller FPGA, and does not have SRAM memory, is it >>> > possible that the lead time that could be configured is limited to a >>> number >>> > which is smaller than the jitter? I know it depends on the host >>> computer >>> > and on the application running on it. in other words, is there >>> > a reasonable margin to play with? >>> >>> Actually its the opposite, too little, and you would see an underflow. >>> Too large, lets say to buffer on the device, then the production of >>> transmit samples backs up onto the host, so its a non issue. >>> >>> > >>> > could you please send the Presentation file which is seen on the >>> video, it >>> > cannot be found on git. >>> > >>> >>> This presentation? >>> >>> https://github.com/guruofquality/grextras/blob/f02da842d31c55c44510117efa0ba5f82e2fca90/pre_cog_pres.pdf >>> >>> -josh >>> >>> >>> > Thanks Again, >>> > Guy >>> > >>> > >>> > On Mon, Jan 21, 2013 at 9:09 PM, John Malsbury < >>> john.malsb...@ettus.com>wrote: >>> > >>> >> Guy, >>> >> >>> >> Sorry for the the delayed response. You seem to have a reasonable >>> >> understanding of the way timestamps and tags are working in GNU Radio. >>> >> >>> >> Here's a basic overview of how the pre-cog TDMA block works. To get a >>> >> sense of time the block reads samples from a UHD source. When >>> streaming >>> >> starts, the UHD source block issues a rx_time and rx_rate tags. After >>> >> receiving these tags, the block will count sample to maintain >>> knowledge of >>> >> the USRP time. >>> >> >>> >> The block will schedule a transmission to occur based on several >>> >> parameters - slot interval and count, guard interval, etc. To ensure >>> that >>> >> the tagged samples arrive to the USRP DSP chains before the transmit >>> time >>> >> passes, the block will produce the frame and output sometime before >>> that >>> >> transmit time. The parameter 'lead_limit' sets how far in advance the >>> >> block will produce the frame, and should be set to the worst case >>> delay >>> >> caused by process timing jitter on the host and interface latency. >>> IIRC, >>> >> I've tested this with 1-5 ms slots, 2-10 slots per frame, and a lead >>> limit >>> >> of about 5 ms with the USRP N210. Typical data rates I tested were >>> >> between 250 kbps to 1 mbps. You might specify a different lead >>> limit with >>> >> the B100. >>> >> >>> >> The demo I've run uses 1 PPS to sync the USRPs. In theory, with a few >>> >> small modifications, you could set the USRP time based on time of >>> received >>> >> frames instead. You will need to understand and account for >>> additional >>> >> latency when you set the time of the USRPs, and your guard intervals >>> will >>> >> probably need to be larger. >>> >> >>> >> This TDMA implementation is mostly a proof-of-life. I'll be glad to >>> help >>> >> you get something running, and can advise on worthwhile improvements >>> to >>> >> this implementation. Porting to C++ is one obvious suggestion to >>> improve >>> >> performance. >>> >> >>> >> -John >>> >> >>> >> >>> >> >>> >> On Mon, Jan 21, 2013 at 6:16 AM, Guy Holtzman <hol...@gmail.com> >>> wrote: >>> >> >>> >>> I am thinking of developing a TDMA MAC + PHY using GNURadio for low >>> speed >>> >>> communication (upto 200KBits per second) for prototyping. since >>> OpenBTS >>> >>> has successively implemented a GSM BS using GNURadio, this seems to >>> be >>> >>> a reasonable choice. but unlike OpenBTS, I want to avoid HW (clock >>> changes) >>> >>> or FPGA programming and develop only on the GNURadio Platform. >>> >>> >>> >>> recently I have seen the pre-cog (or EasyMAC) project presentation >>> using >>> >>> the USRP N210: >>> >>> www.youtube.com/watch?v=pF_4dFQHAZE >>> >>> >>> >>> wiki: >>> >>> https://github.com/jmalsbury/pre-cog/wiki >>> >>> >>> >>> as I understood (and you are welcomed to correct me if I am wrong), >>> UHD >>> >>> provides a timestamp (and tags) functionality for sending IQs and >>> >>> for receiving IQs, so all the latency and jitter problems will >>> likely come >>> >>> from the host side (Drivers and GNU Radio application) >>> >>> since I do not need high speed data, the USB speed is more than >>> enough. I >>> >>> do not know what limitations I will experience using this platform. >>> >>> >>> >>> I don't have any USRP devices on my hands yet, due to that fact I >>> have a >>> >>> few questions regarding the use of USRP B100 (and not USRP N210): >>> >>> >>> >>> 1. What will be the expected latency using USB what will be the >>> >>> maximum jitter (unexpected latency)?, I have read the FAQ, but >>> it is too >>> >>> theoretical, and the paper from 2007 could be out of date ( >>> >>> http://gnuradio.org/redmine/projects/gnuradio/wiki/UsrpFAQLatency) >>> >>> 2. The USRP1 had accuracy problems with the clock when using >>> OpenBTS, >>> >>> was this problem solved with USRP B100? in other words, could two >>> or more >>> >>> USRPs work on a TDMA network without an external common clock? >>> >>> 3. what will be the minimum acceptable time slot duration on a >>> system >>> >>> that does not require ACK mechanism? >>> >>> 4. on a system that requires ACK response what would be a minimum >>> >>> considerable time from a packet being sent until the ACK is >>> received? >>> >>> 5. Are the timestamps for Rx and Tx on the same USRP correlated? >>> >>> 6. Are there any other considerations which can prevent EasyMAC >>> or a >>> >>> similar implementation from working? >>> >>> 7. I know GNU Radio is not a true Real-time platform when running >>> on >>> >>> linux General Purpose CPUs, how will this effect the TDMA? >>> >>> >>> >>> Thank you very much, and sorry for the long email :) >>> >>> >>> >>> Regards, Guy >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >>> >> >> > > _______________________________________________ > 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
