Hi,
Here's a patch I've been using to get a SingleE1 PCI ISDN card (recently
bought from Junghanns.NET) to work with the hfcmulti.ko driver. I'm not
sure the mapping between the PCI subdevice id and the driver data is
right, but at least the card can "talk" to the BS-11 now.
I'm curious if any of you are also using such cards and how they get
them to work.
Best regards,
--
Nico
Hello Bjoern,
[ I sent it to the OpenBSC list too, because there are the Linux
experts ]
> Ok, Ill give it a try later on today.
> Just one thing:
> Ive now compiled OpenBSC on a fresh installed Debian lenny machine,
> and LMT etc. works great but if I try to start bsc_hack I get the
> following:
>
> gsmbase1:/home/tec/openbsc/src# ./bsc_hack
> DB: Database initialized.
> DB: Database prepared.
> could not open socket Address family not supported by protocol
>
> It seems to be related to af_packet Kernel module, but I cant find the
> mod.
>
> Do you have an idea?
Don't ask me about Linux details, I am coming from Windows ;-)
Maybe it is related to mISDN, I think there is also a special
tunnel for capturing the traces in Wireshark. The rest (Telnet
interface) should be standard socket operations.
Maybe someone else can give a better explanation, the above is
just my understanding.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
i just want to know, if my recent patch arrived on this list (my last
mail), because my first mail formatting was detected as spam. i see no
reaction to my last mail.
JFYI, there now is a Chaosradio Express podcast about OpenBSC
available at http://chaosradio.ccc.de/cre120.html
Regards,
--
- 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 Harald,
On Fri, 17 Apr 2009 10:17:13 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> Dieter, what I just found out is that the LI object has a user-configurable
> setting, where we can force it to be stand alone or locked to the E1.
You mean the "PLL synchonisation mode" attribute which is set to
"locked mode" ? I am not sure if we can change it for our version
of the BS-11. As far as I understand the documentation, this is
a setting which is only available with the CCU ("Combo Card Unit", the
universal interface which also allows to use a standard ISDN line).
The documentation mentions at one place that for the CCU variant
they use an oven controlled oscillator which fulfilles the GSM
clock stability requirements even without being snchronized to
the E1 line.
But we should of course try it.
> We could add this setting to the bs11_config program so people can try
> if their E1 clock or their [10 years uncalibrated] BS11 internal oscillator
> is better.
>
> What do you think?
Yes, why not try it. Probably the result is similar to disabling
the master clock of the HFC-E1 card, this way the BS-11 clock
determines the E1 clock (the HFC-E1 card synchronizes to the
trasmitter E1 clock of the BS-11 and the BS-11 locks to the
transmitter clock of the HFC-E1 which is determined by the BS-11).
Surely the cleaner way is to adjust the clock setting in the BS-11
(if this settings works for our BS-11 variant).
> I'm quite sure there must be an option to do this externally. The internal
> oscillator must be calibrated every two years, and I'm sure they do this
> without opening the case (in the field...)
Its possible to calibrate the PLL without opening the case. The attribute
is protected by some checksum, I have not looked at the details. And
"officially" out LMT version should not even allow to see the calibration
dialog ;-) The problem for me is how to measure the clock without opening
the case. I can measure an unmodulated carrier very accurate if it is
within the 10 MHz to 1 GHz range (the HP 8922 is accurate enough to do
this). However I don't have the equippment to measure the modulated and
pulsed signal of the BS-11. Maybe there is some hidden setting to send
just the unmodulated carrier, but I have not yet found anything in this
direction.
Another problem is that changing the calibration requires a restart of
the BS-11 (at least I only saw any effect when I restarted). Additionally
when you query the calibration, you get the "PLL Set Value" and the
"PLL Work Value", the "Set Value" seems to be used when starting up
and the "Work Value" changes, most certainly locking to an external
clock also influences it. I did not find anything in the documentation,
actually those settings are not indended for the end user, just the
factory.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello,
I think I finally found a way to measure the frequency of the
BS-11 in a reliable way. My BS-11 is accurate to within 0.1 ppm
if the oscillator is set to "Standalone Mode". If the oscillator
is locked to the E1 clock of the HFC-E1 card and the HFC-E1 card
is generating the clock, the frequency of the BS-11 drifts more
than +/-1 ppm in about one minute.
I did just a short test, but this results fits to the previous
observations (remember, an old Nokia phone was not able to see
the official networks and the test network at the same time if
the frequency of the test network is off by more than 1 ppm).
Of course I don't know how good the calibration of the other
BS-11 units is, but setting the oscillator to "Standalone Mode"
surely is better than using the HFC-E1 card for synchronisation
(if the HFC-E1 card is not synchronized to the official ISDN
network clock as Andreas suggested).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
ok, next time i will split the patches for easier understanding. if you require splitting of my first patch, let me know.
for better understanding and review, i will explain the usleep replacement patch again. only commit it, if you fully understand the changes. the usleep is replaced by a timer, one for each time slot (signalling only ts).
1. whenever data is queued into the tx-queue, a tx-delay timer is checked:
- the timer is not running: mISDN write event is triggered with BSC_FD_WRITE flag on file descriptor.
- the timer is running: nothing is triggered, because we still have to wait until the tx-timer timed out
2. whenever a time out occurrs:
- the BSC_FD_WRITE flag is set to trigger write event, even if tx-queue is empty.
3. whenever a write event is triggered: if it is ok to write (select() indicated that writing is possible), the tx-queue is checked:
- if queue is empty: nothing is done, delay timer remains disabled, no BSC_FD_WRITE flag is set.
- if queue is not empty: the first message is dequeued and sent to mISDN. the tx-delay timer is started and set for next write event.
special cases:
- if tx-queue is not empty, delay timer is not running and BSC_FD_WRITE flag is set (e.g. right after timeout event), subsequent data is queued and BSC_FD_WRITE flag remains set.
- if tx-timer times out, but there is no data in the tx-queue, the BSC_FD_WRITE flag will be set. the write event handler always checks for data in the tx-queue. if it is empty, the delay timer will not be started and the BSC_FD_WRITE flag will be cleared.
- the timers is not cleared on release of libbsc data structures. i expect all times to be removed on release of libbsc also.
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther
Gesendet: Donnerstag, 23. April 2009 00:11
An: openbsc(a)lists.gnumonks.org
Betreff: Re: AW: first patch: mISDN handling
On Wednesday 22 April 2009 15:44:44 Holger Freyther wrote:
> On Wednesday 22 April 2009 15:25:59 Andreas.Eversberg wrote:
> > i just want to know, if my recent patch arrived on this list (my last
> > mail), because my first mail formatting was detected as spam. i see no
> > reaction to my last mail.
>
> Yes, I waited for Harald to respond as he is the boss. My taste regarding
> patches is very special and I prefer the smaller patches... e.g. I would
> like to have separate patches for things like LAC, auto release of layer2,
> and it is hard for me to judge the actual mISDN changes as you are the
> expert there. One thing that is clearly missing is an updated configure.in
> to check for the mISDNuser header files and fail when they are not there
> and is it really necessary to invoke init_af_isdn()? Where is this coming
> from?
>
>
> I will probably/hopefully merge your:
> - LAC
> - Card NR
> - autorelease
Okay, I managed to do this today. It would be cool if you could split out your
improved log messages (__func__) and extended error checking (making sure we
have 30 bchan's) into a separate patch and I would be happy to merge this
then, afterwards the killing of the usleep should be done.
z.
Hallo Bjoern,
> What do I have to do to use the second TRX instead?
> Plug in the other Twinax connectors?
> Do I need to setup the second TRX separately on LMT?
The PC software (OpenBSC or my Windows software) has to
be adjusted to use TRX1 instead of TRX0. Its basically
"only" changing a parameter at several places, but as
far as I am aware noone tried it yet so some debugging
might be necessary.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Bjoern,
> I finally got time to try out my BTS.
> When I looked at the LMT I was confused about the
> "MBCCU0: No Load" which seems to be the TRX0 ?
Probably this is a similar problem I have with my BS-11, when
turning on the cold BS-11 the first time, frequently the firmware
load for TRX0 fails. Most certainly this comes from a hardware
problem (maybe aged capacitors ?).
I have to restart (turn off and on) the BS-11 a few times till it
works. If the unit has warmed up, I never saw this problem till now.
I also made the experience that it could help if no LMT cable (serial
cable) is attached so I usually try it this way: Turn the BS-11 on
without the LMT cable plugged in (at the BS-11 side) and after a
while (around 5 to 10 minutes) check if the firmware for TRX0 is
loading or is already loaded. If it fails, unplug the LMT cable,
turn the BS-11 off and try again. I am not really sure about the
effect of the LMT cable, but maybe the cable receives noise.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hey,
I had some time during a train ride to do some updates to the existing patch
set. I have merged the hopefully non controversial parts already and would
like to share the current set with you.
What is missing:
- There are still plenty of FIXMEs and the channel allocation is pretty
stupid. One request after another, no attempt to do GSM submit and call
handling at the same time... we just release the channel and start paging
again.
- VLR handling in db.c (remember where the subscriber was and load it....)
- Testing, I have not seen a powered up Siemens BS11 lately and need to test
What is there:
- Having two requests (SMS submit and Phone) should work in a way... and the
API should be "finished".
feedback is welcomed
z.
