From sipos.csaba at kvk.uni-obuda.hu  Sun Feb  1 10:39:53 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Sun, 1 Feb 2015 11:39:53 +0100 (CET)
Subject: Patch for OpenBSC [Nokia Site family]
In-Reply-To: <25881598.7860565.1422787026923.JavaMail.root@kvk.uni-obuda.hu>
Message-ID: <29992482.7860679.1422787193795.JavaMail.root@kvk.uni-obuda.hu>

Dear Holger,

Here it is.

Patch description:

This patch adds the ability to change the RESET_TIMER parameter. This change affects the Nokia Site family only, and it is important for multi-BTS setups. (eg. multiple InSite units daisychained and UltraSite). The parameter can be set in the config file with the following syntax: nokia_site bts-reset-timer  <15-100>. The default value is 15 seconds.

Tested with InSite, MetroSite and UltraSite units.

Thanks!

Csaba


--------------------------------------------------------------
On Tue, Nov 11, 2014 at 04:22:50PM +0100, Sipos Csaba wrote:
> Dear Holger,

Hi,

sorry for the delay. Please send this patch to the ML. I do not
have Nokia BTSes andcan't test your patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_openbsc_reset_timer.diff
Type: text/x-patch
Size: 3536 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20150201/e62fb347/attachment.bin>

From holger at freyther.de  Sun Feb  1 13:56:59 2015
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 1 Feb 2015 14:56:59 +0100
Subject: Patch for OpenBSC [Nokia Site family]
In-Reply-To: <29992482.7860679.1422787193795.JavaMail.root@kvk.uni-obuda.hu>
References: <25881598.7860565.1422787026923.JavaMail.root@kvk.uni-obuda.hu>
 <29992482.7860679.1422787193795.JavaMail.root@kvk.uni-obuda.hu>
Message-ID: <20150201135659.GD4803@xiaoyu.lan>

On Sun, Feb 01, 2015 at 11:39:53AM +0100, Sipos Csaba wrote:
> Dear Holger,

thank you!

> +      "nokia_site bts-reset-timer  <15-100>",
> +	bts->nokia.bts_reset_timer_cnf = atoi(argv[0]);

without using this new command the default will change from 15 to 0
seconds? Shouldn't you initialize bts_reset_timer_cnf with 15 somewhere?
And what is the reason to make this variable a bitfield? is it transported
on the wire like this?


From sipos.csaba at kvk.uni-obuda.hu  Sun Feb  1 21:19:41 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Sun, 1 Feb 2015 22:19:41 +0100 (CET)
Subject: Patch for OpenBSC [Nokia Site family]
In-Reply-To: <20150201135659.GD4803@xiaoyu.lan>
Message-ID: <17805318.7940664.1422825581448.JavaMail.root@kvk.uni-obuda.hu>

Hi Holger,

Sorry for that, clearly there are some mistakes in the patch, will try and fix it.

Thnaks for the feedback!

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Holger Hans Peter Freyther" <holger at freyther.de>
C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
M?solatot kap: openbsc at lists.osmocom.org
Elk?ld?tt ?zenetek: Vas?rnap, 2015. Febru?r. 1. 14:56:59
T?rgy: Re: Patch for OpenBSC [Nokia Site family]

On Sun, Feb 01, 2015 at 11:39:53AM +0100, Sipos Csaba wrote:
> Dear Holger,

thank you!

> +      "nokia_site bts-reset-timer  <15-100>",
> +	bts->nokia.bts_reset_timer_cnf = atoi(argv[0]);

without using this new command the default will change from 15 to 0
seconds? Shouldn't you initialize bts_reset_timer_cnf with 15 somewhere?
And what is the reason to make this variable a bitfield? is it transported
on the wire like this?


From rs515794 at gmail.com  Tue Feb  3 16:43:13 2015
From: rs515794 at gmail.com (ramesh shankar)
Date: Tue, 3 Feb 2015 11:43:13 -0500
Subject: Fwd: openbsc Crypto
In-Reply-To: <CAKmLYbBf0L8ugMCnD-B34Mju5_gi0dtJtVSoLfc7O3LPbMBynA@mail.gmail.com>
References: <CAKmLYbBf0L8ugMCnD-B34Mju5_gi0dtJtVSoLfc7O3LPbMBynA@mail.gmail.com>
Message-ID: <CAKmLYbB4+NGtjgeyxuv8CAfm9TqsesvNufEUOeXkf1Uybu4M+w@mail.gmail.com>

Hello

I have a question on sms

Is it possible to send hex data using telnet localhost port 4242

I saw the posting in forum about SMPP+OpenBSC (march-april 2014), which
talk about Kannel
Can somebody suggest how to configure Kannel with OpenBSC.


regards
Ramesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20150203/4fee414b/attachment.htm>

From rs515794 at gmail.com  Tue Feb  3 16:46:02 2015
From: rs515794 at gmail.com (ramesh shankar)
Date: Tue, 3 Feb 2015 11:46:02 -0500
Subject: SMS and SMPP+OpenBSC+Kannel
Message-ID: <CAKmLYbCWxp1GtuKnpWw0jtJFXgZHZXP_jwMAMHnG_rx5c17EhA@mail.gmail.com>

Hello

I have a question on sms

Is it possible to send hex data using telnet localhost port 4242

I saw the posting in forum about SMPP+OpenBSC (march-april 2014), which
talk about Kannel
Can somebody suggest how to configure Kannel with OpenBSC.

regards
Ramesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20150203/6517bfc1/attachment.htm>

From holger at freyther.de  Wed Feb  4 09:10:31 2015
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 4 Feb 2015 10:10:31 +0100
Subject: recurring issue with OpenBSC
In-Reply-To: <20141202075929.GA14607@xiaoyu.lan>
References: <5479FD5C.3000708@autistici.org>
 <20141130154252.GU16131@xiaoyu.lan>
 <547B76C6.3080408@autistici.org>
 <20141202075929.GA14607@xiaoyu.lan>
Message-ID: <20150204091031.GA8805@xiaoyu.lan>

On Tue, Dec 02, 2014 at 08:59:29AM +0100, Holger Hans Peter Freyther wrote:

> something like the below would be a start. You could add a VTY
> command to dump the queue including the state and the reason
> string. And also show the last reason as this shows the item
> that is currently being dispatched.

My current thought on this system is that we should remove
subscr_put_channel. It is based on some assumptions/goals
that does not make sense anymore.

MT-SMS:

We need a way to enforce that only one SMS is delivered at
a time. This should be done for SMS that arrive through the
MO-SMS (SubmitSM), SMPP and the SMS queue.

MT-Call:

Just page if no call is present yet. We can nowadays upgrade
a "SDCCH" to a TCH (late assignment)


Paging:

We need to change the way we handle the paging response. Instead
of a single callback we should introduce a signal that will be
handled by both SMS and Call after the channel has been authenticated.



This should avoid the whole kind of problem. In terms of time
my estimate would be a week of work.


From sipos.csaba at kvk.uni-obuda.hu  Wed Feb  4 12:12:34 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Wed, 4 Feb 2015 13:12:34 +0100 (CET)
Subject: Patch for OpenBSC [Nokia Site family]
In-Reply-To: <20150202085050.GH1550@xiaoyu.lan>
Message-ID: <28770269.8412705.1423051954604.JavaMail.root@kvk.uni-obuda.hu>

Dear Holger,

I think I found a better way for initialization. The attached version of the patch builds against latest master OpenBSC, contains the fixes I missed from the previous version.

Tested:

1. Without using the config parameter, the reset timer defaults to 15 seconds (as before),
2. With the configuration parameter, the reset timer will use the specified value.

Tested with: InSite (daisy chained, two BTSes), MetroSite and UltraSite units.

Will create another patch for hopping (both baseband and sytheiser hopping works, but it needs a change in the sourcecode, like the reset timer before).

There is another minor problem at the moment: UltraSite needs additional time after OMU configuration done, before it can bootstrap the RSL links. This is due to the fact that UltraSite starts to load the TRX SW after it got the "Use current" command, and it takes arouned 45-50 seconds for the TRXes to be ready for LAPD. So to first RSL bootstrap should be delayed after OMU config complete is received by the BSC. Now the RSL link is bootstrapped right after the OMU is configured and the LAPD link times out way before the TRX will be ready for LAPD. Will try to create a patch for this too, until then, a small hack can make this problem go away (changing n200 parameter to 100).

Regards,
Csaba


----- Eredeti ?zenet -----
Felad?: "Holger Hans Peter Freyther" <holger at freyther.de>
C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
Elk?ld?tt ?zenetek: H?tf?, 2015. Febru?r. 2. 9:50:50
T?rgy: Re: Patch for OpenBSC [Nokia Site family]

On Sun, Feb 01, 2015 at 10:53:19PM +0100, Sipos Csaba wrote:
> Can you please tell me where should I initialize the timer, when the config parameter is not used (user not specified it in the cfg file)?
> 
> I tried to look at other parts of the code but I don't see where the default values are stored, if a parameter is not set in the config file.
> 
> Otherwise I fixed the remaining problems.

It is not the best place but gsm_bts_alloc would allow you to
initialize this field correctly. The other option would be when
the type of the bts is set to nokia.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openbsc_nokia_bts_reset_timer.patch
Type: text/x-patch
Size: 4014 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20150204/b4c8d241/attachment.bin>

From sipos.csaba at kvk.uni-obuda.hu  Sat Feb  7 10:28:14 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Sat, 7 Feb 2015 11:28:14 +0100 (CET)
Subject: Patch for OpenBSC [Nokia Site family]
In-Reply-To: <28770269.8412705.1423051954604.JavaMail.root@kvk.uni-obuda.hu>
Message-ID: <18657664.8913709.1423304894479.JavaMail.root@kvk.uni-obuda.hu>

Dear Holger,

I just wanted to ask if you pleased with the patch or not? I just wanted to make sure that this part is fixed and code quality is OK by you, so I can move on to the next one.

Regards,
Csaba

----- Tov?bb?tott ?zenet -----
Felad?: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
C?mzett: "Holger Hans Peter Freyther" <holger at freyther.de>
M?solatot kap: openbsc at lists.osmocom.org
Elk?ld?tt ?zenetek: Szerda, 2015. Febru?r. 4. 13:12:34
T?rgy: Re: Patch for OpenBSC [Nokia Site family]

Dear Holger,

I think I found a better way for initialization. The attached version of the patch builds against latest master OpenBSC, contains the fixes I missed from the previous version.

Tested:

1. Without using the config parameter, the reset timer defaults to 15 seconds (as before),
2. With the configuration parameter, the reset timer will use the specified value.

Tested with: InSite (daisy chained, two BTSes), MetroSite and UltraSite units.

Will create another patch for hopping (both baseband and sytheiser hopping works, but it needs a change in the sourcecode, like the reset timer before).

There is another minor problem at the moment: UltraSite needs additional time after OMU configuration done, before it can bootstrap the RSL links. This is due to the fact that UltraSite starts to load the TRX SW after it got the "Use current" command, and it takes arouned 45-50 seconds for the TRXes to be ready for LAPD. So to first RSL bootstrap should be delayed after OMU config complete is received by the BSC. Now the RSL link is bootstrapped right after the OMU is configured and the LAPD link times out way before the TRX will be ready for LAPD. Will try to create a patch for this too, until then, a small hack can make this problem go away (changing n200 parameter to 100).

Regards,
Csaba


----- Eredeti ?zenet -----
Felad?: "Holger Hans Peter Freyther" <holger at freyther.de>
C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
Elk?ld?tt ?zenetek: H?tf?, 2015. Febru?r. 2. 9:50:50
T?rgy: Re: Patch for OpenBSC [Nokia Site family]

On Sun, Feb 01, 2015 at 10:53:19PM +0100, Sipos Csaba wrote:
> Can you please tell me where should I initialize the timer, when the config parameter is not used (user not specified it in the cfg file)?
> 
> I tried to look at other parts of the code but I don't see where the default values are stored, if a parameter is not set in the config file.
> 
> Otherwise I fixed the remaining problems.

It is not the best place but gsm_bts_alloc would allow you to
initialize this field correctly. The other option would be when
the type of the bts is set to nokia.


From sipos.csaba at kvk.uni-obuda.hu  Sat Feb  7 17:33:30 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Sat, 7 Feb 2015 18:33:30 +0100 (CET)
Subject: [Patch]: Nokia: make hopping a user changeable parameter
In-Reply-To: <12464002.8937786.1423330074601.JavaMail.root@kvk.uni-obuda.hu>
Message-ID: <7763614.8938103.1423330410312.JavaMail.root@kvk.uni-obuda.hu>

Dear Holger,

Thanks for the commit on my previous patch.

Here is a new one:

This pacth makes hopping type (baseband or RF) a user changeable parameter.

Tested with:

 - MetroSite: baseband and RF hopping works
 - UltraSite: RF hopping works

As previously, the default behavior of OpenBSC is not changed. If the configuration parameter is not provided, it will default to baseband hopping, as before.

It builds against the latest version of OpenBSC master.

Regards,
Csaba
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openbsc_nokia_hopping.patch
Type: text/x-patch
Size: 3702 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20150207/6ed858ea/attachment.bin>

From holger at freyther.de  Sun Feb  8 08:43:39 2015
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 8 Feb 2015 09:43:39 +0100
Subject: [Patch]: Nokia: make hopping a user changeable parameter
In-Reply-To: <7763614.8938103.1423330410312.JavaMail.root@kvk.uni-obuda.hu>
References: <12464002.8937786.1423330074601.JavaMail.root@kvk.uni-obuda.hu>
 <7763614.8938103.1423330410312.JavaMail.root@kvk.uni-obuda.hu>
Message-ID: <20150208084339.GE4069@xiaoyu.lan>

On Sat, Feb 07, 2015 at 06:33:30PM +0100, Sipos Csaba wrote:
> Dear Holger,

Hi!

> It builds against the latest version of OpenBSC master.

what is preferred is if you could already make a git commit
and then use git send-email/git format-patch. Then I don't
have to come up with a commit message. :)

> -				wait_reset:1;
> +				wait_reset:1,
> +				hopping_type:1;

What is the reasoning for the bitfield here? Do we want to
save memory? Is it a packed structure on the network? I think
I raised a point like this with the previous commit.

> +		vty_out(vty, "  nokia_site hopping-type %d%s", bts->nokia.hopping_type, VTY_NEWLINE);

In more recent times I prefer to go with string names instead
of 0/1. E.g "hopping", "synthesizer".

> +DEFUN(cfg_bts_nokia_site_hopping_type,
> +      cfg_bts_nokia_site_hopping_type_cmd,
> +      "nokia_site hopping-type (0|1)",
> +      NOKIA_STR
> +      "Set the hopping type. 0=Baseband hopping, 1=Synthesizer (RF) hopping\n")

This is likely to cause a failure with the python end to end
test. For the above command you need to write documentation
for "nokia_site" "hopping-type" "0" "1". This means the help
string needs to have four topics that end with a \n. I think
the documentation for "0" and "1" is missing.

>  	memcpy(fu_config + len, bts_config_2, sizeof(bts_config_2));
>  	/* set hopping mode (Baseband and RF hopping work for the MetroSite) */
> -	if (need_hopping)
> -		fu_config[len + 2 + 1] = 1;	/* 0: no hopping, 1: Baseband hopping, 2: RF hopping */
> +	if (need_hopping) {
> +		if(hopping_type != 1){
> +			LOGP(DNM, LOGL_NOTICE, "Baseband hopping selected!\n");
> +			fu_config[len + 2 + 1] = 1;	/* 0: no hopping, 1: Baseband hopping, 2: RF hopping */
> +		}
> +		else
> +		{
> +			LOGP(DNM, LOGL_NOTICE, "Synthesizer (RF) hopping selected!\n");
> +			fu_config[len + 2 + 1] = 2;	/* 0: no hopping, 1: Baseband hopping, 2: RF hopping */
> +		}
> +	}


Maybe use an enum to represent the two hopping options. This
way you can put the semantic/description into the enum and
don't need to write it twice. If you go with names for configuring
you can even directly map the values of the enum to "1" and "2"
which will allow you to remove the branch.

For all of this please have a look at the value_string struct
and how we go from string to number and number to string.



From sipos.csaba at kvk.uni-obuda.hu  Sun Feb  8 10:27:40 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Sun, 8 Feb 2015 11:27:40 +0100 (CET)
Subject: [Patch]: Nokia: make hopping a user changeable parameter
In-Reply-To: <20150208084339.GE4069@xiaoyu.lan>
Message-ID: <9811888.8976461.1423391260257.JavaMail.root@kvk.uni-obuda.hu>

Hi,

> What is the reasoning for the bitfield here?

This is a two state flag (0 or 1), there is no point store more than that. Besides, all the previous variables are used like this. If this is not OK, then all the variables work like this already in the code are also not OK (look at wait_reset, skip_reset, did_reset etc.) It sure saves some memory, but its more like the general rule of thumb not to use more memory than it is necessary for a specific variable.

> In more recent times I prefer to go with string names instead of 0/1. E.g "hopping", "synthesizer".

Like my previous answer. I usually use the elements and coding style already considered OK (because it is in the code). If this is not OK, then a whole lot of the code is also not OK, and I don't feel my self up to refactoring all of it. What we can do is to go with this for now, and refactor the whole section later.

> For the above command you need to write documentation

Will look into this. How can I test if it causes any problems? I tested the code and it builds without a single warning, but I never used this end to end python test.

> Maybe use an enum to represent the two hopping options.

The same as the first and second answer. A lot of the alreday provided code is based on the previous bitfield approach for variable handling. I'd rather not change this on a per variable basis. I consider this a refactor task, and I don't think my coding skills are up to somethig like this. So if you don't mind I would stick to this for now, and will try and read a bit about what you suggested, and get back to this problem later, when I fully understand what needs to be done, and refactor all variables in the Nokia code to what you have in mind.

Regards,
Csaba

----- Eredeti ?zenet -----
Felad?: "Holger Hans Peter Freyther" <holger at freyther.de>
C?mzett: "Sipos Csaba" <sipos.csaba at kvk.uni-obuda.hu>
M?solatot kap: openbsc at lists.osmocom.org
Elk?ld?tt ?zenetek: Vas?rnap, 2015. Febru?r. 8. 9:43:39
T?rgy: Re: [Patch]: Nokia: make hopping a user changeable parameter

On Sat, Feb 07, 2015 at 06:33:30PM +0100, Sipos Csaba wrote:
> Dear Holger,

Hi!

> It builds against the latest version of OpenBSC master.

what is preferred is if you could already make a git commit
and then use git send-email/git format-patch. Then I don't
have to come up with a commit message. :)

> -				wait_reset:1;
> +				wait_reset:1,
> +				hopping_type:1;

What is the reasoning for the bitfield here? Do we want to
save memory? Is it a packed structure on the network? I think
I raised a point like this with the previous commit.

> +		vty_out(vty, "  nokia_site hopping-type %d%s", bts->nokia.hopping_type, VTY_NEWLINE);

In more recent times I prefer to go with string names instead
of 0/1. E.g "hopping", "synthesizer".

> +DEFUN(cfg_bts_nokia_site_hopping_type,
> +      cfg_bts_nokia_site_hopping_type_cmd,
> +      "nokia_site hopping-type (0|1)",
> +      NOKIA_STR
> +      "Set the hopping type. 0=Baseband hopping, 1=Synthesizer (RF) hopping\n")

This is likely to cause a failure with the python end to end
test. For the above command you need to write documentation
for "nokia_site" "hopping-type" "0" "1". This means the help
string needs to have four topics that end with a \n. I think
the documentation for "0" and "1" is missing.

>  	memcpy(fu_config + len, bts_config_2, sizeof(bts_config_2));
>  	/* set hopping mode (Baseband and RF hopping work for the MetroSite) */
> -	if (need_hopping)
> -		fu_config[len + 2 + 1] = 1;	/* 0: no hopping, 1: Baseband hopping, 2: RF hopping */
> +	if (need_hopping) {
> +		if(hopping_type != 1){
> +			LOGP(DNM, LOGL_NOTICE, "Baseband hopping selected!\n");
> +			fu_config[len + 2 + 1] = 1;	/* 0: no hopping, 1: Baseband hopping, 2: RF hopping */
> +		}
> +		else
> +		{
> +			LOGP(DNM, LOGL_NOTICE, "Synthesizer (RF) hopping selected!\n");
> +			fu_config[len + 2 + 1] = 2;	/* 0: no hopping, 1: Baseband hopping, 2: RF hopping */
> +		}
> +	}


Maybe use an enum to represent the two hopping options. This
way you can put the semantic/description into the enum and
don't need to write it twice. If you go with names for configuring
you can even directly map the values of the enum to "1" and "2"
which will allow you to remove the branch.

For all of this please have a look at the value_string struct
and how we go from string to number and number to string.


From holger at freyther.de  Sun Feb  8 13:02:28 2015
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 8 Feb 2015 14:02:28 +0100
Subject: [Patch]: Nokia: make hopping a user changeable parameter
In-Reply-To: <9811888.8976461.1423391260257.JavaMail.root@kvk.uni-obuda.hu>
References: <20150208084339.GE4069@xiaoyu.lan>
 <9811888.8976461.1423391260257.JavaMail.root@kvk.uni-obuda.hu>
Message-ID: <20150208130228.GJ4069@xiaoyu.lan>

On Sun, Feb 08, 2015 at 11:27:40AM +0100, Sipos Csaba wrote:
> Hi,

Good Afternoon,


> Will look into this. How can I test if it causes any problems? I tested the code and it builds without a single warning, but I never used this end to end python test.

well, you can manually test it by using the online help
(press '?' after a part of the command). If it is empty
then you have a problem.


> The same as the first and second answer. A lot of the alreday provided code is based on the previous bitfield approach for variable handling. I'd rather not change this on a per variable basis. I consider this a refactor task, and I don't think my coding skills are up to somethig like this. So if you don't mind I would stick to this for now, and will try and read a bit about what you suggested, and get back to this problem later, when I fully understand what needs to be done, and refactor all variables in the Nokia code to what you have in mind.

> > +		if(hopping_type != 1){
> > +			LOGP(DNM, LOGL_NOTICE, "Baseband hopping selected!\n");
> > +			fu_config[len + 2 + 1] = 1;	/* 0: no hopping, 1: Baseband hopping, 2: RF hopping */
> > +		}
> > +		else
> > +		{
> > +			LOGP(DNM, LOGL_NOTICE, "Synthesizer (RF) hopping selected!\n");
> > +			fu_config[len + 2 + 1] = 2;	/* 0: no hopping, 1: Baseband hopping, 2: RF hopping */
> > +		}


I do mind and I am happy to help you to improve the patch. If you use
an enum the above code will turn into

... function (enum nokia_hopping_type hopping_type, ..)

..
	fu_config[len + 2 + 1] = hopping_type;


and when you search for the definition of the enum one will read

enum nokia_hopping_type {
	Nokia_HoppingNone = 0,
	Nokia_HoppingBaseband = 1,
	Nokia_HoppingRF = 2,
};

When it comes to code the first priority should be to make it work
and be expressive as possible. E.g. if you use enum's the semantic
is part of the name (I don't need to know that in your case the 0
is mapped to 1 and a 1 mapped to the 2).


From sipos.csaba at kvk.uni-obuda.hu  Wed Feb 11 18:30:53 2015
From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba)
Date: Wed, 11 Feb 2015 19:30:53 +0100 (CET)
Subject: baseband hopping
In-Reply-To: <4810271.9412686.1423679332024.JavaMail.root@kvk.uni-obuda.hu>
Message-ID: <29067263.9413102.1423679453616.JavaMail.root@kvk.uni-obuda.hu>

Dear list,

If someone can confirm that a setting like this for baseband hopping is valid, that would be awsome:

TRX0: (ARFCN=883)

- TS0: MA=883,885 HSN=0 MAIO=0 (non hopping, BCCH+SDCCH4)
- TS1: MA=883,885 HSN=0 MAIO=0 (hopping, TCH)
- TS2: MA=883,885 HSN=0 MAIO=0 (hopping, TCH)
- TS3: MA=883,885 HSN=0 MAIO=0 (hopping, TCH)
- TS4: MA=883,885 HSN=0 MAIO=0 (hopping, TCH)
- TS5: MA=883,885 HSN=0 MAIO=0 (hopping, TCH)
- TS6: MA=883,885 HSN=0 MAIO=0 (hopping, TCH)
- TS7: MA=883,885 HSN=0 MAIO=0 (hopping, TCH)

TRX1: (ARFCN=885)

- TS0: MA=883,885 HSN=0 MAIO=1 (non-hopping, TCH)
- TS1: MA=883,885 HSN=0 MAIO=1 (hopping, TCH)
- TS2: MA=883,885 HSN=0 MAIO=1 (hopping, TCH)
- TS3: MA=883,885 HSN=0 MAIO=1 (hopping, TCH)
- TS4: MA=883,885 HSN=0 MAIO=1 (hopping, TCH)
- TS5: MA=883,885 HSN=0 MAIO=1 (hopping, TCH)
- TS6: MA=883,885 HSN=0 MAIO=1 (hopping, TCH)
- TS7: MA=883,885 HSN=0 MAIO=1 (hopping, TCH)

This is one sector with 2 TRX configured for BB hopping.

Thanks in advance!

Csaba


From laforge at gnumonks.org  Fri Feb 13 07:10:12 2015
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 13 Feb 2015 08:10:12 +0100
Subject: Announcing OsmoDevCon 2015
Message-ID: <20150213071012.GF20121@nataraja>

Dear Osmocom.org project members,

I'm happy to be able to announce the annual incarnation of OsmoDevCon.

The Date is set for March 27 through 30.  Venue: As usual, IN-Berlin
e.V. in Berlin, Germany.

Further details can be obtained from
	http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2015

Attendance, as usual, is restricted to people with an active history in
the Project by contributions in terms of code, patches, discussions,
documentation or in other form.

= Registration =

If you have wiki access, please add yourself to the #Requested section.

Alternatively, you can send me private e-mail about it.

After review, your (nick)name will be listed in the #Confirmed section.

Looking forward to meeting all of you again soon!

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)