Hello,
I'm having trouble figuring out how to correctly send PDUs to the UHD USRP
Sink. It's my understanding (mostly from [1] and [2]) that you can send a
PDU with
- a dictionary car containing "tx_sob" set to PMT_T, (and maybe
"tx_time" formatted according to notes in [2] or in the source
On Thu, Nov 10, 2016 at 04:17:25PM +0100, Marcus Müller wrote:
> > RF block duration is directly propotional to audio frame durations.
> > 100ms of RF block duration will corresponds to 100ms of audio.
>
> no! And that's exactly the problem. In theory, it should be the way, but
> because neither
On Thu, Nov 10, 2016 at 8:07 AM, Bastian Bloessl
wrote:
> I don't know a good solution, but when I had a similar problem, I ended up
> with:
>
> - the file parser creates an initial message
> - the sync block sends a message back to the file parser when it converted
> the message into stream dom
Hi Ben,
the flowgraph is not tested at all as I have no DRM+ receiver to test
against. I'm not aware of any other open source implementations.
- Felix
On 11/09/2016 05:29 PM, Benny Alexandar wrote:
>
> Hi Felix,
>
>
> Any update on DRM+, I'm planning to use DRM+ transmission using
> gr-drm. I
Good point - I'll play around with that idea. Thanks!
On Thu, Nov 10, 2016 at 11:32 AM, Bastian Bloessl
wrote:
> OK that makes sense, but note that the approach can easily be extended to
> having always N messages in the queue (just create N initial messages). So
> it would not necessarily intro
OK that makes sense, but note that the approach can easily be extended to
having always N messages in the queue (just create N initial messages). So it
would not necessarily introduce a lot of delay.
Best,
Bastian
> On 10 Nov 2016, at 17:27, Michael Wentz wrote:
>
> Bastian,
>
> Thanks for
Bastian,
Thanks for the suggestion, it's a good idea but may not meet my
requirements (my messages have timestamps, some spaced very closely
together, and I'd rather have those loaded up in the queue as soon as
possible rather than have to go through a handshaking process).
I ended up moving my f
I don't know a good solution, but when I had a similar problem, I ended
up with:
- the file parser creates an initial message
- the sync block sends a message back to the file parser when it
converted the message into stream domain
- this message triggers sending the next (actual) message in th
On Wed, Nov 9, 2016 at 8:36 PM, Tom Early wrote:
> I guess it would be helpful if the on-line documentation were updated (at
> least in the OOT tutorial) with:
>
Good suggestion; I've added this as an issue in our tracker:
https://github.com/gnuradio/gnuradio/issues/1087
-Johnathan
Benny,
> RF block duration is directly propotional to audio frame durations.
100ms of RF block duration will corresponds to 100ms of audio.
no! And that's exactly the problem. In theory, it should be the way, but
because neither the RF clock nor the audio DAC rate are exactly what
they should be,
Nathan,
I don't have any other queue in my block - it's just the one associated
with the message port. The following starts printing once I send too many
messages (before the block downstream has started processing them):
WARN ASYNCHRONOUS MESSAGE BUFFER OVERFLOWING; DROPPING MESSAGE
Looking at
Hi Fons,
>The only time that would make sense would be the
>timestamp at the A/D converter of the RF sample that in some way
>corresponds to the start of the compressed frame. And even that
>assumes that there is simple linear relation between the RF samples
>and audio samples.
Yes, thats right.
12 matches
Mail list logo
