This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Vadim Yanitskiy axilirator at gmail.comHi 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.
If you remember, I had a problem with UDP source port. So, I spent
some time and finally solved this challenge. My first idea was to
inherit the existing 'Socket PDU' implementation and I started to
look for a way I could do that. After a few minutes of searching,
I have found your mails with the same question, and a brief answer
from Sylvain, that it is impossible :(
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.
P.S. This message is posted at the baseband-devel mailing list.
With best regards,
Vadim Yanitskiy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170622/df4dcd43/attachment.htm>