From laforge at gnumonks.org  Mon Dec  4 12:23:47 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 4 Dec 2017 13:23:47 +0100
Subject: OsmoDevCon 2018 schedule planning
Message-ID: <20171204122347.GN14790@nataraja>

Dear Osmocom Community,

[please respect the Reply-To and post all follow-up discussion to this
 to openbsc at lists.osmocom.org, so we avoid having long threads
 cross-posted to several mailing lists.]

Like every year in early December, it is time to discuss as schedule for
OsmoDevCon in the upcoming year.

Note: Ths is about OsmoDevCon, the more private meeting of developers,
*NOT* about OsmoCon, the public conference.

== When, Who, Where ==

I propose the following date for OsmoDevCon 2018: 
	April 20 - April 23rd, 2018

* Who: Active developers/contributors of Osmocom projects (as usual)
* Where: IN-Berlin, Berlin (as usual)

Please let me know ASAP if that proposed date works for everyone who'd
want to attend.  We can still change it now, but I would want to nail
down the date pretty soon.

== Format ==

After the experiment of reducing from 4 to 3 days last year (due to
OsmoCon), we will again go for *four days* in 2018.

However, we should clearly divide the days in a way that e.g. "GSM/3G"
topics are on two days, while SDR+Other topics are on the other days, so
people not interested in some topics can skip one or two days, as
needed.

We could even divide it further like:
* 1 day 3GPP RAN (osmo-bts, osmo-bsc, osmo-pcu, virt_phy, fake_trx, ...)
* 1 day 3GPP CN (osmo-msc, osmo-hlr, osmo-sip-connector, nextepc, etc.)
* 2 days misc

Regards, and looking forward to meeting you [again] in 2018,
	Harald

-- 
- 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)


From laforge at gnumonks.org  Tue Dec  5 07:38:43 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 5 Dec 2017 08:38:43 +0100
Subject: SDR board design for hand Held tactical SDR
In-Reply-To: <005701d36349$9f985780$dec90680$@com>
References: <005701d36349$9f985780$dec90680$@com>
Message-ID: <20171205073843.GM14790@nataraja>

Dear Shiv,

> We are looking for SCA compliance SDR hardware design. Please send us the
> design
> [...]
> Waiting for your response.

... and I am waiting for end of world poverty, please tell me when you're done.

An Open Source Community does not exist at your service, to design a product
as per your spec, so you don't have to invest in R&D anymore.
Furthermore, this community lives by contributions of its members.

This mailing list is about SDR projects of the Osmocom community.  It is about
technical questions and open source R&D on that topic.

Please try to educate yourself about the kind of project you are sending
mails to, before you do so.

If you should be interested in contributing your SDR board design for a
hand held tactical SDR to the open source community, please do let us
know.

> Notice: This e-mail and / or attachments (communication) may contain
> information that is confidential and proprietary to The Tata Power
> Company Limited, Strategic Engineering Division (Tata Power SED).
> [...]

It appears you have neither read nor understood our mailing list rules,
particularly not the chapter on pseudo-legal disclaimers.
https://osmocom.org/projects/cellular-infrastructure/wiki/Mailing_List_Rules#Pseudo-legal-disclaimers

Your e-mails have been sent to 361 list members, and all posts on this
list are publicly archived.  Welcome to the open source community, where
we don't live by "confidential", but by sharing information openly.

-- 
- 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)


From laforge at gnumonks.org  Wed Dec  6 16:30:23 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 6 Dec 2017 17:30:23 +0100
Subject: OsmoDevCon 2018 schedule planning
In-Reply-To: <20171204122347.GN14790@nataraja>
References: <20171204122347.GN14790@nataraja>
Message-ID: <20171206163023.GB19109@nataraja>

Dear Osmocom Community,

On Mon, Dec 04, 2017 at 01:23:47PM +0100, Harald Welte wrote:
> == When, Who, Where ==
> 
> I propose the following date for OsmoDevCon 2018: 
> 	April 20 - April 23rd, 2018
> 
> * Who: Active developers/contributors of Osmocom projects (as usual)
> * Where: IN-Berlin, Berlin (as usual)
> 
> Please let me know ASAP if that proposed date works for everyone who'd
> want to attend.  We can still change it now, but I would want to nail
> down the date pretty soon.
>
despite Holger indicating April would be difficult for him, I would
still suggest to stay with the current proposed date:
* nobody else has raised any concerns
* several people have sent positive feedback
* it's the usual time-frame as in previous years
* IN-Berlin has already reserved that time slot without any conflict

Sorry, Holger, I hope you will still be around as much as possible!

Threfore, I hereby invite everyone interested to attend to register
themselves in the usual fashion at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2018
i.e. by adding your name to the 'Requested' section.

Please also start collecting topics on that same wiki page.

And please do let me know if there is anything we can do to make the
event better.

Regards,
	Harald

> == Format ==
> 
> After the experiment of reducing from 4 to 3 days last year (due to
> OsmoCon), we will again go for *four days* in 2018.
> 
> However, we should clearly divide the days in a way that e.g. "GSM/3G"
> topics are on two days, while SDR+Other topics are on the other days, so
> people not interested in some topics can skip one or two days, as
> needed.

Let's collect the suggested topics.  I've added a "Thread" column to
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2018/edit?section=9
so we can see how many days / half-days we need for which thread.

Regards, and looking forward to meeting you [again] in 2018,

-- 
- 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)


From loony.developer at gmail.com  Fri Dec  8 14:35:31 2017
From: loony.developer at gmail.com (Andrew Artyushok)
Date: Fri, 8 Dec 2017 16:35:31 +0200
Subject: TCH/H decoding
Message-ID: <CAEf6gcs8Ym0dCJswZ2C93gz8f-m9Eo3e1k+SCFhgiLeE0iv1bA@mail.gmail.com>

Hello. Question about gsm0503_tch_ahs_decode function in gsm0503_coding
from libosmocore (
http://ftp.osmocom.org/api/latest/libosmocore/coding/html/group__coding.html#gaab9c00633bc6f683808014185465af7a)
. Can you please explain wat's "int odd" mean? If it's odd frame
number then which of the 8? And why to function need 8 burst if in function
loop to 4?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20171208/2b23511c/attachment.htm>

From willcode4 at gmail.com  Sat Dec 16 21:54:38 2017
From: willcode4 at gmail.com (Jeff Long)
Date: Sat, 16 Dec 2017 16:54:38 -0500
Subject: SDRplay rewrite w/RSP2
Message-ID: <d118b69a-7f49-33dc-d063-f6e90604878a@gmail.com>

I picked up a SDRplay RSP2 recently, and the gr-osmosdr support needed 
some work. Here's a rewrite that works with RSP2 and has other 
improvements. When the RSP1A comes in, I'll finish support for that. No 
plans to pick up a RSP1, but someone can see if this works if 
interested. This was tested against the Nov 2017 binary blob.

https://github.com/willcode/gr-osmosdr/tree/sdrplay2

=====

Complete rewrite of sdrplay support

- Supports RSP2
- Will support RSP1A when hardware arrives
- RSP1 is untested
- Uses streaming callbacks instead of polling
- Tuning, gain control imporoved, AGC supported
- Better performance (one less layer of buffers)