Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)

[Activecat]

On Sat, Mar 15, 2014 at 11:14 AM, Marcus D. Leech  wrote:
> The SBX does analog downconversion, nothing more.  It knows nothing about
> the incoming signal, and doesn't demodulate it in any way.
>
> That is what SDR is all about--the signals are represented as
> complex-baseband (i/Q) format for processing by computer algorithms.
>
> The SBX (or any other daughtercard) is simply doing downconversion (or,
> upconversion for TX).

Even the simplest quadrature downconversion also needs to avoid clock
drift.  http://en.wikipedia.org/wiki/Quadrature_modulation#Clocking

If your "analog downconversion" above refers to quadrature
downconversion, then it is very important to have a phase lock loop
(PLL) on the SBX to avoid clock drift.

How could this PLL only present at the host (gnuradio flow graph), but
not Ettus SBX daughtercard ?
Does the flow-graph PLL able to correct all effects due to clock drift of SBX?

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

Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)

[Sylvain Munaut]

Hi,

> There are no documentation of what SBX performs on incoming or
> outgoing signals.  https://www.ettus.com/product/details/SBX

IMHO Ettus is among the brands where there is the _least_ surprises
just because the exact schematic is published, you can see _exactly_
what the SBX does to your signal ...


> If Ettus support personnel doesn't clear things up, the Ettus products
> continue to remain mystery to many newcomers.

Just a thought, but have you considered that "newcomers" aren't the
target audience ?

SDR has "radio" in it, and to use them properly you kind of need an
understanding of how radio works. Ettus isn't here to teach you the
fundamentals of RF, Radios, DSP, SDR, ... you're supposed to learn
those by yourself beforehand.


Cheers,

Sylvain

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

Re: [Discuss-gnuradio] GRC issues with GNU Radio 3.7

[Tom Rondeau]

On Fri, Mar 14, 2014 at 8:03 PM, Ruecan  wrote:
> Thank you Sebastian for your reply,
>
> I pulled your grc fixing, proceed to a clean make then did everything again
> however I got some error:
>
> [ 29%] Building CXX object
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/message_strobe_random_impl.cc.o
> In file included from
> /raid/nae/gnuradio/gr-blocks/lib/message_strobe_random_impl.cc:27:
> /raid/nae/gnuradio/gr-blocks/lib/message_strobe_random_impl.h:48: error:
> 'mt19937' in namespace 'boost::random' does not name a type
> /raid/nae/gnuradio/gr-blocks/lib/message_strobe_random_impl.cc: In
> constructor
> 'gr::blocks::message_strobe_random_impl::message_strobe_random_impl(pmt::pmt_t,
> gr::blocks::message_strobe_random_distribution_t, float, float)':
> /raid/nae/gnuradio/gr-blocks/lib/message_strobe_random_impl.cc:57: error:
> class 'gr::blocks::message_strobe_random_impl' does not have any field named
> 'd_rng'
> /raid/nae/gnuradio/gr-blocks/lib/message_strobe_random_impl.cc: In member
> function 'void gr::blocks::message_strobe_random_impl::update_dist()':
> /raid/nae/gnuradio/gr-blocks/lib/message_strobe_random_impl.cc:89: error:
> 'd_rng' was not declared in this scope
> make[2]: ***
> [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/message_strobe_random_impl.cc.o]
> Error 1
> make[1]: *** [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all] Error 2
>
> The point is those errors I got them before so to fix them (at that time) I
> just went to someone's gnuradio branch, clone it and it did work for my
> machine instead of the master branch of gnuradio which issue thoses errors.
> Actually, I had already stated that matter here, but issue was not fixed:
> http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-td46435.html#a46466
>
> Regards,
> Naceur


Naceur,

This issue was due to a mistaken #ifndef in the header file and was
fixed a few weeks ago.

Tom

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

Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)

[Activecat]

On Sat, Mar 15, 2014 at 4:05 PM, Sylvain Munaut <246...@gmail.com> wrote:
>> There are no documentation of what SBX performs on incoming or
>> outgoing signals.  https://www.ettus.com/product/details/SBX
>
> IMHO Ettus is among the brands where there is the _least_ surprises
> just because the exact schematic is published, you can see _exactly_
> what the SBX does to your signal ...

Let's see yourself at
http://code.ettus.com/redmine/ettus/projects/public/documents
This is the link referred by
http://www.ettus.com/kb/detail/frequently-asked-questions

This link leads to >  "The page you were trying to access doesn't
exist or has been removed" !

>> If Ettus support personnel doesn't clear things up, the Ettus products
>> continue to remain mystery to many newcomers.
>
> Just a thought, but have you considered that "newcomers" aren't the
> target audience ?

"Newcomers" refer to those who purchase Ettus products for the first time.
Sadly they are not given appropriate attention even through they are
consumers of Ettus.

> SDR has "radio" in it, and to use them properly you kind of need an
> understanding of how radio works. Ettus isn't here to teach you the
> fundamentals of RF, Radios, DSP, SDR, ... you're supposed to learn
> those by yourself beforehand.

I do not expect Ettus to teach me the fundamentals, but to clarify
fundamental details with Ettus support personnel who seem to confuse
with RF fundamentals.

You may refer to previous conversations.  Do you agree with him that a
simple quadrature downconverter doesn't need to care about clock drift
because it just "simply downconverter and nothing more"?

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

Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)

[Sylvain Munaut]

Hi,

> Let's see yourself at
> http://code.ettus.com/redmine/ettus/projects/public/documents
> This is the link referred by
> http://www.ettus.com/kb/detail/frequently-asked-questions
>
> This link leads to >  "The page you were trying to access doesn't
> exist or has been removed" !

Wow, they have a broken link because there was a reorganization
recently, big deal.

Use the power of google ... 4th link when searching for "Ettus SBX schematic"

And it's also in their file repo
http://files.ettus.com/schematics/sbx/sbx.pdf if you want it from
official source.


> You may refer to previous conversations.  Do you agree with him that a
> simple quadrature downconverter doesn't need to care about clock drift
> because it just "simply downconverter and nothing more"?

Yes ...


Cheers,

Sylvain

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

Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK

[Abhishek Bhowmick]

Here is the link for my first proposal draft :
https://github.com/abhowmick22/GSoc14-Proposal

I will keep revising it. Seeking feedback in meantime. Thanks all.

Abhishek


On Sat, Mar 15, 2014 at 3:37 AM, Martin Braun wrote:

> On 14.03.2014 19:27, Abhishek Bhowmick wrote:
>
>> Hi,
>> So, according to some suggestions,  I looked into how I can potentially
>> use better signal processing for the OFDM receiver. I was thinking of a
>> LS estimator with higher order interpolation or an MMSE estimator for
>> the channel estimator part. Also, a MMSE-DFE or Viterbi equalizer. These
>> will need matrix operations and other computations, which can
>> potentially be developed into new volk kernels.
>> 1. Are the computational complexities involved feasible in the current
>> framework ?
>> 2. Though they can give better BER in adverse channel conditions, can
>> they do deliver more in terms of throughput/performance?
>> 3. Is it a good idea to include such implementations alongside doing new
>> volk kernels in the same proposal ?
>>
>
> Abishek,
>
> at this point, please just put together a proposal and upload it so we can
> make sure it gets into Melange in time.
>
> M
>
>
>> Abhishek
>>
>>
>> On Wed, Mar 12, 2014 at 3:38 AM, Florian Kaltenberger
>> > > wrote:
>>
>> Hi Nathan and Abhishek,
>>
>>
>> On 10/03/2014 23:22, West, Nathan wrote:
>>
>>> Ah! So there was a slight miscommunication. Yes, porting the
>>> OpenAirInterfaces
>>> SIMD code to VOLK is a good option as well. The turbo channel
>>> coder/decoder
>>> is part of that. I've**briefly**  looked at the code to see what is
>>>
>>> currently there, and
>>> it's my understanding that the work involved will be to write generic
>>> C implementations
>>> of vectorized code where the generic version does not exist. Beyond
>>> that porting to
>>> newer/different ISAs (AVX or NEON depending on your preference and
>>> hardware
>>> availability). I think Florian is on the gr-discuss mailing list, but
>>> I've CCed him to
>>> hopefully provide more details as he's more familiar with the
>>> original
>>> code base.
>>>
>> I only joined this mailing list recently, so I probably missed a
>> part of the discussion. Let me summarize briefly what
>> OpenAirInterface can provide. We have optimized SIMD (SSE4)
>> implementations of the LTE turbo encoder and decoder as well as the
>> LTE tail-biting Viterbi encoder and decoder. We also have the 802.11
>> Viterbi encoder and decoder. The only functions for which we have
>> generic non-vectorized functional equivalents is the LTE turbo
>> decoder.
>> I am not sure I understand why it is necessary to write generic
>> versions for the already optimized SIMD code. My idea was to port
>> the optimized SIMD code from OpenAirInterface to VOLK, such that is
>> can be used by GR applications. I am not familiar with VOLK (yet)
>> but this might just be as easy as writing a wrapper function.
>> As Nathan suggested, the more interesting part is probably to
>> upgrade the code to AVX2 or similar.
>>
>> Cheers,
>> Florian.
>>
>>
>>
>>
>> --
>> Regards;
>> Abhishek Bhowmick,
>> Senior Undergraduate,
>> Department of Electrical Engineering,
>> IIT Bombay.
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>


-- 
Regards;
Abhishek Bhowmick,
Senior Undergraduate,
Department of Electrical Engineering,
IIT Bombay.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)

[Activecat]

On Sat, Mar 15, 2014 at 5:14 PM, Sylvain Munaut <246...@gmail.com> wrote:
>> You may refer to previous conversations.  Do you agree with him that a
>> simple quadrature downconverter doesn't need to care about clock drift
>> because it just "simply downconverter and nothing more"?
>
> Yes ...
>
> Cheers,
> Sylvain


In this case I shall rephrase my question to:
"How to compensate the error due to clock drift which is not handled
by a simple quadrature upconverter ?"

Could anyone of gnuradio forum gives me some idea ?
I hope this is no longer categorized as expecting Ettus to teach me
the fundamentals of RF.

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

Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)

[Attila Kinali]

On Sat, 15 Mar 2014 17:46:58 +0800
Activecat  wrote:

> In this case I shall rephrase my question to:
> "How to compensate the error due to clock drift which is not handled
> by a simple quadrature upconverter ?"

I do not want to sound rude or anything, but you are asking very
basic questions on radio communications. You should read a textbook
or go to an introductory class on that topic.

You can find recommended documents on the suggested reading page[1].
Especially the "Digital Comms" section.

Also a good idea would be to do an Ham Radio licensing course.
These usually cover the most basic modulations and how it relates
to real devices too.


Attila Kinali

[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading/

-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson

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

Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)

[Tom Rondeau]

On Sat, Mar 15, 2014 at 10:46 AM, Activecat  wrote:
> On Sat, Mar 15, 2014 at 5:14 PM, Sylvain Munaut <246...@gmail.com> wrote:
>>> You may refer to previous conversations.  Do you agree with him that a
>>> simple quadrature downconverter doesn't need to care about clock drift
>>> because it just "simply downconverter and nothing more"?
>>
>> Yes ...
>>
>> Cheers,
>> Sylvain
>
>
> In this case I shall rephrase my question to:
> "How to compensate the error due to clock drift which is not handled
> by a simple quadrature upconverter ?"
>
> Could anyone of gnuradio forum gives me some idea ?
> I hope this is no longer categorized as expecting Ettus to teach me
> the fundamentals of RF.

Activecat,

It was mentioned earlier in this thread, you can use a PLL to lock to
a carrier. Basically,  you need an algorithm that performs carrier
recovery.

This thread is starting to get a little too confrontational, so we all
need to take a bit of a break. Please take a look at the PLL blocks in
GNU Radio; you can find them under the Synchronizers category in the
block tree of GRC. Spend some time understanding these blocks and how
to use them. If you still have questions, please open another email
thread.

Thanks,
Tom

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

Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)

[Activecat]

On Sat, Mar 15, 2014 at 5:56 PM, Tom Rondeau  wrote:
> It was mentioned earlier in this thread, you can use a PLL to lock to
> a carrier. Basically,  you need an algorithm that performs carrier
> recovery.
>
> This thread is starting to get a little too confrontational, so we all
> need to take a bit of a break. Please take a look at the PLL blocks in
> GNU Radio; you can find them under the Synchronizers category in the
> block tree of GRC. Spend some time understanding these blocks and how
> to use them. If you still have questions, please open another email
> thread.
>
> Thanks,
> Tom

I saw those PLL blocks but basically these blocks extract clocking at
the host (PC), while clock locking is needed at the SBX.
I feel you guys doesn't understand my concern.
Nevertheless I understand this starts to get confrontational, so I
have to stop here.
Sorry for any misunderstanding and offense arisen.

Thank you very much.
Regards,
Activecat

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

Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)

[Marcus D. Leech]

On 03/15/2014 02:57 AM, Activecat wrote:

Dear Marcus,

Please avoid adding more confusions rather than clarities.


The term "upconversion" and "downconversion" are common terms used in the
radio engineering industry, but may not be common among other technical folks.

In radio engineering industry, there are more than 1 type of
upconversion or downconversion. The common types include:
a).  analog up-conversion:
   The baseband real signal x(t) will be mixed with a carrier
frequency, that its output is a real signal of
y(t) = x(t).cos(wt)  where w = central frequency

b).  complex up-conversion:
   The baseband complex-based signal x(t) = I(t) + j.Q(t) will be
quadrature upconverted so that its output is a real signal of
y(t) = I(t).cos(wt) - Q(t).sin(wt)

For clarity sometimes we need to clarify which one you were referring to.
These two (analog vs complex upconverter) are significantly very
different from each other.

I was using the term "analog" to distinguish from "digital".   The FPGA 
*also* has up/downconverters for doing offsetting and "mop up"
  operations on the signal stream, and those operations are, 
necessarily, performed on a digital sample stream, rather than on an analog

  electron stream.

A quadrature up (or down) converter is structurally very similar to a 
real-valued converter, and most folks in the industry refer to
  both as "upconversion" and "downconversion".  While the mathematical 
expressions that describe them are, as you note, different,
  they're performing a very similar function, and use nearly-identical 
hardware, except that in the complex (quadrature) case, you have

  two mixers, and a phase-split local oscillator.

You can see the schematics of SBX (and other cards) here:

http://www.ettus.com/files/schematics




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

Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)

[Marcus D. Leech]

This thread is starting to get a little too confrontational, so we all
need to take a bit of a break. Please take a look at the PLL blocks in
GNU Radio; you can find them under the Synchronizers category in the
block tree of GRC. Spend some time understanding these blocks and how
to use them. If you still have questions, please open another email
thread.

Thanks,
Tom

___

Sorry, Tom.  I posted another in the thread before looking at you "drop 
this thread" message.   My bad.




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

Re: [Discuss-gnuradio] (GSoC) MIMO Transceiver

[Martin Braun]

Also post this proposal to melange  please.

M
On 15 Mar 2014 06:44, "YiZiRui Zhou"  wrote:

> Hello community,
>
> Two weeks have passed since I added my idea "MIMO Transceiver" on GR GSoC
> webpage. In the past few days, I tried to carry my project a step forward.
> I did some reading and made some tests on MIMO CSI estimation. Seems
> everything goes as I expected.
>
> More GSoC applicants join in the discussion now. So, I think it is time
> for me to formally apply to GSoC, or I will be late :)
> My proposal on "MIMO Transceiver" is released on my github.
>
> https://github.com/zhouyizirui/Wireless/blob/master/gr-mimo/miscellaneous/Proposal.pdf
> And my workbench snapshot.
>
> https://github.com/zhouyizirui/Wireless/blob/master/gr-mimo/miscellaneous/Device.jpg
>
> Although I tried hard to clarify my idea, yet there must be something I
> need to fix in my proposal.  I hope to get some feedbacks from you.
> Wish you a happy work!
>
> Thanks.
> Zhou
>
> ___
> 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] GSoC 2014 project "Wireless Networks In-the-Loop" and "Channel Sounder"

[achuth pv]

Hi every one,

I have certain doubts regarding the "Wireless networks in the loop"
project.
The optimization part which is suggested as one of the possible sub
projects- is the plan to move the python code to c++ so as to use the VOLK
libraries.
Which SDR board / daughter board is initially planned to implement.
I would also like to know more about the client-server as well as about the
server used.

Can any one please guide me regarding this project so that I can set up
proper goals for the proposal.

Thanks in Advance

Achuth

find me at #gnuradio IRC channel - achuthpv





On 4 March 2014 01:35, achuth pv  wrote:

> Hi everyone,
>
> My name is Achuth PV,  first year Master of Technology student in
> Communication and Signal Processing, Indian Institute of Technology,
> Bombay, India.
>
> I am really interested to work in the GSoC project "Wireless Networks
> In-the-Loop" and "Channel Sounder"( proposed in 2012 ).
>
> =
>
> *Wireless Networks In-the-Loop*
>
> The basic idea behind "Wireless Networks In-the-Loop" (WiNeLo) is to build
> a GR-based network emulator. This implies the modeling of the underlying
> SDR hardware, the individual channels & interference characteristics, as
> well as the timing behavior (produce correct amount of noise samples if no
> node is transmitting). The project already started in 2011 and as a
> outcome, the basic functionality -- the framework with client-server based
> "sample dispatcher" as well as some example hardware & channel models --
> has already been implemented in the gr-winelo OOT, which will be published
> on github soon. See
> http://video.fosdem.org/2014/AW1125/Sunday/Wireless_Networks_IntheLoop.webm 
> for
> a quick introdcution to "Wireless Networks In-the-Loop".
>  ObjectivesThere are various tasks covering several areas. Possible
> (sub-)projects are:
>
>- (Signal Processing) Implementation of new hardware/channel models
>like a SDR platform/specific daughterboards or reference channels.
>- (Optimization & Performance) Improve performance of existing
>implementation (port python code to C/C++, develop new mechanisms to
>collect & distribute samples between several nodes).
>- (Signal Processing & Development Tools) Implementation of new
>development tools like "breakpoints on the air link" (pause the entire
>emulation if certain criteria (BER, SNR, interference/collisions) is
>fulfilled on the virtual channel/at single nodes).
>
> Potential mentor(s)
>
> Nico Otterbach
> =
> *Channel Sounder (Proposed in 2012)*
>
> *Details*: Channel sounding describes the process of measuring a
> multipath propagation channel and obtain information about excess delay,
> Doppler spread and fading properties. The final product should make use of
> USRPs for channel sounding (the high timing constraints require use of the
> FPGA) and provide a complete measurement tool which can be used to gather
> statistics about mobile communication channels.
> *Knowledge prerequisite:* Digital signal processing basics, FPGA basics
> *Access to USRPs required.*
>
> *=*
>
> My fields of interest are signal processing, wireless and digital
> communication, hardware and software programming and data networks.
>
> I am really comfortable in programming using C/C++, java, matlab, assembly
> language, VHDL and I have understanding of Python, CUDA, git. I am also
> comfortable in working in Linux. I am a team player and a fast learner and
> has got good commitment. My B Tech final year project was "Implementation
> and comparison of various DCT architectures on FPGA using VHDL"
>
>  I got exposed to GnuRadio for the first time as a part of a course
> project in Wireless and Mobile Communication taken as a part of my masters.
>
> I want to contribute a lot to the open source world and I want GSoC to be
> the stepping stone for that.
>
> Can any one please tell me how to start working on these projects.
>
> Thanks in Advance
>
> Achuth
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Cold not find Zynq gnuradio-runtime module

[Richard Cagley]

On Sun, Mar 9, 2014 at 3:52 PM, Richard Cagley  wrote:

>
> On Sun, Mar 9, 2014 at 2:51 PM, Philip Balister wrote:
>
>> meta-sdr github
>
>
> i created an issue in the repo on github. Hopefully I captured the problem
> sufficiently.
>

Philip,
I needed xauth so I used hob to add it and I get the following error. Seems
related to your original solution for runtime. Is there a way to fix this?

Nothing RPROVIDES 'libgnuradio-runtime-3.7.3git' (but
/home/rcagley/oe-repo/oe/oe-core/meta-hob/recipes-core/images/
hob-image-20140315-163642.bb RDEPENDS on or otherwise requires it
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] For Sale: bladeRF x115 with GPIO expansion

[Louis Brown]

I just don't use it much since I primarily use 2m amateur band.  Very clean and 
little use; never left my lab bench.  The x115 is the large FPGA version.  Also 
included is the GPIO expander board and the 1m USB 3.0 cable.  Works great with 
GNU Radio via gr-osmosdr.

Asking $600 via PayPal with USPS Priority Mail shipping in USA.

Pics here:

http://forums.qrz.com/showthread.php?428974-bladeRF-x115-SDR-and-GPIO-Expansion

Thanks,
Lou
KD4HSO



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

Re: [Discuss-gnuradio] For Sale: bladeRF x115 with GPIO expansion

[Vanush Vaswani]

BladeRF have released an transverter that extends the frequency range down
to 60KHz. Are you sure you want to sell?


On Sun, Mar 16, 2014 at 12:12 PM, Louis Brown  wrote:

> I just don't use it much since I primarily use 2m amateur band.  Very
> clean and little use; never left my lab bench.  The x115 is the large FPGA
> version.  Also included is the GPIO expander board and the 1m USB 3.0
> cable.  Works great with GNU Radio via gr-osmosdr.
>
> Asking $600 via PayPal with USPS Priority Mail shipping in USA.
>
> Pics here:
>
>
> http://forums.qrz.com/showthread.php?428974-bladeRF-x115-SDR-and-GPIO-Expansion
>
> Thanks,
> Lou
> KD4HSO
>
>
>
> ___
> 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] For Sale: bladeRF x115 with GPIO expansion

[Louis Brown]

Yes, thanks, I'm aware of that.  I already have an N210 + WBX + LFTX/LFRX cards 
so that's getting all the use.  I have been doing allot of LF DX monitoring 
recently, so 60 kHz isn't even low enough.

Thanks,
Lou
KD4HSO

On Mar 15, 2014, at 8:16 PM, Vanush Vaswani  wrote:

> BladeRF have released an transverter that extends the frequency range down to 
> 60KHz. Are you sure you want to sell?
> 
> 
> On Sun, Mar 16, 2014 at 12:12 PM, Louis Brown  wrote:
> I just don't use it much since I primarily use 2m amateur band.  Very clean 
> and little use; never left my lab bench.  The x115 is the large FPGA version. 
>  Also included is the GPIO expander board and the 1m USB 3.0 cable.  Works 
> great with GNU Radio via gr-osmosdr.
> 
> Asking $600 via PayPal with USPS Priority Mail shipping in USA.
> 
> Pics here:
> 
> http://forums.qrz.com/showthread.php?428974-bladeRF-x115-SDR-and-GPIO-Expansion
> 
> Thanks,
> Lou
> KD4HSO
> 
> 
> 
> ___
> 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] For Sale: bladeRF x115 with GPIO expansion

[Marcus D. Leech]

On 03/15/2014 09:23 PM, Louis Brown wrote:

Yes, thanks, I'm aware of that.  I already have an N210 + WBX + LFTX/LFRX cards 
so that's getting all the use.  I have been doing allot of LF DX monitoring 
recently, so 60 kHz isn't even low enough.

Thanks,
Lou
KD4HSO

I'll point out that for VLF monitoring, a 96kHz (DC-48kHz) or 192kHz 
(DC-96kHz) sound card works quite well.



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

Re: [Discuss-gnuradio] For Sale: bladeRF x115 with GPIO expansion

[Louis Brown]

Quite so.  I have a GPSDO though, so it's nice to be able to lock to that.  
Last week I recorded WWVB (60 kHz) amplitude and phase for 1 week to monitor 
propagation.  Interesting results to see the fades over 6 days  Phase was 
futile though as their new BPSK mod messes things up.

Thanks,
Lou
KD4HSO


> I'll point out that for VLF monitoring, a 96kHz (DC-48kHz) or 192kHz 
> (DC-96kHz) sound card works quite well. 

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

Re: [Discuss-gnuradio] For Sale: bladeRF x115 with GPIO expansion

[Marcus D. Leech]

On 03/15/2014 09:57 PM, Louis Brown wrote:

Quite so.  I have a GPSDO though, so it's nice to be able to lock to that.  
Last week I recorded WWVB (60 kHz) amplitude and phase for 1 week to monitor 
propagation.  Interesting results to see the fades over 6 days  Phase was 
futile though as their new BPSK mod messes things up.

Thanks,
Lou
KD4HSO



I'll point out that for VLF monitoring, a 96kHz (DC-48kHz) or 192kHz
(DC-96kHz) sound card works quite well.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I built a prototype WWVB receiver in GR a couple of years ago, but I 
don't locally get WWVB :(Neither did my LaCrosse clock though, so it

  wasn't my fault :)


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

Re: [Discuss-gnuradio] For Sale: bladeRF x115 with GPIO expansion

[Louis Brown]

> I built a prototype WWVB receiver in GR a couple of years ago, but I 
> don't locally get WWVB :(Neither did my LaCrosse clock though, so it 
>wasn't my fault :) 

I'll post a new thread with some WWVB data.

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

[Discuss-gnuradio] WWVB monitoring with GNU radio

[Louis Brown]

Here is an (almost) week long plot of WWVB signal strength taken with GR and 
N210 + LFRX + 500 kHz LPF + 100 foot wire.  25 Msps decimated down to 100 sps, 
then RMS to 1 sps.  Very strong -60 dBm signal here 500 miles from the TX, yet 
deep fades which are consistent after sunrise.  Surprisingly consistent 
reception during the day time.

Plot:
https://dl.dropboxusercontent.com/u/49570443/wwvb_rx.png

GRC file:
https://dl.dropboxusercontent.com/u/49570443/wwvb.grc

GRC image:
https://dl.dropboxusercontent.com/u/49570443/wwvb.grc.png

Post processing:
https://dl.dropboxusercontent.com/u/49570443/wwvb2.py




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

Re: [Discuss-gnuradio] Failure of sending square wave over USRPs (back-to-back)

[Activecat]

I have found the answers.
http://nutaq.com/en/blog/multi-channel-synchronization-fpga-based-daq-systems
http://nutaq.com/en/blog/brief-overview-frequency-synchronization-ofdm

On the Nutaq platforms (ZeptoSDR, PicoSDR) you can control VCXO voltage
DAC from GNU Radio (and from FPGA user logic) to implement carrier
frequency offset correction.

Thanks everyone for your help.

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