Hi.
I'm troubleshooting peculiar use case with packet access and osmo-bts-trx. There are
2 options for ME to acknowledge reception of control packet to PCU according to 3GPP
TS 44.060 § 11.2.2:
1) Packet Control Acknowledgement message
2) 4 identical access bursts
The latter can be both 8-bit RACH and 11-bit RACH (not supported by osmo-bts-trx
yet). The choice of response format is defined by OpenBSC in SI: 1) is default, 2)
can be activated with "gprs control-ack-type-rach" option.
The problem is that I don't understand how 2) will be handled by OsmoTRX? Shall I
expect 4 consecutive RACH messages via rx_rach_fn() in scheduler_trx.c in
osmo-bts-trx? Shall it be some other message/function? Will it be ignored/dropped
altogether by OsmoTRX?
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hi All,
I wrote a GSM signal generator application based on osmo-trx. The new
osmo-siggen allows random GSM or EDGE burst generation without using
special configurations of osmo-trx or the socket control interface.
Frame trigger output through GPIO is also available.
I use the application for testing modulation parameters and other PHY
level testing. Hopefully it's useful to other developers beyond
myself.
$ ./osmo-siggen -h
Options:
-h, --help This text
-a, --args UHD device args
-l --log Logging level ('err', 'warn', 'notice', 'info', 'debug')
-b, --burst Burst type ('normal', 'access', 'freq', 'sync', 'edge')
-r, --ref Frequency reference ('internal', 'external', 'gps')
-f, --freq Tx RF frequency
-g, --gain Tx RF gain
-s, --sps Tx samples-per-symbol (only 4 supported)
-m, --mod GSMK modulator type ('laurent4', 'laurent2', 'laurent1', 'nco')
-p, --ampl Tx amplitude (0.0 - 1.0)
-o, --offset Baseband frequency offset
-t, --tsc Normal and EDGE burst training sequence (0-7)
-S, --swap Swap channels
Currently osmo-siggen is located in the below branch. I've tested
solely with B210. C++14 availability is also required for now.
git://git.osmocom.org/osmo-trx ttsou/siggen
-TT
Hi all,
I was wondering if it is possible to generate a TDMA frame sync output
on a GPIO line of a USRP device (and/or any other SDR supported by
osmo-trx). This way it would be much easier to do e.g. BER testing
by using a pure waveform/pattern generator for the "MS side". Such
devices (Like an E4433B) can only generate the uplink bursts with
pseudo-random sequence, but they don't have any receiver, so they're not
able to receive the downlink from the BTS in order to lock on the TDMA
frame and transmit the uplink in sync to that.
There are of course specialized devices (CMU-300, ...) or hardware
options that add such receivers for synchronization on the signal
generators, equipment side, but why go there if there would be an easy
way to generate some kind of a frame sync output.
I would appreciate to know even if there's a way to introduce such
"synchronous GPIO toggles" or the like in the command stream to UHD
devices. If that existed, it should be rather simple to insert those
whenever a new burst for TS0 is sent.
A rather computationally (and bandwidth) expensive other option might be
to use the second RF output to generate such a signal, but I was hoping
not having to abuse the 2nd channel for that ;)
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
hello everyone ......
anyone doingwith rbs2308 ? i am doing with dhai and E1 interface but it doesn't come to operational mode ....if anyone got any output from rbs 2308 pls let me
thanks
rajitha
People keep posting images to this list. I saw that mailman allows to remove
image attachments by file suffix and/or by mime type. I suggest we put jpg,
png, bmp on the list of attachments to remove.
AFAICT there was zero need for a legitimate image post, and if we'd want to we
can always create a wiki page or redmine ticket and attach the image there.
It would be nicer to bounce messages with such attachments completely, but
dropping the attachments is the next best thing.
Opinions?
I don't have access to the list admin, so (if we agree) someone else would need
to effect this / give me the pw:
mailman admin / "MIME-/HTML-Filter" / tick 'yes' on top and add image suffixes
to the reject list
~N
Hello,
In the Netherlands the free gsm channel for private gsm networks is;
1875 - 1879,9 MHz 200 mW e.r.p. 200 kHz
875 - 1879,8 MHz 50 mW/MHz e.r.p. ≤4,5 MHz
But I am a little bit confused as to how to set up an ipacces nanobts with
those frequencies
In OsmoBTS configuration file find bts 0 and set band to GSM1800
Also set frequencies to right value arfcn
The example says (
https://osmocom.org/projects/openbsc/wiki/Multi-BTS_with_handover)
trx 0
rf_locked 0
arfcn 74
...
trx 1
rf_locked 0
arfcn 84
---------------
I am not sure what to put at arfcn as the correct frequency with the
mentioned frequency..
A second question, the nanoBTS comes in 1800 for GSM1800, and GSM1900
variant thereof (almost identical hardware)
Well I can get 2 of the 1900 version very cheap from the USA but setting
the configuration file bts 0 band GSM1800 won´t change the frequeny of the
1900 model to 1800MHz?
Or can I only use the 1900 version in the free 1900MHz DECT frequency range?
I have attached the official document of the Dutch regulatory body with the
allowed frequencies, see page 28 for DECT frequencies in 1900 band and page
29 for picocell frequencies in the 1800 band.
To me it seems both bands 1800 and 1900 are allowed, 1800Mhz is the
official private gsm but for testing purposes using a 1900 model on the
DECT band should be ok to.
If the nanobts 1900 US model could also operate on the 1800 band that would
be even better.
Thanks, Albert
In our osmo-gsm-manuals, there are various code listings that one would like to
copy-paste from the PDF. That would theoretically work, but practically, the
'DRAFT' watermark in the backdrop confuses the text marking, hence making
copy-pasting some text from the manuals very very cumbersome. Though I'm not
that sure why we need a 'DRAFT' watermark in an open source manual (it's
implicitly a draft), I am fine with having such a marking.
But I would like the marking to be less obtrusive. We could experiment with
putting a bitmap image in the backdrop instead of text, or even better IMHO
would be to put it in the page header next to the version.
We could also add a generic "DRAFT" disclaimer near the beginning of each
document.
(Same goes for the sysmocom internal manuals, for which it isn't so easy to get
the asciidoc source to paste from.)
Any opinions on this?
~N
Hi,
I just looked into a build breakage when --disable-static is passed. The
first failure is because of:
libosmo_sigtran_la_LDFLAGS = -version-info $(LIBVERSION) \
-no-undefined \
-export-symbols-regex '^osmo_'
The testcases use xua_* sua_ symbols but they are not exported. Shall
we export them or shall we forbid --disable-static on libosmo-sccp?
The second part is that I had preferred the sccp library to be static
only to avoid having to do proper ABI checking/versioning. If we fix
the above, maybe we have to fix this part too?
holger
Greetings,
Congrats on OsmoCon 2017!
I have been working with OsmocomBB, osmo-sim-auth, mncc-python projects in
Osmocom.
I would like to contribute some code snippets with your acceptance.
To begin with I have committed:
I) MNCC with OsmocomBB - *https://github.com/GerardPinto/call-control-mncc-sap
<https://github.com/GerardPinto/call-control-mncc-sap>* (Has both
implementations in Python and C + Tested voice with gsm-fr with gsm audio
file - works great).
- Some of which can be committed to mncc-python? (In order to support
MNCC with OsmocomBB too) Although, Harald told me it was built for OpenNITB
- I'm not sure, the relevance of this contribution to this repo?
Reason:
1. Solves some mailing list questions: Some questions on mailing list are
pertaining sending voice from PC to phone and receive.
2. Useful for test cases: In the future, if 'gsm-efr' codec is implemented,
we can use these snippets and send audio with gsm-efr sample, instead of
connecting to LCR (Am I correct?)
*Issues faced*: File: l23api.c | function: l1ctl_rx_traffic_req()
264 bits (33 bytes) of voice codec are interleaved into 456 bits. The DAC,
ciphering/deciphering , RF etc. work on 114 bits at a time so, 114 x 4 =
456.
So Layer23 sends 4 - 114 bits into the queue to Layer1 in function =>
l1ctl_rx_traffic_req
*Code*: num = l1a_txq_msgb_count(&l1s.tx_queue[L1S_CHAN_TRAFFIC])
if num > 4 dropping traffic frame. (114 x 4)
The code above indicates if queue has any (114 x 4) bits drop the incoming
voice request.
So I faced the issue of voice packets getting dropped, but that was just
twice/thrice and then it did not give me any trouble (I'm not sure how it
got fixed), I could hear *clear* voice gsm-fr on the called party cell
phone.
*My Question is*: If I happened to send voice packets 33 bytes really fast.
There should be some kind of buffer rather than a check (Code) and drop
frame? - OR this case can never happen?
My apologies, if my understanding is incorrect, I just tried to reverse
engg. from code and GSM codec available online!
II) osmo-sim-auth with added other SIM related API's (still needs code
clean up, SIM response check, code re-usable, README.md etc,)
* https://github.com/GerardPinto/osmo-sim-auth
<https://github.com/GerardPinto/osmo-sim-auth> *
- I did check out PySIM (I think I can add some code to the existing
repository, with your permission).
Could you please let me know if my osmo-sim-auth repo? If it is correct to
combine with PySIM, with the changes done below?
Files modified:
1. SIM.py - Added more API's.
2. osmo-sim-auth.py - Options parser.
Thanks,
Gerard.