Hello, I have an E100, and when I try to acquire data at a decimation rate of 64 the acquisition process chews up 40% of the armv7. I'm trying to do lower decimation rates - is there a plan in place to improve the efficiency of the acquisition code? Thanks, David

I'm trying to do lower decimation rates - is there a plan in place to improve 

On Tue, 2011-01-11 at 07:24 -0800, David Campbell wrote: > Hello, > I have an E100, and when I try to acquire data at a decimation rate of 64 the > acquisition process chews up 40% of the armv7. > > I'm trying to do lower decimation rates - is there a plan in place to improve > the efficiency of the acquisition code? We are working on it as I'm typing this. We have the finest minds in the industry on the task. ;) Seriously though, we're working on improving both Gnuradio's performance on the Cortex-A8, and on the kernel driver and GPMC data transfer to/from the FPGA<->CPU. Unfortunately it's impossible to give an estimate as to how much more performance we can squeeze out of the device. That said, you ought to be able to get around 4Msps (decim=16) out of the E100, if you aren't doing much with the samples. Writing them to Flash is a relatively slow process though and logging raw samples to disk might choke the E100 pretty quickly. --n > > Thanks, > David > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

 I'm trying to do lower decimation rates - is there a plan in place to improve

On 01/11/2011 12:46 PM, Nick Foster wrote: > On Tue, 2011-01-11 at 07:24 -0800, David Campbell wrote: >> Hello, >> I have an E100, and when I try to acquire data at a decimation rate of 64 the >> acquisition process chews up 40% of the armv7. >> >> I'm trying to do lower decimation rates - is there a plan in place to improve >> the efficiency of the acquisition code? > > We are working on it as I'm typing this. We have the finest minds in the > industry on the task. ;) > > Seriously though, we're working on improving both Gnuradio's performance > on the Cortex-A8, and on the kernel driver and GPMC data transfer > to/from the FPGA<->CPU. Unfortunately it's impossible to give an > estimate as to how much more performance we can squeeze out of the > device. Without knowing anything about how you got the numbers, I speculate you are seeing the cost of converting the 16 bit integers from the FPGA to floating point. I did a quick piece of NEON (armv7 simd) for uhd that likely can do a little better. See: http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/lib/transport/convert_types_impl.hpp#L147 uhd can also give you the raw data from the fpga, so if you do not need floating point, this will improve the data rate. Finally, the fpga has free space, so end users can add fpga code to do the high data rate processing. As Nick notes, people are working on various pieces of the system to improve performance. I am staging updates to GNU Radio here: https://github.com/balister/GNU-Radio/commits/e100-updates Be warned, I rebase that branch alot when I am adding new code :) Philip > > That said, you ought to be able to get around 4Msps (decim=16) out of > the E100, if you aren't doing much with the samples. Writing them to > Flash is a relatively slow process though and logging raw samples to > disk might choke the E100 pretty quickly. > > --n > >> >> Thanks, >> David >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com