Re: [Discuss-gnuradio] embed fix sequence in payload part

2007-06-29 Thread Tom Rondeau

pratik hetamsaria wrote:

hi..

i am trying to embed a fixed sequence which i want to recover during 
demodulation. I have read from the previous archives that it would be 
easier to embed it in the payload part.However, as soon as i add 
anything in the payload part, and try to receive using rx_voice, i get 
an error saying


terminate called after throwing an instance of 'std::runtime_error'
  what():  msg length is not a multiple of d_itemsize
Aborted (core dumped)

What I have understood is that the msg length changes as soon as I add 
something to the payload.If I dont do anything and just run 
rx_voice.py then the msg length comes to be 1687/1720


I have tried getting the msg length after adding different sequences.
If i change the code as:
payload = payload + preamble, the msg length changes to 1719

Otherwise, If i change as:
payload = payload + default_access_code
the msg length changes to 1751

where default_access_code and preamble are given in packet_utils.py.

I have not been able to find out the value of d_itemsize or what 
should be its value so that the code runs.


I would be very grateful for any help.

Thanking you,
Pratik Hetamsaria


Pratik,

I'm not entirely sure what you're trying to do. Which example code are 
you using? And also, what's the purpose of what you are trying to do? 
That might help us set you in the right direction.


Please list the code where you are making the change to add your fixed 
sequence.


Tom




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Transmitting a binary 'ones and zeroes' file for Bit Error Analysis

2007-06-29 Thread Tom Rondeau

rashi dixit wrote:

Hello Everyone

I am currently working on binary file transmission from one system to 
another, but couldnt figure a way out yet.


Using tx_voice.py when I send a binary file with just an arbitrary 
stream of ones and zeroes, data is read and transmitted as packets 
well. But unfortunately, on receival side on the retrieval of data, it 
isnt written back into the file in the binary format as originally but 
a combinations of bits are clubbed and expressed by incomprehensible 
hashes and stars. So the data cant be deciphered.


I tried using the GMSK modulation scheme. But the binary data chunks 
are filtered out during transmission onlyprobably due to the 
gaussian filter. Please check me out if I am wrong.


Could anyone suggest a way for a ones and zeroes file to be 
transmitted? My final aim is  to find the 'Bit error rate' of 
transmission form one node to another.


Also is there any way of comparing two binary files? I mean how should 
one approach the bit error analysis keeping correlation in mind etc?


Thanking you all
Rashi Dixit


Rashi,

I'm not sue why you are using tx_voice.py for this. It seems to make 
more sense to use benchmark_tx.py and benchmark_rx.py in the /digital 
examples directory. This will modulate the bits with GMSK by default. 
Keep in mind, though, that you _want_ to modulate the data before 
transmitting it over the air.


The GNU Radio file sink/source write and read files as binary data, so 
the files will look like hashes and stars when viewed with a text 
editor. You can use gnuradio-core/src/utils/read_*_binary.m in 
Matlab/Octave to read these files.


However, I'm not sure you want to just compare the output file to the 
input file unless you also keep track of a packet number. If the header 
is missed or corrupted in the current implementation, the packet is 
completely dropped, which would completely screw up your calculations 
unless you can tell that a full packet has been lossed. Then, you have 
to decide how you want to handle the BER calculation due to one lost 
packet.


Tom




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] 802.11b Headers

2007-06-29 Thread Teun

Hi Guys,

First of all, thanks for all the help you have been giving me, it was really
helpful for me to understand the  USRP / GNU Radio package. 

I'm hoping someone from the BBN group is reading this, or anyone else who
has an idea. 
Within our research group we are interested in decoding 11b/(g?) packet
headers. I have installed the 802.11 BBN code, which runs really good. Even
when I compare it to my laptop, equipped with a packet sniffer, the detected
packets match perfectly. However, the code decodes packets with a data rate
of 1Mbit and occasionally a 2Mbit packets due to the USB limitations. We
would like to detect "all" packets, at least their headers containing the
useful information. Header files use a low modulation type, so I think we
should always be able to capture the header of a packet. Does anyone see any
difficulties in doing so? 

Any comments are really useful.


Thanks again,

Teun
-- 
View this message in context: 
http://www.nabble.com/802.11b-Headers-tf3999092.html#a11357744
Sent from the GnuRadio mailing list archive at Nabble.com.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] 802.11b Headers

2007-06-29 Thread Daniel Sumorok

Hello Teun,
  There are two rates for the 802.11b physical headers - 1 Mbps, and 2 
Mbps.  Most likely, packets that use the CCK modulation (5.5 and 11 Mbps) 
use the 2 Mbps physical header.  I never got the 2 Mbps header decoding 
working properly for some reason, although the code does try to decode 2 
Mbps headers.  (It could detect that a 2 Mbps header was there, and often 
got some of the bits correct...) By the way, these headers don't really 
contain that much more information than the packet length and the data rate 
- however if you want to debug this, I can point you to the appropriate 
places in the code.


  -Dan

At 05:51 AM 6/29/2007, Teun wrote:


Hi Guys,

First of all, thanks for all the help you have been giving me, it was really
helpful for me to understand the  USRP / GNU Radio package.

I'm hoping someone from the BBN group is reading this, or anyone else who
has an idea.
Within our research group we are interested in decoding 11b/(g?) packet
headers. I have installed the 802.11 BBN code, which runs really good. Even
when I compare it to my laptop, equipped with a packet sniffer, the detected
packets match perfectly. However, the code decodes packets with a data rate
of 1Mbit and occasionally a 2Mbit packets due to the USB limitations. We
would like to detect "all" packets, at least their headers containing the
useful information. Header files use a low modulation type, so I think we
should always be able to capture the header of a packet. Does anyone see any
difficulties in doing so?

Any comments are really useful.


Thanks again,

Teun
--
View this message in context: 
http://www.nabble.com/802.11b-Headers-tf3999092.html#a11357744

Sent from the GnuRadio mailing list archive at Nabble.com.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Transmitting a binary 'ones and zeroes' file for Bit Error Analysis

2007-06-29 Thread rashi dixit
Hey Tom

Thanks for the tip to use benchmark files for the same.On going through them 
made me realize they are just as identical to tx_voice.py, rx_voice.py !

And just as you had said, it would be necessary to keep track of the packets 
but I havent yet been able to figure out a way to overcome the lost packet 
situation.

The bottleneck is that if I could attach header (external preamble)from my side 
to the data then the sequence could be tracked. On trying to attach external 
data I dug through the code of pkt.py and packet_utils.py in  
usr/local/lib/python2.4/site-packages/gnuradio/blksmpl and attached a string to 
'payload' from my side.

Many-a-times receiver rejects the incoming packet saying:

 
terminate called after throwing an instance of 'std::runtime_error'
  what():  msg length is not a multiple of d_itemsize
Aborted (core dumped)

Could you the suggest a possible way to overcome this error?

Thanks again!
Rashi



Tom Rondeau <[EMAIL PROTECTED]> wrote: rashi dixit wrote:
> Hello Everyone
>
> I am currently working on binary file transmission from one system to 
> another, but couldnt figure a way out yet.
>
> Using tx_voice.py when I send a binary file with just an arbitrary 
> stream of ones and zeroes, data is read and transmitted as packets 
> well. But unfortunately, on receival side on the retrieval of data, it 
> isnt written back into the file in the binary format as originally but 
> a combinations of bits are clubbed and expressed by incomprehensible 
> hashes and stars. So the data cant be deciphered.
>
> I tried using the GMSK modulation scheme. But the binary data chunks 
> are filtered out during transmission onlyprobably due to the 
> gaussian filter. Please check me out if I am wrong.
>
> Could anyone suggest a way for a ones and zeroes file to be 
> transmitted? My final aim is  to find the 'Bit error rate' of 
> transmission form one node to another.
>
> Also is there any way of comparing two binary files? I mean how should 
> one approach the bit error analysis keeping correlation in mind etc?
>
> Thanking you all
> Rashi Dixit

Rashi,

I'm not sue why you are using tx_voice.py for this. It seems to make 
more sense to use benchmark_tx.py and benchmark_rx.py in the /digital 
examples directory. This will modulate the bits with GMSK by default. 
Keep in mind, though, that you _want_ to modulate the data before 
transmitting it over the air.

The GNU Radio file sink/source write and read files as binary data, so 
the files will look like hashes and stars when viewed with a text 
editor. You can use gnuradio-core/src/utils/read_*_binary.m in 
Matlab/Octave to read these files.

However, I'm not sure you want to just compare the output file to the 
input file unless you also keep track of a packet number. If the header 
is missed or corrupted in the current implementation, the packet is 
completely dropped, which would completely screw up your calculations 
unless you can tell that a full packet has been lossed. Then, you have 
to decide how you want to handle the BER calculation due to one lost 
packet.

Tom




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



-
 Here’s a new way to find what you're looking for - Yahoo! Answers ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] 802.11b Headers

2007-06-29 Thread Teun

Hi Dan,

thanks for your quick reply. The information i'm looking for is exactly the
packet length and the data rate of a packet. I'm using this information to
do some sort of wireless environment characterization.

If you can point me to the right places in the code, that would be awesome.

Thanks, 

Teun



Daniel Sumorok wrote:
> 
> Hello Teun,
>There are two rates for the 802.11b physical headers - 1 Mbps, and 2 
> Mbps.  Most likely, packets that use the CCK modulation (5.5 and 11 Mbps) 
> use the 2 Mbps physical header.  I never got the 2 Mbps header decoding 
> working properly for some reason, although the code does try to decode 2 
> Mbps headers.  (It could detect that a 2 Mbps header was there, and often 
> got some of the bits correct...) By the way, these headers don't really 
> contain that much more information than the packet length and the data
> rate 
> - however if you want to debug this, I can point you to the appropriate 
> places in the code.
> 
>-Dan
> 
> At 05:51 AM 6/29/2007, Teun wrote:
> 
>>Hi Guys,
>>
>>First of all, thanks for all the help you have been giving me, it was
really
>>helpful for me to understand the  USRP / GNU Radio package.
>>
>>I'm hoping someone from the BBN group is reading this, or anyone else who
>>has an idea.
>>Within our research group we are interested in decoding 11b/(g?) packet
>>headers. I have installed the 802.11 BBN code, which runs really good.
Even
>>when I compare it to my laptop, equipped with a packet sniffer, the
detected
>>packets match perfectly. However, the code decodes packets with a data
rate
>>of 1Mbit and occasionally a 2Mbit packets due to the USB limitations. We
>>would like to detect "all" packets, at least their headers containing the
>>useful information. Header files use a low modulation type, so I think we
>>should always be able to capture the header of a packet. Does anyone see
any
>>difficulties in doing so?
>>
>>Any comments are really useful.
>>
>>
>>Thanks again,
>>
>>Teun
>>--
>>View this message in context: 
>>http://www.nabble.com/802.11b-Headers-tf3999092.html#a11357744
>>Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>>
>>
>>___
>>Discuss-gnuradio mailing list
>>Discuss-gnuradio@gnu.org
>>http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://www.nabble.com/802.11b-Headers-tf3999092.html#a11363044
Sent from the GnuRadio mailing list archive at Nabble.com.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Transmitting a binary 'ones and zeroes' file for Bit Error Analysis

2007-06-29 Thread rashi dixit
Hey Tom

Thanks for the tip to use benchmark files for the same.On going through them 
made me realize they are just as identical to tx_voice.py, rx_voice.py !

And just as you had said, it would be necessary to keep track of the packets 
but I havent yet been able to figure out a way to overcome the lost packet 
situation.

The bottleneck is that if I could attach header (external preamble)from my side 
to the data then the sequence could be tracked. On trying to attach external 
data I dug through the code of pkt.py and packet_utils.py in  
usr/local/lib/python2.4/site-packages/gnuradio/blksmpl and attached a string to 
'payload' from my side.

Many-a-times receiver rejects the incoming packet saying:

 
terminate called after throwing an instance of 'std::runtime_error'
  what():  msg length is not a multiple of d_itemsize
Aborted (core dumped)

Could you the suggest a possible way to overcome this error?

Thanks again!
Rashi


Tom Rondeau <[EMAIL PROTECTED]> wrote: rashi dixit wrote:
> Hello Everyone
>
> I am currently working on binary file transmission from one system to 
> another, but couldnt figure a way out yet.
>
> Using tx_voice.py when I send a binary file with just an arbitrary 
> stream of ones and zeroes, data is read and transmitted as packets 
> well. But unfortunately, on receival side on the retrieval of data, it 
> isnt written back into the file in the binary format as originally but 
> a combinations of bits are clubbed and expressed by incomprehensible 
> hashes and stars. So the data cant be deciphered.
>
> I tried using the GMSK modulation scheme. But the binary data chunks 
> are filtered out during transmission onlyprobably due to the 
> gaussian filter. Please check me out if I am wrong.
>
> Could anyone suggest a way for a ones and zeroes file to be 
> transmitted? My final aim is  to find the 'Bit error rate' of 
> transmission form one node to another.
>
> Also is there any way of comparing two binary files? I mean how should 
> one approach the bit error analysis keeping correlation in mind etc?
>
> Thanking you all
> Rashi Dixit

Rashi,

I'm not sue why you are using tx_voice.py for this. It seems to make 
more sense to use benchmark_tx.py and benchmark_rx.py in the /digital 
examples directory. This will modulate the bits with GMSK by default. 
Keep in mind, though, that you _want_ to modulate the data before 
transmitting it over the air.

The GNU Radio file sink/source write and read files as binary data, so 
the files will look like hashes and stars when viewed with a text 
editor. You can use gnuradio-core/src/utils/read_*_binary.m in 
Matlab/Octave to read these files.

However, I'm not sure you want to just compare the output file to the 
input file unless you also keep track of a packet number. If the header 
is missed or corrupted in the current implementation, the packet is 
completely dropped, which would completely screw up your calculations 
unless you can tell that a full packet has been lossed. Then, you have 
to decide how you want to handle the BER calculation due to one lost 
packet.

Tom




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


 Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download 
Now! http://messenger.yahoo.com/download.php___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] FFT Spectral smoothing]

2007-06-29 Thread Trond Danielsen

2007/6/29, Aadil Volkwin <[EMAIL PROTECTED]>:

Hi,

My apologies for the lengthy silence. I have been out of town and unable
to respond to mail.

I'm not entirely clear on what you mean when you ask if the smoothing is
over time or frequency.

In essence, I would like to reproduce an output comparable to that of a
spectrum analyser.

That is, the GNU FFT show the frequencies and their related power in dB
respectively, instantaneously.

I would like to average the values of the Power spectrum and obtain an
output showing the "smoothed/average" frequency values over a certain
period. for instance say 100 samples of each frequency. Such that the
values outputted are more stable and accurate and less eratic.

As I am new to GNU_RADIO, I am not aware if the functionality for
smoothing is built in and If I would need to write code to do this
averaging of values, i'm not quite clear on where to begin.

My apologies again for the lengthy delay and look forward and appreciate
your assistance regarding this matter.

regards,

Aadil Volkwin


You can use the single pole iir filter to smooth the signal. The
single pole filter is also known as a exponential moving average
filter. You can find the GNU Radio documentation for it here:
http://gnuradio.org/doc/doxygen/classgr__single__pole__iir__filter__cc.html

If you want to know more, I can recommend this:
http://www.dspguide.com/ch19/2.htm

--
Trond Danielsen


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] Implementing State machine control

2007-06-29 Thread Eng. Firas

Dear Friends ,

How we can implement a state machine control in Gnu Radio ? I want to run
some gnuradio blocks in such away that I can control which block is to be
run and which one is to stop depending on time sequences or time states.
This control should be  dynamically executed during the run time. Any help
will be very appreciated.

Firas


-- 
View this message in context: 
http://www.nabble.com/Implementing-State-machine-control-tf4001403.html#a11365311
Sent from the GnuRadio mailing list archive at Nabble.com.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] how to set parameters for usrp_nbfm_ptt.py

2007-06-29 Thread zhifeng chen

Hi,
I just buy two sets of RFX900 a few days ago. now I can run usrp_siggen.py
and usrp_fft.py normally now. But when I try to run usrp_nbfm_ptt.py for a
full duplex test, I can hear nothing in both sides. I check the source code
and find self.set_transmit(False) in the __init__ of ptt_graph, so I change
it to self.set_transmit(True) in PC_A with microphone input and leave it
False in PC_B with speaker output. Now there are some noise output in PC_B,
but still don't have any voice ouput come from my input from microphone in
PC_A. I am try to search in archives of this maillist and read the source
codes by myself, but still have not find the answer. Could anyone help me
for below question:
1. Do I need to change the usrp_nbfm_ptt source code to test RFX900? If so,
how to change for simplex and duplex respectively?
2. I see rx_subdev_spec, tx_subdev_spec, audio_input and audio_output
options may be detect by program automtically if we don'e spectify, is it
right? I also find side A seems to be first priority if automatically
detected, but why there are still signal input and output in side B at the
same time?
3. How to set parameters in command line to run usrp_nbfm_ptt.py, my current
setting is: ./usrp_nbfm_ptt.py -f 900e6 for both PC_A and PC_B.
4. after showup the gui, I can't move the sliders in the control panel,
although there are sliders there. Is it normal?

Thank you very much!

Sincerely,
Zhifeng
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] Next release?

2007-06-29 Thread Berndt Josef Wulf
G'day,

when can we expect a new release?

cheerio Berndt


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] embed fix sequence in payload part

2007-06-29 Thread pratik hetamsaria
hi..
 
 i am presently working on tx_voice.py and rx_voice.py  for transmission of 
audio files. I am interested in finding out the BER . Now, the problem is that 
a few packets are dropped so i need to keep track of a packet sequence number. 
I am trying to embed a packet sequence number so that during the time of 
demodulation i know exactly which bits i should compare. I have looked into the 
code of packet_utils.py located at python2.4/site-packages/gnuradio and try to 
embed the sequence number over there in the payload part. What i have 
understood is that the preamble and access codes are dropped during the time of 
reception. So, i thought it would be easier to embed it in the payload part. 
Please correct me if i am wrong. 
 
 But when i try adding any sequence then during the time of reception, i 
receive the errors as i have mentioned. I have seen that there is an option of 
padding the payload with zeros. So,  after i add  a sequence number, the  
length of the payload still remains the same as it was before adding the 
sequence number (the number of bits padded have changed).So, i dont know what 
really has changed which causes this error. 
 
 What i have added is just one line in the make_packet function of 
packet_utils.py 
 
 
 def make_packet(payload, samples_per_symbol, bits_per_symbol,
 access_code=default_access_code, pad_for_usrp=True):
 
 (packed_access_code, padded) = 
conv_1_0_string_to_packed_binary_string(access_code)
 (packed_preamble, ignore) = 
conv_1_0_string_to_packed_binary_string(preamble)
 payload =  packed_preamble + payload   %LINE ADDED
 payload_with_crc = gru.gen_and_append_crc32(payload)
 pkt = ''.join((packed_access_code,  make_header(L), 
whiten(payload_with_crc), '\x55'))
 
 if pad_for_usrp:
 pkt = pkt + (_npadding_bytes(len(pkt), samples_per_symbol, 
bits_per_symbol) * '\x55')
 
 return pkt
 
 
 I have not changed anything at the receiving end. Please tell me if i need to 
do change anything during reception. I have printed the msg length from the 
pkt.py code at python2.4/site-packages/gnuradio/blksimpl
 
  For comparison of BER i am taking the payload part as reference i.e. i am 
writing the payload part onto a file and during the time of reception also, i 
am doing the same. Please tell if there is a better way of doing BER.
 
 thanks for your help
 Pratik Hetamsaria
 Tom Rondeau <[EMAIL PROTECTED]> wrote: pratik hetamsaria  wrote:
 > hi..
 >
 > i am trying to embed a fixed sequence which i want to recover during 
 > demodulation. I have read from the previous archives that it would be 
 > easier to embed it in the payload part.However, as soon as i add 
 > anything in the payload part, and try to receive using rx_voice, i get 
 > an error saying
 >
 > terminate called after throwing an instance of 'std::runtime_error'
 >   what():  msg length is not a multiple of d_itemsize
 > Aborted (core dumped)
 >
 > What I have understood is that the msg length changes as soon as I add 
 > something to the payload.If I dont do anything and just run 
 > rx_voice.py then the msg length comes to be 1687/1720
 >
 > I have tried getting the msg length after adding different sequences.
 > If i change the code as:
 > payload = payload + preamble, the msg length changes to 1719
 >
 > Otherwise, If i change  as:
 > payload = payload + default_access_code
 > the msg length changes to 1751
 >
 > where default_access_code and preamble are given in packet_utils.py.
 >
 > I have not been able to find out the value of d_itemsize or what 
 > should be its value so that the code runs.
 >
 > I would be very grateful for any help.
 >
 > Thanking you,
 > Pratik Hetamsaria
 
 Pratik,
 
 I'm not entirely sure what you're trying to do. Which example code are 
 you using? And also, what's the purpose of what you are trying to do? 
 That might help us set you in the right direction.
 
 Please list the code where you are making the change to add your fixed 
 sequence.
 
 Tom
 
 


-
 Here’s a new way to find what you're looking for - Yahoo! Answers ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Binary data transmission

2007-06-29 Thread bellzii

hey patrik,

Tom's reply :
http://www.nabble.com/Transmitting-a-binary-%27ones-and-zeroes%27-file-for-Bit-Error-Analysis-tf3990983.html
http://www.nabble.com/Transmitting-a-binary-%27ones-and-zeroes%27-file-for-Bit-Error-Analysis-tf3990983.html
 

might help you can use  gr_vector_source as your data generator

hope this helps



pratik hetamsaria wrote:
> 
> hi,
>  
>  Can anybody please tell me how to transmit binary data from GNU Radio. I
> have been able to transmit and receive audio files using rx_voice.py and
> tx_voice.py but not been able to send binary data. Is there already some
> code written for it or i would have to make up my own?? I would jus like
> to transmit simple sequences like '0101' and keep repeating it over and
> over again.
>  
>  Any help is greatly appreciated.
>  
>  Thanks
>  Pratik
>  
>   
> -
>  Here’s a new way to find what you're looking for - Yahoo! Answers 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Binary-data-transmission-tf3996296.html#a11367170
Sent from the GnuRadio mailing list archive at Nabble.com.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio