i tested external clock from isdn line yesterday. modern phones, like the i-phone will not register to the base station. (tested it yesterday together with other phones). no packet is received by openbsc. so i set the clock to "locked" and retrieved the clock from my isdn line (layer 1 up). it did not help at all. the phone found the base station id while scanning for networks, but the registration did not work.
is it possible that the provisioning (during startup) is faulty?
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Harald Welte
Gesendet: Freitag, 17. April 2009 10:17
An: Dieter Spaar
Cc: openbsc(a)lists.gnumonks.org
Betreff: BS-11 PLL clock source / calibration
On Wed, Apr 08, 2009 at 07:44:02PM +0200, Dieter Spaar wrote:
> The BS-11 takes the clock from the E1 line as reference. So you somehow
> have to make sure that this clock is stable and accurate. If you don't
> use another ISDN line, you have to generate a stable and accurate clock
> for the E1 card yourself.
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.
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?
> Another approach might be to calibrate the BS-11 internal oscillator,
> this can be done by software. However it is not yet sure if this will
> solve the problem in a reliable way, also I have not yet found a way
> to measure the BS-11 clock without opening the case.
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...)
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 Marcel,
On Wed, 08 Apr 2009 19:14:36 +0200, "Marcel Klein" <marcel(a)koeln.ccc.de> wrote:
>
> Hm wouldn't it be possible to sync our clock with the official networks
> (without an extra ISDN-line)? Somebody told me that there are several
> ways to sync the clock. Here we discussed the ISDN way, but somebody
> told me that it should also be possible to set the clock over GPS and/or
> other networks in our area.
The BS-11 takes the clock from the E1 line as reference. So you somehow
have to make sure that this clock is stable and accurate. If you don't
use another ISDN line, you have to generate a stable and accurate clock
for the E1 card yourself.
Another approach might be to calibrate the BS-11 internal oscillator,
this can be done by software. However it is not yet sure if this will
solve the problem in a reliable way, also I have not yet found a way
to measure the BS-11 clock without opening the case.
If you want to experiment with your test network only it should not
care, beside some additional effort to initially register to the
network, the BS-11 clock is most certainly stable enough so that
a phone can stay synchronized to the BS-11 network and that it can
be used with this network.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
i will work on several parts parallel, but i will provide a seperat patch for every part of course. the biggest (signalling) thing is the state machine + information elements + call control. i cannot split this into serveral patches.
for me "call handling" is the application ontop of OpenBSC. there must be an API to use OpenBSC in other applications. currently the "application" in OpenBSC just takes an incomming call, does a data base lookup, and sends "SETUP" message. also it forwards messages like "ALTERING" or "CONNECT". this must be replaced by a different application in order to terminate calls instead of forwarding them.
the interface, i like to introduce, will use primitives which are specified in GSM 04 07. they begin with MNCC_xxx_yyy, where xxx is the primitive type and yyy the info about request/acknowlede and direction info:
example: MNCC_SETUP_IND indicates a setup from the remote (requested by mobile, sent to us)
i like to use a structure for every message type with its information elements: (example)
struct MNCC_setup *setup = (struct MNCC_setup *arg) // arg depends on the message type
if (setup->emergency)
printf("emergency call\n");
else
printf("dialed number is %s, and type is %d\n", setup->called, setup->called_type);
....
i will parse/create all information elements, even if not needed by built-in "call handling" or by my application. messages to the layer 3 will use a send message. (mncc_send(struct gsm_call *call, int prim, void *arg)) messages from layer 3 will use a call back function with similar parameters. this callback function pointer will point towards selected application. a special function for "allocating" the call will also be provided. this is required for application to find a free call structure.
my goal is to make the API close to the GSM specs. also if someone has better idea for API interface, please let me know.
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther
Gesendet: Donnerstag, 16. April 2009 12:30
An: openbsc(a)lists.gnumonks.org
Betreff: Re: success
On Tuesday 14 April 2009 13:10:36 Andreas.Eversberg wrote:
> - remove all call/subscriber handling from layer 3 and put it into a
> seperat file (layer 4 call control). it will then be possible to
> initialize libbsc without the built-in call control and database, to use
> it for other applications like asterisk and linux-call-router.
my two cents on this.
call handling:
I think whatever we have/put into OpenBSC should be fully spec
compliant. I don't see the reason to allow to use an entire different
implementation of the call handling. I totally agree that policies
(e.g. which state to enter after ...) should be fully controllable on
the app layer.
> the estimated time for this will be about 2-3 months. the result will be
> a complete BSC+MSC with routing and PBX features and asterisk interface.
> i will provide a patch en-block, because i work on all parts at the same
> time.
hmm a patch accumulating 2-3 months of work? that will be pretty hard for
everyone to review or even change direction early on...
here is the layout of bchannel 2:
44332211
the bits for timeslot 1 (the right two) are not used, because we use this for signalling
the bits for timeslot 2 are also not used, when i do a phone call.
the bits for timeslot 3 and 4 are used when i do a call from mobile to mobile.
a second call will use timeslot 5 and 6. all audio works.
if a call would use timeslot 2 and 3, you would not notice that the channels are in reverse order. because the first timeslot used for audio is always 3 and the second is 4, i must select the right order.
-----Ursprüngliche Nachricht-----
Von: Harald Welte [mailto:laforge@gnumonks.org]
Gesendet: Mittwoch, 15. April 2009 23:27
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: AW: success
On Wed, Apr 15, 2009 at 01:46:19AM +0200, Andreas.Eversberg wrote:
> did harald change the bit order on the controller? there is a flag for that.
> you can patch the hfcmulti.c. maybe harald did that but forgot to put it into
> the kernel patch. i will also provide patch to openbsc to automatically
> consider that bit order in conjunction with misdn interface.
I did not make any such change. Which brings up the question: Why is it
working for me, nibbler, zecke, ... ? Probably really just coincidence, after
all there are only four subslots in one slot, and we're typically using two of
them, so the chances we end up using the right bits might be quite big, right?
--
- 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)
hi,
on the easterhegg 2009 we got everything running. even audio worked! and
we catched our first imsi from a public network.
the following things must be changed in the software:
- sending time slot 1 frames requires a queue and a timer, rather than
using "usleep()". sleeping causes loss of audio and signalling
informations. (i work on that)
- subslots are in reverse order: slot 2 (0..3) must have mask 00110000
and not 00001100. this causes no audio.
- both time slots (2 and 3) must be configured, or unitialized pointers
cause a crash.
- data link is available since DL_ESTABLISH_IND is received and not
MPH_*.
- in order to release layer 2 and unload the driver after stopping of
bsc_hack, a special ioctl must be given after opening socket.
- some little extras: changing card number and "location area code" by
additional arguments.
@harald | @dieter: other isdn drivers (windows) have obviously reversed
bit order on transparent channel. bit 0 is exchanged with bit 7 and so
on. to make it work, i did not change the bit order, i just changed the
location of the subslot, and it worked.
i would like to provide a patch for the solutions above. i will see, if
i can do that this weekend.
furthermore i like to improve the libbsc:
- provide a real state machine to the layer 3 with timers. make calls
setup and release cleanly.
- support transcoding of all information elements.
- remove all call/subscriber handling from layer 3 and put it into a
seperat file (layer 4 call control). it will then be possible to
initialize libbsc without the built-in call control and database, to use
it for other applications like asterisk and linux-call-router.
- add application interface to traffic channels for transcoding and
switching.
- add support for libbsc to linux-call-router.
the estimated time for this will be about 2-3 months. the result will be
a complete BSC+MSC with routing and PBX features and asterisk interface.
i will provide a patch en-block, because i work on all parts at the same
time.
greetinx,
andreas
do we need a switch to select between mISDN bit order and other e1 drivers? what other e1 drivers are/will be supported? or can i just change the bit order, because no other e1 driver is used with the code? if not, i would suggest to add a "msb" flag to the time slot structure.
i was thinking of having a flag for using hardware multiplexing on hfc-e1 controller, but because the data is not synchronized (hdlc frames), we need to touch every bit to see where the frame starts and where it ends, so we have no speed benefit.
to make a better processing in kernel space, i need to put the gsm speech codec into kernel space. i need a source code that is open, light weight, and without integer math. any suggestions?
-----Ursprüngliche Nachricht-----
Von: Dieter Spaar [mailto:spaar@mirider.augusta.de]
Gesendet: Dienstag, 14. April 2009 16:26
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: success
Hello Andreas,
On Tue, 14 Apr 2009 13:10:36 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> on the easterhegg 2009 we got everything running. even audio worked! and
> we catched our first imsi from a public network.
Congratulation, great to hear that !
> @harald | @dieter: other isdn drivers (windows) have obviously reversed
> bit order on transparent channel. bit 0 is exchanged with bit 7 and so
> on. to make it work, i did not change the bit order, i just changed the
> location of the subslot, and it worked.
I noticed the same with my own Windows driver (its not an official driver,
just my personal very experimental stuff for the HFC-E1 card). However
because it worked with the Linux version (at least on Haralds PC) I though
it was a problem with my implementation and did not take care.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
did harald change the bit order on the controller? there is a flag for that. you can patch the hfcmulti.c. maybe harald did that but forgot to put it into the kernel patch. i will also provide patch to openbsc to automatically consider that bit order in conjunction with misdn interface.
-----Ursprüngliche Nachricht-----
Von: Dieter Spaar [mailto:spaar@mirider.augusta.de]
Gesendet: Dienstag, 14. April 2009 19:27
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: AW: success
Hello Andreas,
On Tue, 14 Apr 2009 16:54:40 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
> do we need a switch to select between mISDN bit order and other e1
> drivers? what other e1 drivers are/will be supported? or can i just
> change the bit order, because no other e1 driver is used with the code?
> if not, i would suggest to add a "msb" flag to the time slot structure.
I can only talk for my "personal" Windows driver, for me the changed
bit order works. I just wonder why mISDN and the HFC-E1 works different
on Haralds PC than on others.
> to make a better processing in kernel space, i need to put the gsm
> speech codec into kernel space. i need a source code that is open, light
> weight, and without integer math. any suggestions?
For a Full Rate Codec (should work too, however OpenBSC has to
modified so that "Full Rate" is used by the phones too) you can
use Toast (http://kbs.cs.tu-berlin.de/~jutta/toast.html).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Andreas,
On Tue, 14 Apr 2009 16:54:40 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
> do we need a switch to select between mISDN bit order and other e1
> drivers? what other e1 drivers are/will be supported? or can i just
> change the bit order, because no other e1 driver is used with the code?
> if not, i would suggest to add a "msb" flag to the time slot structure.
I can only talk for my "personal" Windows driver, for me the changed
bit order works. I just wonder why mISDN and the HFC-E1 works different
on Haralds PC than on others.
> to make a better processing in kernel space, i need to put the gsm
> speech codec into kernel space. i need a source code that is open, light
> weight, and without integer math. any suggestions?
For a Full Rate Codec (should work too, however OpenBSC has to
modified so that "Full Rate" is used by the phones too) you can
use Toast (http://kbs.cs.tu-berlin.de/~jutta/toast.html).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Andreas,
On Tue, 14 Apr 2009 13:10:36 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> on the easterhegg 2009 we got everything running. even audio worked! and
> we catched our first imsi from a public network.
Congratulation, great to hear that !
> @harald | @dieter: other isdn drivers (windows) have obviously reversed
> bit order on transparent channel. bit 0 is exchanged with bit 7 and so
> on. to make it work, i did not change the bit order, i just changed the
> location of the subslot, and it worked.
I noticed the same with my own Windows driver (its not an official driver,
just my personal very experimental stuff for the HFC-E1 card). However
because it worked with the Linux version (at least on Haralds PC) I though
it was a problem with my implementation and did not take care.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
