[Discuss-gnuradio] Error in creating block

2015-04-02 Thread Vishwanatha H G
Hi..
 I crated a block named 'costas_loop_cc'. but when I connect to test this
block with NULL sink and NULL Source, shows the error like this:
Error 1:
Generating: /home/lekha/top_block.py
Executing: /home/lekha/top_block.py

  File /home/lekha/top_block.py, line 31
self.costas_loop_cc_0 = 
^
SyntaxError: invalid syntax

 Done

the part of the generated  top_block.py code related to error is:
   ##
# Blocks
##
self.costas_loop_cc_0 = line 31
cannot find 'loop_bw': digital.costas_loop_cc($loop_bw, $order)

self.blocks_null_source_0 =
blocks.null_source(gr.sizeof_gr_complex*1)
self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_gr_complex*1)

##
# Connections
##
self.connect((self.blocks_null_source_0, 0),
(self.costas_loop_cc_0, 0))
self.connect((self.costas_loop_cc_0, 0), (self.blocks_null_sink_0,
0))

I wish it is a small error but I couldn’t  get. while creating a block when
I execute  gr_modtool makexml command it shows the error :

AttributeError: 'NoneType' object has no attribute 'group'.

 what does it mean AttributeError? Is there any relation with this to above
mentioned error. thanks for your advice
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] OOK modulation naming

2015-04-02 Thread Jeff Long
After way to much searching ... under Anisochronous modulation, there is 
something called Digital Pulse Interval Width Modulation (DPIWM).


http://paradise.caltech.edu/papers/thesis010.pdf

Seems like as good a name as any.

- Jeff

On 04/02/2015 03:28 PM, Michael Ossmann wrote:

I though NRZI had a constant symbol rate.  I would expect 011101001 in
NRZI to look like:

_-_--___-

Mike


On Thu, Apr 02, 2015 at 03:23:57PM -0400, Jeff Long wrote:


Hey Mike,

I think that NRZI.

- Jeff

On 04/02/2015 02:36 PM, John Ackermann N8UR wrote:

Why not make the ratio 1:3 and then you could call it Morse PWM. :-)

On 4/2/2015 2:16 PM, Michael Ossmann wrote:

A friend recently showed me an OOK modulation that I had never seen
before, and I'm wondering if anyone knows a name for this scheme.

It is PWM where both the on periods and off periods carry data in their
durations.

In the example we observed, an on or off period with a duration of two
units represents a zero.  An on or off period with a duration of one
unit represents a one.  Example:

--_-_--_--__-

This sequence of amplitudes represents the binary data 011101001.

Note that this scheme has a variable data rate.  (Two packets carrying
the same number of bits may have different durations.)  Overall,
however, the data rate is higher than in a similar looking scheme in
which data are encoded only in the on periods.

Does anyone know what to call this?  I am tempted to call it Biphase
PWM.

Thanks,

Mike

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



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



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



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


Re: [Discuss-gnuradio] OOK modulation naming

2015-04-02 Thread Jeff Long

Hey Mike,

I think that NRZI.

- Jeff

On 04/02/2015 02:36 PM, John Ackermann N8UR wrote:

Why not make the ratio 1:3 and then you could call it Morse PWM. :-)

On 4/2/2015 2:16 PM, Michael Ossmann wrote:

A friend recently showed me an OOK modulation that I had never seen
before, and I'm wondering if anyone knows a name for this scheme.

It is PWM where both the on periods and off periods carry data in their
durations.

In the example we observed, an on or off period with a duration of two
units represents a zero.  An on or off period with a duration of one
unit represents a one.  Example:

--_-_--_--__-

This sequence of amplitudes represents the binary data 011101001.

Note that this scheme has a variable data rate.  (Two packets carrying
the same number of bits may have different durations.)  Overall,
however, the data rate is higher than in a similar looking scheme in
which data are encoded only in the on periods.

Does anyone know what to call this?  I am tempted to call it Biphase
PWM.

Thanks,

Mike

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



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



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


Re: [Discuss-gnuradio] OOK modulation naming

2015-04-02 Thread Michael Ossmann
I though NRZI had a constant symbol rate.  I would expect 011101001 in
NRZI to look like:

_-_--___-

Mike


On Thu, Apr 02, 2015 at 03:23:57PM -0400, Jeff Long wrote:

 Hey Mike,
 
 I think that NRZI.
 
 - Jeff
 
 On 04/02/2015 02:36 PM, John Ackermann N8UR wrote:
  Why not make the ratio 1:3 and then you could call it Morse PWM. :-)
 
  On 4/2/2015 2:16 PM, Michael Ossmann wrote:
  A friend recently showed me an OOK modulation that I had never seen
  before, and I'm wondering if anyone knows a name for this scheme.
 
  It is PWM where both the on periods and off periods carry data in their
  durations.
 
  In the example we observed, an on or off period with a duration of two
  units represents a zero.  An on or off period with a duration of one
  unit represents a one.  Example:
 
  --_-_--_--__-
 
  This sequence of amplitudes represents the binary data 011101001.
 
  Note that this scheme has a variable data rate.  (Two packets carrying
  the same number of bits may have different durations.)  Overall,
  however, the data rate is higher than in a similar looking scheme in
  which data are encoded only in the on periods.
 
  Does anyone know what to call this?  I am tempted to call it Biphase
  PWM.
 
  Thanks,
 
  Mike
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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


Re: [Discuss-gnuradio] Demodulating short bursts of BPSK

2015-04-02 Thread Karl Koscher
If the packets have a preamble, there's a block called correlate_and_sync
which should do what you want, although it has some issues. See a thread I
started a few days ago about that...

On Thu, Apr 2, 2015 at 3:36 PM, Mike Willis willis...@gmail.com wrote:

 I have an application that needs to decode short bursts of DBPSK data
 (which I am not generating myself). The problem I am having is that
 the standard PSK Demod blocks don't lock up in time to correctly
 decode the first few flags in the packetised data, which means I
 generally lose the first packet. Is there a solution to this - e.g.
 once the demodulator has locked up, go back some time (samples) and
 start again knowing the locked parameters?

 Mike

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

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


[Discuss-gnuradio] Demodulating short bursts of BPSK

2015-04-02 Thread Mike Willis
I have an application that needs to decode short bursts of DBPSK data
(which I am not generating myself). The problem I am having is that
the standard PSK Demod blocks don't lock up in time to correctly
decode the first few flags in the packetised data, which means I
generally lose the first packet. Is there a solution to this - e.g.
once the demodulator has locked up, go back some time (samples) and
start again knowing the locked parameters?

Mike

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


Re: [Discuss-gnuradio] GNU Radio on Zedboard

2015-04-02 Thread Getz, Robin
Philip Balister wrote:
 On 04/01/2015 04:53 PM, Alireza Khodamoradi wrote:
  Thank you Philip!
 
  I also don't have the audio jack working. Should I ask it on the
  meta-xilinx list?
 
 Bug them. It is also likely a driver issue. My understanding is there are a 
 bunch of
 analog devices parts on the board that they wrote drivers for.

There is a different kernel that we (Analog Device's) maintains, which includes 
both ALSA drivers
for the audio chip (ADAU1761) and the HDMI output (ADV7511).

https://github.com/analogdevicesinc/linux

there are a few zynq branches in there. Normally Xilinx pulls drivers from 
there for their kernels, 
but anyone can do the same.

Our build instructions (if that's the sort of thing you want to do) is at:
http://wiki.analog.com/resources/eval/user-guides/ad-fmcomms2-ebz/software/linux/zynq_2014r2

We provide binaries for Zed which includes a 3.17 kernel and Xbuntu/xfce for 
many of
the FMC prototyping cards we make.
http://wiki.analog.com/resources/tools-software/linux-software/zynq_images

This does include GNURadio (3.7.4) binary, which some people used/contributed.
This doesn't support the GNURadio FPGA accelerator work that was done. (if that 
is
what you were really looking for).

 I'm not sure if
 those drivers made it into upstream Linux, and then you have the issue of the
 best kernel for our purposes is about 3.14.

Upstream - it's hard to upstream the device side, when Xilinx hasn't upstream 
the DMA side.
Greg (and others) do not like half a driver. Things are getting better now, and 
we need to
focus on that more.

-Robin

 
  On Wed, Apr 1, 2015 at 4:50 PM, Philip Balister phi...@balister.org wrote:
 
  On 03/31/2015 11:39 AM, Alireza Khodamoradi wrote:
  Philip,
 
  I got it working. For some reason if I use *Ubuntu's Archive
  Manager* on
  my
  laptop to uncompress the .xz file, it doesn't work!
 
  I had to uncompress it by this command: *unxz -d
  sdimage-8G-zedboard.direct.xz* in order to get it work.
 
  Now I have a linux running on the zedboard with the gnu-radio. But I
  can't
  get the VGA to work - I have to use UART to connect to the linux - I
  saw
  it
  has *startx* , is there any way for me to get the VGA working?
 
  I'd ask on the meta-xilinx list. We use hte BSP from Xilinx, which I
  do not think has support for the video display. For that you need a
  special driver (and I believe you need some stuff in the fpga). The
  build we have doesn't depend on anything loaded in the fpga.
 
  Philip
 
 
  Thank you,
  Alireza
 
  On Fri, Mar 20, 2015 at 6:54 AM, Philip Balister
  phi...@balister.org
  wrote:
 
  On 03/19/2015 10:48 AM, Alireza Khodamoradi wrote:
  Here are the files I have in the FAT partition (boot):
 
  1- boot.bin
  2- u-boot.img
  3- uEnv.txt
  4- uImage
  5- zc702-zynq7.dtb
 
  * I used this image: *sdimage-8G-zc702.direct*
 
  So this all looks correct. When you put the card in the PC both the
  FAT and roofs partitions are mounted OK? You did use an 8G card?
 
  I'm not sure what to say at this point. Everything looks OK. I am
  traveling and away from borads for a few weeks.
 
  Philip
 
 
  On Thu, Mar 19, 2015 at 6:41 AM, Philip Balister
  phi...@balister.org
  wrote:
 
  On 03/18/2015 10:44 PM, Alireza Khodamoradi wrote:
  Philip,
 
  Thank you for letting me using your images. I tried both of them
  with
  the *dd
  *command, it took me around 2000 seconds (30 mins) each and
  after
  using
  them on the board I get the following message via the UART:
 
  *U-Boot SPL 2014.01 (Jan 09 2015 - 20:24:45)* *mmc boot*
  *reading fpga.bin*
  *spl: error reding image fpga.bin, err - -1* *reading
  system.dtb*
  *spl: error reading image system.dtb, err - -1* *reading
  u-boot.img*
  *spl: error reading image u-boot.img, err - -1* *### ERROR ###
  Please RESET the board ###*
 
  So the first stage boot loader is running, which is good.
 
  It looks for a couple of files which should be there, which is OK.
  (fpga.bin and system.dtb)
 
  Then it tries to load u-boot.img which it doesn't find. This is bad.
 
  Can you put the card in a PC and send the list of file in the FAT
  partition?
 
  Philip
 
 
 
  I got the above message for sdimage-8G-zc702.direct. I get no
  message
  for
  the other image.
 
  What am I doing wrong?
 
  On Fri, Mar 13, 2015 at 11:22 AM, Philip Balister 
  phi...@balister.org
 
  wrote:
 
  On 03/13/2015 01:17 PM, Alireza Khodamoradi wrote:
  Hello everyone,
 
  I'm going through the instructions from here:
 
  http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq
 
  I should go over those carefully, but in the mentime I have
  some
  images
  built for the zedbaord here:
 
 
 
 
 
 https://www.dropbox.com/sh/yfbpj63pcenqatr/AAAt0s3xFXs47I7q5pNopheHa?
  dl=0
 
  Take the zedboard one, uncompress it and write it to an sd
  card. Be
  sure
  to unmount (not eject) the sd card and run:
 
  sudo dd if=sdimage-8G-zedboard.direct of=/dev/sdX
 
  where sdx is the device the sd card is on.
 
  Philip
 
 
  

Re: [Discuss-gnuradio] Demodulating short bursts of BPSK

2015-04-02 Thread Richard Bell
Mike,

Let's call short bursts of data packets (because that’s really what they
are). In packet transmissions, there are a few ways of ensuring that the
synchronizers have enough time to lock up. The easiest way for you to go
about this, is adding a packet header that carries no information, such as
101010101, but can be used by the sync blocks to synchronize. The sync
blocks require transitions to make the magic happen. If you add this in
front of all your real data bursts, you will lose some of those SYNC frame
bits each time, but you don't care about that because it's not real data
AND the synchronizers will be locked by the time the real data starts.

v/r,
Rich

On Thu, Apr 2, 2015 at 3:36 PM, Mike Willis willis...@gmail.com wrote:

 I have an application that needs to decode short bursts of DBPSK data
 (which I am not generating myself). The problem I am having is that
 the standard PSK Demod blocks don't lock up in time to correctly
 decode the first few flags in the packetised data, which means I
 generally lose the first packet. Is there a solution to this - e.g.
 once the demodulator has locked up, go back some time (samples) and
 start again knowing the locked parameters?

 Mike

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

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


Re: [Discuss-gnuradio] Error in creating block

2015-04-02 Thread Marcus Müller
Hi Vishwanatha,

the generated python is bogus; the --line31...-- should not
be there. This indicates that there is something wrong with your GRC XML
file, most probably the python command in the make/make tag is
failing. Reading the line cannot find 'loop_bw':
digital.costas_loop_cc($loop_bw, $order),
I'd assume that you meant to use loop_bw as a parameter to your block's
constructor/make function, but maybe forgot to define it somewhere else
(or you've got a typo).

Greetings,
Marcus

On 04/02/2015 11:03 AM, Vishwanatha H G wrote:
 Hi..
  I crated a block named 'costas_loop_cc'. but when I connect to test
 this block with NULL sink and NULL Source, shows the error like this:
 Error 1:
 Generating: /home/lekha/top_block.py
 Executing: /home/lekha/top_block.py

   File /home/lekha/top_block.py, line 31
 self.costas_loop_cc_0 = 
 ^
 SyntaxError: invalid syntax

  Done

 the part of the generated  top_block.py code related to error is:
##
 # Blocks
 ##
 self.costas_loop_cc_0 = line 31
 cannot find 'loop_bw': digital.costas_loop_cc($loop_bw, $order)
 
 self.blocks_null_source_0 =
 blocks.null_source(gr.sizeof_gr_complex*1)
 self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_gr_complex*1)

 ##
 # Connections
 ##
 self.connect((self.blocks_null_source_0, 0),
 (self.costas_loop_cc_0, 0))
 self.connect((self.costas_loop_cc_0, 0),
 (self.blocks_null_sink_0, 0))

 I wish it is a small error but I couldn’t  get. while creating a block
 when I execute  gr_modtool makexml command it shows the error :

 AttributeError: 'NoneType' object has no attribute 'group'.

  what does it mean AttributeError? Is there any relation with this to
 above mentioned error. thanks for your advice



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

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


Re: [Discuss-gnuradio] Failed to install gnuradio with PyBOMBS

2015-04-02 Thread Activecat
Dear Sir,

Thanks, this solve the problems.
The GNU Radio has been installed successfully using PyBOMBS.

Thank you very much.


On Thu, Apr 2, 2015 at 10:30 AM, Ron Economos w...@comcast.net wrote:

  The actual fix is a little more complicated. You can download a patched
 file from here:

 http://www.w6rz.net/dvbt2_paprtr_cc_impl.cc

 w6rz.net is my personal website.

 Ron


 On 04/01/2015 07:11 PM, Activecat wrote:

 Dear Sir,

  I have comment out the #include complex.h, but still has error, as
 below:

  [ 80%] Building CXX object
 gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt2/dvbt2_paprtr_cc_impl.cc.o
 [ 86%] Built target gnuradio-qtgui
 [ 86%] Built target fcd_nfm_rx
 [ 87%] Built target test_atsci
 [ 87%] Built target _atsc_swig
 [ 87%] Built target _qtgui_swig
 [ 88%] Built target gnuradio-channels
 [ 88%] Built target _channels_swig
 [ 92%] Built target gnuradio-digital
 [ 92%] Built target _digital_swig
 [ 98%] Built target gnuradio-trellis
 [ 98%] Built target _trellis_swig

 /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:
 In member function ‘virtual int gr::dtv::dvbt2_paprtr_cc_impl::work(int,
 gr_vector_const_void_star, gr_vector_void_star)’:

 /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:770:102:
 error: ‘_Complex_I’ was not declared in this scope

 /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:771:37:
 error: ‘cexp’ was not declared in this scope

 /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:772:48:
 error: ‘creal’ was not declared in this scope

 /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:773:49:
 error: ‘cimag’ was not declared in this scope
 make[2]: ***
 [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt2/dvbt2_paprtr_cc_impl.cc.o]
 Error 1
 make[1]: *** [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/all] Error 2
 make: *** [all] Error 2
 Build failed. See output above for error messages.


  The complete log is at
 https://github.com/activecat/gnuradio/blob/master/installation_log_003.txt
 Please advise, thanks.


 On Thu, Apr 2, 2015 at 9:49 AM, Ron Economos w...@comcast.net wrote:

 In your previous pull request, you deleted the line:

 #include complex.h

 in gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc

 This would directly fix the build issues reported by Activecat and Marcus
 Leech.

 Ron

 On 04/01/2015 06:34 PM, Michael Dickens wrote:

 I'm not sure my forthcoming pull request directly addresses these
 specific issues, but it does a bunch of others for C++11 compliance in
 std::complex -- whether or not you're using C++11; it's backward compatible
 with C++0x and earlier, and should be forward compatible as well. Before we
 address these specific issues, let's get my patches in place -- they remove
 all of the GCC extensions to std::complex, so they might have an impact on
 these issues. I should be able to do the PR tomorrow; still testing on
 various systems tonight. - MLD
 On Wed, Apr 1, 2015, at 09:24 PM, Johnathan Corgan wrote:

 I believe Michael Dickens will have a comprehensive fix for issues like
 this soon.



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




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


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


Re: [Discuss-gnuradio] Run to completion not working with message passing blocks

2015-04-02 Thread Piotr Krysik
W dniu 01.04.2015 o 12:10, Marcus Müller pisze:
 Hi  Piotr,

 nice to hear you got a step ahead!
 so,
 I did that and what I obtained was:
 ---
   16   Thread 0x7fffbdffb700 (LWP 13462) python
 pthread_cond_wait@@GLIBC_2.3.2 () at
 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
   3Thread 0x7fffe9720700 (LWP 13449) gsm_clock_offs1
 pthread_cond_timedwait@@GLIBC_2.3.2 () at
 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
 * 1Thread 0x77fc7740 (LWP 13444) python 0x778e8da3 in
 select () at ../sysdeps/unix/syscall-template.S:81
 ---

 I'd have a blind guess:
 Thread 16 might be the surviving part of a python-spawned Timer()
 thread, which caused a message _post at another thread, which might be
 something that hangs if that block's thread no longer exists.

 Can you switch to that thread:
 thread 16
 and then try to get a python backtrace [1]
 py-bt
 and maybe a simple C-style backtrace
 bt

 that might give you some information what is actually waiting on a
 condition (which is what I guess from pthread_cond_wait).

 Greetings,
 Marcus

 [1] for this to work, you might need to follow these instructions from
 http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB:

 ... make sure that the python development package is installed
 (|python-devel| on Redhatoids, |python2.7-dev| on Debianoids); for
 some systems, you should append the content of
 |/usr/share/doc/{python-devel,python2.7-dev}/gdbinit[.gz]| to your
 |~/.gdbinit|, and re-start |gdb|.

Marcus,

Regarding the timer - this is what I thought at first, so I removed it
from the block. It didn't help, so I removed almost everything leaving
only message input of the block. But the problem persisted.

I will try you advice with GDB and let everybody know of the result.

Best Regards,
Piotr

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


Re: [Discuss-gnuradio] OOK modulation naming

2015-04-02 Thread John Ackermann N8UR

Why not make the ratio 1:3 and then you could call it Morse PWM. :-)

On 4/2/2015 2:16 PM, Michael Ossmann wrote:

A friend recently showed me an OOK modulation that I had never seen
before, and I'm wondering if anyone knows a name for this scheme.

It is PWM where both the on periods and off periods carry data in their
durations.

In the example we observed, an on or off period with a duration of two
units represents a zero.  An on or off period with a duration of one
unit represents a one.  Example:

--_-_--_--__-

This sequence of amplitudes represents the binary data 011101001.

Note that this scheme has a variable data rate.  (Two packets carrying
the same number of bits may have different durations.)  Overall,
however, the data rate is higher than in a similar looking scheme in
which data are encoded only in the on periods.

Does anyone know what to call this?  I am tempted to call it Biphase
PWM.

Thanks,

Mike

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



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


[Discuss-gnuradio] OOK modulation naming

2015-04-02 Thread Michael Ossmann
A friend recently showed me an OOK modulation that I had never seen
before, and I'm wondering if anyone knows a name for this scheme.

It is PWM where both the on periods and off periods carry data in their
durations.

In the example we observed, an on or off period with a duration of two
units represents a zero.  An on or off period with a duration of one
unit represents a one.  Example:

--_-_--_--__-

This sequence of amplitudes represents the binary data 011101001.

Note that this scheme has a variable data rate.  (Two packets carrying
the same number of bits may have different durations.)  Overall,
however, the data rate is higher than in a similar looking scheme in
which data are encoded only in the on periods.

Does anyone know what to call this?  I am tempted to call it Biphase
PWM.

Thanks,

Mike

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