axilirator at gmail.com
Sun Jul 16 17:00:12 UTC 2017
> I'm very happy to hear from you again.
Glad to see you too!
> It's great that you figured it out. I'm more than interested
> to help you to push this topic forward. Will you be able to tell
> me how to compile and run the software so I will be able to test
> it on my side?
Thanks! I definitely need to create a page on wiki about that.
This is a brief guideline how to run OsmocomBB on SDR:
1) You will need to clone a fork of GR-GSM from GitHub:
I am going to send a pull request, as soon as I finish
some things and clean up the code according to your
2) Build GR-GSM as usually, and you will see a new GNURadio
block named 'TRX Interface' in gnuradio-companion.
3) Clone my branch of OsmocomBB:
git clone git://git.osmocom.org/osmocom-bb -b fixeria/sdr_phy
4) Make sure you have a fresh version of libosmocore, and build
OsmocomBB without firmware (we don't need it anymore):
5) Go to the 'apps/trx/' directory, and launch the 'grgsm_trx.py'
application. One will init a simple follow graph and actual
6) Go to the 'osmocom-bb/src/host/trxcon/' directory, and run
the 'trxcon' application, which is used to connect OsmocomBB
L2&3 applications with transceiver application.
./trxcon -d DAPP:DL1C:DSCH
7) Go to the 'osmocom-bb/src/host/layer23/src/misc/' directory
and run the 'ccch_scan' application, and you will see how
it actually works ;)
./ccch_scan -a ARFCN -i 127.0.0.1
> To answer this I will need to know more about what hardware you plan to
> use to receive and transmit. With i.e. USRP on a hardware level you have
> the synchronization. If you plan to use RTL-SDR + some transmitter then
> we will probably need some way to provide synchronization at a hardware
> level too. As for GSM Receiver - it sends bursts together with GSMTAP
> header which contains frame number. So you can identify bursts.
I think, exactly devices like USRP should be our primary hardware
platform. I use UmTRX - USRP based board, designed exactly for mobile
networks. At the same time, I would prefer to keep in mind further
possibility to use the project with separate RX and TX hardware.
> We will need to write some modulator for bursts. We can adapt the code
> from osmo-trx or use portion of the code from GMSK Mod block. Using GMSK
> Mod block might not be a good idea because of 8.25 symbols long guard
> periods between bursts. The quater bit long shifts might be a problem.
Yeah, I had a little discussion on #gnuradio IRC, and some guy
consulted me a bit. One problem, we will probably deal with, is
GNURadio scheduling engine and block buffers. At the same time, the
trxcon application can send TX bursts in advance. As much frames before
as it's required to normal TX operation. This is how OsmoBTS does.
He also described an exemplary algorithm of TX operation:
1) Take in your bits (burst)
2) Up sample
3) Pulse shape with an interpolating fir filter with a Gaussian response
4) Feed that into a frequency modulation operation with the correct gain
5) Then channel filter those with an FFT filter
6) Use a frequency rotator of you need to freq shift the signal within
your DSP bandwidth
7) And perform a final up sampling and antialias filter before TX.
What do you think?
> Can you tell me what you would like to do on OsmocomBB side and what to
> do on the GNU Radio side? I'm asking because have some idea how to make
> a low level part of GSM TRX in GNU Radio.
OsmocomBB's side does all burst transcoding operations itself,
so we only need to modulate and send requested bursts in time.
We will also need to perform power measurements, but let's focus
on TX for now.
> What hardware you want to use (RTL-SDR to receive and Calypso
> phone to transmit)?
No, we need to build a Calypso independent PHY for OsmocomBB.
See my answer above.
With best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the baseband-devel