Re: [Discuss-gnuradio] GR Conference Recording?
Eagerly waiting for the videos. --- Regards Sreeraj Rajendran From: Tom Rondeau To: Dan CaJacob Cc: Discuss-gnuradio@gnu.org Sent: Thursday, 13 September 2012 6:24 AM Subject: Re: [Discuss-gnuradio] GR Conference Recording? On Sat, Sep 8, 2012 at 11:58 PM, Dan CaJacob wrote: > Is the any possibility that the GR conference could be video-recorded? I > will not be able to attend this year and I would selfishly like to see the > talks anyway. > > Last year, the audio recordings were great, especially since it was the > conefrence's first year. There are so many that I'd like to see that don't > even go that far. > > There is an outfit called NextDayVideo (http://nextdayvideo.com/), which I > assume many other pythonistas are aware of. They seem to be doing the video > recording for many of the Python conferences, including PyCon and others. > You can find the videos on YouTube and they seem to do an excellent job of > balancing focus between the presenter and the presentation screen itself. > Code and graphics are always very clear. > > Their website covers their range of services. Videos are edited live, so > there is very little lag between the talk itself and posting. For lower > budgets, they offer training to confence staff and let them shoot the video > themselves. > > I am conscious of the fact that this would be an additional expense and all > that entails. I, speaking for myself, would be willing to pay an > e-registration fee (comparable to the conference registration fee itself) of > some kind to help subsidize the cost. Would others feel the same way? > > Obviously, I'd like to attend in person. I am sure others would too, but > similarly have other obligations that make it impossible. Perhaps this could > also grow the GR community and bring more attention to the confence in the > future? There seem to be more videos every year and I know I have benefited > from them. The GR Conference seems to be a great opportunity to grab some > new content. > > I apologize if this sounds like a sales pitch. As I said, I am just > selfishly trying to attend the conference in any way I can. If it helps > other too - bonus! > > Thanks. Dan, Yes, I am hoping that all of the talks are recorded on video. I will be working with the conference center this week to see what we can actually accomplish. My hope is to just use their A/V team to handle the setup and recording. We'll take the videos and publish them somehow/somewhere. I hope to know more about this soon (what we can expect for video files, formats, etc.). Thanks for the pointer, though! I'll keep it in mind. Tom ___ 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
Thanks Josh, that helps quite a bit! Our sampling frequency is not particularly fast, it will only be around 5 MS/S. Right now the send and receive frame size are still the defaults, 1472 for receive and 1444 for send. In the notes, it says "to improve receive latency, configure the transport for a smaller frame size", will this work for send latency as well? Also is there an equation I can use to determine what the best frame sizes would be, or should I just go with trial and error and use latency_test.cpp to determine if it has shifted? If you change the frame size, how much improvement in latency do you usually see? Again, thank you so much. -Anisha On Fri, Sep 28, 2012 at 6:57 PM, Josh Blum wrote: > > > On 09/28/2012 02:46 PM, Anisha Gorur wrote: > > Thanks Matt! > > Do you have any idea for what kind of latency we would expect? Also would > > The dominating factor in latency here is the gigabit ethernet, this > tends to be around 100us. Here are a few notes about that: > > > http://files.ettus.com/uhd_docs/manual/html/transport.html#latency-optimization > > > the data be routed through the host? My Radio, We only have a couple > months > > Normally the samples would all go to the host computer that configured > the USRP. It is possible to configure the USRP with one machine but send > the samples to an arbitrary network location: > > > http://files.ettus.com/uhd_docs/manual/html/usrp2.html#alternative-stream-destination > > For that matter, there is nothing wrong with splitting up the USRP > configuration among several computers. It all depends how you plan on > using the data. > > > to do this, but we have tried to synchronize USRPs before, so we are > aware > > of some of the problems. > > Anything in particular that I could help to clarify? > > -josh > > > Thanks, > > Anisha > > > > On Wed, Sep 26, 2012 at 3:51 PM, My Radio > wrote: > > > >> 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 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 > -- Anisha Gorur Class of 2012 Electrical Engineering ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can another DUC chain be added to USRP N210?
Thanks Josh, What I am looking for on the TX side of things is basically the same thing I have on the RX side. If I set the subdev spec on the basic RX to "A:A A:B" and then use usrp->set_rx_freq(uhd::tune_request_t(freq)) for each channel, I get two separate rx channels, both with their own IQ pairs. On the TX side I only manage to have one IQ pair, as in I through TX_A and Q through TX_B. We were trying for a 4 channel transmit on 2 USRPs, so that they could all be connected by s MIMO cable. One more question, when you say "too complicated to be worth it", generally, what kind of modification would be necessary? Thanks for your time! -Anisha On Fri, Sep 28, 2012 at 6:36 PM, Josh Blum wrote: > > > On 09/28/2012 08:49 AM, Anisha Gorur wrote: > > Hello All, > > > > I am using a USRP N210. When i set the subdev spec for my basic RX > > daughterboard as "A:A A:B" I can receive two channels. However, if I try > to > > do something similar for the basic TX I get an error like "The user > > specified 2 channels, but there are only 1 tx dsps on mboard 0." I assume > > this is because there is only one DUC chain in the N210. Is there a way > to > > modify this so that I can have two DUC chains in the same way that I have > > two DDC chains? > > Thanks, > > Anisha > > I think adding two complete DUC chains into N210 would be too > complicated to be worth it. > > Is there something specific that you cant do with the single DUC chain? > As long as the cordic is set to zero, I and Q will remain completely > separate from host samples, all the way to the SMA connectors A and B. > > Otherwise, perhaps you need a different rotation for I vs Q? I think > that would be better accomplished by two different cordics. Then perhaps > a custom DSP in the FPGA is for you: > > http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/README.txt#L29 > > I hope that helps. > > -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 > -- Anisha Gorur Class of 2012 Electrical Engineering ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
