Hi Piotr, I just wrote a simple (more or less working) GNURadio block for connection with OsmocomBB. It is named "TRX Interface" and currently only capable to transform (in Osmocom bursts are followed by a bit different header) and send received bursts through the UDP link.

So, I have copied actual implementation, stripped out everything related to TCP and implemented a feature to set UDP source port. Now I am able to receive all DL bursts, coming from GR-GSM to my trxcon application. At the moment I am working on TDMA scheduler, which is almost finished. It's time to start writing GR-GSM blocks for burst transmission. The following thoughts / questions are in my mind:

- TX should be simpler than RX, because we don't need to detect bursts and correct any errors.

- Both receiver and transmitter should be time synchronized. I think, the SCH clock from the 'GSM Receiver' block may be easily shared. Moreover, actual clock indications could be forwarded to my block.

- If I am correct, to transmit a burst, one should be converted to symbols. How can we do that? - We cannot simply use the existing 'GMSK Mod' block, because GSM uses TDMA. Right? If so, point me to the right direction.

Hi Piotr, Glad to see you too! 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: https://github.com/axilirator/gr-gsm/tree/fixeria/trx I am going to send a pull request, as soon as I finish some things and clean up the code according to your requirements. 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): cd osmocom-bb/src/ make nofirmware 5) Go to the 'apps/trx/' directory, and launch the 'grgsm_trx.py' application. One will init a simple follow graph and actual TRX interface. 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 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. 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? 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. No, we need to build a Calypso independent PHY for OsmocomBB. See my answer above. With best regards, Vadim Yanitskiy.