[Discuss-gnuradio] how to get bootable cd of gnuradio
hi everyone.tell me how to get the bootable cd of gnuradio .is there available or not.please reply me sooner___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] using general_work when output rate is not fixed
-- Forwarded message --
From: Adeel Anwar
Date: Wed, Sep 26, 2012 at 3:52 AM
Subject: Re: [Discuss-gnuradio] using general_work when output rate is not
fixed
To: "Rahman, Muhammad Mahboob Ur"
Mahboob,
uhd usrp sink. Now, the other issue is, when I send pre-recorded GMSK
samples to the uhd usrp sink, I still see lot of underruns occuring
If ur aim is to TX discontinuous samples with SOB and EOB tags to avoid
under-flows then
1. pre-recorded GMSK samples can be sent using gr_message_burst_source
http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeLogV3_6_2
2. u can take following gr-uhd example as a reference and modify it
http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/entry/gr-uhd/examples/c++/tag_source_demo.h
-Adeel
On Tue, Sep 25, 2012 at 12:02 PM, Rahman, Muhammad Mahboob Ur <
mahboob-rah...@uiowa.edu> wrote:
> Hi Tom & All,
>
> I am now doing consume_each(noutput_items) but my problem is not solved
> yet. I have also made sure that my code effectively sends one sob tag and
> one eob tag per burst of samples.
>
> Questions about new experiment:
> Now, I have created yet another simple experiment whose flow-graph is as
> follows:
>
> uhd usrp source --> my custom block --> uhd usrp sink
>|
>--> file sink
>
> The relevant code of my custom block is below:
> int
> howto_send_discont::general_work (...) {
>
> int ninput_items_used_in_this_work_call;
> ninput_items_used_in_this_work_call = 0;
>
> for (int i = 0; i < noutput_items; i++){
>
> samp_count++;
> if (samp_count == 1) { out[i] = gr_complex(0.7,0);
> this->make_sob_tag(this->nitems_written(0)+i);}
> else if (samp_count == 2) { out[i] = gr_complex(0.7,0);
> this->make_eob_tag(this->nitems_written(0)+i);}
> else if (samp_count == 25000) {
> samp_count = 0; send_tx_pkt = true; pkt_no++; }
> if (send_tx_pkt) {
> pkt_samp_no++;
> ninput_items_used_in_this_work_call++;
> /*if (total_samps_outputted_so_far == 7761) {
>pkt_samp_no = 1; samp_count = 1;
> total_samps_outputted_so_far = 1; pkt_no = 0; }
> else if (total_samps_outputted_so_far < 7761){
>total_samps_outputted_so_far++; }*/
> out[i] = gmsk_pkt_samples_2[pkt_samp_no-1];
> if (pkt_samp_no == 1) {
> this->make_sob_tag(this->nitems_written(0)+i);
> }
> else if (pkt_samp_no == 1536) {
> this->make_eob_tag(this->nitems_written(0)+i);
> pkt_samp_no = 0;
> send_tx_pkt = false;
> }
> }
>
> }
>
> consume_each (noutput_items);
>
> // Tell runtime system how many output items we produced.
> return ninput_items_used_in_this_work_call;
> }
>
> You can see from the above code that my custom block maintains an internal
> counter samp_count which causes the custom block to output N samples
> whenever internal counter's count equals M (N=1536, M=25000 in my case). I
> use the same counter to initially send a burst of 2 samples to uhd usrp
> sink after attaching sob and eob tags so as to avoid underflow problem at
> the transmit side. But my problems are persistent which are:
>
> - I see many zero-valued samples among the first 7761 output samples of my
> custom block, even when the samples my custom block should output are
> either constant valued samples or pre-recorded GMSK samples (depending upon
> which line is uncommented in my above code). Why it is so?
>
> - Even though I have avoided the above mentioned problem by noticing that
> in my case, after first 7761 samples, all the subsequent samples are
> correct. So, I use another counter to start all over again (to reset the
> functionality of my block) once my custom block has sent 7761 samples to
> uhd usrp sink. Now, the other issue is, when I send pre-recorded GMSK
> samples to the uhd usrp sink, I still see lot of underruns occuring
> indefinitely at tx side. Why are the sob and eob tags being ineffective?
> Moreover, when those GMSK packets are received at another node, the packet
> decode rate is too low over there (I guess not all of the samples
> corresponding to many GMSK packets are being transmitted from node1, fix
> me).
>
>
> Thanks in anticipation for your help,
> Mahboob
> ___
> 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
Re: [Discuss-gnuradio] Reg : WCDMA data
Finally recorded it with my newly arrived SBX -- View this message in context: http://gnuradio.4.n7.nabble.com/Reg-WCDMA-data-tp37711p37753.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to get bootable cd of gnuradio
Iso image of Ubuntu+Gnuradio installed inside a vmware player ... is this what you want ? Its easy and you can make by yourself :) -- View this message in context: http://gnuradio.4.n7.nabble.com/how-to-get-bootable-cd-of-gnuradio-tp37751p37754.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 8-channel receiver
I have a quick theoretical question. Is there any way to construct an 8-channel receiver using 4 USRPS without data going through the host computer? Basically some kind of way to daisy chain mimo cables (though I know this is not possible), or at least get the same benefits you would receive from daisy chaining mimo cables, without using a switch or network connections. Thank you, Anisha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 8-channel receiver
Clarification: This would be using USRP N210, not USRP1, where I know it is possible to have an 8 channel receive or transmit only using a mimo cable. On Wed, Sep 26, 2012 at 12:38 PM, Anisha Gorur wrote: > I have a quick theoretical question. Is there any way to construct an > 8-channel receiver using 4 USRPS without data going through the host > computer? Basically some kind of way to daisy chain mimo cables (though I > know this is not possible), or at least get the same benefits you would > receive from daisy chaining mimo cables, without using a switch or network > connections. > > Thank you, > Anisha > > -- Anisha Gorur Class of 2012 Electrical Engineering ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP LO Relocation Latency
Dear gr / USRP fellows, I'm currently experimenting with USRP B100 Local Oscillator relocation time. I've done some experiments on the RX path by tuning towards and away from an OFDM beacon signal. I have flushed into the received signal some recognizable "relocation marks" which allowed me to analyze the received signal integrity in the temporal vicinity of the relocation instant. It looks like the LO responds to the steering command in some milliseconds to about two tens of millisecs, still "artifacts" such as unsuppressed, dominant carrier or unstable gain remain there for some hundreds of millisecs. I saw that the wiki states "perhaps a second" as the LO settling time. But can anybody confirm the above behaviour analysis ? best regards vince -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] simple ARQ MAC over TDMA; using GNU Radio and USRPs in GRC
Hey list, For those who were not at the GR Conference 2012: I presented some work demonstrating a simple ARQ MAC over TDMA; using GNU Radio and USRPs in GRC. Its very cool work, I encourage anyone to take a peek at the slides, and checkout the repo and run the examples. The MAC layer work is actually the work of John Malsbury (I'm just the messenger). He will be continually polishing and debugging the code over the next week or so. There should be a wiki page soon... So, I promised at the presentation that I would email the slides and the relevant information to checkout the repository. -- Here is the presentation (pdf format): https://github.com/guruofquality/grextras/blob/pre_cog/pre_cog_pres.pdf?raw=true -- Here are some teaser screenshots from the slides: http://i.imgur.com/HYgeb.png http://i.imgur.com/EvDof.png -- The code is available on the pre_cog branch of grextras: GRExtras main wiki page: https://github.com/guruofquality/grextras/wiki GitHub URL $ git clone https://github.com/guruofquality/grextras.git Check out this branch: $ git checkout pre_cog GRC flowgraphs are here: /examples/*.grc Contact j...@ettus.com j...@ettus.com *Note*: Users will have to generate the tdma hier block first, and then reload GRC to use the top level simple MAC block. Feedback is always welcome! -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 8-channel receiver
You can use a gigabit ethernet switch and put all the USRPs on there. You should be able to make USRPs send data to each other. You will of course need to do work to get your algorithms into the FPGA. Matt On Wed, Sep 26, 2012 at 12:38 PM, Anisha Gorur wrote: > I have a quick theoretical question. Is there any way to construct an > 8-channel receiver using 4 USRPS without data going through the host > computer? Basically some kind of way to daisy chain mimo cables (though I > know this is not possible), or at least get the same benefits you would > receive from daisy chaining mimo cables, without using a switch or network > connections. > > Thank you, > Anisha > > > ___ > 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
Re: [Discuss-gnuradio] Message passing - PSDU block and sink connection
On 09/26/2012 12:47 AM, Jose Torres Diaz wrote: > Hi, > > I've just finished my block that generates PSDUs and then, it transmits > downstream subscribers using message passing mechanism. I am using as a > sink "Extras: Blob to Socket", but when I run my flowgraph in GNU Radio > Companion (after connect my new block and the sink), I got the following > error: > > Traceback (most recent call last): > File "/home/usrpvm/Desktop/only_test_block/asrp/top_block.py", line 51, > in > tb = top_block() > File "/home/usrpvm/Desktop/only_test_block/asrp/top_block.py", line 33, > in __init__ > 0, 0, 0, 0, 0, 1, 1, 1) > TypeError: unbound method make() must be called with my_block instance as > first argument (got int instance instead) > I think the code getting generated is malformed. You might double check and the code in top_block.py -josh > I would really appreciate some help with this issue. Thanks a lot, > > Regards, > > Jose > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Reception Problem
On 09/26/2012 01:52 AM, Bilal wrote: > I m using USRP2,I have configured usrp2 and tested > uhd_usrp_probe,uhd_siggen_gui and uhd_fft all works fine. > Now i want to make my own program like uhd_fft but there is a problem that > the terminal prompt returns right after i execute the program with > notification > > root@aqs-desktop:/home/aqs/Desktop# python my_uhd_fft.py > linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.004.003-224-gc2e197c0 > > root@aqs-desktop:/home/aqs/Desktop# > > > my_uhd_fft.py program is: > > from gnuradio import uhd > from gnuradio import gr > from gnuradio.wxgui import stdgui2,fftsink2 > import wx > class top_block(stdgui2.std_top_block): > def __init__(self): > self.addr=uhd.device_addr() > self.u = uhd.usrp_source(self.addr,\ > uhd.io_type.COMPLEX_FLOAT32, 1) > self.u.set_samp_rate(4000) > self.scope = fftsink2.fft_sink_c (panel, \ > 512, 4000) > self.connect(self.u, self.scope) > if __name__ == '__main__()': > app = stdgui2.stdapp(top_block,"FFT",nstatus=1) > app.MainLoop() > I'm not 100% positive that the flow graph is actually started in this case. I highly recommend that you put a similar application together in GRC with USRP source and WX scope sink block. You will get nicely generated code too! -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to capture the Rx data using uhd_rx_cfile and agree with the uhd_fft Scope mode data
On 09/26/2012 01:36 AM, LD Zhang wrote: > Hi, > > I did try and made a GRC example of using a USRP Source and a fft sink, > scope sink, and a file sink to test out the idea. > > When looking at the scope sink, the data is about +/- 2x10^-4. I changed > the gain of the USRP source block to 20 dB. But nothing happened to the > signal amplitude. How is this possible? > You mentioned LFRX? There are no configurable gain elements for the LFRX daughterboard. If this helps, the various gain ranges are listed for various daughterboard frontends here: http://files.ettus.com/uhd_docs/manual/html/dboards.html#basic-rx-and-lfrx -josh > Please see the attached GRC if you want to see what I am doing. Thanks. > > LD > >> I could go directly to GRC GUI directly and try to learn to do everything >>> there. But I think there is value in being able to do this simple thing >>> from the command line. Your help and suggestions are appreciated. >>> >> >> I will second this motion. >> >> All of the hooks are available in the USRP source block, most of which >> can be changed at runtime with a simple variable widget. Its nice to >> change setting at runtime to see the effect. >> >> Also, you can easily attach a file sink and a scope sink and an fft >> sink. That way you know that you have captured to file the same thing >> you are observing. >> >> Also, be careful with the format of the file data. Its a binary array of >> std::complex, not float, not double, etc... >> >> -josh >> >> >> ___ >> 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
Re: [Discuss-gnuradio] USRP LO Relocation Latency
On 09/26/2012 01:00 PM, Vincenzo Pellegrini wrote: > Dear gr / USRP fellows, > > I'm currently experimenting with USRP B100 Local Oscillator relocation time. > I've done some experiments on the RX path by tuning towards and away from > an OFDM beacon signal. > > I have flushed into the received signal some recognizable "relocation > marks" which allowed me to analyze the > received signal integrity in the temporal vicinity of the relocation > instant. > > It looks like the LO responds to the steering command in some milliseconds > to about two tens of millisecs, > still "artifacts" such as unsuppressed, dominant carrier or unstable gain > remain there for some hundreds of millisecs. > > I saw that the wiki states "perhaps a second" as the LO settling time. > But can anybody confirm the above behaviour analysis ? It depends on the daughterboard. SBX and WBX have a worst case settling time of about 300us according to the ADI docs. You should also be able to schedule tuning through time commands so that the window of "interruption" is explicitly between time X and X + 300us. Here is some psudo code involving using timed commands to tune: http://files.ettus.com/uhd_docs/manual/html/sync.html#align-los-in-the-front-end-sbx-wbx-n-series -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] simple ARQ MAC over TDMA; using GNU Radio and USRPs in GRC
Hi Josh, A quick question, what is the time reference you are using for the TDMA engine? Is it GPS or something else? How accurate about the time synchronization? On Wed, Sep 26, 2012 at 1:31 PM, Josh Blum wrote: > Hey list, > > For those who were not at the GR Conference 2012: I presented some work > demonstrating a simple ARQ MAC over TDMA; using GNU Radio and USRPs in > GRC. Its very cool work, I encourage anyone to take a peek at the > slides, and checkout the repo and run the examples. > > The MAC layer work is actually the work of John Malsbury (I'm just the > messenger). He will be continually polishing and debugging the code over > the next week or so. There should be a wiki page soon... > > So, I promised at the presentation that I would email the slides and the > relevant information to checkout the repository. > > > -- Here is the presentation (pdf format): > > > https://github.com/guruofquality/grextras/blob/pre_cog/pre_cog_pres.pdf?raw=true > > > -- Here are some teaser screenshots from the slides: > > http://i.imgur.com/HYgeb.png > http://i.imgur.com/EvDof.png > > > -- The code is available on the pre_cog branch of grextras: > > GRExtras main wiki page: > https://github.com/guruofquality/grextras/wiki > GitHub URL > $ git clone https://github.com/guruofquality/grextras.git > Check out this branch: > $ git checkout pre_cog > GRC flowgraphs are here: > /examples/*.grc > Contact > j...@ettus.com > j...@ettus.com > > *Note*: Users will have to generate the tdma hier block first, and then > reload GRC to use the top level simple MAC block. > > > Feedback is always welcome! > -Josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Alex, *Dreams can come true – just believe.* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] simple ARQ MAC over TDMA; using GNU Radio and USRPs in GRC
On 09/26/2012 03:20 PM, Alex Zhang wrote: > Hi Josh, > > A quick question, what is the time reference you are using for the TDMA > engine? Is it GPS or something else? How accurate about the time > synchronization? In this case we tested in the LAB with shared reference and PPS. GPSDO per USRP should be great too. Both of these options will be highly accurate. Now, it should be possible for a more advanced TDMA engine to try and determine the transmit windows without explicit synchronization. I hope we get this into the example as well. The guard interval parameter could be modified depending upon the accuracy. -josh > > On Wed, Sep 26, 2012 at 1:31 PM, Josh Blum wrote: > >> Hey list, >> >> For those who were not at the GR Conference 2012: I presented some work >> demonstrating a simple ARQ MAC over TDMA; using GNU Radio and USRPs in >> GRC. Its very cool work, I encourage anyone to take a peek at the >> slides, and checkout the repo and run the examples. >> >> The MAC layer work is actually the work of John Malsbury (I'm just the >> messenger). He will be continually polishing and debugging the code over >> the next week or so. There should be a wiki page soon... >> >> So, I promised at the presentation that I would email the slides and the >> relevant information to checkout the repository. >> >> >> -- Here is the presentation (pdf format): >> >> >> https://github.com/guruofquality/grextras/blob/pre_cog/pre_cog_pres.pdf?raw=true >> >> >> -- Here are some teaser screenshots from the slides: >> >> http://i.imgur.com/HYgeb.png >> http://i.imgur.com/EvDof.png >> >> >> -- The code is available on the pre_cog branch of grextras: >> >> GRExtras main wiki page: >> https://github.com/guruofquality/grextras/wiki >> GitHub URL >> $ git clone https://github.com/guruofquality/grextras.git >> Check out this branch: >> $ git checkout pre_cog >> GRC flowgraphs are here: >> /examples/*.grc >> Contact >> j...@ettus.com >> j...@ettus.com >> >> *Note*: Users will have to generate the tdma hier block first, and then >> reload GRC to use the top level simple MAC block. >> >> >> Feedback is always welcome! >> -Josh >> >> ___ >> 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
Re: [Discuss-gnuradio] 8-channel receiver
One should remember the extremes involved in syncing all USRP'S which will lead to developing a new driver for USRP2. What about the your APP development time?. Are you interested in developing new driver or app ? On Thu, Sep 27, 2012 at 12:04 AM, Matt Ettus wrote: > You can use a gigabit ethernet switch and put all the USRPs on there. > You should be able to make USRPs send data to each other. You will of > course need to do work to get your algorithms into the FPGA. > > Matt > > On Wed, Sep 26, 2012 at 12:38 PM, Anisha Gorur wrote: > > I have a quick theoretical question. Is there any way to construct an > > 8-channel receiver using 4 USRPS without data going through the host > > computer? Basically some kind of way to daisy chain mimo cables (though I > > know this is not possible), or at least get the same benefits you would > > receive from daisy chaining mimo cables, without using a switch or > network > > connections. > > > > Thank you, > > Anisha > > > > > > ___ > > 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] Wav sink problem
Hi, i construct very simple scheme Audio Source --> Wav Sink gr generates non-null wav file -rw-rw-r-- 1 anton anton 24M сент. 27 00:46 freq2.wav but when i try to play it or fetch info about file with soxi (sox plugin) i got nothing aplay freq2.wav Воспроизведение WAVE 'freq2.wav' : Signed 16 bit Little Endian, Частота 44100 Гц, Моно and soxi freq2.wav shows $ soxi freq2.wav Input File : 'freq2.wav' Channels : 1 Sample Rate: 44100 Precision : 16-bit Sample Encoding: 16-bit Signed Integer PCM so it seems to me wav sink produces corrupted wav files or ... what am i doing wrong? e.g. soxi info on good wav file $ soxi arecord.wav Input File : 'arecord.wav' Channels : 1 Sample Rate: 8000 Precision : 8-bit Duration : 00:00:02.38 = 19000 samples ~ 178.125 CDDA sectors File Size : 19.0k Bit Rate : 64.1k Sample Encoding: 8-bit Unsigned Integer PCM look at Sample Encoding - it is Signed for gnuradio and Unsigned for all others. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] simple ARQ MAC over TDMA; using GNU Radio and USRPs in GRC
This system used a 1PPS to sync the radios - for the sake of getting it up and running quickly. A GPSDO would work just as well, with ~50 ns of accuracy, which is pretty good. Alternatively, as Josh said, you could synchronize the radios with other methods, like over-the air broadcast of a "system time". The beauty of this solution is that you could potentially implement this functionality on high protocol layers(i.e. link management) and use the ctrl ports of the blocks to make adjustments to the USRPs time. I should have better documentation up next week so you can mold this to your application. -John On Wed, Sep 26, 2012 at 12:43 PM, Josh Blum wrote: > > > On 09/26/2012 03:20 PM, Alex Zhang wrote: > > Hi Josh, > > > > A quick question, what is the time reference you are using for the TDMA > > engine? Is it GPS or something else? How accurate about the time > > synchronization? > > In this case we tested in the LAB with shared reference and PPS. GPSDO > per USRP should be great too. Both of these options will be highly > accurate. > > Now, it should be possible for a more advanced TDMA engine to try and > determine the transmit windows without explicit synchronization. I hope > we get this into the example as well. > > The guard interval parameter could be modified depending upon the accuracy. > > -josh > > > > > On Wed, Sep 26, 2012 at 1:31 PM, Josh Blum wrote: > > > >> Hey list, > >> > >> For those who were not at the GR Conference 2012: I presented some work > >> demonstrating a simple ARQ MAC over TDMA; using GNU Radio and USRPs in > >> GRC. Its very cool work, I encourage anyone to take a peek at the > >> slides, and checkout the repo and run the examples. > >> > >> The MAC layer work is actually the work of John Malsbury (I'm just the > >> messenger). He will be continually polishing and debugging the code over > >> the next week or so. There should be a wiki page soon... > >> > >> So, I promised at the presentation that I would email the slides and the > >> relevant information to checkout the repository. > >> > >> > >> -- Here is the presentation (pdf format): > >> > >> > >> > https://github.com/guruofquality/grextras/blob/pre_cog/pre_cog_pres.pdf?raw=true > >> > >> > >> -- Here are some teaser screenshots from the slides: > >> > >> http://i.imgur.com/HYgeb.png > >> http://i.imgur.com/EvDof.png > >> > >> > >> -- The code is available on the pre_cog branch of grextras: > >> > >> GRExtras main wiki page: > >> https://github.com/guruofquality/grextras/wiki > >> GitHub URL > >> $ git clone https://github.com/guruofquality/grextras.git > >> Check out this branch: > >> $ git checkout pre_cog > >> GRC flowgraphs are here: > >> /examples/*.grc > >> Contact > >> j...@ettus.com > >> j...@ettus.com > >> > >> *Note*: Users will have to generate the tdma hier block first, and then > >> reload GRC to use the top level simple MAC block. > >> > >> > >> Feedback is always welcome! > >> -Josh > >> > >> ___ > >> 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] Synchronize phases between two N200
Hi,
I'm trying to synchronize two N200s in phases with both of them having
GPSDO inside. I followedthe instructions on ettus for synchronizing channel
phase. However, I got error message as follows,
UHD source block got error code 0x2gr_block_executor: source produced no output. We're marking it DONE.UHD source block
got error code 0x2gr_block_executor: source
produced no output. We're marking it DONE.
and here's part of my code:bool start(void){#ifdef
GR_UHD_USE_STREAM_API_rx_stream = _dev->get_rx_stream(_stream_args);
_samps_per_packet = _rx_stream->get_max_num_samps();#endif
//setup a stream command that starts streaming slightly in the future
static const double reasonable_delay = 0.5; //order of magnitude over RTT
uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
stream_cmd.num_samps = 20;stream_cmd.stream_now = false;
stream_cmd.time_spec = uhd::time_spec_t(reasonable_delay);
_dev->issue_stream_cmd(stream_cmd);_tag_now = true;return true;
}
Thanks for any help in advance.
Best regards,
Oliver___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] About the sampling rate
Dear all, I find the sampling rate of USRP is surprisingly accurate. Now I set the sampling rate as 4 MHz, and there are always exactly 4M points between two pps signals. Even if I take off the GPS antenna, the sampling rate is still very accurate. This means I only need the GPS antenna at the beginning to get an accurate time stamp. Later I can take off the antenna and still can get accurate time from sampling rate. My colleagues and I do not understand how does USRP make the sampling rate so accurate. We had used other types of A/D converters before. They usually do not have such accurate sampling rate. Sometimes they have around 4M plus and minus 100 points in one second under 4M sampling rate. Thanks for your attention. Wu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
