Cross band relais / bridge - DMR?

GNU Radio
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

would any of the USRPs together with gnuradio be suitable to serve as a
configurable cross band relais?
I sometimes have applications where we have to communicate which huge
amounts of radio systems which are not ours, which means that we either
have to give out a whole bunch of radios from us (and we don’t have so
many) or work with the radios of the other party (which is not always
desireable).
A very nice thing would be a cross band relais which would transmit
whatever is received from one of the channels on the other channel.
Simplex would absolutely suffice.

I have been working my way through grc but I am not absolutely clear how
to realize the squelch/PTT logic. Of course, I don’t want the box to
xmit continuously but only if an actual signal is received. There also
has to be some lockout-logic, so the relaying only goes in one direction
at a time. Otherwise, we would have a nasty feedback :).

The creamtip would be if gnuradio would speak ETSI DMR but I also didn’t
find too much about that yet…
We plan to change to DMR somewhat soon but most partners/customers still
use analog radios…

Any hints?

  • -S

(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk25s9gACgkQbQKZlCdPOMO6CQCePUXYndEyWBA4CMoa2fvB87QO
j6kAoIXFSWeH8/6/4J+Tgyb6o2pOfKHn
=nX3b
-----END PGP SIGNATURE-----

2

On Thu, 2011-04-28 at 21:37 +0300, Stefan Gofferje wrote:

many) or work with the radios of the other party (which is not always
desireable).
A very nice thing would be a cross band relais which would transmit
whatever is received from one of the channels on the other channel.
Simplex would absolutely suffice.

Without any details at all on what systems you’re trying to communicate
with, the answer is “very probably, but you’ll have to do it all
yourself”. In other words, the hardware when used with Gnuradio will
generate and receive pretty much any signal less than [25MHz for N210,
8MHz for USRP1, ~4MHz for E100] wide. But you’re going to have to
implement the whole transceiver system yourself, and that’s not a
plug-and-play proposition by any stretch of the imagination.

You may need to have complete details of the protocols used for each of
the systems you plan to communicate with, especially if you plan on
operating/receiving a trunk. In the case of some of the protocols
(Motorola Smartnet, LTR Multinet, EDACS) the standards are not publicly
available, and lots of reverse-engineering will be involved in
successfully getting Gnuradio to communicate with these systems.

I have been working my way through grc but I am not absolutely clear how
to realize the squelch/PTT logic. Of course, I don’t want the box to
xmit continuously but only if an actual signal is received. There also
has to be some lockout-logic, so the relaying only goes in one direction
at a time. Otherwise, we would have a nasty feedback :).

This is readily accomplished with existing Gnuradio blocks when combined
with Python code for the main application. You may or may not be able to
get such a system working entirely within GRC. There are multiple
existing squelch blocks based on tone decoding and/or receive power
level. I’ve been meaning to put in an “FM quieting” squelch like COTS
handheld FM radios use, but haven’t gotten around to it. Power squelch
works fine for most uses.

The creamtip would be if gnuradio would speak ETSI DMR but I also didn’t
find too much about that yet…
We plan to change to DMR somewhat soon but most partners/customers still
use analog radios…

Gnuradio is certainly capable of speaking ETSI DMR. Nobody has written
such a transceiver for Gnuradio, so if you’re willing to do the legwork,
it would be a welcome addition to the platform. It would definitely
involve writing your own C++ signal processing blocks as well as Python
code to glue them together.

–n

3

On Thu, 2011-04-28 at 23:19 +0300, Stefan Gofferje wrote:

8MHz for USRP1, ~4MHz for E100] wide. But you’re going to have to
implement the whole transceiver system yourself, and that’s not a
plug-and-play proposition by any stretch of the imagination.

Basically, we are just talking about good old analog FM narrowband radio
com. MAYBE - as I said as a creamtip - ETSI DMR 2 Analog. But if nobody
has written a trx yet, I guess, I have to forget about that. My
developer skills are way out of that league. There might be a chance
that I could get our boss to put out a bounty for that but I have to
prove that the USRPs are what we need before that.

If you’re just doing NBFM that’s pretty braindead simple.

One thing however is not totally clear to me.
A conventional radio has some “startup time” for the PLL to “swing in”
when you start transmitting. How is that with SDRs or the USRP in
specific? Does feeding data to the TX immediately result into a clear
and stable signal or is there also some “swing in” time to consider?

Specifically, does one have to consider some prerun time of transmitting
some “filler” before transmitting the actual payload?

Every time you tune the TX you’ll have to wait a few ms for it to become
stable. For voice transmission purposes, a few ms is effectively
instantaneous anyway. And if you aren’t retuning, then it will come up
instantly, because the LO will still be running in between sample
bursts.

–n

4

Nick,

Could you confirm that switching TX frequency takes “a few ms”? How did
you get this number? Is it the same for switching TX frequency after
the code has been running for a while, that is, reconfiguring the TX
frequency dynamically?

Andrew

5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 04/28/2011 10:03 PM, Nick F. wrote:

Without any details at all on what systems you’re trying to communicate
with, the answer is “very probably, but you’ll have to do it all
yourself”. In other words, the hardware when used with Gnuradio will
generate and receive pretty much any signal less than [25MHz for N210,
8MHz for USRP1, ~4MHz for E100] wide. But you’re going to have to
implement the whole transceiver system yourself, and that’s not a
plug-and-play proposition by any stretch of the imagination.

Basically, we are just talking about good old analog FM narrowband radio
com. MAYBE - as I said as a creamtip - ETSI DMR 2 Analog. But if nobody
has written a trx yet, I guess, I have to forget about that. My
developer skills are way out of that league. There might be a chance
that I could get our boss to put out a bounty for that but I have to
prove that the USRPs are what we need before that.

This is readily accomplished with existing Gnuradio blocks when combined
with Python code for the main application. You may or may not be able to
get such a system working entirely within GRC. There are multiple
existing squelch blocks based on tone decoding and/or receive power
level. I’ve been meaning to put in an “FM quieting” squelch like COTS
handheld FM radios use, but haven’t gotten around to it. Power squelch
works fine for most uses.

Marcus has already given me some pointers about the squelch / PTT thing.
One thing however is not totally clear to me.
A conventional radio has some “startup time” for the PLL to “swing in”
when you start transmitting. How is that with SDRs or the USRP in
specific? Does feeding data to the TX immediately result into a clear
and stable signal or is there also some “swing in” time to consider?

Specifically, does one have to consider some prerun time of transmitting
some “filler” before transmitting the actual payload?

  • -S

(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg’d Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk25y+EACgkQbQKZlCdPOMPVJQCfZqKNEhkMosJlL2KdYWEbUwIA
bJsAnj86sCxAu/gLNTB4T5+Z2Q4mOdnv
=0LrP
-----END PGP SIGNATURE-----

6

Hi Nick,

High end fractional N PLL’s generally have a settling time of 100us or
less if it is shifting to another frequency in the same band (say within
100MHz) assuming a high enough loop bandwidth. If it is starting up for
the first time, then a few ms of settling time is ok.

I am just wondering what other factors/latencies that cause a settling
time of several ms all the time?

Best regards,
-Vijay

— On Fri, 4/29/11, Nick F. [email protected] wrote:

From: Nick F. [email protected]
Subject: Re: [Discuss-gnuradio] Cross band relais / bridge - DMR?
To: “Feng Andrew Ge” [email protected]
Cc: [email protected]
Date: Friday, April 29, 2011, 3:51 PM

On Fri, 2011-04-29 at 15:42 -0400, Feng Andrew Ge wrote:

Nick,

Could you confirm that switching TX frequency takes “a few ms”? How did
you get this number? Is it the same for switching TX frequency after
the code has been running for a while, that is, reconfiguring the TX
frequency dynamically?

We don’t have a guaranteed spec for PLL settling time on the WBX, and we
encourage users to experimentally determine the settling time for their
particular setup and frequency. The figure I gave is based on what I’ve
seen in the lab, to the best of my recollection. =) It should be pretty
straightforward to determine the settling time for your setup and
frequency step by taking a data capture of a known source.

Any time you retune a PLL VCO, it will take some time to settle. If you
need to avoid that settling time, you can do CORDIC-only tuning with the
advanced tuning parameters to shift around within the bandwidth of your
ADC. This will provide a basically instantaneous tuning speed within a
range of 50MHz for USRP2/N2XX, or 32MHz for USRP1/E100.

–n

7

On Fri, 2011-04-29 at 15:42 -0400, Feng Andrew Ge wrote:

Nick,

Could you confirm that switching TX frequency takes “a few ms”? How did
you get this number? Is it the same for switching TX frequency after
the code has been running for a while, that is, reconfiguring the TX
frequency dynamically?

We don’t have a guaranteed spec for PLL settling time on the WBX, and we
encourage users to experimentally determine the settling time for their
particular setup and frequency. The figure I gave is based on what I’ve
seen in the lab, to the best of my recollection. =) It should be pretty
straightforward to determine the settling time for your setup and
frequency step by taking a data capture of a known source.

Any time you retune a PLL VCO, it will take some time to settle. If you
need to avoid that settling time, you can do CORDIC-only tuning with the
advanced tuning parameters to shift around within the bandwidth of your
ADC. This will provide a basically instantaneous tuning speed within a
range of 50MHz for USRP2/N2XX, or 32MHz for USRP1/E100.

–n