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
Dear Osmocom community,
as the pandemic continues and physical meetings are out of the question
for the forseeable future, it would be a good idea to have a periodic
virtual online meeting of the interested Osmocom community.
I was thinking of a format where we would serve two major purposes:
1) technical talks about osmocom relevant topics - ideally
current/recent developments
* can be pre-recorded to avoid any problems with technical setup,
streaming, ...
* should ideally have a Q+A session at their initial "airing" during
one OsmoDevCall
2) unstructured solicited social event (USSE)
* random chat in audio (optionally video)
* not recorded, obviously
The recording of the technical presentation should then be permanently
made available (like the presentations of our prior OsmoCon /
OsmoDevCon).
Not every OsmoDevCall would neccessarily need the two parts, but I think
it would be great if we can make that happen. We could also have e.g. a
two-weekly schedule for the USSE and a monthly schedule for the
technical presentation.
We'd need somebody to volunteer to "manage" the "broadcast" side of
this, preferably somebody with at least some prior exposure to online
events (like the c3voc).
I'm using https://osmocom.org/issues/4928 to collect a tentative list
of topics. Feel free to add your ideas there, as well as any comment/
feedback you may have.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
