Dear fellow Osmocom developers,
as you all know, we've sadly had to skip OsmoDevCon 2020 and 2021,
trying to compensate it at least to some extent with our OsmoDevCall
every two weeks.
The COVID-19 pandemic is far from over, and we don't know what the
upcoming winter season will bring.
Nevertheless, I think it would be a good idea to start a discussion of
whether we should plan for an OsmoDevCon in 2022.
I personally would say let's plan for the usual late April 2022 time frame,
and if the pandemic situation deteriorates, we can still cancel it with
something like one month lead time.
I would also personally suggest to limit attendance to people who are fully
vaccinated, and in addition do a self-test for all participants every
morning.
In terms of venue, we might also consider to move to a venue that allows better
ventilation. Irrespective of the above we can also bring the air filters from
the sysmocom office.
So with that as an input statement, I would like to hear your opinion
on the above proposals. Who would want to attend? Any complaints against
the "vaccinated only plus daily self-tests in the morning" approach?
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)
Dear Osmocom community,
today our mailing list server lists.osmocom.org has finally been migrated
from mailman2-on-freebsd to mailman3-on-linux. This also included a variety
of changes to DNS. I'll spare you the details, but everything _should_ be up
and running now.
* The List-Id headers should not have changed.
* all list subscriptions + user accounts have been converted.
* old 'static html' archives are still available (read only) at URLs like
https://lists.osmocom.org/pipermail/baseband-devel/
* old List URLs like https://lists.osmocom.org/mailman/listinfo/baseband-devel
are redirected to their respective modern counterparts
In case you notice any mailing list related problem, please don't hesitate to
contact me.
Happy hacking,
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)
would permit try transmitting.<br><br>So if you either find a legal way to =
include the ETSI code at build time, or<br>preferable write a GPL compatibl=
e audio decoder, I think we would be happy to<br>include it in the git repo=
sitory.<br><br>cheers<br> holger<br><br><br>Hello
Pepijn,<br><br>On Sat, 24 Sep 2011 15:49:37 +0200, "Pepijn van den Berkhof=
" <<a ymailto=3D"mailto:vandenberkhof.pepijn@gmail.com" href=3D"mailto:v=
andenberkhof.pepijn(a)gmail.com">vandenberkhof.pepijn(a)gmail.com</a>> wrote=
:<br>> <br>> But do you actually hear output from a real life network=
? Because I<br>> tried the examples attached to the ETSI document regard=
ing the testing<br>> of the codec. They work very nicely, but no luck on=
real life networks<br>> so far. (yes, no encryption)<br><br>I know that=
others have used the current code to decode speech, maybe<br>someone can c=
onfirm it.<br><br>I haven't worked with the code for a while and so can't c=
onfirm it,<br>but it has worked for me in the past.<br><br>Maybe I find the=
time to try it within the next few weeks, if possible<br>I will also try t=
o provide a sample capture from a test TETRA network<br>so everyone can try=
the sample. "Test TETRA Network" means from a<br>network under our
control run in a faraday cage so that there are<br>no legal issues providi=
ng the capture.<br><br>Best regards,<br> Dieter<br>-- <br>Dieter Spaa=
r, Germany &n=
bsp; <a ymailto=3D"mailto:spaar@mirider.augusta.de" h=
ref=3D"mailto:spaar@mirider.augusta.de">spaar(a)mirider.augusta.de</a><br><br=
><br><div id=3D"yiv1108789824">is that could help us for voice decoding : ?=
<br><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.joys99.com=
/d-4784.html">http://www.joys99.com/d-4784.html</a><br clear=3D"all"><br>--=
<br><br>=0A</div><br>_______________________________________________<br>te=
tra mailing list<br><a ymailto=3D"mailto:tetra@lists.osmocom.org" href=3D"m=
ailto:tetra@lists.osmocom.org">tetra(a)lists.osmocom.org</a><br><a href=3D"ht=
tps://lists.osmocom.org/mailman/listinfo/tetra" target=3D"_blank">https://l=ists.osmocom.org/mailman/listinfo/tetra</a><br><br><br></div></div></div></=
body></html>
--1668814050-976982791-1316890565=:17022--
=========
The BCCH is used for two types of broadcast control channel:
* BSCH (broadcast sync channel)
* Broadcast Network Chanenl (BNCH)
These channels, whcih are present only on the downlink, transmit information
about the serving base station. The BSCH transmits the SYNC message. This
provides physical layer synchronization information, including an
extended training sequence for synchronisation and slot alignment, frequency
correction bits to set the carrier frequency, along with MAC layer information
on frame timing (i.e. the number of the current slot, frame and multiframe) as
well as network layer information. Due to the physical layer synchronisation,
the BSCH is transmitted on a synchronisation burst rather than a normal
downlink burst.
The BNCH either carries the ACCESS-DEFINE message or the SYSINFO message.
The SYSINFO message fives the main carrier frequency so that mobiles can tune
to it after picking up any SYSINFO message infromation on any secondary control
channels, power information and network layer information.
The broadcast control channels are normally transmitted in frame 18. Each takes
up to one block of 216 bits, leaving the other block withing the burst for the
corresponding assigned channel or for the base station to send signalling to
other mobiles. O each slot, the sequence shon win figure 7.45 is used, and the
sequence is offset b yone for each slot in the frame, so that every frame 18
has one BSCH and one BNCH. However, transmitting the network information takes
several half-slot BNCH instances, and it will take some time therefore for a
mobile to acquire all the information it needs. This is not normally a concern
since mobiles will be switched on before they are used and an initial delay can
be tolerated. The standards allow the option of transmitting the BNCH in other
physical control channels (indicated by the AACH) as neccessary. Mobiles
continue to monitor the BCCH after they are switched on and also during
transmissions so as to ensure that they receive network information and remain
synchronised.
Multiframe number 1 2 3 4
DL Frame 18, first half slot BSCH*
DL Frame 18, second half slot * BNCH
* = Transmitted on a Synchronisation Burst
Figure 7.45 BSCH and BNCH transmission sequence.
==============
--
- 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)
