On Wed, Jul 1, 2015 at 6:22 AM, Nguyễn Văn Lý
wrote:
> I solved my problem by using the argument *bladerf=i* with *i* = 0,1,2,3
>
> On Wed, Jul 1, 2015 at 5:14 PM, Nguyễn Văn Lý
> wrote:
>
>> Hi all,
>>
>> I want to use 4 bladeRF devices on a single laptop. This means I have to
>> load the FPGA
>
>
> I'm wondering if we might add a #define for the multimap change... that
> way, one could conditionally compile in a std::sort if required.
>
>
Hi Martin,
For what it's worth, I like that idea. It feels a little icky to be doing
an unnecessary sort just to ensure the code won't break.
Cheer
ay result in the tags
>>> being presented in order (I don't recall off the top of my head if
>>> std::multimap guarantees that, although I can imagine many/most
>>> implementations may store them in-order).
>>>
>>> I don't know if GNURadio wish
Hi all,
When calling gr::block::get_tags_in_range() or
gr::block::get_tags_in_window(), does the GNU Radio API guarantee that the
returned vector will be sorted based upon the tag offsets (from "earliest"
to "latest")?
Since the API docs [1] do not explicitly state this to be the case, I would
as
On Mon, Jun 15, 2015 at 4:54 PM, Philip Balister
wrote:
>
> For the next year, I'd like to get more people actually using the
> infrastructure we have. I'd like to get a list of gnuradio apps together
> and start validating they run on various embedded platforms.
>
As someone who's been followi
