discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] guard band


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] guard band
Date: Sun, 22 Jun 2014 18:19:57 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

Sara,

> If there is a call established between the 2 end users but they are
not speaking , then no new packets to send ?

This is not a question for the GNU Radio mailing list, since this is a
characteristic of the soft phone, obviously.

>  If there is no new packets coming , I want to send zeros instead of
repeating the sent packets , How Can I do this ?

How and why would you repeat packets? There's no mechanism for that that
I would know of.

Ok, so to make this as short as possible, here's my deduction on your
question:

- you don't know the "real world" rate at which packets are generated by
your soft phone. If you knew, you wouldn't be asking, because then you
would just be padding them to match the over-the-air bit rate [0].

- knowing when to wait for a packet or when to zero-pad would require
knowing how much voice duration was carried in one packet AND how much
real-world time has passed. Knowing that requires knowing what kind of
information these packets carry. My first mail regarding how to deal
with RTP packets applies.

- you want to transfer packeted data, but you want to construct a
continuously streaming transmitter; while this is possible[1], it's
certainly not really easy to implement cleanly in GNU Radio and not very
intuitive, either. I'd recommend going for bursted transmission using
the start-of-burst tag functionality.


Greetings,
Marcus

[0] ... which would be, information-theoretically, a bad thing to do, if
the amount of padding was significant: compressing speech (ie. removing
redundancy) and transmitting that at a higher bitrate just to add zeros
to match the original bit rate is really just reducing your energy per
bit. You'll probably get a better transmission if you were to reduce
your transmission symbol rate to match your soundcard's sample rate and
transmit uncompressed audio, and you would be avoiding all the hassle
you're experiencing now.
[1] This is usually done when re-synching is expensive. A typical
example for these kind of transceivers are wireless optical networks,
where the medium is often occupied by a rectangle signal, unless there
is a packet on there, which has a preamble. Using GNU Radio, detection
of preambled packets has gotten easier, compare the modern gr-digital
examples, and clock recovery is, if needed, possible, so there usually
is no need to continuously occupy your carrier with zeros.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]