UmTRX integration into UHD

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/UmTRX@lists.osmocom.org/.

Thomas Tsou thomastsou at gmail.com
Mon Feb 13 03:18:22 UTC 2012


On Sat, Feb 11, 2012 at 6:47 AM,  <Max.Suraev at fairwaves.ru> wrote:
> I think we would stick to option 3 (separate umtrx folder) - because it'll become
> pretty messy over time (essentially every place where clock or codec controller is
> used requires alteration). Also It seems that with this approach it will be easier to
> push UMTRX support into upstream once it's mature enough.

Those are good points. I agree.

> This brings up another question: where does dispatching happens? E. g. which codepath
> is used to choose between usrp1, usrp2 and umtrx?

Each "usrp" has it's own find / make calls that are registered into
the "device function registry container" before main(). That occurs
with the UHD_STATIC_BLOCK macro, which is basically a memberless,
constructor object. When called, the device::find and device::make
iterate through the registered find / make tuples. I think 'make' uses
the first discovered device if no arguments are passed in.

> Is there some technical reason why we can't use something like '#include
> "../usrp2/io_impl.cpp"' inside /umtrx/umtrx_iface.hpp for example? Or it's purely
> question of aesthetics?

Not really. For the current Ettus devices, the io_impl.cpp
implementations really are different, so it doesn't make any sense.

  Thomas



More information about the UmTRX mailing list