Tue 15-jan-2019
LimeSDR transmit check.
Fired up old HP 8614A signal generator at 1880 Mhz, and let it stabilize
for 1 hour.
Level measurement after adjusting ALC, 0dBm = -0.4 dBm as checked with
spectrum analyzer
Checked level with HP L423A probe.
Check of LimeSDR mini output.
Output as seen on spectrum analyzer -1.0 dBm. This correlates with
LMS7002 datasheet with
a possible 1 dB loss between chip and analyzer, including SMA-BNC coax
adapter, 2 m foam
insulated RG58 size cable, BNC - N connector.
So, for practical purposes the LimeSDR mini provides 0 dBm ( +/- 1.4 dBm )
LimeSDR receive check.
Receive antenna rigged with a 1/10 dB splitter, -10 dB port connected to
spectrum analyzer, -1 dB
port to LimeSDR.
Connect single Nokia Handset, and make a call from osmobsc to fixed
phone, so that only one mobile
is using TCH. Move phone to get different uplink levels and correlate
these to spectrum analyzer.
Since carrier is TDMA, use peak hold on analyzer.
Active subscriber connections:
conn ID=31, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1@mgw
BTS 1, TRX 0, Timeslot 1, Lchan 0: Type TCH_F
Connection: 1, State: ESTABLISHED
BS Power: 10 dBm, MS Power: 10 dBm
Channel Mode / Codec: SPEECH_V1
No Subscriber
Bound IP: 192.168.1.75 Port 16384 RTP_TYPE2=0 CONN_ID=0
Conn. IP: 192.168.1.70 Port 4110 RTP_TYPE=3 SPEECH_MODE=0x00
Measurement Report:
Flags:
MS Timing Offset: 0
L1 MS Power: 10 dBm, Timing Advance: 4
RXL-FULL-dl: -51 dBm, RXL-SUB-dl: -51 dBm RXQ-FULL-dl: 0,
RXQ-SUB-dl: 0
RXL-FULL-ul: -54 dBm, RXL-SUB-ul: -54 dBm RXQ-FULL-ul: 0,
RXQ-SUB-ul: 0
Level on uplink -54 dBm, indicated on spectrum analyzer -53 (-63) dBm.
OsmoBSC# show conn
Active subscriber connections:
conn ID=31, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1@mgw
BTS 1, TRX 0, Timeslot 1, Lchan 0: Type TCH_F
Connection: 1, State: ESTABLISHED
BS Power: 10 dBm, MS Power: 10 dBm
Channel Mode / Codec: SPEECH_V1
No Subscriber
Bound IP: 192.168.1.75 Port 16384 RTP_TYPE2=0 CONN_ID=0
Conn. IP: 192.168.1.70 Port 4110 RTP_TYPE=3 SPEECH_MODE=0x00
Measurement Report:
Flags:
MS Timing Offset: 0
L1 MS Power: 10 dBm, Timing Advance: 4
RXL-FULL-dl: -69 dBm, RXL-SUB-dl: -69 dBm RXQ-FULL-dl: 0,
RXQ-SUB-dl: 0
RXL-FULL-ul: -59 dBm, RXL-SUB-ul: -59 dBm RXQ-FULL-ul: 0,
RXQ-SUB-ul: 0
Mobile moved to another location within the lab.
Level on uplink -59 dBm, indicated on spectrum analyzer -60 (-70) dBm.
Conclusion:
For such a simple low cost SDR, the accuracy seems within a couple of
dB. Instruments used
were are not "professional grade", at least not w.r. 2019, but I
estimate I can measure
within +/- 2 dB or so with this crude config. Power output is 10 times
lower than I expected,
I was probably mislead by some review on the web, and had to go down to
the actual scematic
and datasheet to understand that the expected level should be around 0 dBm.
(thanks for pointing this out, Harald)
For practical use outside a lab output is far too low. My plan is to add
a small simple booster
to bring level up to +15 which would allow me to cover my 2 acre lot
without breaking any rules.
Else, I am impressed, good value for a low price tag. I had expected far
worse than indicated accuracy.
Best Regards,
Gullik
Hi all,
when reviewing osmo-hlr db schema upgrades, I came up with the idea that we
shouldn't upgrade automatically. That's why, for schema updates, osmo-hlr now
refuses to start and requires one start with the --db-upgrade option.
Our systemd service file does not include that option.
The result is that after an upgraded osmo-hlr binary, admins may have to take
extra action to upgrade the DB.
The rationale is that if someone by accident launches a newer osmo-hlr only
once, with automatic upgrade the user is then stuck with the newer version DB,
since we don't make a backup and we don't provide a downgrade path.
I'm now wondering whether that is really necessary. In the daily churn, it
creates noise. How to make this less noisy?
- Users could add the --db-upgrade option to the service file to always
upgrade. (But it is cumbersome to have a .service file that differs from the
installed version)
- We could also add a cfg file option to allow-db-upgrades.
- We could drop the behavior and always upgrade.
In the lack of strong opinions, this will probably stay as it is. I'd just like
to hear what you guys think about it. Is it annoying or a good idea?
Thanks!
~N
Hey list..
so i want to do some experiments setting the default TA in the PCU to
the distance from the tower to the main population centre, rather than
have it set to 220 (invalid)
So, this email is not about the details of that issue, rather just a
quick question.
In the interim while this gets finally done right, would we accept
adding a default-timing-advance param to the vty config?
Otherwise I can patch and compile version for each BTS, but the vty
config would be WAY more handy!
thnx
k/
Hi Community,
Is it possible to send SMS using alphanumeric characters as a sender address?
We tried it using an Open-Source SMS GW and it can send alphanumeric information in the sender address.
Unfortunately, the SMS sent through API was not received to the test phone and the logs below are seen in OSMO-MSC.
<000c> smpp_smsc.c:729 [entropy] Rx SUBMIT-SM (09170000023/1/1)
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
We also tried sending SMS with only Numeric information in the sender address and the SMS was received successfully by the test phone.
We can share the traces taken and the configurations used if needed.
TIA.
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
Hi,
Some weeks ago I managed to integrate osmobts with my asterisk server.
In the beginning, I did
not get any call progress, ( as opposed to running WITHOUT asterisk ). I
realized that defining
the msc to sipconnector socket effectively disabled all the logic
related to this.
To remedy the situation, I set an asterisk "progress statement" whenever
the extensions.conf
indicated a number belonging to my GSM network. This works OK, but now,
I don't get call progress
on calls toward PSTN. These extensions do not have "progress"
statements, since all SIP phones
interpret the call progress sip messages such as RINGING.
I am interested in your comments whether msc + sipconnector should
emulate mobiles as "sip phones",
it does seem to just silently drop call progress messages, and is this
the way it should work?
The functionality IS there, since when osmobts was bridging the calls,
call progress WAS there.
Well, I kludged up a solution for the GSM-only situation, and this seems
suboptimal.
I guess some clever asterisk hacking would solve that, possibly having a
redundant progress statement
on ALL extensions would do it, but would I not lose "actual" call
progress signals from the PSTN,
since asterisk would emulate them? Another way would be a small "local"
asterisk.....before the *real* one.
Boldly moving on to MultiBTS and handover....
Gullik
Hi Community,
Is it possible to send SMS using alphanumeric information as a sender address?
We tried it using an Open-Source SMS GW and it can send alphanumeric information in the sender address.
Unfortunately, the SMS sent through API was not received to the test phone and the logs below are seen in OSMO-MSC.
<000c> smpp_smsc.c:729 [entropy] Rx SUBMIT-SM (09170000023/1/1)
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 259 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
<0017> sms_queue.c:155 Sending SMS 260 failed 0 times.
We also tried sending SMS with only Numeric information in the sender address and the SMS was received successfully by the test phone.
Also attached in this email are the traces and configuration files used and taken during the testing.
Kindly advice if we missed something in our configuration.
TIA.
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
Harald Welte wrote:
> [...] the big difference is that the mobile has been calibrated to
> (if I remember) 2dB accuracy,
The GSM 05.05 spec indeed sets a tolerance of 2 dB under normal
conditions or 2.5 dB under extreme conditions on the mobile station's
maximum power output level for each band. These tolerances get looser
for the lower power control level, up to 5 dB under normal conditions
or 6 dB under extreme conditions for the lowest PCL.
However, as someone who is intimately familiar with the actual
calibration procedures performed by MS manufacturers (just did it
myself less than 48 hours ago for a new batch of boards), I can tell
you how it is actually done. There is a table of target power levels
in dBm, and the calibration station goes through the full set of
allowed PCLs (5-19 for EGSM and GSM850, or 0-15 for DCS and PCS) and
steers the Tx power output (as measured by the test instrument,
usually R&S CMU200) for each PCL to the dBm number in the table.
But there is a hack in this setup which most MS manufacturers fail to
disclose: with all GSM MS RF designs I have laid my hands on so far,
including the one I've inherited from Openmoko (OK, I admit that all
of my experience is with old stuff, not any of the recent stuff from
MTK or Spreadtrum, but don't blame me, blame MTK and Spreadtrum for
not publicly releasing their full chip docs and reference firmware
source code), the MS hardware is oftentimes not actually capable of
putting out the maximum power output prescribed by the spec (33 dBm
for low bands or 30 dBm for high bands) while staying in the linear
range of the PA (the range in which the relation between the APC
control voltage and RF Vout is mostly linear), and thus the calibration
procedure has to be fudged. In the case of Openmoko, they set the
calibration targets for the highest power levels to 31.8 dBm and
28.8 dBm instead of 33/30 (for low and high bands, respectively), the
next PCL down is set to 30.5/27.5 instead of 31/28, and then the
proper official numbers from the spec further down. I have to do the
same on my current GSM MS boards: when I tried putting out the full
33/30 dBm at the maximum PCL as the spec calls for, I can usually hit
it if I crank the PA really high, but then it goes out of its linear
range, and lacking better RF kung-fu, I have to assume that it's bad..
The maximum Tx power level fudging done by manufacturers in my or
Openmoko's position is 1.2 dB, which is less than the spec tolerance
of 2 dB, thus manufacturers like OM who did this fudging had no
problems passing type approval tests, but I really wish I could find
someone with more professional GSM MS design and manufacturing
experience who could explain what actually happens, why we are not
able hit the highest power levels while staying in the PA's linear
range (the PA datasheet says it can put out 34.2 dBm in the low bands
and 32.0 dBm in the high bands), and how the RF hw design might be
improved so we can put out the highest power levels without fudging.
Aside from the just-described fudging, the actual calibration tolerance
(the maximum error between what the calibration procedure aims for and
what actually comes out as measured by the CMU200) is less than 0.7 dB
- and those ~0.5-0.6 dB errors happen mostly toward the lower power
levels where the spec tolerances are the loosest; the maximum power
level is calibrated to the shifted target number to better than 0.1 dB.
M~
Below is a measurement on my "most distant" BTS, BTS 1. From what I see,
downlink is 35 dB
below uplink, which of course is natural when the MS can produce 30 dBm,
and the BTS which
in this case uses a bareback Limesdr min, can only produce 10 dBm.
the bsc parameter ms max power is set to 15 for both bts 0 and bts 1.
However, it seems MS output power is *much* stronger.
Further, my understanding is that it is the BTS level measurements that
decides when to handover,
i.e. measurements in the upstream, and not the MS receive levels...
Since there is such a mismatch between the micro BTS and the MS, maybe
the RX should be attenuated,
to bring upsteram levels more equal to downstream.
OsmoBSC# show conns
Active subscriber connections:
conn ID=6, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1@mgw
BTS 0, TRX 0, Timeslot 1, Lchan 0: Type TCH_F
Connection: 1, State: ESTABLISHED
BS Power: 20 dBm, MS Power: 16 dBm
Channel Mode / Codec: SPEECH_V1
No Subscriber
Bound IP: 127.0.0.1 Port 16390 RTP_TYPE2=0 CONN_ID=0
Conn. IP: 192.168.1.70 Port 4186 RTP_TYPE=3 SPEECH_MODE=0x00
Measurement Report:
Flags:
MS Timing Offset: 0
L1 MS Power: 16 dBm, Timing Advance: 0
RXL-FULL-dl: -110 dBm, RXL-SUB-dl: -110 dBm RXQ-FULL-dl: 5,
RXQ-SUB-dl: 5
RXL-FULL-ul: -74 dBm, RXL-SUB-ul: -73 dBm RXQ-FULL-ul: 3,
RXQ-SUB-ul: 1
What are *your* experiences with "power control" and with "handover".
Best Regards,
Gullik