Re: [Discuss-gnuradio] ATSC fixups

[Johnathan Corgan]

On 07/15/2013 07:01 PM, Andrew Davis wrote:

> After this stuff and the reorganization a simple diff would not have 
> saved much, also i'm working on 'atsc_tx.py',so 'all_atsc.py' would
> be confusing, hence the name change.

First, let me say that I'm very happy this code is getting some
attention. It was originally written to use the low-IF output of a TV
tuner and ADC, and also when GNU Radio only had a single-threaded
scheduler.  Later, it was only minimally modified to use the USRP
complex baseband IQ output. (I wasn't around GNU Radio at the time and
the above is only what I surmise by looking at the code history.)

The changes you describe are more like it would have been written had
the USRP existed at the time.

The all_atsc.py file was a work-in-progress effort by Ben Reynwar that I
merged in, but he and I never finished what we were going to do with it.

> Also the other scripts seem unnecessary with the new
> thread-per-block sceduler, the also seem to cause a lot of beginners
> confusion. So I felt they needed to go.

Agree.

> I have also built a ( semi ) working complex fpll for gr-atsc, this 
> removes the need for up-converting and the filtering after the
> current fpll, my next atsc_rx will need the new script style. After I
> finish updating the bit timing loop we will be almost real time I
> believe!

The upconversion and filtering is a large CPU waste when it could be
done at baseband, but it seems this was just a quick-and-dirty way to
get the baseband IQ from a USRP to look like a low-IF output instead in
order to re-use what was already written and working.

Real-time execution would be a welcome accomplishment!

> P.S. I could still just do the diff to the old all_atsc.py and rename
> if you want.

No need.

By the way, before any of this can be merged, we'll need a copyright
assignment from you.  I'll email you off-list about how this works.

Thanks again for working on this.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ATSC fixups

[Andrew Davis]

Sure:

- first the description is correct and not just copied from interp_short.py
- removed the writing to 'atsc_complex.data' as this uses a lot of space
and seems to have no meaning outside of debugging
- I use interleave_short_to_complex instead of s2s -> s2f -> f2c chain
- lp_coeffs and duc_coeffs uses input_rate instead of just the number,
should make changing it easier
- lp_coeffs no longer arbitrarily adds 3 gain
- duc now shifts the frequency in the correct direction
- the root raised cosine filter taps no longer need to be heterodyned into
place as I just use it at baseband
- the root raised cosine filer gets used now ( for some reason it was not
in the chain before and this was severely causing ISI )
- lower_edge and upper_edge seemed arbitrary and were not in the right spot
anyway

After this stuff and the reorganization a simple diff would not have saved
much,
also i'm working on 'atsc_tx.py',so 'all_atsc.py' would be confusing, hence
the name change.

Also the other scripts seem unnecessary with the new thread-per-block
sceduler, the also seem to cause
a lot of beginners confusion. So I felt they needed to go.

I have also built a ( semi ) working complex fpll for gr-atsc, this removes
the need for up-converting and the filtering
after the current fpll, my next atsc_rx will need the new script style.
After I finish updating the bit timing loop
we will be almost real time I believe!

P.S. I could still just do the diff to the old all_atsc.py and rename if
you want.

Thank you
Andrew


On Mon, Jul 15, 2013 at 6:52 PM, Johnathan Corgan
wrote:

> On Sun, Jul 14, 2013 at 12:03 PM, Andrew Davis wrote:
>
>
>> I have been working on getting gr-atsc running again, I have found a few
>> speedups and some bugs that prevented ATSC decoding from working with new
>> versions of GNURadio. I have put these fixes into a branch that can now
>> decode signals from my local TV station. The changes are in commit in this
>> branch: https://github.com/glneo/gnuradio/tree/atscfixup
>>
>
> Andrew, can you detail the difference in implementation between the
> atsc_rx.py file you added and the all_atsc.py file that was there already?
>
> --
> Johnathan Corgan
> Corgan Labs - SDR Training and Development Services
> http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ATSC fixups

[Johnathan Corgan]

On Sun, Jul 14, 2013 at 12:03 PM, Andrew Davis wrote:


> I have been working on getting gr-atsc running again, I have found a few
> speedups and some bugs that prevented ATSC decoding from working with new
> versions of GNURadio. I have put these fixes into a branch that can now
> decode signals from my local TV station. The changes are in commit in this
> branch: https://github.com/glneo/gnuradio/tree/atscfixup
>

Andrew, can you detail the difference in implementation between the
atsc_rx.py file you added and the all_atsc.py file that was there already?

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Mistake in fmdet_cf_impl.cc:109?

[Johnathan Corgan]

On Thu, Jul 11, 2013 at 3:37 AM, Perper  wrote:


> I was reading the c++ code of FM demodulators in gnuradio and I
> encountered this in fmdet_cf_impl.cc:109:
>
> -
> Sdot = d_scl * (-S0+d_8*S1-d_8*S1+S4);
> -
>
> I don't know according to what principle this demodulator work exactly
> but it doesn't seem to make too much sense to first add d_8*S1 and then
> subtract it.
>

This code looks 'vestigial'; something left over from early development or
debugging that wasn't removed.  I'll make a note to clean it up.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem with clock_recovery_mm on low data rates

[Nemanja Savic]

I would be also happy if somebody would answer you, but from my past
experience, nobody talks much about clock recovery M&M, and I am quite sure
that setting up values are not well explained.

Nemanja


On Mon, Jul 15, 2013 at 10:56 AM, Niaz Ahmed  wrote:

> Hi all,
> I am implementing a fsk receiver and using clock_recovery_mm for
> synchronization. The block was working fine till I lowered my data rate to
> 50bps. I do not know what goes wrong for low data rates.
>
> I am using 48k sampling rate and while working with 100bps I was having
> 480 samples per symbol (As i am implementing binary FSK so symbol rate= bit
> rate ). When dealing with 50bps I changed the symbol rate => omega =  960
> but the block was not giving the right output.
>
> I dig into the block and found some strange things. I found that the clock
> recovery goes wrong when consecutive sequence (either 1 or 0) is input to
> it. The problem that i figured out by using the scope sink (in grc)
> was with both the 100bps as well as 50 bps. But the 100 bps it was still
> decoded by the binary slicer, however in case of 50 bps it was becoming
> weird. Screen shots of for 100 bps ad 50 bps are attached. According to our
> understanding the highlighted portion is not correctly decoded.
>
> --
> *
> Best Regards
>
> Niaz Ahmed*
>
> NUCES-FAST, Islamabad Campus
> EXT-369
>
> Engineers motto: cheap, good, fast: choose any two (copied)
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

Re: [Discuss-gnuradio] GRAS flow control from work function

[Josh Blum]

On 07/15/2013 05:43 PM, devin.butterfi...@gmail.com wrote:
> Hi,
> 
> I'm using gras for my application and my custom block needs to be
> able to do a blocking read to get data from an external source. With
> the standard scheduler I used a non blocking read in a polling loop
> with an interruptable sleep and this worked Ok. Do I need to do it
> this way with gras or can I get away with with blocking?
> 

Basically, you want to avoid stealing away the work() thread for too
long. So I recommend polling with a small timeout and return if there is
nothing. Work will get called again.

Relevant discussion:
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-05/msg00124.html

> Another thing my block must do is stop the flow graph if its external
> source has signaled that it is done. I did this with the standard
> scheduler by returning WORK_DONE. How should this be done with gras?
> 
> 

Use this->mark_done()

https://github.com/guruofquality/gras/blob/master/include/gras/block.hpp#L213

-josh

> Thanks. -- Regards, Devin
> 
> 
> 
> 
> ___ 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] GRAS flow control from work function

[devin . butterfield]

Hi, 

I'm using gras for my application and my custom block needs to be able to do a 
blocking read to get data from an external source. With the standard scheduler 
I used a non blocking read in a polling loop with an interruptable sleep and 
this worked Ok. Do I need to do it this way with gras or can I get away with 
with blocking? 

Another thing my block must do is stop the flow graph if its external source 
has signaled that it is done. I did this with the standard scheduler by 
returning WORK_DONE. How should this be done with gras? 

Thanks.
--
Regards, Devin 


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

Re: [Discuss-gnuradio] Does GRAS support setting max noutput_items?

[devin . butterfield]

Hi Josh, 

Thanks for the quick work on this. Setting max noutputitems from grc works fine 
now. 
--
Regards, Devin 

- Reply message -
From: "Josh Blum" 
To: 
Cc: 
Subject: [Discuss-gnuradio] Does GRAS support setting max noutput_items?
Date: Sun, Jul 14, 2013 12:27 pm




On 07/14/2013 02:43 PM, Devin Butterfield wrote:
> Hi folks,
> 
> I just started experimenting with GRAS and ran into this:
> 
 GRAS: The debug asserts are enabled. <<<
> Created default thread pool with 4 threads.
> Traceback (most recent call last):
>   File "top_block.py", line 80, in 
> tb.Run(True, 10)
>   File
> "/opt/gnuradio/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py",
> line 76, in Run
> self.start(max_nouts)
> TypeError: start() takes exactly 1 argument (2 given)
> 
> Is this feature broken?
> 

Yea, Its in the block config that can be set at the global config level
or the block level, or the port level.

https://github.com/guruofquality/gras/blob/master/include/gras/block_config.hpp

https://github.com/guruofquality/gras/blob/master/include/gras/top_block.hpp#L24

https://github.com/guruofquality/gras/blob/master/include/gras/block.hpp#L42

Its also available in the wrapper set set_max_noutput_items on the
blocks, it just didnt get into the second parameter for the run/start
API calls. I can add it...

Just curious... What are you trying to do at a high level? Constrain the
available buffer that a block can produce (without upstream consuming)?
Constrain the maximum number of items in a single call to work? etc..

-josh

> Thanks.
> --
> Regards, Devin
> 
> 
> 
> ___
> 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] AttributeError: 'function' object has no attribute 'to_basic_block' ? (GR 3.7.0)

[Monahan-Mitchell, Tim]

>>> One of my OOT blocks is a function that takes in shorts and outputs shorts 
>>> (a 1-to-2 interpolator).

>>> I have a simple flowgraph created in GRC:   File Source -> My block -> File 
>>> sync .

>>> GRC is happy until I run the flowgraph, and I get this:

>>> Executing: "<> /top_block.py"

>>> Traceback (most recent call last):
>>>   File "<> /top_block.py", line 54, in 
>>> tb = top_block()
>>>   File "<> /top_block.py", line 39, in __init__
>>> self.connect((self.my_block_s_to_s_0, 0), (self.blocks_file_sink_0, 0))
>>>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", 
>>> line 130, in connect
>>> self._connect(points[i-1], points[i])
>>>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", 
>>> line 141, in _connect
>>> self._tb.primitive_connect(src_block.to_basic_block(), src_port,
>>> AttributeError: 'function' object has no attribute 'to_basic_block'

> I have found the error (or at least I am closer): The Python code that GRC 
> generates is slightly different between v3.6.4.2 and v3.7.0 for the same test 
> flowgraph. Namely, the newer version omits an empty set of parens, thusly:

> From v3.6.4.2 :

>   ##
>   # Blocks
>   ##
>   self.my_oot_my_block_0 = my_oot.my_block()

> From v3.7.0 :

>   ##
>   # Blocks
>   ##
>   self.my_oot_my_block_0 = my_oot.my_block

> My block has no parameters (thus the empty parens).

> If I manually edit the v3.7.0 generated py code to add the missing parens, it 
> all works fine as with v3.6.4.2.

> Question: Is this a v3.7.0 bug, or some subtle coding error in my OOT module? 
> As far as I can tell, I converted it according to the 3.6 -> 3.7 recipe.

Answer: This was my subtle coding error. I left the empty parens out of the XML 
file's 'make' entry (last line below).

File: my_oot_my_block.xml


  my_block
  my_oot_my_block
  my_oot
  import my_oot
  my_oot.my_block  <- Forgot () after the name.  Case closed.

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

[Discuss-gnuradio] decode problem in benchmark

[yeran]

Hi everyone,

I have a question about benchmark decoding. I'm using bpsk mod and demod.

In order to understand what's happening in the demodulation process, I added a 
file sink after time_recov block and after unpack block respectively. According 
to my understanding, the receiver block does the mapping and decision making 
process. It maps the complex number in rx_time_recov.32fc to 1 if the complex 
number is bigger than zero. It will map the complex number in 
rx_time_recov.32fc to 0 if the complex number is smaller than zero. And this 
mapping result, 1 or 0, is written into rx_unpack.8b.

However, in real experiment, I found wired result. Sometimes the mapping is 
using the algorithm as above, sometimes it is totally the opposite way. 
(complex number in rx_time_recov.32fc smaller than zero will be mapped as 1). 
Even this algorithm is not the same within one packet. For instance, the access 
code is mapped using one algorithm, and the payload is mapped the other way. 

I don't understand why this is happening. Is there anything to do with the 
phase error or anything? Can anyone give me some suggestions on how it works?

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

[Discuss-gnuradio] Scheduler Issues with Branch Prediction

[Ron Sadlier]

Hello everyone,

I've been having the same issue with the scheduler for the past 2 months or
so and I'm starting to unravel what I believe is occurring. Let me describe
my flowgraph first, then describe what's happening when I run the flow
graph, and then describe some REALLY interesting things I've noticed and my
thoughts. I apologize for the length of this in advance! :) . This isn't as
much of a "help me!" post as it is "what is happening here and is there a
problem with the scheduler or my thinking?"

My flowgraph consists of:

File source -> Custom Encode -> Custom Server Query -> Custom Server Query
-> Custom Decode -> Bit Error Rate Calculator

The encode scheme I am using is rather simple: it splits a byte into 4
"flags", each representing the four possible values of two bits
(00,01,10,11). The first "Custom Server Query" sends these flags to our
server, which stores them and returns a reference number, which is the
output of the block, with the second query block doing this process in
reverse. Overall, the actual implementations of these blocks are all
extremely simple, but unimportant, except that they all have if statement
chains to perform different processes based on the incoming flag. (This is
important later)

Now I expect the entire file to transfer over with a 0 BER. What I find is
that only a relatively short length transfers successfully before the data
on the other end becomes completely jumbled. I cannot ascertain what sort
of jumbling occurs, ie dropping, shifting, delays, because it appears to
change each run and happen at different file locations.

I don't have a throttle after the file source because it does not work.
Extreme example: I can set the throttle speed to 1 and it will still
process at the fastest rate possible. If I put any other block in between
the file source and the throttle, then the throttle works as it should. It
doesn't fix the jumble issue, but the throttle acts as it was designed to
by bursting with an average of the set value. That's weird thing #1: Why
does throttle work if there is a block in between it and the file source
block, but not if directly connected?

Next, I determined that the jumbling doesn't happen for small file sizes
(21kB) for random content files, but does for larger files. Why is random
import? Because if I put sequential data through (0x0 0x1 0x2 0x3 0x0 0x1
0x2 0x3 0x4...), it works *perfectly* with any file length at any flow
graph speed. This is a little unexpected, but not unheard of, as it appears
to be an artifact of branch prediction failure (see the following for a
good discussion if you are unfamiliar:
http://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-an-unsorted-array).
This would be a factor because my blocks have if statements for what type
of input flag is being processed.

After that, I put a sleep() in my encode block to more uniformly control
execution speed for testing. Even then, the lowest sleep value I can use
for random file data before jumbling is around 300microseconds. For
sequential data I can omit the sleep altogether, meaning it can process at
the fastest possible rate.

This is the opposite of what I would think would occur. If this was a
buffer overrun issue, then why does the jumbling only happen when the
flowgraph runs slower?

After some thinking, I'm starting to become suspicious of the threading
model. I'll admit that I haven't fully reviewed the threading code (thus,
am I making any obvious blunders in thinking below?) My idea of the issue
boils down to threads becoming unsynchronized. Executing with sequential
data would perform all encoding and decoding tasks with optimal speed and
ideally no branch prediction failures, such that the time slice of each
thread for general work would ideally take the same time to execute. If
running random data, branch prediction would surely fail almost every time.
But the time it didn't fail would speed up that particular iteration
greatly. Is is possible these threads are getting jumbled when this occurs
a few times in a row, making a "bubble" of fast execution speed and the
data NOT being guaranteed FIFO?

Unless there is another feature of the scheduler I am unaware of and I am
over thinking the importance of branch prediction here, I cannot reason why
sequential data produces no problems. Even if I am completely wrong with my
reasoning here, it doesn't explain away the fact that my jumbling still
occurs. I've tried this on multiple machines with different versions of
linux, but with GNR version 3.6.4.1. I've used built from source installs
and the Ettus binary.

Does anyone have any thoughts on this? Where are the guts of the scheduler
located in the repo? I can find files for the thread for a block, but not
the file that creates the threads and controls them. I'm just using sleep()
in my encoding block as a temporary fix.

Best,
Ron Sadlier
___
Discuss-gnuradio mailing list
Discuss

Re: [Discuss-gnuradio] AttributeError: 'function' object has no attribute 'to_basic_block' ? (GR 3.7.0)

[Monahan-Mitchell, Tim]

>> One of my OOT blocks is a function that takes in shorts and outputs shorts 
>> (a 1-to-2 interpolator).

>> I have a simple flowgraph created in GRC:   File Source -> My block -> File 
>> sync .

>> GRC is happy until I run the flowgraph, and I get this:

>> Executing: "<> /top_block.py"

>> Traceback (most recent call last):
>>   File "<> /top_block.py", line 54, in 
>> tb = top_block()
>>   File "<> /top_block.py", line 39, in __init__
>> self.connect((self.my_block_s_to_s_0, 0), (self.blocks_file_sink_0, 0))
>>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", 
>> line 130, in connect
>> self._connect(points[i-1], points[i])
>>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", 
>> line 141, in _connect
>> self._tb.primitive_connect(src_block.to_basic_block(), src_port,
>> AttributeError: 'function' object has no attribute 'to_basic_block'

I have found the error (or at least I am closer): The Python code that GRC 
generates is slightly different between v3.6.4.2 and v3.7.0 for the same test 
flowgraph. Namely, the newer version omits an empty set of parens, thusly:

>From v3.6.4.2 :

##
# Blocks
##
self.my_oot_my_block_0 = my_oot.my_block()

>From v3.7.0 :

##
# Blocks
##
self.my_oot_my_block_0 = my_oot.my_block

My block has no parameters (thus the empty parens).

If I manually edit the v3.7.0 generated py code to add the missing parens, it 
all works fine as with v3.6.4.2.

Question: Is this a v3.7.0 bug, or some subtle coding error in my OOT module? 
As far as I can tell, I converted it according to the 3.6 -> 3.7 recipe.

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

Re: [Discuss-gnuradio] calibrating USRP

[Marcus D. Leech]

On 07/15/2013 08:55 AM, Nemanja Savic wrote:
I think this should be the last question in this thread. Which input 
signal levels should I stick? OIP3 at the first LNA MGA-62563 is 23 
dBm. Since the gain is arround 22 dB, is it ok to stay below -20dBm?


Best,
Nemanja



Yes, signals below -20dBm should keep things reasonably linear.

The thing to remember is that these receivers are generally designed for 
from-the-antenna use, where signal levels below -60dBm are quite common, and

  signals that are at -20dBm are "screamingly loud".




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

Re: [Discuss-gnuradio] calibrating USRP

[Nemanja Savic]

I think this should be the last question in this thread. Which input signal
levels should I stick? OIP3 at the first LNA MGA-62563 is 23 dBm. Since the
gain is arround 22 dB, is it ok to stay below -20dBm?

Best,
Nemanja


On Wed, Jul 10, 2013 at 2:33 PM, Marcus D. Leech  wrote:

> **
>
> I think that i am a little bit confused with calibration. Is there any way
> to determine the gain of the circuitry in front of the ADC? Is it correct
> enough to say that power level at the input of PGA in front of ADC is
> just ((sampled_value*Vp-p)/2^12  ^  2 ) / Rinputpga?
>
>  The total gain in front of the ADC will vary from daughtercard to
> daughtercard, and with frequency.
>
> Calculate the power inside the flow-graph, which is proportional to
> AVG(I*I + Q*Q).   For RMS power, there's an RMS block.
>
> What you need to do is use a *calibrated-in-power* signal source, and use
> that to calibrate your receiving setup.
>
> You can't reliably backtrack from the values coming out of the USRP,
> because you don't know the total gain in front of the ADC to sufficient
>   precision.
>
>
>
>
> On Mon, Jun 3, 2013 at 5:05 PM, Marcus Leech  wrote:
>
>> I'd tune slightly-off the target frequency.  The gain isn't going to
>> change that rapidly across the tuned frequency range.  If I were doing
>> this, I'd probably calibrate every 20Mhz or so.
>>
>>  Since neither UHD nor Gnu Radio have the concept of calibration data,
>> you can store it in whatever way is appropriate for your application. It's
>> a simple matter of programming...
>>
>> on Jun 03, 2013, *Nemanja Savic*  wrote:
>>
>>  Thank you Marcus for super fast answer. Well, for the begining I would
>> like to skip temperature calibration, only power level calibration
>> regarding frequency. I have following doubts:
>> 1. To which frequency should be tuned USRP if for example generator
>> generates 400 MHz. Should it be almost the same frequency, so that
>> downconverted signal falls very close to DC or something else.
>> 2. What is the best advice for storing calibration data.
>>
>>
>> On Mon, Jun 3, 2013 at 4:44 PM, Marcus Leech  wrote:
>>
>>> Indeed, the only way to do this is to use a signal generator with known
>>> power levels, and precision attenuators.  You'll have to repeat the process
>>> over the full tuning range of the device(s) in question, since
>>>  effective gain will change a little with tuned frequency--that's just a
>>> natural property of analog RF components.  The gain will also change (a
>>> little) with ambient temperature as well, so it depends on how precise you
>>> want your calibrations to be.
>>>
>>>
>>>
>>>  on Jun 03, 2013, *Nemanja Savic*  wrote:
>>>
>>>Hi all guys (yet again),
>>> I have a question about calibrating received power level of my USRP,
>>> equipped with wbx, lftx and lfrx.
>>> I am not sure whether it is apropriate to discuss that here.
>>> Basically I would like to be able to determine absolute power level I am
>>> receiving. I suppose that basic procedure for doing this would be using
>>> super precise, expensive signal generator. Then tracing signal of know
>>> power to daughter board and measure power level in fft sink. And maybe also
>>> doing this for complete band of daughterboard usage. If the previous is
>>> correct, than I would like to ask you, how do you store calibrating data,
>>> inside .h file or ...?
>>> Best and thank you,
>>>
>>> --
>>> Nemanja Savić
>>> --
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>> --
>> Nemanja Savić
>>
>>
>
>
> --
> Nemanja Savić
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>


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

[Discuss-gnuradio] Project Status: GSoC 2013

[Shashank Gaur]

Hello All,

I already sent this email twice over weekend, I am not sure if its getting
delivered. Apologies if I spam the list/your inbox.

I am Shashank, one of the GSoC students this year. My project proposal was
to work on IEEE 802.11 receiver developed by Bastian Bloessl at University
of Innsbruck and as well an connector to Wireshark application.

As the time comes for the Developer's Call as well the Mid Term, I would be
obliged to have some help/feedback from the community.

Since I realized that I have been and intend to stick around with the
community for long time, so I thought it would be more useful to put up all
info on a blog. You will find all the info
here.
I will try to publish some more detailed posts very soon. Also the code is
available here .

For short, here is some summary:

Having almost same objectives and as well with some recent developments
from Bastian, I have been trying to collaborate with him to develop the
project, and with his insight its been much easier to work on the stuff. I
have been able edit the gr-ieee802-11 in order to bridge the OOT module
developed by Bastian into it.

The modified gr-ieee802-11 module passes out the pdu using parse_mac block
as a pair, and the wireshark connector takes that pair, extract information
and uses it to create the PCAP headers for Wireshark to use.

All of the reference for my work till now has been Bastian's
Project

The main milestone I wish to finish up before Mid Term is to testing the
bridge between the Wireshark OOT module and gr-ieee802-11 module and
finishing it. Addition to that either convert the FTW
txfor current module or use
it to create a pseudo random ieee 802.11
transmitter. As well after that I would like to move to the other part of
proposal such as working on channel encoding, higher modulations, etc. for
the gr-ieee802-11 module.

Looking forward to discussing this in more detail.

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