Yes, it's possible. The use of the rational re-sampler
is to be compatible with commercial DVB-T receivers.
If you're just interested in USRP to USRP, then it's
okay to use a 10 Msps sample rate. The signal will
be slightly wider than a standard 8 MHz signal at
9.142857 Msps.
You can modify my DV
Enjoy,
http://youtu.be/fbcYt0UGX9k
Philip
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Jonathan Fox wrote
> Hey List,
>
> I have two scripts I am running, the ofdm_v1_tx_freq_test.py and the RX
> version of it (see flow graph images and attached transmitter Python
> script). I am transmitting a sinusoid using OFDM modulation over the USRP,
> it works perfectly.
>
> I have made an a
> (this=0xaca2e0) at
> /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146
>
>
#16 0x7f0317585e91 in boost::detail::shared_count::~shared_count
> (this=0xadb1a0, __in_chrg=) at
> /usr/include/boost/smart_ptr/detail/shared_count.hpp:371 #17
> 0x7f0317591d0a in
I'll be starting the hangout promptly at 1700 UTC. (That's 1 PM EDT)
I am 99.9% certain I will start the hangout by inviting one person, then
posting a link in the #gnuradio irc channel. This worked an hour ago, so
I expect things to go smoothly today.
Philip
On Wed, Apr 16, 2014 at 3:38 PM, Azza wrote:
> Tom Rondeau-2 wrote
> > On Wed, Apr 16, 2014 at 2:06 PM, Azza <
>
> > azza.ben.mosbah@
>
> > > wrote:
> >
> >> Tom Rondeau-2 wrote
> >> > On Wed, Apr 16, 2014 at 10:57 AM, Azza <
> >>
> >> > azza.ben.mosbah@
> >>
> >> > > wrote:
> >> >
> >> >> Thank
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Also, if using encryption over a wireless link, you'll need some way
to ensure that damaged data gets resent, or to ensure a damaged block
does not affect the decryptability of following data.
So I think your flowgraphs should read
Mic/Soundcard -> l
There is no crypto in the main GNU Radio installation. I am not aware of any
public out-of-tree modules that implement crypto. Your best bet would probably
be handling crypto at the data socket layer and pushing to a GNU Radio
PDU-to-tagged-stream or using GR's message passing interface to pass
Question 3: AES is indeed a common system for voice encryption, widely used
for example in US police / public safety radios (APCO25 standard). Older
systems used often DES, but not with a neat linear predictive voice codec,
but just a CVSD digitizer, DES box and FSK radio link (Motorola SECURENET).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Iftah,
usually you'd run it with a debugger, and try to find out where
exactly the access violation happens.
Greetings,
Marcus
On 17.04.2014 16:12, iftah giladi wrote:
> Hey,
>
>
>
> In order to start my on application code using the uhd code,
Hey,
In order to start my on application code using the uhd code, I tried
creating a new blank project ,and did all
The necessary includes, and library include in the linker an compiler and so
on..
As a starter I copied the uhd_find_devices.cpp to my project lib and build
it.
It's run o.k
Hi all,
I want to simulate a voice transmission system in GNURadio Companion (GRC)
before I build a real one. My system configuration is as follows.
TX:
mic --> encoder --> encryption --> modulator --> RF
Rx:
speaker <-- decoder <-- decryption <-- demodulator <-- RF
I have succeed in simulati
Can I trans/receive without Rational Resampler?
It distorts the signal too much :(
Mon, 31 Mar 2014 20:12:27 +0400 от Nasi :
>Thanks a lot! I will try them too...
>
>
>Mon, 31 Mar 2014 09:08:04 -0700 (PDT) от Bogdan Diaconescu
>:
>>
>>One thing I did once and worked are:
>>
>>1. Use a file sink
Hi all,
I want to simulate a voice transmission system in GNURadio Companion (GRC)
before I build a real one. My system configuration is as follows.
TX:
mic --> encoder --> encryption --> modulator --> RF
Rx:
speaker <-- decoder <-- decryption <-- demodulator <-- RF
I have succeed in simulati
Hi all,
I want to simulate a voice transmission system in GNURadio Companion (GRC)
before I build a real one. My system configuration is as follows.
TX:
mic --> encoder --> encryption --> modulator --> RF
Rx:
speaker <-- decoder <-- decryption <-- demodulator <-- RF
I have succeed in simulatin
>>> Sounds plausible. Ctest is actually just running a shell script.
You can try running that script through gdb. The name of the script will
be printed near the top of ctest -V. Alternatively you should be able to
find it in
$build/modname/python/namespace/qa_whatever_your_test_is_called.sh; a
16 matches
Mail list logo
