From laforge at gnumonks.org  Wed Mar  3 08:47:14 2021
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 3 Mar 2021 09:47:14 +0100
Subject: Announcement of "OsmoDevCall"
In-Reply-To: <75E55A63-450B-4CEA-96CC-BC54E3B19593@hxcore.ol>
References: <X+2wTcPivXaUspv7@nataraja> <YC98xWbUYqVHJ3qf@nataraja>
 <YDVLsGMsyNvw1THp@nataraja>
 <75E55A63-450B-4CEA-96CC-BC54E3B19593@hxcore.ol>
Message-ID: <YD9NEqOwgAgvq9oG@nataraja>

Hi Garret,

On Fri, Feb 26, 2021 at 09:44:53PM +0000, Garrett wrote:
>    Thanks for tonight, was very informative 

happy to hear.

>    If its not to0 late to add stuff to the agenda I would love to
>    hear of any progress on sysmoOCTSIM and the various breakout boards for
>    M.2 modems.

sysmoOCTSIM is a sysmocom product (proprietary hardware with open source
firmware on the SAM3 controllers for sim card emulation), so I'm normally
against "advertising" that too much in the context of Osmocom, which is an
open source project.

Talks about the osmo-remsim or the SIMtrace2 firmware (both open source
projects) are fine, and of course they can mention compatible hardware like
the sysmoOCTSIM, but only as a side-note.  There's already "osmo-remsim in practice"
already on the list of topics.

The modem break-out boards, or in fact all of the various Osmocom OSHW
projects (like SFP breakout, SFP experimenter, ...) would of course make
useful additions.  I've added the following entries to
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall#Future

* "mPCIe and M.2/ngff modem breakout boards"
* "SFP experimenter and SFP breakout boards"

Regards,
	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 osmocom.org  Tue Mar  9 19:47:44 2021
From: laforge at osmocom.org (Harald Welte)
Date: Tue, 9 Mar 2021 20:47:44 +0100
Subject: Announcement of "OsmoDevCall" on March 12, 2021
In-Reply-To: <YC98xWbUYqVHJ3qf@nataraja>
References: <X+2wTcPivXaUspv7@nataraja>
 <YC98xWbUYqVHJ3qf@nataraja>
Message-ID: <YEfQ4KFQU6lJT0Mt@nataraja>

Dear Osmocom community,

It's my pleasure to announce the second OsmoDevCall at

	March 12, 2021 at 20:00 CET

at

	https://meeting4.franken.de/b/har-xbc-bsx-wvs

This first meeting will have the following schedule:

20:00 meet + greet
20:15 presentation: 2020 Osmocom review
20:45 USSE: unstructured supplementary social event [*]
22:00 close of call

Presentation Abstract:

This talk will summarize the major developments within Osmocom during
the year 2020.  Focus will be on the Osmocom CNI projects, but will
also cover developments in other projects

Attendance is free of charge and open to anyone with an interest
in Osmocom.

More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall

Looking forward to meeting you on Friday.

Best regards,
	Harald

[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20210309/dc325cf4/attachment.bin>

From laforge at osmocom.org  Thu Mar 25 17:43:32 2021
From: laforge at osmocom.org (Harald Welte)
Date: Thu, 25 Mar 2021 18:43:32 +0100
Subject: Announcement of "OsmoDevCall" on March 26, 2021
In-Reply-To: <YEfQ4KFQU6lJT0Mt@nataraja>
References: <X+2wTcPivXaUspv7@nataraja> <YC98xWbUYqVHJ3qf@nataraja>
 <YEfQ4KFQU6lJT0Mt@nataraja>
Message-ID: <YFzLxJHq3StXbB3l@nataraja>

Dear Osmocom community,

It's my pleasure to announce the second OsmoDevCall at

	March 26, 2021 at 20:00 CET
at
	https://meeting4.franken.de/b/har-xbc-bsx-wvs

This first meeting will have the following schedule:

20:00 meet + greet
20:15 presentation: multi-TRX + frequency hopping in OsmoBTS
20:45 USSE: unstructured supplementary social event [*]
22:00 close of call

Presentation Abstract:

This talk will present the relatively recent introduction for the support
of baseband frequency hopping in multi-TRX OsmoBTS.

Attendance is free of charge and open to anyone with an interest
in Osmocom.

More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall

Looking forward to meeting you on Friday.

Best regards,
	Harald

[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.

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


From zvpunry at zvpunry.de  Fri Mar 26 00:51:30 2021
From: zvpunry at zvpunry.de (Michael Loeffler)
Date: Fri, 26 Mar 2021 01:51:30 +0100
Subject: gr-osmosdr: add clock_source= parameter
In-Reply-To: <d35a97b9-ced2-465b-3933-0e7f86673027@zvpunry.de>
References: <d35a97b9-ced2-465b-3933-0e7f86673027@zvpunry.de>
Message-ID: <16c19246-7418-95c8-4822-a0ce65cc1e56@zvpunry.de>

Hello,

over three years ago I submitted this patch and it probably wasn't 
noticed so I send it again. The patch still applies without conflict to 
the current version of gr-osmosdr.

Am 19.10.17 um 22:06 schrieb Michael Loeffler:
> Hello,
>
> the attached patch allows to set the clock_source on uhd devices in
> programs like gqrx.
>
> Bye


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-uhd-add-clock_source-parameter.patch
Type: text/x-patch
Size: 2033 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20210326/1aa75658/attachment.bin>

From radio at aijk.org  Sun Mar 28 16:33:52 2021
From: radio at aijk.org (radio at aijk.org)
Date: Sun, 28 Mar 2021 17:33:52 +0100
Subject: Improving the frequency precision of R820T dongles
Message-ID: <009001d723f0$2575f690$7061e3b0$@aijk.org>

Hello,

To avoid confusion, this post is about frequency errors inherent in the
dongle hardware, which is quite separate from crystal drift.

Having noticed that some dongles have impressive frequency stability, I did
some calibration tests, and discovered (as I should have known) that the
limited number length of the dongle hardware tunes to only an approximation
of the requested frequency. In extreme cases the frequency error, i.e. the
difference between the actual frequency and the requested frequency, can be
as much as 1 ppm.

To get around this limitation, I added an experimental function to
librtlsdr.c that returns the *exact* frequency that the dongle is tuned to.
It does this by reading internal registers, and working backwards to compute
the frequency.

Software that makes use of the added function can expect 1 to 2 orders of
magnitude improvement in precision, when a dongle is calibrated at one
frequency and then tuned to other frequencies.

If people here are interested in this work, please let me know where I can
post details, preferably including the occasional graph and table.

Ian