SDR_PHY question

Tomcsányi, Domonkos domi at
Wed Sep 6 16:09:29 UTC 2017


Just a quick thing: to get ABI supported version of UHD do not use the Ettus ppa uhd, but use the one called uhd-lts or something similar. It is compiled with the right ABI version for the gnuradio distro package.


2017. szept. 6. dátummal, 17:42 időpontban Adrian Musceac <kantooon at> írta:

> Hi Vadim,
>> In general, trxcon should be able to 'speak' with OsmoTRX,
>> because one do use classical transceiver UDP interfaces. But
>> there are some CTRL commands, which aren't implemented in OsmoTRX
>> yet (such as ECHO and MEASURE).
> Yes, I implemented both commands, I can share the code with you. My
> problem is that Gnuradio (distro version) is built against an
> incompatible ABI version of libuhd, so I have to jump through major
> hoops just to get both osmo-trx and gnuradio working. So currently all
> my tests are using osmo-trx only.
>> The order of bursts should be consistent, I mean frame-by-frame.
>> You need to make sure that a frame number from SCH burst is being
>> decoded correctly by OsmoTRX. Every burst coming from OsmoTRX
>> has a header with frame number, which is used by trxcon to
>> determine a current frame position within a multiframe.
>> Probably, the problem is due to incorrect / consistent
>> frame number values. The internal clock counter (sched_clck.c)
>> is only used to schedule the UL bursts transmission.
> Yes, the SCH burst has a correct frame number. But the BCCH and CCCH
> bursts fail to be decoded. CRC fails in
> libosmocore/coding/gsm0503_coding.c
> Is your gr-gsm fake-trx able to decode correctly BCCH and CCCH? I
> double checked the osmo-trx code and besides some major differences
> between the MS branch and master, everything looks correct.
>> You can also join the development process, feel free to mail me.
>> I will create the wiki page as soon as possible.
> Yes, I'd like that, but for now I just want to get BCCH and CCCH
> working and the mobile syncing with the BTS. Then I will be able to
> test.
> Cheers,
> Adrian

More information about the baseband-devel mailing list