Harald Welte's blog
   

RSS

Harald's Web
gnumonks.org
hmw-consulting.de
sysmocom.de

Projects
OpenBSC
OsmocomBB
OsmocomTETRA
deDECTed.org
gpl-violations.org
gpl-devices.org
OpenMoko
gnufiish
OpenEZX
OpenBeacon
OpenPCD
librfid
openmrtd
opentom.org
netfilter/iptables

Categories

Archives

Other Bloggers
David Burgess
Zecke
Dieter Spaar
Michael Lauer
Stefan Schmidt
Rusty Russell
David Miller
Martin Pool
Jeremy Kerr
Tim Pritlove (German)
fukami (German)
fefe (German)
Bradley M. Kuhn
Lawrence Lessig
Kalyan Varma

Aggregators
kernelplanet.org
planet.netfilter.org
planet.openezx.org
planet.openmoko.org
planet.foss.in

Ohloh profile for laforge
identi.ca
twitter
flattr
Linked in
Xing

Creative Commons License
Articles on this blog/journal are licensed under a Creative Commons Attribution-NoDerivs 2.5 License.


blosxom


Contact/Impressum

       
Sat, 17 Jan 2009
Why do all those netbook need to have fans?

This is a question that I've been asking myself ever since the first eeePC was released. Sure, there are other problems like bad keyboards and mechanical design (with the exception of the HP mininotes) and too small / low-res displays. But the question that bothers me most is: Why do those supposedly-so-power-saving new processors still need a fan in those systems?

I am the happy owner of a Panasonic Let's Note CF-R5. It was bought in September 2006, where it was already end-of-life. It does not have nor need a fan, the Intel U1300 (1.06GHz) CPU and the Intel IGP chipset are doing quite fine without it. So why are the supposedly less power-consuming later systems like Intel Atom built with fans? It's really annoying to me. I don't want this kind of noisy design. It sucks. It is a clear sign of bad engineering.

So far, the only replacement for the CF-R5 that I would consider is a CF-R7 or CF-R8. A netbook faster than the CF-R5 without fan could make me reconsider.

[ /electronics | permanent link ]

OpenBSC: Coding multiplex/demultiplex of TRAU frames

In order to make OpenBSC to actually support switching of the TCH (traffic channels) associated with voice an data calls, we need to implement the following bits:

  • A 16kbit sub-slot processor that splits a given E1 slot (64kbits/sec) into its four sub-slots
  • TRAU-frame synchronization inside those sub-slots (each of them has different alignment which might also change over time, depending on the distance of the phone from the BTS)
  • TRAU-frame decoding (C/D/T bits)
  • TRAU-frame uplink to downlink conversion
  • TRAU-frame re-encoding
  • multiplex of 16kbit sub-slots into E1 timeslot

I've been working on quite a bit of code for this during the last week, but its still not finished yet (and I cannot test, since I don't [yet] have a BS-11 in Taipei).

At some later point we also definitely need to add code to implement the timing adjustments which result from BTS transmit buffer fill level metering requiring us to advance or delay further frames by certain amounts of microseconds. For now I'm just ignoring this, since the BTS is required to buffer the data anyway.

Zecke seems to be debugging the paging code whenever he has time. With some luck we both finish soon and then finally have decent voice calls between phones.

[ /gsm | permanent link ]