Reminder about call today

GNU Radio
1

This is just a reminder about today’s Developers’ Call. Due to other
conflicts, the time has been changed from the normal time to 1600 EST or
2100 UTC.

http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20120216

We’ll probably want to spend a significant amount of time on discussing
the
projects we want to put forward for the GSoC, so please join us if you
are
interested in participating.

Thanks,
Tom

2

Hey all,

I actually really want to join the call, because I have a GSoC idea, but
I
have a conflict with teaching assistant duties during that time.

So I thought I’d briefly share, and if it does become of interest then
maybe someone can get ahold of me and I could try to mentor or
something.
I thought it might be cool to show that GNU Radio and the USRPP can be
more than just about wireless technology, pushing forward on a hot topic
recently: PowerLine networking.

I’ve been trying to dig up details of PowerLine implementations, but I
think they are typically very “wireless PHY” oriented. I think they are
in
general OFDM based with Turbo Convolutional Codes. I think that GNU
Radio
already provides a lot of the blocks that would be necessary to build
the
PHY. I am not sure of what the necessary frontend might be for this, but
maybe by the summer if Matt and GNU Radio folks are truly interested, a
prototype could be made.

Some info i found on PowerLine details:
http://helpfromageek.com/2011/05/18/white-paper-powerline-networking/

3

to stick the Rx/Tx port of the USRP into a wall socket :slight_smile:

Trust me, I am far from an EE person, so ignore any outrageous
misunderstandings :wink: I guess this will start as more of question:
since
we can’t stick Rx/Tx directly in to a wall socket… what actually needs
to
happen to stick an Rx/Tx in to a wall socket? I’m guessing a bunch of
filtering goes on with the actual power, but beyond that I have no clue.
I
guess part of this is I was wondering if it is feasible to develop a
frontend to stick a USRP in to a wall socket. Then, due to the horrible
channels you mention, I think it makes for an interesting/feasible 3
month
project to get communication through to power line with those channels.
Even measurement on what those channels are like would be interesting,
and
I know whatever might come out of this would really open up the ability
for
the academic community to directly research power line networks.

Thanks, Tom!

  • George
4

On Thu, Feb 16, 2012 at 10:24, Tom R. [email protected] wrote:

Powerline communications have been discussed for quite
a while, but they tend to be horrible channels (old copper, long distances,
bad shielding, etc.). So yes, I’d expect OFDM for the equalization and
multipath (or ‘echos’ in this case) issues and heavy channel coding are
required.

OFDM for the equalization and FEC for the channel errors has been a
successful technique used in residential power-line communications.
However, commercial buildings tend to have long and unpredictable
power delay profiles, requiring long symbol times. In addition, there
are enormous sources of interference (primarily impulse noise) from
things like elevator motors and paper shredders (!), as well as strong
shortwave RF induced signals. Finally, some installations use
multiple transformers between floors, with their own very
unpredictable channel response.

As an alternative, one commercial R&D contract I did a while back was
to use DSSS/CDMA with long codes to reduce the interference by the
coding gain, then use additional delay correlators to receive and
combine echos (a basic RAKE receiver). This worked extremely well for
interference rejection, without FEC at the data level, but at the
expense of a low bit rate and long synchronization times. Since the
communication requirement was a unidirectional broadcast, this worked
out well.

The initial implementation was done in GNU Radio with a chipping rate
of 2 Mcps, then ported to the USRP2 FPGA (minus the rake) for chipping
rates up to 25 Mcps.

I think this goes to the point that GNU Radio is an excellent tool for
experimentation, R&D, prototyping, etc., and not so much for chasing
existing standards.

My main question regarding this topic is to figure out what would be
necessary to create a test bed to try it out on? Obviously, we aren’t going
to stick the Rx/Tx port of the USRP into a wall socket :slight_smile:

That company made some generic 50-ohm to wall socket power couplers
for the project, but I don’t know if they ever made them commercially.
I still have a pair in my lab to play with :slight_smile:

Johnathan

5

On Thu, Feb 16, 2012 at 11:49, George N. [email protected] wrote:

Trust me, I am far from an EE person, so ignore any outrageous
misunderstandings :wink: I guess this will start as more of question: since we
can’t stick Rx/Tx directly in to a wall socket… what actually needs to
happen to stick an Rx/Tx in to a wall socket?

The impedance of a power line varies a lot with frequency. Power
couplers use capacitors and transformers to try to match the impedance
the best they can, but it’s hard to get anything broadband.

Then there are all the safety issues when dealing with high voltage,
and the protection circuitry for the 50-ohm side to deal with things
like lightning induced spikes, etc.

Johnathan

6

The easy button to interface to the AC plug would be to pick up some old
power line telephone extenders from Radio Shack and cut them open. You
could then use the basic RX and TX cards.

From: discuss-gnuradio-bounces+evan=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+evan=removed_email_address@domain.invalid] On Behalf Of
George N.
Sent: Thursday, February 16, 2012 12:49 PM
To: Tom R.
Cc: GNURadio D.ion List
Subject: Re: [Discuss-gnuradio] Reminder about call today

Interesting thought. Powerline communications have been discussed for
quite
a while, but they tend to be horrible channels (old copper, long
distances,
bad shielding, etc.). So yes, I’d expect OFDM for the equalization and
multipath (or ‘echos’ in this case) issues and heavy channel coding are
required.

My main question regarding this topic is to figure out what would be
necessary to create a test bed to try it out on? Obviously, we aren’t
going
to stick the Rx/Tx port of the USRP into a wall socket :slight_smile:

Trust me, I am far from an EE person, so ignore any outrageous
misunderstandings :wink: I guess this will start as more of question:
since we
can’t stick Rx/Tx directly in to a wall socket… what actually needs to
happen to stick an Rx/Tx in to a wall socket? I’m guessing a bunch of
filtering goes on with the actual power, but beyond that I have no clue.
I
guess part of this is I was wondering if it is feasible to develop a
frontend to stick a USRP in to a wall socket. Then, due to the horrible
channels you mention, I think it makes for an interesting/feasible 3
month
project to get communication through to power line with those channels.
Even measurement on what those channels are like would be interesting,
and I
know whatever might come out of this would really open up the ability
for
the academic community to directly research power line networks.

Thanks, Tom!

  • George
7

unpredictable channel response.

Hey Jonathan,

This was a super informative post, it’s really interesting to hear about
experience of actually building PLC in practice. I haven’t seen very
many
studies on it, but it seems like different buildings have greatly
varying
profiles. I didn’t think of things like elevator motors in office
buildings, but that’s got to introduce a lot of interference.

If you ever do this again, I would love to see some of the channels over
time. I ordered some basic PLC equipment, but all I really have access
to
are packets :stuck_out_tongue:

As an alternative, one commercial R&D contract I did a while back was
to use DSSS/CDMA with long codes to reduce the interference by the
coding gain, then use additional delay correlators to receive and
combine echos (a basic RAKE receiver). This worked extremely well for
interference rejection, without FEC at the data level, but at the
expense of a low bit rate and long synchronization times. Since the
communication requirement was a unidirectional broadcast, this worked
out well.

Nice, I guess with unidirectional broadcast that does work out well for
you. How do you actually get echoes in a PL? I never thought about
this.

necessary to create a test bed to try it out on? Obviously, we aren’t
going
to stick the Rx/Tx port of the USRP into a wall socket :slight_smile:

That company made some generic 50-ohm to wall socket power couplers
for the project, but I don’t know if they ever made them commercially.
I still have a pair in my lab to play with :slight_smile:

It would be really cool to be able to hook up the USRP to a PL and
understand various channels in different types of buildings. Totally
not
conducive to my dissertation, but I find it interesting.

  • George
8

On Thu, Feb 16, 2012 at 11:06 AM, George N. [email protected]
wrote:

Hey all,

I actually really want to join the call, because I have a GSoC idea, but I
have a conflict with teaching assistant duties during that time.

Hi George,
Sorry the timing won’t work out this month.

PHY. I am not sure of what the necessary frontend might be for this, but
maybe by the summer if Matt and GNU Radio folks are truly interested, a
prototype could be made.

Some info i found on PowerLine details:
http://helpfromageek.com/2011/05/18/white-paper-powerline-networking/

Interesting thought. Powerline communications have been discussed for
quite
a while, but they tend to be horrible channels (old copper, long
distances,
bad shielding, etc.). So yes, I’d expect OFDM for the equalization and
multipath (or ‘echos’ in this case) issues and heavy channel coding are
required.

My main question regarding this topic is to figure out what would be
necessary to create a test bed to try it out on? Obviously, we aren’t
going
to stick the Rx/Tx port of the USRP into a wall socket :slight_smile:

Thanks for the idea!

Tom