[Discuss-gnuradio] Fw: [amateur-DSN] 8.4GHz LNA Boards

[Patrik Tast]

FYI,

Patrik

- Original Message - 
From: "l_moline" 

To: 
Sent: Monday, March 26, 2012 18:07
Subject: [amateur-DSN] 8.4GHz LNA Boards



Hello,
If anyone is interested in boards for an 8.4GHz LNA please contact 
Downeast Microwave. They may generate boards if there is enough interest. 
Thanks!




Yahoo! Groups Links

<*> To visit your group on the web, go to:
   http://groups.yahoo.com/group/amateur-DSN/ 



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

[Discuss-gnuradio] Reminder for the GSoC

[Tom Rondeau]

There's one week left to submit applications (due April 6) as students
to this year's GSoC. I have heard that a number of people already
have, so this is just a gentle reminder to come and participate this
year!

Since we are participating under the larger GNU project's umbrella, we
will follow their student application for consistency. Our webpage has
been updated to reflect this.
http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC

Thanks!
Tom

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

[Discuss-gnuradio] gr_sync_block question

[Nowlan, Sean]

Do objects that extend gr_sync_block *require* that their work function 
*always* returns as many items as the scheduler asked in noutput_items, except 
for the case when a block may be completely finished producing items? What does 
the scheduler do if the (number of items returned) < noutput_items? Does it 
ever try calling the work function again?

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

[Discuss-gnuradio] gr-Trellis FSM

[valentac]

I've implemented a Manchester Decoder via an FSM using the combined Viterbi
algorithm in gr-trellis, and its working great decoding my signal. However,
I've noticed that after ~1000 times running (see code), I get an error...

what(): fsm::fsm(const char *name): file open error

I'd expect this to happen in case of a buffer overrun or RAM limitation, but
even if I reduce the time between packets, I get the same error. 

Thanks for your help.




***
Manchester_FSM_test.py
*** 
#!/usr/bin/env python

from gnuradio import gr
from gnuradio import trellis
from gnuradio import eng_notation
import math
import sys
#import fsm_utils
from gnuradio.eng_option import eng_option
from optparse import OptionParser

def main():
for i in range(2005):

x=manchester([1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0,1,0,0,1,1,0,1,0])
print i


def run_test (f,Kb,bitspersymbol,K,dimensionality,constellation,data_in):
tb = gr.top_block ()


src = gr.vector_source_s(data_in)

#src_head = gr.head (gr.sizeof_short,Kb/16) # packet size in shorts
#s2fsmi = gr.packed_to_unpacked_ss(bitspersymbol,gr.GR_MSB_FIRST) #
unpack shorts to symbols compatible with the FSM input cardinality
#enc = trellis.encoder_bb(f,0) # initial state = 0
#mod = gr.chunks_to_symbols_sf(constellation,dimensionality)
va =
trellis.viterbi_combined_sb(f,K,0,-1,dimensionality,constellation,trellis.TRELLIS_EUCLIDEAN)
# Put -1 if the Initial/Final states are not set.
dst = gr.vector_sink_b();
tb.connect (src,va,dst)

tb.run()
   
return dst.data()


def manchester(data_in):


fname="fsm_files/manchester_encoder.fsm"


# system parameters
f=trellis.fsm(fname) # get the FSM specification from a file (will
hopefully be automated in the future...)

Kb=64
bitspersymbol = int(round(math.log(f.I())/math.log(2))) # bits per FSM
input symbol
K=Kb/bitspersymbol # packet size in trellis steps

dimensionality = 2
constellation = [0, 0,0,1,1,0,1,1] 
if len(constellation)/dimensionality != f.O():
sys.stderr.write ('Incompatible FSM output cardinality and
modulation size.\n')
#sys.exit (1)


   
(data)=run_test(f,Kb,bitspersymbol,K,dimensionality,constellation,data_in) #
run experiment with different seed to get different noise realizations
return data

if __name__ == '__main__':
main()


*** 
Manchester_encoder.fsm
*** 
2 2 4

0 1
0 1

1 2
1 2

Manchester Encoder
-- 
View this message in context: 
http://old.nabble.com/gr-Trellis-FSM-tp33544924p33544924.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] gr_sync_block question

[Josh Blum]

On 03/30/2012 11:23 AM, Nowlan, Sean wrote:
> Do objects that extend gr_sync_block *require* that their work
> function *always* returns as many items as the scheduler asked in
> noutput_items, except for the case when a block may be completely
> finished producing items? What does the scheduler do if the (number
> of items returned) < noutput_items? Does it ever try calling the work
> function again?
> 

You can return any number of items between 1 and noutput_items. The
scheduler will simply call work again with any items that werent
consumed + extra that accumulated into the input buffers in the interim
time.

Returning 0 or -1 will tell the block executor code to stop.

-Josh

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

Re: [Discuss-gnuradio] Pack k bits?

[Nowlan, Sean]

Any comment on this? I think the current implementation of 
gr_packed_to_unpacked_bb(int k, gr_endianness_t endianness) puts bits in an 
incorrect order when k > 1 and endianness = gr.GR_LSB_FIRST.

From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Nowlan, Sean
Sent: Wednesday, March 28, 2012 9:26 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Pack k bits?

I think it would work if I modified 
gnuradio/gnuradio-core/src/lib/gengen/gr_packed_to_unpacked_XX.cc.t (line 119) 
to the following:

x = (x>>1) | (get_bit_le(in, index_tmp) << (d_bits_per_chunk - 1) );

-OR-

x |= get_bit_le(in, index_tmp) << j;

I haven't tested, but I think these are functionally equivalent. Does this 
change sound reasonable?

-- Sean

From: 
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org]
 On Behalf Of Nowlan, Sean
Sent: Wednesday, March 28, 2012 8:49 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Pack k bits?

I want to take an input stream of bytes in which only one LSB is relevant 
(e.g., the output of the GR GLFSR block) and pack these bits into bytes with k 
relevant bits. For example, I'd like to take a stream of raw bits generated by 
the GLFSR and feed them to an M-PSK modulator, which requires chunks with 
k=log2(M) bits. Unfortunately I haven't found this to be straightforward. There 
is no "pack_k_bits" module that I could find, so I tried using  
unpacked_to_packed_bb and packed_to_unpacked_bb. They are not working like I 
would expect. For instance, here's an example in Python:

...
data = [1,0,1,0, 0,0,1,0, 1,1,1,0, 0,1,1,0]# 45 
67
self.source = gr.vector_source_b(data, False, 1)
self.pack = gr.unpacked_to_packed_bb(1, gr.GR_LSB_FIRST)
self.unpack = gr.packed_to_unpacked_bb(2, gr.GR_LSB_FIRST)  # stuff 2 bits 
into LSB of each output byte
self.head = gr.head(gr.sizeof_char, 8)  # should 
have 16/2 = 8 output bytes
self.sink = gr.file_sink(gr.sizeof_char, "out.bin")
self.connect(self.source, self.pack, self.unpack, self.head, self.sink)
...

This gives the following:
$ hexdump -C out.bin
000  02 02 00 02 03 02 01 02   ||
008

But I would expect the following:
000  01 01 00 01 03 01 02 01   ||
008

Notice that the two least significant bits are in reverse order. Any clue 
what's going on here?

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

[Discuss-gnuradio] Customized packet sink

[anay tuljapurkar]

Hey All,
 Is the gr_packet_sink.cc capable of handling a customized packet
format structure or would one have to come up with a customized packet sink
structure of ones own ignoring the complexity of access code/ sync vector ?

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

[Discuss-gnuradio] A interface between UHD source code function send() and benchmark?

[baobaonanpo D]

Hi，
  Is there anyone who use the uhd source code like tx_burst.cpp, use the
function send(buffs, samples_to_send, md, timeout) to send data, I use the
tx_burst.cpp and rx_samples_to_file.cpp to transmit and receive data, but
the received data is without rules.
  I think the data must be deal with like modulated and framer packed as in
benchmark,  I want to circular call the function send() and recv() in a
source file and convert the received data in form of which it to be send,
like benchmark_tx and benchmark_rx, but I have no idea how to do a
interface between function send() and benchmark.
  Maybe it is means I want to convert the data form from stream to packet,
is it right? hey!
  Is there anyone do the same work? would you  so nice to give me a hand,
thanks very much!


-- 
Ding Yuzhen
Beijng University of Posts and Telecommunications
School of computer science
E-mail：baobaona...@gmail.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio