Re: [USRP-users] E310 not locking on GPS

2019-05-02 Thread Jason Matusiak via USRP-users
You are probably right.  What I discovered was it is the ublox itself that is 
the problem.

My solution is that at the top of my GR constructor, I disable the gpsd, send a 
reset command to the ublox, and then reenable the gpsd. So far so good with 
that approach.

On May 2, 2019, at 7:36 PM, Dan CaJacob 
mailto:dan.caja...@gmail.com>> wrote:
GPS doesn't like to go back in time. You probably need to reset the almanac and 
a reboot is doing that.

On Tue, Apr 30, 2019, 9:53 AM Jason Matusiak via USRP-users < 
usrp-users@lists.ettus.com> wrote:
I've seen this a few times, but I cannot seem to lock it down to any particular 
reason.  While sitting at my desk with a GPS simulator (so I have a known good 
signal), I will be doing testing and everything is fine (it seems to be walking 
around the place where the unit was built).  I will turn off the GPS unit for 
the night and then the next day when I turn it on, I never get a fix.  I've 
seen this numerous times and the only way I can fix it is to reboot the E310.  
It is like the GPS is getting into a mucked up stated.  Data comes streaming 
through, but it is just the last good signal.

I can't figure out a way to reset the GPS without rebooting it, does anyone 
know of a way?  I tried killing and restarting the daemon, but that doesn't 
seem to do anything.  I really think it is the GPS module, but rebooting it 
everytime I want to run things "just in case."

One other weird thing, when I run gpsmon in this screwed up state, it mostly 
looks OK, but it has weird characters displayed throughout the ASCII heading 
(for lack of a better term).

This is a good setup on a different unit (so I don't expect to see a fix):
tcp://localhost:2947  u-blox>
┌──┐┌─┐ 
or":11}
│Ch PRN  Az  El S/N Flag U ││ECEF Pos: +6378137.00m  +0.00m  +0.00m   │ 
er":"u-blox","subtype":"Unknown","activated":"2018-10-10T06:21:07.701Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}]}
│ 0   1   0 165   0 0110   ││ECEF Vel: +0.00m/s +0.00m/s +0.00m/s │ 
false,"timing":false,"split24":false,"pps":true}
│ 1   2   0 165   0 0110   ││ │
│ 2   4   0 165   0 0110   ││LTP Pos:   0.0°   0.0°   -18.00m │
│ 3   6   0 165  23 0310   ││LTP Vel:0.00m/s   0.0°   0.00m/s │
│ 4   7   0 165   0 0110   ││ │
│ 5   9   0 165  23 0310   ││Time: 0 00:00:00.00  │
│ 6  14   0 165  22 0310   ││Time GPS: Day:   │
│ 7  19   0 165  22 0310   ││ │
│ 8  20   0 165  21 0310   ││Est Pos Err998.72st Vel Err   0.00m/s│
│ 9  21   0 165   0 0110   ││PRNs:  0 PDOP:100.0 Fix 0x00 Flags 0x40  │
│10  22   0 165   0 0110   │└─── NAV_SOL ─┘
│11  23   0 165   0 0110   │┌─┐
│12  24   0 165   0 0110   ││DOP [H] 100.0[V] 100.0[P] 100.0[T] 100.0[G] 100.0│
│13  28   0 165  23 0310   │└─── NAV_DOP ─┘
│14  30   0 165   0 0110   │┌─┐
│15 136   0 165   0 0110   ││TOFF: > 1 dayPPS:│

There are lines around the different sections (they look like lines, not dashes 
and bars).


and then on the unit that is hosed:
tcp://localhost:2947  u-blox>
lqqklqk 
or":11}
xCh PRN  Az  El S/N Flag U xxECEF Pos: -2414806.17m +5389584.51m +2400650.28m x 
er":"u-blox","subtype":"Unknown","activated":"2019-01-08T14:52:40.454Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}]}
x 0   2   0 165  50 0700   xxECEF Vel: +0.00m/s +0.00m/s +0.00m/s x 
false,"timing":false,"split24":false,"pps":true}
x 1   4   0 165  50 0700   xx x
x 2   5   0 165  50 0700   xxLTP Pos:  22.2557151134f 114.134790532f20.19m x
x 3   8   0 165   0 0100   xxLTP Vel:0.00m/s   0.0f   0.00m/s x
x 4   9   0 165  50 0700   xx x
x 5  10   0 165  50 0700   xxTime: 61 06:13:40.00 x
x 6  12   0 165  50 0700   xxTime GPS: 1877+529282.000 Day: 6 x
x 7  13   0 165  50 0600   xx x
x 8  17   0 165  50 0700   xxEst Pos Err2238690.24st Vel Err   0.00m/sx
x 9  20   0 165  50 0700   xxPRNs:  0 PDOP:100.0 Fix 0x00 Flags 0xdc  x
x10  23   0 165  50 0700   xmqqq NAV_SOL qj
x11  24   0 165   0 0110   xlqk
x12  27   0 165  50 0700   xxDOP [H] 100.0[V] 100.0[P] 100.0[T]

Re: [USRP-users] N310 Multi Device Configuration

2019-05-02 Thread Ali Dormiani via USRP-users
Hello fellow N310 users. My lab has 6 N310's all operating and streaming to
a single data server (10 Gbe links).

We use GNU Radio for everything. The software is great for controlling
multiple devices with many antennas easily (highly recommended). My
experience with native C++ UHD driver commands is rather limited.


Maybe RF mapping is the problem? There was a recent change where UHD 3.13 +
redid that stuff.

The N310 antenna mapping is available from here:

https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#N310_2

Never used it but it seems that UHD is expecting letters.



On Thu, May 2, 2019 at 10:52 AM Jorge Chen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi, Neharika and All,
>
> I met some problems on controlling 2 N310s too.
>
> But first of all, the argument "second_addr" indicates the IP addr. of
> the second SFP+ port on that device, and is set in the case of dual 10G
> streaming.
> I think the first way you wrote is the right way to access the 2 N310s,
> even though it is not listed in the Multiple USRP Configuration page.
> (https://files.ettus.com/manual/page_multiple.html)
> With that, I can control them (set rf parameters and receive signal on all
> 8 channels) without the error message you mentioned, what version of the
> UHD you're using? (UHD 3.13.1, 3.14 worked for me)
>
> My only problem is that they stop working (hang) at transmitting.
> An alternative way  is that I create 2 usrp objects to control them as the
> commands below.
>
> *uhd::usrp::multi_usrp::sptr tx_usrp_1
> = 
> uhd::usrp::multi_usrp::make("addr=192.168.30.3,master_clock_rate=122.88e6,clock_source=external,time_source=external")
>  uhd::usrp::multi_usrp::sptr
> tx_usrp_2
> = 
> uhd::usrp::multi_usrp::make("addr=192.168.40.3,master_clock_rate=122.88e6,clock_source=external,time_source=external")*
> Even though it works ( transmit signal simultaneously on all channels ), I
> don't think it's the best way (or right way) to use multiple USRPs.
>
> Has anyone done this before? or any suggestion?
>
> Thanks
> Jorge
>
>
>
> Neharika Valecha via USRP-users  於 2019年5月2日
> 週四 下午9:20寫道:
>
>> Hello,
>>
>> I am using two N310 USRP's to create an 8x8 MIMO setup. But, I am unable
>> to make both of them work together. I am using an example program from
>> the UHD driver - txrx_loopback_to_file.
>>
>> I give the following command:
>>
>> ./txrx_loopback_to_file --tx-rate 7.68e6 --rx-rate 7.68e6 --tx-freq
>> 2.60e9 --rx-freq 2.60e9 --tx-gain 70 --rx-gain 60 --tx-channels
>> "0,1,2,3" --rx-channels "0,1,2,3" --tx-args 
>> "addr=192.168.10.2,second_addr=192.168.20.2,time_source=external,clock_source=external,master_clock_rate=122.88e6"
>> --rx-args
>> "addr=192.168.10.2,second_addr=192.168.20.2,time_source=external,clock_source=external,master_clock_rate=122.88e6"
>> --settling 1
>>
>> and only one USRP turns on.
>> In USRP X300 there were two ways to use multiple USRP's,
>> 1. Use --tx-args and --rx-args to specify "addr0,addr1" to access two
>> different USRP's with --tx-channels and --rx-channels as "0,1". I tried
>> that here but it gives an error, "Error message: Someone tried to claim
>> this device again".
>>
>> 2. To define just one "addr" in --tx-args and --rx-args but have
>> --tx-channels and --rx-channels as "0,1,2,3" (as X300 is 2x2). When
>> tried with N310 with channel values "0,1,2,3,4,5,6,7" it gives an error
>> that Tx channels invalid.
>>
>> So, could you tell me what is the correct syntax to access two USRP's?
>>
>> Thank you
>> Neharika
>> ___
>> 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
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] E310 not locking on GPS

2019-05-02 Thread Dan CaJacob via USRP-users
GPS doesn't like to go back in time. You probably need to reset the almanac
and a reboot is doing that.

On Tue, Apr 30, 2019, 9:53 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I've seen this a few times, but I cannot seem to lock it down to any
> particular reason.  While sitting at my desk with a GPS simulator (so I
> have a known good signal), I will be doing testing and everything is fine
> (it seems to be walking around the place where the unit was built).  I will
> turn off the GPS unit for the night and then the next day when I turn it
> on, I never get a fix.  I've seen this numerous times and the only way I
> can fix it is to reboot the E310.  It is like the GPS is getting into a
> mucked up stated.  Data comes streaming through, but it is just the last
> good signal.
>
> I can't figure out a way to reset the GPS without rebooting it, does
> anyone know of a way?  I tried killing and restarting the daemon, but that
> doesn't seem to do anything.  I really think it is the GPS module, but
> rebooting it everytime I want to run things "just in case."
>
> One other weird thing, when I run gpsmon in this screwed up state, it
> mostly looks OK, but it has weird characters displayed throughout the ASCII
> heading (for lack of a better term).
>
> This is a good setup on a different unit (so I don't expect to see a fix):
> tcp://localhost:2947  u-blox>
> ┌──┐┌─┐
> or":11}
> │Ch PRN  Az  El S/N Flag U ││ECEF Pos: +6378137.00m  +0.00m  +0.00m
> │
> er":"u-blox","subtype":"Unknown","activated":"2018-10-10T06:21:07.701Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}]}
> │ 0   1   0 165   0 0110   ││ECEF Vel: +0.00m/s +0.00m/s
> +0.00m/s │ false,"timing":false,"split24":false,"pps":true}
> │ 1   2   0 165   0 0110   ││
> │
> │ 2   4   0 165   0 0110   ││LTP Pos:   0.0°   0.0°
> -18.00m │
> │ 3   6   0 165  23 0310   ││LTP Vel:0.00m/s   0.0°   0.00m/s
> │
> │ 4   7   0 165   0 0110   ││
> │
> │ 5   9   0 165  23 0310   ││Time: 0 00:00:00.00
>│
> │ 6  14   0 165  22 0310   ││Time GPS: Day:
> │
> │ 7  19   0 165  22 0310   ││
> │
> │ 8  20   0 165  21 0310   ││Est Pos Err998.72st Vel Err   0.00m/s
>│
> │ 9  21   0 165   0 0110   ││PRNs:  0 PDOP:100.0 Fix 0x00 Flags 0x40
>│
> │10  22   0 165   0 0110   │└─── NAV_SOL
> ─┘
> │11  23   0 165   0 0110
> │┌─┐
> │12  24   0 165   0 0110   ││DOP [H] 100.0[V] 100.0[P] 100.0[T] 100.0[G]
> 100.0│
> │13  28   0 165  23 0310   │└─── NAV_DOP
> ─┘
> │14  30   0 165   0 0110
> │┌─┐
> │15 136   0 165   0 0110   ││TOFF: > 1 dayPPS:
>│
>
> There are lines around the different sections (they look like lines, not
> dashes and bars).
>
>
> and then on the unit that is hosed:
> tcp://localhost:2947  u-blox>
> lqqklqk
> or":11}
> xCh PRN  Az  El S/N Flag U xxECEF Pos: -2414806.17m +5389584.51m
> +2400650.28m x
> er":"u-blox","subtype":"Unknown","activated":"2019-01-08T14:52:40.454Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}]}
> x 0   2   0 165  50 0700   xxECEF Vel: +0.00m/s +0.00m/s
> +0.00m/s x false,"timing":false,"split24":false,"pps":true}
> x 1   4   0 165  50 0700   xx
> x
> x 2   5   0 165  50 0700   xxLTP Pos:  22.2557151134f 114.134790532f
>  20.19m x
> x 3   8   0 165   0 0100   xxLTP Vel:0.00m/s   0.0f   0.00m/s
> x
> x 4   9   0 165  50 0700   xx
> x
> x 5  10   0 165  50 0700   xxTime: 61 06:13:40.00
> x
> x 6  12   0 165  50 0700   xxTime GPS: 1877+529282.000 Day: 6
> x
> x 7  13   0 165  50 0600   xx
> x
> x 8  17   0 165  50 0700   xxEst Pos Err2238690.24st Vel Err   0.00m/s
>x
> x 9  20   0 165  50 0700   xxPRNs:  0 PDOP:100.0 Fix 0x00 Flags 0xdc
>x
> x10  23   0 165  50 0700   xmqqq NAV_SOL
> qj
> x11  24   0 165   0 0110
> xlqk
> x12  27   0 165  50 0700   xxDOP [H] 100.0[V] 100.0[P] 100.0[T] 100.0[G]
> 100.0x
> x13  28   0 165  50 0700   xmqqq NAV_DOP
> qj
> x14 129 127  51   0 0110
> xlqk
> x15xxTOFF: > 1 dayPPS:
>x
> mqq NAV_SVINFO
> jmqj
>
> Not that instead of lines, I see characters.  What is up with that
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
_

Re: [USRP-users] Plagued by sporadic TX underruns on some systems, B200

2019-05-02 Thread Mark-Jan Bastian via USRP-users
Hi Mathhias,

On Thu, May 02, 2019 at 02:18:38PM +0200, Matthias Br??ndli via USRP-users 
wrote:
> On some systems, we observe sporadic underruns. They occur in irregular
> intervals, something like once a minute, sometimes rarer. Seen with both
> USB2 and USB3 hosts, over several UHD versions. Until now we've mostly
> been able to avoid the issue by selecting machines that don't show the
> issue, but we hope we can find a mitigation in software.

The USB bus is managed using a USB hostcontroller that uses busmastering/
scatter/gather over PCI/PCIe to retrieve and store it's data.
The USB 2.0 EHCI hostcontroller(s) are more straightforward than the 
XHCI hostcontroller used by USB 3, that has to deal with more complexity.

If 480 mbps is more than enough for your stream (2048 MSPS ~ 8 MB/sec
over a USB 2.0 bulk endpoint, using transactions of two times 512 bytes
every 125 usec (8000 Hz USB framerate) could satisfy your bandwidth
demands. You could even see these frames on a moderatly fast scope 
(500+ MHz), using a low-capacitance FET/active/differential probe and 
trigger on too much or a lack of them.

Another option is using a powered USB 2.0 or USB 3.0 hub. Since USB
hubs do not receive firmware updates, they should be very stable. 
If there is a problem with a USB enumuration timing/reset signalling 
or on the 5 gbps lanes, a hub might resolve an incompatibily in of one 
of the USB peers.

For more in-depth USB debugging, there are external USB 2.0 and 3.x 
hardware bus analysers available, for example from the swiss company
ellisys.com.
These can log all USB traffic to a PC and filter the data, without 
interfering on the timing of the signals - ideal tools for USB device 
development and debug compatibility issues.

For more in-depth PCIe transaction debugging of the USB host controllers, 
serialtek.com sells also PCIe 'AIC' hardware connector interposer 
cards that you can put between your motherboard and an external 
PCIe xHCI based USB hostcontroller.

> Both the data source the modulator connects to and the USRP have a
> disciplined time reference, implying there is no rate drift (plus, that
> would trigger regular underruns, not sporadic ones).

Some things can be very subtle, for example this (quite amazing)
2013 ethernet PHY bug:
https://www.theregister.co.uk/2013/02/06/packet_of_death_intel_ethernet/
Very tough engineering by the affacted customer, who made it reproducable
and fixed by a simple EEprom update from the vendor.

Pure theory: What if this intermittent issue would be an issue with a 
certain sequence of packetlengths, some of them on the boundary of the 
maximum size for that endpoint and endpointtype, that are not handled 
properly at one or both sides, causing a glitch/retransmission/faillure, 
resulting in the application-level visible underruns ?
How would you measure that ? How could you optimize the packetlengths 
so that the issue is quicker to reproduce ? Or avoid the issue by
anticipating and avoiding such packetsequences ?

> Could CPU frequency scaling lead to interruptions?

It would leave that off - less interference with thermal peak management or 
other system management mode interrupts from your motherboard, most constant 
performance in outputing your samples.

> [4]
> https://files.ettus.com/manual/page_transport.html#transport_usb
> 
> Default send_frame_size seems to be on line 85 of
> https://files.ettus.com/manual/b200__impl_8hpp_source.html

Best regards,

Mark-Jan

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] N310 Multi Device Configuration

2019-05-02 Thread Jorge Chen via USRP-users
Hi, Neharika and All,

I met some problems on controlling 2 N310s too.

But first of all, the argument "second_addr" indicates the IP addr. of
the second
SFP+ port on that device, and is set in the case of dual 10G streaming.
I think the first way you wrote is the right way to access the 2 N310s,
even though it is not listed in the Multiple USRP Configuration page.
(https://files.ettus.com/manual/page_multiple.html)
With that, I can control them (set rf parameters and receive signal on all
8 channels) without the error message you mentioned, what version of the
UHD you're using? (UHD 3.13.1, 3.14 worked for me)

My only problem is that they stop working (hang) at transmitting.
An alternative way  is that I create 2 usrp objects to control them as the
commands below.

*uhd::usrp::multi_usrp::sptr tx_usrp_1
= 
uhd::usrp::multi_usrp::make("addr=192.168.30.3,master_clock_rate=122.88e6,clock_source=external,time_source=external")
uhd::usrp::multi_usrp::sptr
tx_usrp_2
= 
uhd::usrp::multi_usrp::make("addr=192.168.40.3,master_clock_rate=122.88e6,clock_source=external,time_source=external")*
Even though it works ( transmit signal simultaneously on all channels ), I
don't think it's the best way (or right way) to use multiple USRPs.

Has anyone done this before? or any suggestion?

Thanks
Jorge



Neharika Valecha via USRP-users  於 2019年5月2日 週四
下午9:20寫道:

> Hello,
>
> I am using two N310 USRP's to create an 8x8 MIMO setup. But, I am unable
> to make both of them work together. I am using an example program from
> the UHD driver - txrx_loopback_to_file.
>
> I give the following command:
>
> ./txrx_loopback_to_file --tx-rate 7.68e6 --rx-rate 7.68e6 --tx-freq 2.60e9
> --rx-freq 2.60e9 --tx-gain 70 --rx-gain 60 --tx-channels "0,1,2,3"
> --rx-channels "0,1,2,3" --tx-args 
> "addr=192.168.10.2,second_addr=192.168.20.2,time_source=external,clock_source=external,master_clock_rate=122.88e6"
> --rx-args
> "addr=192.168.10.2,second_addr=192.168.20.2,time_source=external,clock_source=external,master_clock_rate=122.88e6"
> --settling 1
>
> and only one USRP turns on.
> In USRP X300 there were two ways to use multiple USRP's,
> 1. Use --tx-args and --rx-args to specify "addr0,addr1" to access two
> different USRP's with --tx-channels and --rx-channels as "0,1". I tried
> that here but it gives an error, "Error message: Someone tried to claim
> this device again".
>
> 2. To define just one "addr" in --tx-args and --rx-args but have
> --tx-channels and --rx-channels as "0,1,2,3" (as X300 is 2x2). When tried
> with N310 with channel values "0,1,2,3,4,5,6,7" it gives an error that Tx
> channels invalid.
>
> So, could you tell me what is the correct syntax to access two USRP's?
>
> Thank you
> Neharika
> ___
> 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


Re: [USRP-users] Plagued by sporadic TX underruns on some systems, B200

2019-05-02 Thread Luke Whittlesey via USRP-users
I've had similar issues on the e310 with similar sample rates. On the e310
no usb is involved. Unfortunately I have not been able to fully get rid of
the underrun issues as well.

So far I have tried:
- separate threads with ping-pong buffers: this helped
- linux real-time scheduling
- increasing the linux process nice value : this helped
- compiling with -O3 : this helped because I forgot initially
- making the buffers a multiple of tx_streamer::get_max_num_samps() :
https://github.com/EttusResearch/uhd/issues/128 : didn't help

With all of this I still get about 1 underrun an hour, but it is sporadic.

>From here I'm a bit stumped in looking for a software solution. Unless
there is something in UHD?

Some things that I haven't yet tried.
- increasing buffering on the FPGA : should give me more time before an
underrun
- pushing more of the work to the FPGA to reduce burden on the pc

On Thu, May 2, 2019 at 11:26 AM Ron Economos via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Setting a large number of UHD buffers can help quite a bit. In the GRC
> UHD Sink block device address:
>
> "num_send_frames=256"
>
> In Python:
>
>  self.uhd_usrp_sink_0_0 = uhd.usrp_sink(
>  ",".join(("num_send_frames=256", "")),
>  uhd.stream_args(
>  cpu_format="fc32",
>  channels=range(1),
>  ),
>  )
>
> Ron
>
> On 5/2/19 05:18, Matthias Brändli via USRP-users wrote:
> > Dear all,
> >
> > I'm maintaining ODR-DabMod[1], a Digital Audio Broadcasting modulator
> > which uses UHD to drive a USRP at 2048ksps, in most applications a B200.
> >
> > ODR-DabMod runs the modulator and the UHD output in separate threads, to
> > ensure that a few modulated frames are always ready when the USRP needs
> > one[2]. It requests realtime scheduling[3]. The system runs headless (no
> > X11 running), and generally doesn't have anything else running.
> >
> > On some systems, we observe sporadic underruns. They occur in irregular
> > intervals, something like once a minute, sometimes rarer. Seen with both
> > USB2 and USB3 hosts, over several UHD versions. Until now we've mostly
> > been able to avoid the issue by selecting machines that don't show the
> > issue, but we hope we can find a mitigation in software.
> >
> > Both the data source the modulator connects to and the USRP have a
> > disciplined time reference, implying there is no rate drift (plus, that
> > would trigger regular underruns, not sporadic ones).
> >
> >
> > There are some parameters described in USB Transport Parameters[4], does
> > it make sense to change those?
> >
> > Could CPU frequency scaling lead to interruptions?
> >
> > Are there other knobs to turn that I'm not aware of? Device, stream or
> > linux kernel settings?
> >
> > Is the approach of using a separate thread for UHD output beneficial?
> >
> > Anything else?
> >
> > Sorry for the vague description of the issue and the many questions, but
> > I'm a bit out of ideas about how to approach that. If anybody had
> > similar problems I'd be curious to hear your experiences.
> >
> > Cheers
> > mpb
> >
> > [1]
> > https://github.com/Opendigitalradio/ODR-DabMod
> >
> > [2]
> > Look for m_queue in
> >
> https://github.com/Opendigitalradio/ODR-DabMod/blob/master/src/output/SDR.cpp
> >
> > [3]
> > For all threads involved in DSP and the SDR output thread. Grep for
> > `set_realtime_prio`.
> >
> > [4]
> > https://files.ettus.com/manual/page_transport.html#transport_usb
> >
> > Default send_frame_size seems to be on line 85 of
> > https://files.ettus.com/manual/b200__impl_8hpp_source.html
> >
> > ___
> > 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
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] Plagued by sporadic TX underruns on some systems, B200

2019-05-02 Thread Ron Economos via USRP-users
Setting a large number of UHD buffers can help quite a bit. In the GRC 
UHD Sink block device address:


"num_send_frames=256"

In Python:

    self.uhd_usrp_sink_0_0 = uhd.usrp_sink(
        ",".join(("num_send_frames=256", "")),
        uhd.stream_args(
            cpu_format="fc32",
            channels=range(1),
        ),
    )

Ron

On 5/2/19 05:18, Matthias Brändli via USRP-users wrote:

Dear all,

I'm maintaining ODR-DabMod[1], a Digital Audio Broadcasting modulator
which uses UHD to drive a USRP at 2048ksps, in most applications a B200.

ODR-DabMod runs the modulator and the UHD output in separate threads, to
ensure that a few modulated frames are always ready when the USRP needs
one[2]. It requests realtime scheduling[3]. The system runs headless (no
X11 running), and generally doesn't have anything else running.

On some systems, we observe sporadic underruns. They occur in irregular
intervals, something like once a minute, sometimes rarer. Seen with both
USB2 and USB3 hosts, over several UHD versions. Until now we've mostly
been able to avoid the issue by selecting machines that don't show the
issue, but we hope we can find a mitigation in software.

Both the data source the modulator connects to and the USRP have a
disciplined time reference, implying there is no rate drift (plus, that
would trigger regular underruns, not sporadic ones).


There are some parameters described in USB Transport Parameters[4], does
it make sense to change those?

Could CPU frequency scaling lead to interruptions?

Are there other knobs to turn that I'm not aware of? Device, stream or
linux kernel settings?

Is the approach of using a separate thread for UHD output beneficial?

Anything else?

Sorry for the vague description of the issue and the many questions, but
I'm a bit out of ideas about how to approach that. If anybody had
similar problems I'd be curious to hear your experiences.

Cheers
mpb

[1]
https://github.com/Opendigitalradio/ODR-DabMod

[2]
Look for m_queue in
https://github.com/Opendigitalradio/ODR-DabMod/blob/master/src/output/SDR.cpp

[3]
For all threads involved in DSP and the SDR output thread. Grep for
`set_realtime_prio`.

[4]
https://files.ettus.com/manual/page_transport.html#transport_usb

Default send_frame_size seems to be on line 85 of
https://files.ettus.com/manual/b200__impl_8hpp_source.html

___
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


[USRP-users] OpenBTS with x310

2019-05-02 Thread Andrew Toomey via USRP-users
USRP Forum,

I am trying to get OpenBTS working with an x310 with UBX160 daughter cards
inside. My test phone can see my network but when I try to connect the
phone fails connection. I also have a B210 that is running on the same
machine that does allow the phone to successfully connect to my fake
network. I have noticed that the sample rate of the x310 cannot go as low
as the sample rate of the GSM protocol so I think this may be a source of
my problems. The sample rate of the B210 can reach the 270.833 KHz rate of
GSM.

My question is has anyone successfully created an OpenBTS network with an
x310 and UBX160 daughter cards. I have seen sources say that the x310 can
work with OpenBTS but have seen conflicting sources on which daughter cards
are compatible.

http://openbts.org/w/index.php?title=Ettus_Research_USRP  this source says
the UBX is not supported

https://kb.ettus.com/OpenBTS This sources says the UBS is supported

Any info on this subject would be greatly appreciated.

Thanks!
Andrew Toomey
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] Introducing Theseus Cores: Open source FPGA cores for DSP and SDR

2019-05-02 Thread Robert via USRP-users
Hi!

I agree with Johannes that Schmidl&Cox OFDM sync would be a nice extension. 

Do you plan to provide pre-built FPGA images containing Theseus Cores in the 
future for certain USRP devices? I guess this would make it even easier for 
first time users and would well suit the "batteries included" concept.

Cheers
Robert

-Original Message-
From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of 
Johannes Demel via USRP-users
Sent: Thursday, May 02, 2019 9:55 AM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Introducing Theseus Cores: Open source FPGA cores for 
DSP and SDR

Hi EJ,

this sounds like a very interesting project. Since you asked for ideas, 
I guess it would be nice to have a Schmidl&Cox style OFDM 
synchronization block.

Cheers
Johannes

Am 29.04.19 um 02:00 schrieb EJ Kreinar via USRP-users:
> Hi all,
> 
> I'm very happy to announce the (very modest) release of the Theseus 
> Cores project: https://gitlab.com/theseus-cores/theseus-cores
> 
> Theseus Cores is designed to provide open source FPGA cores for digital 
> signal processing and software defined radio, plus the means to *use* 
> the FPGA cores in real life In practice, that mostly means FPGA code 
> propagates up through RFNoC blocks which have both UHD and Gnuradio 
> software hooks for users to attach to. In the future it would be great 
> to support other FPGA platforms if there's interest too.
> 
> So far, Theseus Cores provides the following RFNoC FPGA blocks and 
> corresponding software:
> - *Polyphase M/2 Channelizer*: A polyphase channelizer where each 
> channel outputs 2x sample rate and is compatible with 
> perfect-reconstruction. Thanks to Phil Vallance for re-implementing the 
> channelizer described in his GRCon 2017 presentation-- it works!
> - *"1-to-N" DDC Chain*: Parameterized instantiations of "N" independent 
> DDCs, where each DDC is connected to the *first* input (a very basic, 
> brute force channelizer). Note I've seen several mailing list 
> discussions in the past year about 1-to-4 or 1-to-8 DDC channelizers -- 
> this block provides the generalized version of that scenario.
> - *DUC + DDC Rational Resampler*: A "hacked" rational resampler, 
> consisting of a DUC and a DDC back-to-back. It's not pretty, but it can 
> occasionally be helpful.
> 
> Furthermore, in an effort to TRY to create an open source FPGA project 
> that doesnt catastrophically break on a regular basis, we've set up 
> continuous integration tests for both software and FPGA. Dockerfiles are 
> provided here (https://gitlab.com/theseus-cores/theseus-docker). Theseus 
> Cores also pushes tagged docker images for various versions of UHD and 
> Gnuradio, where the branches for UHD-3.13, UHD-3.14, UHD's master, and 
> gnuradio's maint-3.7 are rebuilt weekly. This may be of auxiliary use to 
> people building UHD and gnuradio in a CI scenario: 
> https://hub.docker.com/u/theseuscores
> 
> *What's next??* It's a modest list of features so far, but I'm sure we 
> can all sympathize that things move slowly when developing FPGA code. 
> Here's a quick rundown of a few ideas on the horizon:
> - Arbitrary resampling
> - Channel downselection for the M/2 channelizer (currently all channels 
> must be output... it's far more useful to select a subset of channels to 
> return and just grab those)
> - Channel reconsonstruction *after* the M/2 channelizer (maybe)
> - OFDM receiver (maybe)
> 
> We need more ideas and contributors! Now that this thing exists, I would 
> LOVE to see Theseus Cores fill itself out with some of the more common 
> DSP utilities that really should be available as open-source... it would 
> be absolutely amazing to provide a library of components and 
> applications for FPGA developers in a similar way that gnuradio provides 
> for the software community. Please reach out with suggestions for 
> relevant FPGA utilities or applications you'd like to see -- or even 
> better, if you have ideas or code you're willing to share with the 
> project! If you are interested in getting involved in any way, I would 
> be happy to hear from you.
> 
> Cheers,
> EJ
> 
> ___
> 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
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] How to periodically write files using USRP and GNUradio

2019-05-02 Thread GhostOp14 via USRP-users
Ali, I just pushed a couple of updates.  Let's see if that fixes it for you.

I added:
1. [Timer] Some thread safety to the timer module.  I also noticed in my
flowgraph if I went to the top block options and turned on "realtime
scheduling" it was generally more accurate on the timing (makes sense).
2. [File Sink] Added a proper gnuradio stop() function to make sure files
get properly closed on exit. (Burns me every time swig doesn't
guarantee that C++ destructors get called so you really need to clean up in
stop().  I just get lazy sometimes)

Anyway do a fresh git pull and let me know if that fixes any of your issues
or if you still experience them.



On Wed, May 1, 2019 at 8:52 PM GhostOp14  wrote:

> Thanks Ali,
>
> I'll take a look at what you found with inconsistencies and see if I can
> hunt them down.
>
>
>
> On Wed, May 1, 2019 at 5:35 PM Ali Dormiani  wrote:
>
>> Hello GhostOp14 and USRP users,
>>
>> Your oot blocks are amazing. They do exactly what we need in a clean way.
>> In testing, we have found that there are rare anomalies though (occur like
>> a rare Poisson process).
>>
>> 1. Sometimes the advanced file sink will create an empty file of 0 bytes.
>>
>> 2. Sometimes the state timer messes up. We avoid a runaway data capture
>> by using the 'max file size' parameter in the advanced file sink.
>>
>> Overall, this solution is very good and eliminates a lot of variables
>> from our experiments. All of our USRP devices are initialized once and
>> constantly stream data (only some of which is saved). Our phase calibration
>> is a lot more consistent now.
>>
>> Thank you again for providing these oot blocks on Github. My own custom
>> embedded python block was inelegant and inconsistent.
>>
>> Cheers,
>>
>> Ali
>>
>>
>> On Wed, May 1, 2019 at 6:19 AM GhostOp14 via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Morning everyone, not sure my note yesterday hit the list correctly so
>>> I'm trying again.
>>>
>>> Mark: I have a solution for you.  I added a new block yesterday to
>>> gr-filerepeater (pybombs or github).  There's now a state timer block
>>> that'll generate a message based on block-specified timing.  Trigger time,
>>> cycle time, etc.  gr-filerepeater also has a new file sink block I've added
>>> in the past couple of weeks specifically to address the same kind of
>>> problem.  You can feed the timer msg out to the new sink msg in.  The new
>>> block will then key off the state (1/0) in the msg metadata and start/stop
>>> writing to a file.  You can specify a directory and a base file name, then
>>> every time a new file write is started it'll append a timestamp.  Should
>>> exactly match up to what you're trying to accomplish.  I'll post on the
>>> gnuradio list as well since they're gnuradio blocks.
>>>
>>>
>>>
>>> On Mon, Apr 29, 2019 at 8:24 PM Marcus D. Leech via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 On 04/29/2019 08:08 PM, Mark Wagner via USRP-users wrote:
 > Hey all,
 >
 > I'd like to know how to write short files of streamed USRP data
 > periodically using GNUradio. For instance, I'd like the USRP to
 > automatically record 5 seconds of data every 10 minutes. It does not
 > matter to me whether the USRP is constantly on and most of the data
 is
 > being discarded, or if the USRP wakes up every 10 minutes to record
 > the data before sleeping. Whichever is easiest to achieve is fine by
 > me. Does anyone have experience doing this kind of thing?
 >
 > -Mark
 >
 >
 >
 > --
 > Mark Wagner
 > University of California San Diego
 > Electrical and Computer Engineering
 >
 >
 If you're using Gnu Radio, you can simply use the file sink, and have
 it
 record to "/dev/null" most of the time, then have something (perhaps via
the XMLRPC built-in feature) change the filename to whatever your
 desired filename is, and then revert it back to "/dev/null".

 I think I said the same thing on the discuss-gnuradio mailing list a
 few
 days ago.

 The usrp-users mailing list isn't the best place to ask Gnu Radio
 questions, a question like this, which is inherently radio-type
 agnostic, probably
belongs on the discuss-gnuradio mailng list, because it's more about
 "how do I make Gnu Radio dance".



 ___
 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
>>>
>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


[USRP-users] N310 Multi Device Configuration

2019-05-02 Thread Neharika Valecha via USRP-users
Hello,

I am using two N310 USRP's to create an 8x8 MIMO setup. But, I am unable to
make both of them work together. I am using an example program from the UHD
driver - txrx_loopback_to_file.

I give the following command:

./txrx_loopback_to_file --tx-rate 7.68e6 --rx-rate 7.68e6 --tx-freq 2.60e9
--rx-freq 2.60e9 --tx-gain 70 --rx-gain 60 --tx-channels "0,1,2,3"
--rx-channels "0,1,2,3" --tx-args
"addr=192.168.10.2,second_addr=192.168.20.2,time_source=external,clock_source=external,master_clock_rate=122.88e6"
--rx-args
"addr=192.168.10.2,second_addr=192.168.20.2,time_source=external,clock_source=external,master_clock_rate=122.88e6"
--settling 1

and only one USRP turns on.
In USRP X300 there were two ways to use multiple USRP's,
1. Use --tx-args and --rx-args to specify "addr0,addr1" to access two
different USRP's with --tx-channels and --rx-channels as "0,1". I tried
that here but it gives an error, "Error message: Someone tried to claim
this device again".

2. To define just one "addr" in --tx-args and --rx-args but have
--tx-channels and --rx-channels as "0,1,2,3" (as X300 is 2x2). When tried
with N310 with channel values "0,1,2,3,4,5,6,7" it gives an error that Tx
channels invalid.

So, could you tell me what is the correct syntax to access two USRP's?

Thank you
Neharika
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] E320 numpy missing?

2019-05-02 Thread Jason Matusiak via USRP-users
Chris,

It is a shame that the E320 doesn't seem to have complete support, but maybe 
someone from Ettus will chime in at some point (though it has already been over 
a month since you posted).  As of now, these are paperweights in our office and 
I have to switch gears to a different project with a different vendor until it 
gets updated.  I am not sure who we can even ping at Ettus on the embedded 
front in case they aren't monitoring the mailing list.  Do you have a contact 
there on the embedded side?

You don't happen to have a series of steps posted somewhere that you use to try 
to get the E320 to a usable state do you?




From: USRP-users  on behalf of Chris 
Gobbett via USRP-users 
Sent: Wednesday, May 1, 2019 9:21 PM
To: Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?

I've had similar problems since this post in March, and still waiting on a 
'clean' way forward
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-March/059332.html

In the interim I've done lots of cross-compiling and also stealing 
libraries/binaries from working E310 images; many of the included binaries seem 
gimped or a step down from what was on the E310.

- Original Message -
From:
"Jason Matusiak" 

To:
"Philip Balister" , "Ettus Mail List" 

Cc:

Sent:
Wed, 1 May 2019 14:40:16 +
Subject:
Re: [USRP-users] E320 numpy missing?


I just double-checked and ENABLE_PYTHON is on in my system (which was 
apparently the default since I didn't spell it out in my cmake command).


From: Jason Matusiak
Sent: Wednesday, May 1, 2019 10:36 AM
To: Philip Balister; Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?

I actually was using a .sh file from earlier in April, but pulling down the 
most recent: e3xx_e320_sdk_default-v3.13.0.2-20190415.zip, I still don't see 
pretty much any site-packages in the sysroot.

Those things seem to be there automatically when using the .sh info with the 
e310 files.

I will try including python in the cmake path (which I've never needed to do 
before), but is that going to be enough?  I feel like the back-and-forth you 
and I had last year with the rocko build for the E310 were for pretty similar 
issues.  But honestly, I need to look back at the emails for the exact issues 
at the time.


From: Philip Balister 
Sent: Wednesday, May 1, 2019 10:31 AM
To: Jason Matusiak; Ettus Mail List
Subject: Re: [USRP-users] E320 numpy missing?

On 05/01/2019 09:55 AM, Jason Matusiak via USRP-users wrote:
> I also get a "ImportError: No module named sip" when I try to run: 
> uhd_siggen_gui
>
> So I think a few things might be missing from the cross-compile setup.

I took a few minutes and looked at the current state of the BSP. It
looks like you might have this image:

https://github.com/EttusResearch/meta-ettus/blob/master/meta-ettus-core/recipes-core/images/developer-image.bb

I forget where numpy is the gnuradio dependency tree, but I'm going to
guess if you enable python support in gnuradio (yes it might be possible
to use gnuradio without python) you will need numpy to build/run.

Philip

>
> 
> From: Jason Matusiak
> Sent: Wednesday, May 1, 2019 8:46 AM
> To: Ettus Mail List
> Subject: E320 numpy missing?
>
> Finally got my E320 in and I cross-compiled a new setup.  I tried to fire up 
> my flowgraph (which works fine on an E310) and it is complaining about numpy 
> missing.
>
> If I do a search from / on the E320, the only numpy that is showing up is:
> /usr/include/boost/python/numpy
>
> If I do a search from a good E310 in / I see:
> ./usr/lib/python2.7/site-packages/numpy
> ./usr/lib/python2.7/site-packages/numpy/core/include/numpy
> ./usr/lib/python2.7/site-packages/Cython/Includes/numpy
> ./usr/include/boost/python/numpy
>
>
> Back on the host machine, my E320 cross-compile prefix shows numpy:
> ./sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy
>
> My good E310 prefix shows:
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/build/src.linux-x86_64-2.7/numpy/core/include/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/src/debug/python-numpy/1.13.1-r0/numpy-1.13.1/numpy/core/include/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/Cython/Includes/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/lib/python2.7/site-packages/numpy/core/include/numpy
> ./sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/boost/python/numpy
>
> So, was numpy forgotten?  Left out for a reason?  I am going to attempt to 
> build it by hand, 

[USRP-users] Plagued by sporadic TX underruns on some systems, B200

2019-05-02 Thread Matthias Brändli via USRP-users
Dear all,

I'm maintaining ODR-DabMod[1], a Digital Audio Broadcasting modulator
which uses UHD to drive a USRP at 2048ksps, in most applications a B200.

ODR-DabMod runs the modulator and the UHD output in separate threads, to
ensure that a few modulated frames are always ready when the USRP needs
one[2]. It requests realtime scheduling[3]. The system runs headless (no
X11 running), and generally doesn't have anything else running.

On some systems, we observe sporadic underruns. They occur in irregular
intervals, something like once a minute, sometimes rarer. Seen with both
USB2 and USB3 hosts, over several UHD versions. Until now we've mostly
been able to avoid the issue by selecting machines that don't show the
issue, but we hope we can find a mitigation in software.

Both the data source the modulator connects to and the USRP have a
disciplined time reference, implying there is no rate drift (plus, that
would trigger regular underruns, not sporadic ones).


There are some parameters described in USB Transport Parameters[4], does
it make sense to change those?

Could CPU frequency scaling lead to interruptions?

Are there other knobs to turn that I'm not aware of? Device, stream or
linux kernel settings?

Is the approach of using a separate thread for UHD output beneficial?

Anything else?

Sorry for the vague description of the issue and the many questions, but
I'm a bit out of ideas about how to approach that. If anybody had
similar problems I'd be curious to hear your experiences.

Cheers
mpb

[1]
https://github.com/Opendigitalradio/ODR-DabMod

[2]
Look for m_queue in
https://github.com/Opendigitalradio/ODR-DabMod/blob/master/src/output/SDR.cpp

[3]
For all threads involved in DSP and the SDR output thread. Grep for
`set_realtime_prio`.

[4]
https://files.ettus.com/manual/page_transport.html#transport_usb

Default send_frame_size seems to be on line 85 of
https://files.ettus.com/manual/b200__impl_8hpp_source.html

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] Introducing Theseus Cores: Open source FPGA cores for DSP and SDR

2019-05-02 Thread Johannes Demel via USRP-users
Hi EJ,

this sounds like a very interesting project. Since you asked for ideas, 
I guess it would be nice to have a Schmidl&Cox style OFDM 
synchronization block.

Cheers
Johannes

Am 29.04.19 um 02:00 schrieb EJ Kreinar via USRP-users:
> Hi all,
> 
> I'm very happy to announce the (very modest) release of the Theseus 
> Cores project: https://gitlab.com/theseus-cores/theseus-cores
> 
> Theseus Cores is designed to provide open source FPGA cores for digital 
> signal processing and software defined radio, plus the means to *use* 
> the FPGA cores in real life In practice, that mostly means FPGA code 
> propagates up through RFNoC blocks which have both UHD and Gnuradio 
> software hooks for users to attach to. In the future it would be great 
> to support other FPGA platforms if there's interest too.
> 
> So far, Theseus Cores provides the following RFNoC FPGA blocks and 
> corresponding software:
> - *Polyphase M/2 Channelizer*: A polyphase channelizer where each 
> channel outputs 2x sample rate and is compatible with 
> perfect-reconstruction. Thanks to Phil Vallance for re-implementing the 
> channelizer described in his GRCon 2017 presentation-- it works!
> - *"1-to-N" DDC Chain*: Parameterized instantiations of "N" independent 
> DDCs, where each DDC is connected to the *first* input (a very basic, 
> brute force channelizer). Note I've seen several mailing list 
> discussions in the past year about 1-to-4 or 1-to-8 DDC channelizers -- 
> this block provides the generalized version of that scenario.
> - *DUC + DDC Rational Resampler*: A "hacked" rational resampler, 
> consisting of a DUC and a DDC back-to-back. It's not pretty, but it can 
> occasionally be helpful.
> 
> Furthermore, in an effort to TRY to create an open source FPGA project 
> that doesnt catastrophically break on a regular basis, we've set up 
> continuous integration tests for both software and FPGA. Dockerfiles are 
> provided here (https://gitlab.com/theseus-cores/theseus-docker). Theseus 
> Cores also pushes tagged docker images for various versions of UHD and 
> Gnuradio, where the branches for UHD-3.13, UHD-3.14, UHD's master, and 
> gnuradio's maint-3.7 are rebuilt weekly. This may be of auxiliary use to 
> people building UHD and gnuradio in a CI scenario: 
> https://hub.docker.com/u/theseuscores
> 
> *What's next??* It's a modest list of features so far, but I'm sure we 
> can all sympathize that things move slowly when developing FPGA code. 
> Here's a quick rundown of a few ideas on the horizon:
> - Arbitrary resampling
> - Channel downselection for the M/2 channelizer (currently all channels 
> must be output... it's far more useful to select a subset of channels to 
> return and just grab those)
> - Channel reconsonstruction *after* the M/2 channelizer (maybe)
> - OFDM receiver (maybe)
> 
> We need more ideas and contributors! Now that this thing exists, I would 
> LOVE to see Theseus Cores fill itself out with some of the more common 
> DSP utilities that really should be available as open-source... it would 
> be absolutely amazing to provide a library of components and 
> applications for FPGA developers in a similar way that gnuradio provides 
> for the software community. Please reach out with suggestions for 
> relevant FPGA utilities or applications you'd like to see -- or even 
> better, if you have ideas or code you're willing to share with the 
> project! If you are interested in getting involved in any way, I would 
> be happy to hear from you.
> 
> Cheers,
> EJ
> 
> ___
> 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