It’s nerdtime again :)


Over at Kernel Newbies you can have a look at the changelog of the recently released Linux Kernel 2.6.22.


Here’s the cool part about the new wireless stack:


New Wireless stack

For too many years, Linux wireless support has worked, but not very well. 2.6.22 has a completely new, better wireless stack included. This new wireless stack has been donated by the known WiFi specialist company Devicescape (many thanks to Devicescape for their contribution and support to open source!). This wireless stack has many features, like a complete software MAC implementation, WEP, WPA, a “link-layer”; bridging module, hostapd, QoS support to prioritize things like VoIP, 802.11g support, and full debug capabilities. All of this comes in a single implementation that drivers can use without rewriting those features themselves, which sadly has been done multiple times in the linux WiFi world.

Another feature of this stack is a completely new user interface. The old stacks have an ugly ioctl-based interface which were standarized under the name of “wireless extensions”; (wext). The new interface uses a netlink-based interface, suited for the needs of desktop-based configuration interfaces, but retaining at the same time userspace compatibility with the old interface.

The disadvantage is the lack of drivers using this stack: the drivers that have been in the tree for a long time do not support this stack, and will need to be ported (which will hopefully not be that hard, since the new stack is actually a much better ground to build drivers upon that the current mess). There are quite a lot of new and ported drivers that are already using the new stack which have not been merged in this release, but will get merged in future releases, like the RT2x00 drivers, the bcm43xx driver, zd1211rw, adm8211, rtl818x, Intel iwlwifi (ipw3945 and ipw4965). Distributions like Ubuntu and Fedora already are using them.

In any case, this is the building block that will bring better wireless support to Linux.

openmoko.png


The first “real”; Open-Source Linux Smartphone is available for 300 US$ :D

Go over to http://www.openmoko.com and get some more information…


Here are the specs in short:



  • 2.8" VGA TFT color display (640×480!)

  • Touchscreen, usable with stylus or fingers

  • 266HZ Samsung System on a Chip (SOC)

  • USB 1.1, switchable between Client and Host (unpowered)

  • Integrated AGPS

  • 2.5G GSM – quad band, voice, CSD, GPRS

  • Bluetooth 2.0

  • Micro SD slot

  • High Quality audio codec

haken.gif

Exam went fine too :)

Answered everything and it may even be "right"; (it was more a "if you'd have to design a protocol to do X, how would you do it"; kind of exam…

haken.gif

Exam went fine too :)

Answered everything and besides 2 out of 15+ questions, I think I got everything right… Don't know if the answers I gave to those 2 made sense. We'll see :)

another wooohoo for me :D

Da ich es jetzt kapiert hab schreib ich es hier nieder :D

Also, wie ihr sicher alle wisst ist in UMTS dank dem Einsatz orthogonaler Codes die Zellkapazität in der Praxis nur durch die Interferenz bestimmt welche u.a. die nicht 100%ig saubere Trennung der Codes und andere Störeinflüsse erzeugen.

Wenn ihr nun unbedingt wissen wollt wieviel Teilnehmer dann so ca. in eine Zelle passen und ihr ohne dieses Wissen schrecklicke, schreckliche Schmerzen bekommt ist hier eure Rettung!

Die Teilnehmer Kapazität K errechnet sich so:

K = (((W / R ) / ((Eb/I0) * (1+i) *a))) + 1

Da das an und für sich nur Buchstaben sind hier nochmal aufgeschlüsselt:



  • K = Teilnehmerkapazit√§t der Zelle


  • W = Die Chiprate. Bei UMTS also fest bei 3,84 Megachip/s


  • R = Die Nutzdatenrate von der wir bei jedem Teilnehmer ausgehen. Wenn die alle telefonieren nutzen sie in UMTS den AMR Codec und der verbraucht dann z.B. 12,2 kBit/s


  • Eb = Die Energie mit der ihr jedes Informationsbit noch empfangt


  • I0 = Die St√ɬ∂rleistungsdichte


  • ==> Eb / I0 ist also sozusagen eine Art "gute Energie / Rauschen"; Verh√§ltnis f√ºr jedes empfangene Bit. Wenn dieses Verh√§ltnis zu schlecht wird kann man meist nix mehr decodieren. Normale Basisstationen brauchen f√ºr eine Anst√§ndige Sprachkommunikation eine BER (BitErrorRatio) von 10^-4 damit sie es noch decodieren k√ɬ∂nnen. Meist reichen ihnen dazu ein Eb/I0 Verh√§ltnis von 7 dB (→ 10 ^ (7/10)) aus.

    ==> Eb / I0 ist also 10^(7/10) im "Normalfall";

  • i = die Interferenz die euch die Nachbarzellen einbrocken. hier ist ein Wert von 0,8 recht realistisch


  • ==> Also das Verh√§ltnis von Signal zu St√ɬ∂rungen muss, bedingt durch die St√ɬ∂rungen der anderen Zellen, 1,8 Fach so gut sein damit das noch klappt :( Anders gesagt: die anderen Zellen klatschen euch nochmal 80% auf eure bisherige Interferenz oben drauf. Evtl ist es so viel weil zum trennen der Unterschiedlichen Zellen nur pseudo-orthogonale Scramblingcodes verwendet werden.

  • a = Der Voice Activation Faktor. Netterweise wird in "Stillephasen"; die Anzahl der √ºbertragenen Daten reduziert und somit treten die richtig fiesen St√ɬ∂rungen nur 45% der Zeit auf (→ 45% Reden , 55% schweigen)


  • Das +1 am Ende kommt dazu weil ihr euch ja nicht selber st√ɬ∂rt :)



As my "Mobile Communication Systems"; exam is tomorrow I'm doing a bit of research atm concerning GPRS Security.

Over here you can find a Master Thesis by Geir Stian Bjåen and Erling Kaasin about this topic. Pretty nice paper to read up on things :)

4 Sender + 1 Kanal = Kein Problem :)

Dank orthogonalen Codes können die alle gleichzeitig senden und man kann ihr spezielles Signal nacher wieder wunderbar rausfiltern :)

Orthogonale Codes

Das Beispiel ist evtl. wegen den drei Nullen n bissl doof, aber es klappt ja :)

p.s. falls ihr es noch nicht gemerkt hab: ich lern n bissl Mobile Communication Systems ^^

angrybeavers_shadowed.jpg

Hier finden sich so ziemlich alle Folgen der Biberbrüder als Flash-Streamingvideo (im Original: "angry beavers";)