Re: [Discuss-gnuradio] A few words on development
On Wed, May 18, 2011 at 9:43 AM, Martin Braun wrote: > On Tue, May 17, 2011 at 07:51:00PM -0400, Marcus D. Leech wrote: > > What it seems to come down to is a lack of initiative. We are all > willing > > to wait until someone else does something for us, and then report on > the > > problems. But it's hard to start something and push it out there. > First, > > you expose yourself to criticism and bug reports. You might feel > > uncomfortable about your code. Don't. Don't worry about those things. > We > > the community as a whole will be much more grateful for your efforts > in > > making the project better than insulting you for mistakes or "ugly" > code. > > We can work on minor issues like that. Especially if everyone is > helping. > > > > Thanks for your time, > > > > Tom > > > > Having been a contributor of both new-content and bug-fixes and > "sidecars" > > (like build-gnuradio), I can attest that the experience is very > > rewarding. I only regret that I can't spend more time on making Gnu > Radio > > better. Between my full-time job, and spending my > > "spare" (ha!) time *using* Gnu Radio for actual applications work, I > find I > > have less time for bug-fixing/contributing than I used to. > > > > The Josh object is amazing, to be sure. But even an energetic young > > whipper-snapper like Josh can't keep from burnout forever. > > So, those of you who feel competent to contribute, and have been > holding > > back, JUST DO IT :-) > > I can agree on one thing in particular: I wish I had more time to work > on GNU Radio, it's a great project. Also, contributing stuff is better > than requesting things. > > Still, I also believe the community thing can be improved for GNU Radio. > From my experiences, I can say that the process of contributing stuff is > quite opaque. > > For the one-line bug-fixes, this seems not to be a problem. For bigger > contributions, things could be smoother. > > First of all, how exactly does one contribute stuff? There's Tom's blog > entry on how to use github, there's the gnuradio-patch mailing list, and > theres the trac bugtracker. So what do I use? Do all major patches go > through Tom? But isn't he busy? By the way, the official GR website > seems to have a very outdated document on this topic > (http://gnuradio.org/redmine/wiki/gnuradio/Development). > Agreed. We really need to update the website and make things more clear. But here's the general rules to follow: - use a patch for a small fix; just a couple of lines in one or two files - use the "Issues" on the Redmine page to add feature requests or to report bugs that you don't know how to fix ( http://gnuradio.org/redmine/projects/gnuradio/issues) - use a git branch (on github or other service) for developing big things Yes, I'm very busy, but right now everything is coming through me. There is a thought of a "gatekeeper" for the code that gets merged into master to make sure it fits with our standards. This mostly means that any new code is checked to see if it breaks anything or changes any interfaces. New code and new features tend to be much easier to work with. API changes have to be saved for the next branch. Also, I admit that we tend to be bad about looking at the issues on the Redmine page. Every now and then, I'll find some time to try and work a few of them out. Partly, these issues tend not to be critical; people seem to report the critical issues on the list. I would like it if we all tried to start using the issues concept a bit more; it will provide a better history/record of the project's evolution. And what kind of stuff is accepted, anyway? How do I know that whatever > code I feel should be part of the GNU Radio core will be actually > merged? > That's a very interesting question. A couple of us have some sort of plan in mind for the project, but largely, it develops as needs arise or someone gets interested in something. There are two things here. First, we as a community are starting to develop a better roadmap of the project. This is due largely to our monthly conference calls (details on that in the next email). We are really starting to lay down a plan for what's going to be in 3.5. Second, if you have something that you are working on that you think should be a part of GNU Radio, the best thing would be to email the list and start a discussion on it. Ask if it's a CGRAN project (like an application), and add-on to GNU Radio, or some deeper change to the code that might need some discussion between a bunch of us. Again, we (that is, I) need to be better about using our webpage. We have this concept of a roadmap on the wiki that hasn't really been used for a while. We should try and lay down a plan for this (and then stick to it as much as possible). > The Coding Guide is a good step in the right direction. But let me > suggest some other things to smoothen the 'community integration': > - There could be another document with the def
[Discuss-gnuradio] Developers' Call, May 19, 2011
We will be having our monthly Developers' conference call today. Date: May 19, 2011 Time: 10 PM UTC (6 PM EDT, 3 PM PDT) SIP: sip:gnura...@digitalbazaar.com IRC: #gnuradio on freenode I am traveling and on a semi-holiday right now, and it is unlikely that I can make the call today. Johnathan Corgan will be leading it, instead. Can someone who is online today try to take good notes in the IRC channel and email me the log? Agenda items: - Begin work on next for GNU Radio 3.5: - Add cmake build structure. - We want to start exploring using cmake instead of autotools. We should be able to have parallel build systems to work with until we figure out which one "wins" and then remove the other. This might take a few version cycles. - add gr-digital. I've been working on some enhancements to some of the digital modulation blocks. We will add this to gr-digital and deprecate their counterparts in gnuradio-core. This is the first step in splitting up the core into more appropriate components. - adding uhd examples/apps. Start relying less on USRP code for all our examples; have gr-usrp/apps, gr-usrp2/apps, and gr-uhd/apps. I made some start on this and more needs to be done. - Work on making a consistent API and naming scheme. Based on M. Dickens' suggestion. As part of the coding standard guide, we should make the block names and certain aspects of the API for each block clear ( http://gnuradio.org/redmine/wiki/gnuradio/Coding_guide). - Start using Volk for gnuradio-core blocks. Need to ensure it works on the E100 and then start integrating Volk into blocks to improve efficiency of our code. - Some updates on the GR conference. - There has been a lot of discussion on the mailing list about the project. If anyone has any more to say to help us make development and contributions easier, we should talk about them. Thanks! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ptime get_time(void) precision down to millisec microsec nanosec ?
Hi Everyone First, I would like to introduce myself (ourselves) : VeriSat, Oslo based company (Norway). We are working on a project, using USRP (N210) platform, which aim is to build a DVB-RCS Terminal Shortly RCS is for satellite communication, and is Multi Frequencies TDMA. (http://verisat.no) So synchronization is an important issue for us. Now I have a question regarding the use of a USRP N210 with GPSDO kit, and the use of the UHD function ptime get_time(void) in /host/lib/usrp/gps_ctrl.cpp @ line 133 According to the implementation of get_time(void), it returns the date time with precision down to second. It looks like it queries the USRP waiting for a reply starting with "$GPRMC". then is parses the reply to extract year, month, day, hours, min and sec. Is it possible to extract from the reply the milli ? micro ? and nano seconds ? For example using toked[2-8] or toked[10-11] (because UHD_ASSERT_THROW(toked.size() == 12);) If not, is there any way to include more precision in get_time() by changing code not only in gps_ctrl.cpp, but also in the firmware ? According to http://lists.gnu.org/archive/html/discuss-gnuradio/2011-02/msg00162.html USRP should get 50 ns precision, so I assume it's possible in some way ? Best Regards Bastien ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QAM demod Error in GRC
Dear list and Josh, I'm still getting this error when using the QAM Demod block (qamX_demod is not connected internally). Are there any new developments concerning these blocks? Vlad. Josh Blum-2 wrote: > > Well, when you receive a qam signal, and lock to it, you still have some > unknown phase offset. Lets suppose qam8 has two possible phases: 0 and > 180 degrees. Since you don't know which phase is correct, you can look > for the packet header in the received signal at 0 degrees and > simultaneously at 180 degrees. Whichever phase offset yields a valid > packet is the winner. Of course, this all assumes that you are framing > your data with some kind of packet headers. > > Anyone else have some qam demodulation ideas to share? > > -josh > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- View this message in context: http://old.nabble.com/QAM-demod-Error-in-GRC-tp23722153p31655276.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] ptime get_time(void) precision down to millisec microsec nanosec ?
Hi I think there is a misunderstanding. I do not want to set the time of the USRP. I want to use the USRP (with GPSDO) as my time reference. This is why I want to query the USRP using the UHD function ptime get_time(void) in /host/lib/usrp/gps_ctrl.cpp @ line 133 This function only returns date and time down to seconds, and the toked[] array has a bigger length than what is used : " UHD_ASSERT_THROW(toked.size() == 12); //if it's not we got something weird in there now = ptime( date( greg_year(boost::lexical_cast(toked[9].substr(4, 2)) + 2000), //just trust me on this one greg_month(boost::lexical_cast(toked[9].substr(2, 2))), greg_day(boost::lexical_cast(toked[9].substr(0, 2))) ), hours( boost::lexical_cast(toked[1].substr(0, 2))) + minutes(boost::lexical_cast(toked[1].substr(2, 2))) + seconds(boost::lexical_cast(toked[1].substr(4, 2))) ); " So I would like to know the format of the string returned by the safe_gps_read(); function, " reply = safe_gps_read(); " or better the description of the toked[] array after it get through " tok.assign(reply); toked.assign(tok.begin(), tok.end()); " Bastien On 2011-05-19 14:46, Josh Blum wrote: > >> Is it possible to extract from the reply the milli ? micro ? and nano >> seconds ? For example using toked[2-8] or toked[10-11] (because > > I recommend that you use query the seconds to catch the PPS edge, and > then set the time for the next PPS. This will set the GPSDO time into > the device at the precision of a clock cycle: > > http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#aaa80cd6ee4b3c1bf52afb9c3ef02f64d > > -Josh > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ptime get_time(void) precision down to millisec microsec nanosec ?
On Thu, 2011-05-19 at 17:07 +, Bastien Auneau wrote: > Hi > > I think there is a misunderstanding. > I do not want to set the time of the USRP. > I want to use the USRP (with GPSDO) as my time reference. > This is why I want to query the USRP using the UHD function ptime > get_time(void) in > /host/lib/usrp/gps_ctrl.cpp @ line 133 > > This function only returns date and time down to seconds, and the > toked[] array has a bigger length than what is used : > " > UHD_ASSERT_THROW(toked.size() == 12); //if it's not we got something > weird in there > > now = ptime( date( > greg_year(boost::lexical_cast(toked[9].substr(4, 2)) + 2000), > //just trust me on this one > greg_month(boost::lexical_cast(toked[9].substr(2, 2))), > greg_day(boost::lexical_cast(toked[9].substr(0, 2))) >), > hours( boost::lexical_cast(toked[1].substr(0, 2))) > + minutes(boost::lexical_cast(toked[1].substr(2, 2))) > + seconds(boost::lexical_cast(toked[1].substr(4, 2))) > ); > " > > So I would like to know the format of the string returned by the > safe_gps_read(); function, > " > reply = safe_gps_read(); OK, so 4 things: 1. Querying the GPS time through the device is going to net you accuracy in the 10s of milliseconds, maybe worse. Asking for more precision in the GPRMC sentence is meaningless, since the query has to go through both the Ethernet transport and the serial port on the N210 on its way to you. 2. The GPSDO PPS output is used in the N210 to synchronize the sample time across multiple devices. The PPS edge is the ONLY output of the GPSDO which is guaranteed to be synchronized, and its synchronization is good to (typical) 50ns. That output goes straight into the FPGA to provide a sync pulse. Typically, you call get_time() to get the UTC time in seconds, and then set_time_next_pps() to tell the FPGA to sync its sample time to the next PPS pulse. Then you know the absolute time, and you can calculate the absolute time of any given sample from the N210 based on the absolute time and the sample count. 3. The GPRMC sentence provides for decimal time down to the millisecond; however, the Jackson Labs Firefly device (like most GPS devices) issues sentences on the rising edge of PPS, and so the fractional seconds component is always zero. 4. The toked vector gives you the GPRMC sentence components in order, separated by comma or period. --n > " > > or better the description of the toked[] array after it get through > " > tok.assign(reply); > toked.assign(tok.begin(), tok.end()); > " > > Bastien > > On 2011-05-19 14:46, Josh Blum wrote: > > > >> Is it possible to extract from the reply the milli ? micro ? and nano > >> seconds ? For example using toked[2-8] or toked[10-11] (because > > > > I recommend that you use query the seconds to catch the PPS edge, and > > then set the time for the next PPS. This will set the GPSDO time into > > the device at the precision of a clock cycle: > > > > http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#aaa80cd6ee4b3c1bf52afb9c3ef02f64d > > > > -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] ptime get_time(void) precision down to millisec microsec nanosec ?
I don't understand why I should do : > Typically, you call get_time() to get the UTC time > in seconds, and then set_time_next_pps() to tell the FPGA to sync its > sample time to the next PPS pulse why should I use set_time_next_pps() ? Is it needed to init USRP lock to GPS time ? My understanding is that USRP is GPS locked because it has GPSDO. then I use get_time() to ensure that my PC clock will not get delayed by more than some millisec (+/-) from USRP clock. Taking into account ethernet delay, and some more internal delay, I was expecting to get some 10 to 20 millisec accuracy. This way I know that I can send all the burst to USRP with TX_timestamp around 50 millisec in the future. Without this mechanism, I'm afraid to get the PC clock drifting from USRP (so GPS) clock, leading to send burst with tx_timestamp in the past I will then have to use some much bigger margin to send my burst (like 500 millisec) which would add big latency to system Bastien On 2011-05-19 16:54, Nick Foster wrote: > On Thu, 2011-05-19 at 17:07 +, Bastien Auneau wrote: >> Hi >> >> I think there is a misunderstanding. >> I do not want to set the time of the USRP. >> I want to use the USRP (with GPSDO) as my time reference. >> This is why I want to query the USRP using the UHD function ptime >> get_time(void) in >> /host/lib/usrp/gps_ctrl.cpp @ line 133 >> >> This function only returns date and time down to seconds, and the >> toked[] array has a bigger length than what is used : >> " >> UHD_ASSERT_THROW(toked.size() == 12); //if it's not we got something >> weird in there >> >> now = ptime( date( >> greg_year(boost::lexical_cast(toked[9].substr(4, 2)) + 2000), >> //just trust me on this one >> greg_month(boost::lexical_cast(toked[9].substr(2, 2))), >> greg_day(boost::lexical_cast(toked[9].substr(0, 2))) >>), >> hours( boost::lexical_cast(toked[1].substr(0, 2))) >> + minutes(boost::lexical_cast(toked[1].substr(2, 2))) >> + seconds(boost::lexical_cast(toked[1].substr(4, 2))) >> ); >> " >> >> So I would like to know the format of the string returned by the >> safe_gps_read(); function, >> " >> reply = safe_gps_read(); > > OK, so 4 things: > > 1. Querying the GPS time through the device is going to net you accuracy > in the 10s of milliseconds, maybe worse. Asking for more precision in > the GPRMC sentence is meaningless, since the query has to go through > both the Ethernet transport and the serial port on the N210 on its way > to you. > > 2. The GPSDO PPS output is used in the N210 to synchronize the sample > time across multiple devices. The PPS edge is the ONLY output of the > GPSDO which is guaranteed to be synchronized, and its synchronization is > good to (typical) 50ns. That output goes straight into the FPGA to > provide a sync pulse. Typically, you call get_time() to get the UTC time > in seconds, and then set_time_next_pps() to tell the FPGA to sync its > sample time to the next PPS pulse. Then you know the absolute time, and > you can calculate the absolute time of any given sample from the N210 > based on the absolute time and the sample count. > > 3. The GPRMC sentence provides for decimal time down to the millisecond; > however, the Jackson Labs Firefly device (like most GPS devices) issues > sentences on the rising edge of PPS, and so the fractional seconds > component is always zero. > > 4. The toked vector gives you the GPRMC sentence components in order, > separated by comma or period. > > --n > >> " >> >> or better the description of the toked[] array after it get through >> " >> tok.assign(reply); >> toked.assign(tok.begin(), tok.end()); >> " >> >> Bastien >> >> On 2011-05-19 14:46, Josh Blum wrote: >>> Is it possible to extract from the reply the milli ? micro ? and nano seconds ? For example using toked[2-8] or toked[10-11] (because >>> >>> I recommend that you use query the seconds to catch the PPS edge, and >>> then set the time for the next PPS. This will set the GPSDO time into >>> the device at the precision of a clock cycle: >>> >>> http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#aaa80cd6ee4b3c1bf52afb9c3ef02f64d >>> >>> -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] QAM demod Error in GRC
Vlad It is apparent to me that you did not understand Josh's explanation. Possibly he was not forceful enough. ;-). This is not an error. It is the mathematical consequence of doing QAM with rotational symmetries. YOU MUST provide your OWN synchronization to remove the phase ambiguity. It is not a bug or an error. It is a feature. It is the mathematical nature of the beast. Bob On Thu, May 19, 2011 at 7:55 AM, Vlad Stoianovici < stoianovici_v...@yahoo.com> wrote: > > Dear list and Josh, > I'm still getting this error when using the QAM Demod block (qamX_demod is > not connected internally). > Are there any new developments concerning these blocks? > > Vlad. > > > Josh Blum-2 wrote: > > > > Well, when you receive a qam signal, and lock to it, you still have some > > unknown phase offset. Lets suppose qam8 has two possible phases: 0 and > > 180 degrees. Since you don't know which phase is correct, you can look > > for the packet header in the received signal at 0 degrees and > > simultaneously at 180 degrees. Whichever phase offset yields a valid > > packet is the winner. Of course, this all assumes that you are framing > > your data with some kind of packet headers. > > > > Anyone else have some qam demodulation ideas to share? > > > > -josh > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > -- > View this message in context: > http://old.nabble.com/QAM-demod-Error-in-GRC-tp23722153p31655276.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 > -- Bob McGwier rwmcgw...@gmail.com Amateur Radio Station: N4HY Engineer, Mathematician (Ph.D Brown University) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ptime get_time(void) precision down to millisec microsec nanosec ?
On 19/05/2011 3:13 PM, Bastien Auneau wrote: why should I use set_time_next_pps() ? Is it needed to init USRP lock to GPS time ? Keep in mind that the PPS support pre-dates the existence of an "in skin" GPSDO, and the *primary* purpose of the GPSDO is to provide a stable 10MHz reference clock for the PLL synthesizers, ADC clocks, and DSP-chain within the FPGA. Internal to the FPGA, there's a clock register that runs at 100MHz (10ns/tick). The purpose of set_time_next_pps() is to arrange for that register to be set to whatever you supply, at the next 1PPS input transition. The purpose is to allow synchronization of multiple USRP2/N210 so that they all more-or-less agree on sample timing. Consider the following scenario: o A number, greater than one, of USRP2/N2xxx o All seeing the same 1PPS and 10MHz ref-clocks o They've all just been sent a set_time_next_pps() command from the host o The 1PPS pulse arrives some time *after* you've done the set_time_next_pps() o Once that 1PPS pulse arrives, on a one-shot basis, the master clock in all of the the USRP2/N2xx to which you've sent the set_time_next_pps() command all now agree on the current "time". But this is a sample time, and it only has meaning within the context of sample synchronization. It doesn't necessarily have any relationship at all to "real" time. The USRP-family, internally, neither knows, nor really cares, about absolute time-of-day. Now, having said that, the UHD protocol allows you to set the "time at next PPS" or "time right now please" to anything you want, and it looks (from the FPGA code, Josh could confirm) that the time is divided into a 32-bit seconds field, and a 32-bit "ticks" field. The "ticks" field ticks over at the nominal FPGA clock frequency of 100MHz, which gives 10ns per tick. So you could set the 32-bit seconds field to the host TOD clock more-or-less directly, after scaling the ticks appropriately. My understanding is that USRP is GPS locked because it has GPSDO. then I use get_time() to ensure that my PC clock will not get delayed by more than some millisec (+/-) from USRP clock. Taking into account ethernet delay, and some more internal delay, I was expecting to get some 10 to 20 millisec accuracy. This way I know that I can send all the burst to USRP with TX_timestamp around 50 millisec in the future. Again, the USRP2/N2XXX family use the GPSDO primarily to provide a high-quality 10MHz reference clock, and the 1PPS for synchronizing the *sample* timestamping mechanisms. The USRP2/N2XX does not, at this point, actually parse the NMEA-0183 GPS sentences and set its internal time-of-day (actually, sample) clock to GPS time. The "in skin" GPSDO was primarily regarded (AFAIK) as a convenient substitute for an external 10MHz and 1PPS reference, to simplify packaging. The "model" is that the host(s) are the primary time-of-day reference. If you want to make sure the USRP2/N2XXX doesn't drift relative to the host, I would make sure the host is running NTPD, and then have your *application* occasionally use the set_time_next_pps() or set_time_now() functions to cause synchronization between the hosts time-of-day "view" and that of the USRP2/N2XX. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QAM demod Error in GRC
Wouldn't one normally use differential encoding to avoid this problem? Maybe I'm missing something important. Ben On Thu, May 19, 2011 at 12:21 PM, Robert McGwier wrote: > Vlad > It is apparent to me that you did not understand Josh's explanation. > Possibly he was not forceful enough. ;-). > This is not an error. It is the mathematical consequence of doing QAM with > rotational symmetries. YOU MUST provide your OWN synchronization to remove > the phase ambiguity. It is not a bug or an error. It is a feature. It is > the mathematical nature of the beast. > Bob > > On Thu, May 19, 2011 at 7:55 AM, Vlad Stoianovici > wrote: >> >> Dear list and Josh, >> I'm still getting this error when using the QAM Demod block (qamX_demod is >> not connected internally). >> Are there any new developments concerning these blocks? >> >> Vlad. >> >> >> Josh Blum-2 wrote: >> > >> > Well, when you receive a qam signal, and lock to it, you still have some >> > unknown phase offset. Lets suppose qam8 has two possible phases: 0 and >> > 180 degrees. Since you don't know which phase is correct, you can look >> > for the packet header in the received signal at 0 degrees and >> > simultaneously at 180 degrees. Whichever phase offset yields a valid >> > packet is the winner. Of course, this all assumes that you are framing >> > your data with some kind of packet headers. >> > >> > Anyone else have some qam demodulation ideas to share? >> > >> > -josh >> > ___ >> > Discuss-gnuradio mailing list >> > Discuss-gnuradio@gnu.org >> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > >> >> -- >> View this message in context: >> http://old.nabble.com/QAM-demod-Error-in-GRC-tp23722153p31655276.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 > > > > -- > Bob McGwier > rwmcgw...@gmail.com > Amateur Radio Station: N4HY > Engineer, Mathematician (Ph.D Brown University) > > > ___ > 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] QAM demod Error in GRC
On 19/05/2011 1:21 PM, Robert McGwier wrote: Vlad It is apparent to me that you did not understand Josh's explanation. Possibly he was not forceful enough. ;-). This is not an error. It is the mathematical consequence of doing QAM with rotational symmetries. YOU MUST provide your OWN synchronization to remove the phase ambiguity. It is not a bug or an error. It is a feature. It is the mathematical nature of the beast. Bob Perhaps I have only part of the conversation here, but it sounds like the main complaint is that there are internal errors inside the QAMx, x=8,16,64,256 demod blocks--they're implemented as hierarchical blocks in Python. Looking into it, it seems like there still aren't any implementations of QAMx demodulators--what is there is basically a hollow shell that does nothing useful. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC pure FSK with USRP1 board sampling troubles
Hello, everyone. I have been coming here for all of my GNURadio and GRC problems, and everyone seems beyond knowledgeable. That being said, I have come to the end of my recourses and am forced to pose a question. I hope this hasn't already been answered, but I've been searching for a while, and have not found anything relevant to what I'm about to post. I am trying to implement FSK over the air using the USRP1 boards within GRC. I have successfully sent large files between two computers, but am now trying to implement sending a .wav via the .wav source (and in the future, live audio with the audio source). In the case of pure bytes, the only thing that controls the sampling rate is the USRP, ie 128M(samples/second)/interpolation. However, in the case of a .wav file with a set sampling rate seems to be much harder. The following is the signal chain I'm using, and the chain of my logic as well. Transmit: >>Bit pipeline<< -Source: .wav at 44.1khz. -Multiply constant: 127 times the values within [-1,1] from the .wav source. -Float to short, -Short to float: This essentially truncates the float output [-127,127] of the .wav to 255 discrete values (since I don't know an easier way to do this within GRC) -Float to char: Now we take those discrete values from [-127,127] and map them to a byte each. >>FSK Modulation<< -Simple framer: Since the framer appends a barker code to the beginning of my packet that is 8 bytes, a byte for the sequence number, and another byte at the end of the packet (according to the code, the byte is 0x55, why this is there, I still don't know), I set the packet length to 4086 (ie 4086+10=4096 total packet length, a multiple of 128, as per http://old.nabble.com/RFX2400%2BUSRP-buffers-td19415046.html#a19415046 http://old.nabble.com/RFX2400%2BUSRP-buffers-td19415046.html#a19415046 ). SAMPLE RATE: I have assumed it to be about the same, since the bytes added are negligible compared to the packet length -Packed to Unpacked: Bits/chunk=1, therefore, for each byte put into the packed to unpacked, I receive 8 bytes out. SAMPLE RATE: 44.1kHz*8 = 352.8kHz. -Chunks to symbols: Since I'm only doing 2 level FSK, I only care about the value of the MSB, but I'm pretty sure the code for chunks to symbols reads all the bits anyway, so again, our sample rate is not affected. -Interpolating FIR filter: Set to length 8, with taps = 1. This spreads the effective mark and space bits out a little bit, ensuring full periods from the output of the FM mod block. Therefore, for each float in, I get 8 float out. SAMPLE RATE = 352.9kHz*8 = 2.8224MHz. -FM mod: This is where my confidence drops. I have selected my symbols as 2 and 4 in the previous block, and set sensitivity to pi/16. Therefore, for every "0" (symbol = 2), I get a full sinusoidal period in 8 samples, and 2 full periods in 8 samples of a "1" (symbol = 4). Now, I'm stuck. I have kind of assumed the sample rate at the output of the FM mod block to be equal to that going in, ie 2.8224MHz. The USRP broadcasts at 128M(sample/sec) / interpolation. Therefore, 129M/2.8224M ~ 45 (my interpolation). I guess this is where I am stuck. I'm not going to post the details of the receive side, as it's essentially exactly the same, but backwards, but I'm not getting a coherent .wav a the output of my speakers. It goes on for a small amount of time, and then the USRP outputs garbage (actually it looks like a sinusoid with very low frequency) for a split second, then back to the regularly scheduled program. I am wondering if there is, and how a buffer in the USRP (either block or actual hardware) treats a signal that is being "fed" either too fast, or too slow. And if so, do I have to add a rational resampler? I'm thinking I do, but I don't think anything will get the two sampling rates to match exactly I know this is a long one, but I'm at the end of the road of fully understanding FSK within GRC and the USRP board, and am pleased with my previous results. Now that there are two competing sampling rates, I don't know what to do. Thanks for your infinite wisdom, Justyn -- View this message in context: http://old.nabble.com/GRC-pure-FSK-with-USRP1-board-sampling-troubles-tp31650945p31650945.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] GRC pure FSK with USRP1 board sampling troubles
On Thu, 2011-05-19 at 12:44 -0700, justynnuff wrote: > Hello, everyone. > > I have been coming here for all of my GNURadio and GRC problems, and > everyone seems beyond knowledgeable. That being said, I have come to the > end of my recourses and am forced to pose a question. I hope this hasn't > already been answered, but I've been searching for a while, and have not > found anything relevant to what I'm about to post. > > I am trying to implement FSK over the air using the USRP1 boards within GRC. > I have successfully sent large files between two computers, but am now > trying to implement sending a .wav via the .wav source (and in the future, > live audio with the audio source). In the case of pure bytes, the only > thing that controls the sampling rate is the USRP, ie > 128M(samples/second)/interpolation. However, in the case of a .wav file > with a set sampling rate seems to be much harder. The following is the > signal chain I'm using, and the chain of my logic as well. > > Transmit: > >>Bit pipeline<< > -Source: .wav at 44.1khz. > -Multiply constant: 127 times the values within [-1,1] from the .wav > source. > -Float to short, > -Short to float: This essentially truncates the float output [-127,127] of > the .wav to 255 discrete values (since I don't know an easier way to do this > within GRC) > -Float to char: Now we take those discrete values from [-127,127] and map > them to a byte each. > > >>FSK Modulation<< > -Simple framer: Since the framer appends a barker code to the beginning of > my packet that is 8 bytes, a byte for the sequence number, and another byte > at the end of the packet (according to the code, the byte is 0x55, why this > is there, I still don't know), I set the packet length to 4086 (ie > 4086+10=4096 total packet length, a multiple of 128, as per > http://old.nabble.com/RFX2400%2BUSRP-buffers-td19415046.html#a19415046 > http://old.nabble.com/RFX2400%2BUSRP-buffers-td19415046.html#a19415046 ). > SAMPLE RATE: I have assumed it to be about the same, since the bytes added > are negligible compared to the packet length > -Packed to Unpacked: Bits/chunk=1, therefore, for each byte put into the > packed to unpacked, I receive 8 bytes out. > SAMPLE RATE: 44.1kHz*8 = 352.8kHz. > -Chunks to symbols: Since I'm only doing 2 level FSK, I only care about the > value of the MSB, but I'm pretty sure the code for chunks to symbols reads > all the bits anyway, so again, our sample rate is not affected. > -Interpolating FIR filter: Set to length 8, with taps = 1. This spreads > the effective mark and space bits out a little bit, ensuring full periods > from the output of the FM mod block. Therefore, for each float in, I get 8 > float out. > SAMPLE RATE = 352.9kHz*8 = 2.8224MHz. > -FM mod: This is where my confidence drops. I have selected my symbols as > 2 and 4 in the previous block, and set sensitivity to pi/16. Therefore, for > every "0" (symbol = 2), I get a full sinusoidal period in 8 samples, and 2 > full periods in 8 samples of a "1" (symbol = 4). > > Now, I'm stuck. I have kind of assumed the sample rate at the output of the > FM mod block to be equal to that going in, ie 2.8224MHz. The USRP broadcasts > at 128M(sample/sec) / interpolation. Therefore, 129M/2.8224M ~ 45 (my > interpolation). > > I guess this is where I am stuck. I'm not going to post the details of the > receive side, as it's essentially exactly the same, but backwards, but I'm > not getting a coherent .wav a the output of my speakers. It goes on for a > small amount of time, and then the USRP outputs garbage (actually it looks > like a sinusoid with very low frequency) for a split second, then back to > the regularly scheduled program. I am wondering if there is, and how a > buffer in the USRP (either block or actual hardware) treats a signal that is > being "fed" either too fast, or too slow. And if so, do I have to add a > rational resampler? I'm thinking I do, but I don't think anything will get > the two sampling rates to match exactly I think your transmit side is fine. The .wav source should be unthrottled. The receive side is where you're going to run into trouble. This is the classic two-clock problem. Basically, you're exactly right -- the two sample rates are never going to match exactly. You do need to add a resampler to get your sample rates to match (assuming perfect clock accuracy), but in reality the soundcard clock and the USRP clock are going to drift with respect to each other. In the "real world" this problem is usually solved by dynamically resampling the audio stream at a rate controlled by a feedback loop responding to the observed clock mismatch. The Gnuradio audio source/sink don't include this part, and so they don't work so great with a USRP or other independently-clocked hardware. If your ALSA-fu is strong and you have some free time, though, it'd be super awesome to see this part taken care of. I've been meaning to tackle this in the audio sink for a while
Re: [Discuss-gnuradio] GRC pure FSK with USRP1 board sampling troubles
Nick Foster-4 wrote: > > I think your transmit side is fine. The .wav source should be > unthrottled. The receive side is where you're going to run into trouble. > Indeed you're right. Upon further research, I realised that nothing throttles the Tx side but the USRP. So, according to my previous math, all I need is 128Msam/sec / interpolation > 2.8MHz. I chose interpolation 44. This ensures my signal will always transmit at 2.909MHz. That means with a decimation on the Rx side of 22, I receive the signal at 2.909MHz. That's still fine, since on the receiving end I have USRP > quadrature demod > simple correlator > char to float. I simply undo everything I did on the Tx side sampling-rate-wise , ie 2.909MHz/64 ~ 45.4kHz. I'm not worried about the USRP clock and audio clock mismatch. I'll deal with that after more immediate matters: On my transmit side, I'm still getting the whole "uUuUuU" bit at the bottom of the screen. That is, "not enough samples to send to the USRP." This coupled with the fact that when I get those interruption bursts on the receive side, both my scope right off the USRP shows at interruption and the "seqno" from the simple correlator at the bottom of the screen slow down. this leads me to believe problems are happening on the transmit side. But since both as you said, and as I discovered, nothing is throttling the USRP but the USRP, I don't know what it is. I think the only answer is that my computer is simply not providing enough data over the USB as the USRP needs. Right? -- View this message in context: http://old.nabble.com/GRC-pure-FSK-with-USRP1-board-sampling-troubles-tp31650945p31660072.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] GRC pure FSK with USRP1 board sampling troubles
Nick Foster wrote: > In the "real world" this problem is usually solved by > dynamically resampling the audio stream at a rate controlled > by a feedback loop responding to the observed clock mismatch. I have a USRP1 with a BasicTX daughterboard. When transmitting, what is the proper method in a GNU Radio app for "observing" the USRP, such that underrun (uUuUuU) errors are guaranteed not to occur? [corollary: neither do we want queues to build up] We're of course assuming here that the CPU has plenty of power, that the TX sampling rate is completely reasonable, etc., etc. We're also suggesting that our app might not necessarily have on tap an infinite number of samples for immediate shipment to the USRP at all times. (Think: just-in-time)... We're assuming that the design specs for our app say that: "USRP underruns are totally unacceptable" (is this a realistic goal to have in the "real world"?) Is this capability available at all or is it hardware-dependent? Or perhaps driver-dependent (UHD or whatever)? > If your ALSA-fu is strong and you have some free time, though, > it'd be super awesome to see this part taken care of. I've been > meaning to tackle this in the audio sink for a while now, but > put it off. There are at least two cases I've been looking at which wouldn't benefit (at least directly) from this, unfortunately 1) audio sink is only half of it, audio source is also needed 2) All the VOIP stuff seems to use a standard sample rate of 8,000 If GNU Radio does try to take a stab at the two-clocks problem is it possible to generalize the solution beyond just ALSA users? Thx & 73 de KA1RBI Max ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC pure FSK with USRP1 board sampling troubles
On 05/19/2011 09:49 PM, ikjtel wrote: > > We're assuming that the design specs for our app say that: > "USRP underruns are totally unacceptable" > (is this a realistic goal to have in the "real world"?) > > While extended underruns are problematic, a short underrun should be equivalent to a noise-burst of some sort occurring on the channel. These are, after all, radio channels we're talking about. They need to be reasonably robust in the face of "stuff you can't control". In the real world, glitches happen on analog channels. Which is why you develop techniques to cope with them. I see the occasional underrun/overrun as equivalent to these glitches. You'd rather they not happen often enough that they seriously impact your channel BER. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 not Found with UHD on SD Card
Hi I have installed UHD on SD Card. When I turn on USRP2, LED "D & F" on ( SD card is working properly) . Ubuntu 10.04 with GNUradio 3.2.2 has been installed on PC. When I run the command " sudo find_usrps", I got " NO USRP2 Found". The command "sudo find_usrps" worked fine with my previous SD card. I also have tried the command "sudo uhd_find_devices", and got " command not found". Please guide me...wether I have to install something on my PC to work with UHD (SDcard). Waiting for Response Zimran Rafique___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 not Found with UHD on SD Card
On 05/19/2011 07:50 PM, hafiz zimran wrote: > Hi > I have installed UHD on SD Card. When I turn on USRP2, LED "D & F" on ( SD > card is working properly) . > Ubuntu 10.04 with GNUradio 3.2.2 has been installed on PC. > When I run the command " sudo find_usrps", I got " NO USRP2 Found". > The command "sudo find_usrps" worked fine with my previous SD card. That command "find_usrps" for the old gnuradio driver and not for uhd. You will want to use "uhd_find_devices". > I also have tried the command "sudo uhd_find_devices", and got " command not > found". > http://www.cyberciti.biz/faq/linux-unix-command-not-found-error-and-how-to-get-rid-of-it/ > Please guide me...wether I have to install something on my PC to work with > UHD (SDcard). > Did you install uhd? http://code.ettus.com/redmine/ettus/projects/uhd/wiki > Waiting for Response > > Zimran Rafique > > > > ___ > 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] USRP2 not Found with UHD on SD Card
http://www.ettus.com/uhd_docs/manual/html/build.html On Thu, 2011-05-19 at 19:50 -0700, hafiz zimran wrote: > Hi > I have installed UHD on SD Card. When I turn on USRP2, LED "D & F" on > ( SD card is working properly) . > Ubuntu 10.04 with GNUradio 3.2.2 has been installed on PC. > When I run the command " sudo find_usrps", I got " NO USRP2 Found". > The command "sudo find_usrps" worked fine with my previous SD card. > I also have tried the command "sudo uhd_find_devices", and got " > command not found". > > Please guide me...wether I have to install something on my PC to work > with UHD (SDcard). > > Waiting for Response > > Zimran Rafique > ___ > 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] GRC pure FSK with USRP1 board sampling troubles
> In the real world, glitches happen on analog channels. > Which is why you develop techniques to cope with them. > I see the occasional underrun/overrun as equivalent to > these glitches. Yep - it just so happens that these are "digital" (P25) channels, not analog ones, but robust detection/correction protocols at the higher levels are there to cope with the occasional glitches... In P25 there are so-called "status symbols" (SS) which are sent at regular intervals and are interspersed in the bitstream - it's my guess that an underrun occurring during USRP tranmission of P25 would be observable at the receiver as a momentary glitch as you've said and also (unless somehow pre-correction were done) as a sudden random shift in the phase of these "clock" (status) symbols, (perhaps not an everyday occurrence in production environments)... P25 trunking uses slotted Aloha which (as I understand the current GR state) isn't completely precluded in USRP1 even though USRP1 doesn't support timestamping. However once again suspect that the slot timing would be momentarily thrown off by the occurrence of a TX underrun. It's time to break down and buy a USRP2, though :-\ and WBX too > You'd rather they not happen often enough > that they seriously impact your channel BER. Yeah - that was the previous question - precisely how to write data towards the USRP1 sink, essentially in real-time, "at a rate controlled by a feedback loop responding to the observed clock mismatch." I too am not focusing on the occasional error, the question was a systemic one... Perhaps the answer lies outside of GR... 73 Max ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC pure FSK with USRP1 board sampling troubles
On 05/19/2011 11:51 PM, ikjtel wrote: > Yep - it just so happens that these are "digital" (P25) channels, > not analog ones, but robust detection/correction protocols at the > higher levels are there to cope with the occasional glitches... > If they fly through the aether, they're analog. Once a signal leaves the warm cozy domain of the digital world, it's analog. It becomes analog as soon as it leaves the DAC on the USRP. It's then at the mercy of the not-so-tender ministrations of the actively-trying-gut-you analog world. You may well have deluded the signal into thinking it's digital, but it's a thin, thin delusion once it hits the antenna :-) -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
