DECT anyone?

GNU Radio
1

Hello,

I’m currently investigating the possibilities to do DECT with GNU Radio.
I currently have a USRP1 with BasicRX/TX. If possible, I’d like to avoid
buying the RFX1800 because of budget reasons (I’m a student right now),
so do you think it’s feasible by “abusing” the RF part of a used DECT
base station?

I noticed that DECT is on the wishlist, and it sounds like a nice
project for a master’s thesis… is anyone already working on DECT?

Alex

2

On Sun, Nov 11, 2007 at 06:51:05PM +0100, Alexander L. wrote:

Hello,

I’m currently investigating the possibilities to do DECT with GNU Radio.
I currently have a USRP1 with BasicRX/TX. If possible, I’d like to avoid
buying the RFX1800 because of budget reasons (I’m a student right now),
so do you think it’s feasible by “abusing” the RF part of a used DECT
base station?

That sounds like the hard way. You could end up spending a long
time trying to kludge up some hardware when there’s already a working
solution.

I noticed that DECT is on the wishlist, and it sounds like a nice
project for a master’s thesis…

If you’re serious about this as a project for your master’s thesis
and you’re willing to contribute the code to the project, we can
probably find some way to get you a daugtherboard. Will the
university pay for the daughterboard?

is anyone already working on DECT?

Johnathan did a bit of work a while ago. Not sure where that code
ended up. I thought it was in “limbo”, but I didn’t find it there.

DECT would be a great demo!

Eric

3

On Sun, 2007-11-11 at 10:36 -0800, Eric B. wrote:

is anyone already working on DECT?

Johnathan did a bit of work a while ago. Not sure where that code
ended up. I thought it was in “limbo”, but I didn’t find it there.

I had started a receiver module in examples/python/dect, but didn’t get
very far. What’s there will tune to a supplied frequency, apply the
appropriate channel filter, demodulate the GMSK to (unpacked) bits, then
record to a file. I was able to “grep” the bits for DECT
pre-amble/synchronization codes and see them.

This was to be a “service monitor” type of application, not a base
station or handset. So none of the TDMA aspects were considered. We
still need (ahem) mblocks and in-band signaling to properly implement
either end of the protocol.

A base station stack that could handle a single DECT TDMA carrier would
be able to support 12 cordless phones full-duplex. Wrap it up in an
Asterisk channel driver and you have a small office cordless PBX for the
price of a USRP and PC, using entirely Open Source software.

The DECT protocols are very well documented, and the handsets are very
cheap…

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

4

Is there an ETA for the mblocks? I’m not that much in a hurry, I won’t
be able to start my thesis before next summer anyway. And I’ll be happy
to discuss something like a roadmap with you folks before proposing this
project to a supervisor over here. No idea if it’s too big for a MSc
thesis …

The m-blocks are finished and in use. However the in-band signaling is
still in development. What is really needed is C++ daughterboard
support, the coupling of m-blocks and standard GR blocks, and a few
other outstanding issues in the core in-band component before it is
complete. Once these issues pick up, it can finally go out the door. I
really hope that these issues can be cleared by late January in all
reality.

DECT would be a great project for use of the new m-blocks and in-band
signaling, I’d highly recommend it. As Eric stated, the protocol is
well documented and our framework should give you a great base to
implement it.

  • George
5

Sorry for the long delay replying…

Eric B. wrote:

If you’re serious about this as a project for your master’s thesis
and you’re willing to contribute the code to the project, we can
probably find some way to get you a daugtherboard. Will the
university pay for the daughterboard?

Will try to convince them. Otherwise I’ll sell my car :wink:

Johnathan C. wrote:

I had started a receiver module in examples/python/dect, but didn’t get
very far. What’s there will tune to a supplied frequency, apply the
appropriate channel filter, demodulate the GMSK to (unpacked) bits, then
record to a file. I was able to “grep” the bits for DECT
pre-amble/synchronization codes and see them.

Well, at least a starting point…

This was to be a “service monitor” type of application, not a base
station or handset. So none of the TDMA aspects were considered. We
still need (ahem) mblocks and in-band signaling to properly implement
either end of the protocol.

Is there an ETA for the mblocks? I’m not that much in a hurry, I won’t
be able to start my thesis before next summer anyway. And I’ll be happy
to discuss something like a roadmap with you folks before proposing this
project to a supervisor over here. No idea if it’s too big for a MSc
thesis …

A base station stack that could handle a single DECT TDMA carrier would
be able to support 12 cordless phones full-duplex. Wrap it up in an
Asterisk channel driver and you have a small office cordless PBX for the
price of a USRP and PC, using entirely Open Source software.

Yep, true, that’s interesting from the political POV, but that’s a
rather expensive solution to get a SOHO cordless PBX… However, as a
proof of concept it’s worth the investment. And most likely cheaper than
an “old school” enterprise PBX with the DECT features enabled and DECT
base stations attached…

The DECT protocols are very well documented, and the handsets are very
cheap…

That’s true. You even get SIP capable base stations over here in Europe
for ~EUR 70-100 (USD 100-150) that allow you to assign different VoIP
providers to different handsets, use IM on the handsets, … but of
course without source ;-).

I wonder what other means to aid development are out there. I guess some
kind of DECT monitor and/or base station with debugging capabilities
would be really nice. If we do DECT in free software, we should be able
to prove it’s ETSI compliant :wink:

Alex