Re: [Discuss-gnuradio] precise transmit scheduling
Thank you so much for your reply, Steven. I tried to use gr.message_source to push the new data into the msg_queue? As my understanding, the msg_queue push new data by using msg_queue.insert_tail(gr_message_sptr msg. The new data pushed into the msg_queue need to be the type of gr_message_sptr. How can I convert my binary Barker code of this message type?The data I'm trying to sent bit-by-bit is a binary sequence Barker code, like 5-bit Barker: 1,1,1,0,1. When I sent them together as a whole sequence, I used vector_source_s directly write them as vector. In order to sending them bit-by-bit, how can I push this sequence in to the msg_queue bit-by-bit?Thank you so much for your help!Sincerely,YanOn 11/04/10, Steven Clark steven.p.cl...@gmail.com wrote:On Thu, Nov 4, 2010 at 5:33 PM, Yan Nie yn...@uwo.ca yn...@uwo.ca wrote: Dear all,I am developing a transmitter on USRP1 with LFTX daughterboard. This transmitter sends a BPSK modulated Barker code sequence up-converting to a frequency ranging from 1MHz to 20MHz. I implemented the transmission of the whole sequence in one fixed frequency in the requried range on one USRP1 board and receiving on the other USRP1 board. My question is :How can I scheduling the transmitter by sending several bits of the sequence a time and the delays between each time transmitting are 1ms?How can the RF frequency be linearly hopping from 1MHz to 20MHz by secheduling? I've seen that m-blocks appears partially motivated by precise scheduling of transmission. Is the m-block implements is suitable for this scheduling? If so, could anyone give me any suggestion on how can it implement the scheduling for my project? Tons of thanks in advance! I really need your help with this scheduling. Sincerely,YanI am also very interested in this. I have had some success by using gr.message_source, and having a python thread that periodically pushes new data into the system by putting it on the message queue. Transmitter auto_tr is enabled so that when the usrp runs out of data it turns off the transmit until the next message arrives. Scheduling at the python level seems very rough, with intervals varying ~+/- 1ms without tuning each time, and ~+/- 10ms when tuning before each burst. I was under the impression that calling set_rx_freq() to tune just the DUC rather than usrp.tune() should be faster/more responsive, but I haven't seen this to be true... Any scheduling / hopping tips would be greatly appreciated!-Steven attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] precise transmit scheduling
Dear all,I am developing a transmitter on USRP1 with LFTX daughterboard. This transmitter sends a BPSK modulated Barker code sequence up-converting to a frequency ranging from 1MHz to 20MHz. I implemented the transmission of the whole sequence in one fixed frequency in the requried range on one USRP1 board and receiving on the other USRP1 board. My question is :How can I scheduling the transmitter by sending several bits of the sequence a time and the delays between each time transmitting are 1ms?How can the RF frequency be linearly hopping from 1MHz to 20MHz by secheduling?I've seen that m-blocks appears partially motivated by precise scheduling of transmission. Is the m-block implements is suitable for this scheduling? If so, could anyone give me any suggestion on how can it implement the scheduling for my project? Tons of thanks in advance! I really need your help with this scheduling.Sincerely,Yan attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] precise transmit scheduling: GNUradio state-of-the-art?
Hi, (get your reading glasses on ;)) The m-block is the place to start, as it is completely motivated by what you want to accomplish. The BBN document, which I think you've found, details everything about the m-block which Eric has stuck pretty much exactly to. The m-block is completely useable, as I've been using it for the past couple of months now. I think it is supposed to be released in 3.1. Eric has merged it in to the trunk. I sent a similar mail to the mailing list that I wanted to build a MAC protocol with tight timing issues, and the m-block is great on the GNU Radio end for this... but the USRP and communication between it and GNU Radio is not quite ready for it. So what you want out of packet processing is variable length packets, high priority packets, some packet level control over the radio, and the ability for very precise scheduling of packets. The current FPGA code is setup to be very 'streaming' based. GNU Radio communicates with the USRP using fixed sized blocks which are interpreted *completely* as samples, and streamed right out. While the m-block can do variable length packets, prioritize packets, set timestamps on packets, etc... the USRP has no clue what in the world this is. There is a strong need for a platform to completely build and evaluate a mac protocol from scratch, and software-radios are great for it. Kind of like SoftMAC, but a much cleaner slate to begin with. Wanting to build a MAC on the platform, and the need for this... I decided to take up the in-band signaling project with Eric, Thibaud, and Brian. The goal of in-band signaling is to bridge the gap between GNU Radio / m-block and the USRP. We've been working on it since February, and we're making nice progress. I've been hacking up the GNU Radio end, creating an interface between the application and the USRP. It is pretty close to useable. Right now it can open a connection to the USRP under control of an m-block, receive m-block packets and fragment them in to lower level USB blocks to burst over the USB bus, interpret C/S packets, and receive data back from the USB bus and recreate m-block packets. Thibaud and Brian have done great work on the FPGA code... decoding the new USB packets, reading the packet headers appropriately, stripping out the data and transmitting it, and receiving samples and reconstructing USB blocks and passing them back up to GNU Radio. Documentation of the USB packets we are using to communicate are here: http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb You'll see that there are control status packets which will be used to control the radio on a per packet basis or do register read/writes on the USRP. I have implemented this functionality in GNU Radio, but the FPGA code to parse these control/status packets are still being worked on. The other major thing that needs done is synchronization of a logical timer between the USRP and GNU Radio. This is needed for timestamps. Once the FPGA can interpret and send me back a ping response, I am going to work on synchronizing the two. All of the in-band code is being worked on in developer branches and branches/features/inband-usb is where we merge our changes. I have written some test applications for the basic TX and RX with in-band signaling: http://gnuradio.org/trac/browser/gnuradio/branches/developers/gnychis/inband/usrp/host/apps/test_usrp_inband_tx.cc http://gnuradio.org/trac/browser/gnuradio/branches/developers/gnychis/inband/usrp/host/apps/test_usrp_inband_rx.cc The TX application is written as m-blocks where it generates a sine wave and builds m-block packets, then passes these packets to USRP server which does all the in-band signaling magic. It's a great example of how the m-block works and how it communicates with in-band signaling. Likewise, the RX reads incoming samples. Using two USRPs, the TX application can transmit a sine wave, and the RX application can receive the sine wave... all using the in-band signaling. All transmissions are timestamped as 'NOW' (0x). As for the FPGA code, I don't think that we have an RBF file somewhere in the repository to use. Thibaud and Leo have been custom building them from code in their developer branches. If you are keen on using it, I can have them build an RBF for you. So in summary, we're close... we're very close. But it's not complete. I would think by the beginning of August we will have something working pretty nicely. If you have any questions feel free to contact me... there are tons of details that I'm kind of glossing over but we can definitely discuss. - George Brad Karp wrote: [Re-sending, as prior post appeared not to hit the list...] Greetings, all. I should preface this question by confessing that I'm new to the USRP hardware and the gnuradio software. My students and I have only just started hacking on 4 USRPs with 2.4 GHz
Re: [Discuss-gnuradio] precise transmit scheduling: GNUradio state-of-the-art?
George Nychis wrote: The m-block is the place to start, as it is completely motivated by what you want to accomplish. The BBN document, which I think you've found, details everything about the m-block which Eric has stuck pretty much exactly to. The m-block is completely useable, as I've been using it for the past couple of months now. I think it is supposed to be released in 3.1. Eric has merged it in to the trunk. [...] So in summary, we're close... we're very close. But it's not complete. I would think by the beginning of August we will have something working pretty nicely. The basic mblock code will indeed be in release 3.1. However, as you mention, the modified USRP code to take advantage of it will not be ready. Other 'convenience' code to pass data back and forth between gr_blocks and mblocks will not be complete either. So it will be useful for experimentation to learn how mblocks function, but not suitable for use with the USRP until 3.2 release. Of course, all the code is available in the development trunk for anyone to use (once it gets merged from the developer branches.) -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] precise transmit scheduling: GNUradio state-of-the-art?
Have you looked into real-time versions of the Linux kernel? I've used real-time Linux to control devices at the microsecond level. (We were generating pluses directly control a CCD chip and move charge on the chip.) I think you are going to have to find a way to combine gnuradio and one of the real-time linux systems. Real time Linux is pretty easy to use. This has more info and Google will turn up even more. http://www.linuxdevices.com/articles/AT4503827066.html --- Brad Karp [EMAIL PROTECTED] wrote: [Re-sending, as prior post appeared not to hit the list...] Greetings, all. I should preface this question by confessing that I'm new to the USRP hardware and the gnuradio software. My students and I have only just started hacking on 4 USRPs with 2.4 GHz daughterboards here in lab. We'd like to use the platform to build a MAC protocol prototype. As I know has been widely discussed in the gnuradio community, link-layer acknowledgements require fairly precise timing of transmissions. For example, the receiver of a data packet must delay a very short interval before sending an ACK for the packet received (e.g., on the order of 50 us). My question: What's the state of the art in precise scheduling of transmissions for gnuradio? I'm looking for building blocks I can use that will allow fairly precise scheduling of packet transmissions despite the 10 ms process scheduling granularity of Linux. I've seen in the archives of this list that BBN's work on m-blocks appears at least partly motivated by precise scheduling of transmissions. And other list traffic suggests that m-blocks are being more broadly adopted; e.g., mail from Eric Blossom suggesting that he was enhancing the m-block code further, perhaps with the eventual goal of merging m-blocks into the core gnuradio distribution. Is the m-block implementation in a state where my students and I could use the code to schedule packet transmissions in the MAC protocol we're implementing? Are there other implementations of precise packet transmit scheduling anyone can point me to? Many thanks, -Brad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Chris Albertson Home: 310-376-1029 [EMAIL PROTECTED] Office: 310-336-5189 [EMAIL PROTECTED] KG6OMK/AG Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
