copyleft hardware planet

OsmoSDR: First 16 OsmoSDR boards available for developers

Wed, 16 May 2012 20:39:00 +0000

There are something like 16 units of OsmoSDR that we have produce and which are able to sell to interested developers.

However, as there are only 16 units right now, and as the firmware and host software is in a barely usable but incomplete state, we would like to make sure that those 16 units get sold to people who actually have an interest (and expect to have at least some time time!) to fix and improve the current shortcomings.

So if you want to be among the first 16, I suggest you contact me at Harald Welte <laforge@…> and include a short description of who you are (if you are not a Osmocom regular) as well as some incidcation that you are actually going to work on improving the code. If you already know an area that you'd like to work on, please state that, too.

The price will be 180 EUR incl. VAT (that's 151.26 EUR without), i.e. the same price as for the units that will later be sold openly.

I have put together a wiki page with the current status at OsmoSDR/Status to make you aware where we are and what is missing.

Thanks in advance for your willingness to be early users and help us to improve the codebase.

Freetronics: New device: ProtoStick micro prototyping shield for the LeoStick

Tue, 15 May 2012 06:14:21 +0000

The Freetronics LeoStick is an amazing little Arduino-compatible board, and now we've made it even easier to build your own micro-sized projects on it with the introduction of the ProtoStick.

The ProtoStick provides 70 general-purpose plated-through holes for you to add your own parts to your LeoStick projects. It includes markings for the ICSP header as well, so you can choose to either use those holes for your own purpose or you can fit a female header to bring ICSP connections up to your project.

Because the board is so tiny we didn't want to waste space using an entire row of pads just for the header breakouts, so instead we put a tiny row of breakouts between the headers and the first row! That makes it easy for you to jumper across from any header to your circuit.

We'd love to hear about any projects you build using the ProtoStick, so make sure you jump on the Freetronics Forum and tell us about it!

Sebastien Bourdeauducq, lekernel.net: EHSM 2012 CFP

Mon, 14 May 2012 03:54:59 +0000

Exceptionally Hard & Soft Meeting
exploring the frontiers of open source and DIY
Berlin, December 28-30 2012

Some electronics books from the 50s claimed making triode tubes would be an impossible endeavour for amateurs. Today, there are at least two DIY laboratories making not only triodes but also all sorts of vacuum electron devices.

Three years after the first GPS satellite was launched, few people used the technology, which was perceived as very complicated and expensive. Yet, someone successfully operated his homebrew receiver made from hundreds of that time’s electronic parts.

These days, microchips are often thought to be impenetrable and
impossible to manufacture without large-scale facilities. But many individuals are reverse engineering microelectronics designs, often breaking security systems based on the obscurity of the silicon layout. Some are even devising DIY methods to replicate parts of the microchip manufacturing process, with impressive results.

What are the frontiers of DIY technology? The first Exceptionally Hard & Soft Meeting (EHSM) will feature presentations of the brightest DIY achievements. But we do not want to stop at DIY. In fact, we should not, because teamwork is the only way to get the big things done.

The open source ethos is about keeping the freedom and openness of DIY when many people are involved. At a time when thousands of developers from hundreds of companies contribute to Linux and the world’s largest physics laboratories share openly licensed hardware designs on OHWR, we will explore the cutting-edge open source hardware and software practices.

This premiere of the EHSM will be held in Berlin on December 28-30 2012. Everyone is welcome to attend it. Curiosity is enough to qualify, and we have kept the minimal entrance fee affordable. Please order your ticket as soon as possible, to help us make this event happen.

They are already coming
To give you an idea of what is coming up, we are pleased to announce that the following speakers will be presenting their awesome work:

Jeffrey Gough will talk about and demonstrate metalwork techniques. How to go beyond extruded ABS coming from a 3D printer? There might even be a hands-on workshop coming up, stay tuned.
Shawn Tan has been working on a new open source microprocessor design and will introduce it at EHSM.
Ben Krasnow makes all sorts of seemingly impossible science experiments at home, such as creating aerogel (yes, that thing on spacecraft), Pop Rocks candy, or building a scanning electron microscope. He will talk about a yet undisclosed but promising topic.

More speakers will be announced as we confirm them, check this space!

Tickets and funding
EHSM is entirely supported by its attendees and sponsors. To help us make this event happen, please donate and/or order your ticket as soon as possible. EHSM is a non-profit event and most of the money will be used to cover speakers’ travel expenses.

Submit your presentation
Since we do not pretend to be aware of all the amazing tech out there, we are expecting your proposals.

Send a mail to orga AT ehsm.eu with at least the following information:

Name of the speaker
Short bio of the speaker and/or his/her team
Speaker contact information (e-mail + mobile phone if possible)
Where the speaker will be traveling from
Title of the presentation
Abstract
Links to more information (if available)

The standard format for presentations is one-hour lectures, but we are flexible. Write us a note if you have special time or other requirements.

We are waiting for your presentations in these areas:

Open hardware
Big open source project management
Licensing and business models for open source
Manufacturing: metalwork, glass blowing, …
Electronics engineering
Signal processing
Radars
Semiconductors
Rocket science
Thin film technologies
Hardware acceleration
Satellite design
Vacuum electron devices
Millimeter wave technology
Reverse engineering
Applied quantum physics
Thermodynamics
Nuclear science
Nanotechnologies
Ultra high speed photography

…and anything awesome which is not listed here.

If you know of someone else’s work that would be relevant, feel free to tip us! (orga AT ehsm.eu)

For academia
While researchers are most welcome to present their work at EHSM, please note that this is not a traditional academic conference. We will not formally publish proceedings(*), and we do not claim affiliation with any institution. We are also OK with previously published work, we simply expect high-quality presentations.

(*) Contrary to the practice of most academic publishers, we will, however, do our best to ensure the free dissemination of information.

Dates
Doors open: December 28th, 2012, 09:00
Doors close: December 30th, 2012, 18:00
Early registration fee ends: July 15th, 2012
Submission deadline: November 21st, 2012
Notifications of acceptance : November 28th, 2012 (or sooner)
Full programme published: November 28th, 2012

Venue
TU Berlin, Hörsaalgebäude Elektrotechnik
Lecture room HE101
Straße des 17. Juni 136
10623 Berlin, Germany
U Bahn: Ernst-Reuter-Platz

We thank TU Berlin and Freitagsrunde for providing the venue.

WE ARE LOOKING FORWARD TO WELCOMING YOU IN BERLIN!
- the EHSM organizing committee

OggStreamer: #oggstreamer OggStreamer @ LiWoLi 2012 (Linux Week Linz)

Thu, 10 May 2012 15:52:18 +0000

I have the chance to give a short presentation of the OggStreamer at the Linux Week Linz on Friday 25.5. So if you are interested and want to drop by I’ll give a 20-minutes short presentation around 18h30 at the “Stadtwerkstatt Saal”.

It is a great event, offering a number of interesting topics – you can check out the LiWoLi 2012 Program here.

Liu Xiangfu, openmobilefree.net: mForce 200 designed base on Icarus (Icarus 衍生板 mForce200)

Tue, 08 May 2012 12:32:47 +0000

mForce200 designed by lijiangchun base on Icarus. you can buy it at his taobao shop, he release designed source files at google code. it have 2 SPARTAN-6 XC6SLX150-FGG484BIV1027 chips, using a big heat sink instead a noise fan. it’s using a ATX power connecter and a strange USB Standard-A receptacle for USB connect.

May 1st, I received the device, after 12 hours test, it give ~200MHS, Utility: 2.6/m. not as good as Icarus. by talking with the author <lijangchu at gmail dot com>, there are two switches missing in this boards. he will send me a new one. then I will test again and update this page.

May 3rd. I received the new boards. this working one give ~380MHS, Utility: ~5.2/m, same as Icarus, from the power meter, idle it needs ~4.6W, mining needs ~20W, mForce 200 cgminer status page: http://downloads.openmobilefree.net/Icarus/miner.mForce200.php

 First reaction was: I want my money back
 Quality: bad
 Heat sinks placement: bad
 USB cable: bad (2 USB-A plug on both side)
 Power supply/plug: bad (the power cable is already exposed)
 Heat sinks: bad (form factor)
 Hardware errors(Discarded): too high 6% (Icarus only give 0.1% ~ 0.8%)

Working One:

Two Switches Missing:

GNU Radio Blog: FO-29 reception with Gqrx and Funcube Dongle (new recording)

oz9aec@gmail.com (Alexandru Csete) — Mon, 07 May 2012 22:53:22 +0000

Here is a new recording showing an updated Gqrx receiving the FO-29 amateur radio satellite using the Funcube Dongle. Previous recordings used an early version of Gqrx. It was a very quiet pass, most notable thing was probably the Russian and Spanish hams using FM. They probably don't have a clue that their signal comes over a satellite transponder. Another video recording focusing on the FM transmissions during this FO-29 pass is available here.

Watch video on YouTube.

GNU Radio Blog: APRS reception with Gqrx and Funcube Dongle

oz9aec@gmail.com (Alexandru Csete) — Mon, 07 May 2012 10:00:00 +0000

I don't think I ever posted a video showing the built-in AFSK1200 demodulator and decoder in Gqrx, so here it is. The video show local APRS traffic in Copenhagen on a Sunday afternoon. I also tried to receive from the ISS but nothing heard this time.

Watch video on YouTube.

Harald Welte: Some follow-up on the Osmocom Berlin meetings

Mon, 07 May 2012 02:00:00 +0000

We've now had the first two incarnations of the Osmocom Berlin User Group Meeting. The start was great, and we had probably something around 10 attendees. Some were the usual suspects like the various Osmocom developers living in Berlin. But we also had a number of new people attending each of both of the meetings, which is good.

To my big surprise people are even flying in from other parts of Europe in order to be able to attend. Last time from Sweden, and for the next meeting some folks from the Netherlands have announced themselves.

To an even bigger surprise, the attendee from Sweden announced that he is working for an Ericsson research lab, and apparently they are using OsmocomBB quite a bit inside that lab. They think it's a great tool, and apparently nothing else with the same flexibility (i.e. full source code) is at their hands that can compete.

On the one hand it is surprising to see such a large traditional Telco supplier to start to use such amateur tools like OsmocomBB, which definitely have not had even a fraction of the testing (particularly with various operators in various countries) like the commercial protocol stacks.

On the other hand, if you think more about it, Ericsson is entirely a network equipment supplier today. They have spun off their baseband processor business to become part of ST-Ericsson, they have pulled out of Sony-Ericsson, sold their TEMS product line to Ascom and other bits and pieces to Tieto. So right now, if they need a MS-side protocol stack or engineering phones, they probably have to obtain what is available on the market. And that's unfortunately not all that great, as the products are either

Measurement devices aimed at mostly L1 testing / QA (Racal, Agilent, Rohde-Schwarz)
Trace mobiles primarily aimed at field testing (TEMS, Sagem OT) and while they provide traces they don't permit you to send arbitrary data or behave spec-incompliant
Mobile Phone development platforms (Qualcomm, MTK, Infinenon, ...) which don't necessarily give you the full source code to the stack, and are only available if you actually intend to build a handset

So all in all, the more I think about it, it is actually not too surprising that they ended up with OsmocomBB. It's free (as in free beer) and they get the full source code with it. You need a lot of skills and time to get it running and find your way around how to use it, but I guess if you're working in cellular protocols and embedded systems, it's not that hard.

Peter Zotov, whitequark: Reaching the Limits of Adobe Stupidity

Sun, 06 May 2012 14:08:00 +0000

Lately, I’ve been working on Flash ActionScript 3 decompiler, and I noticed an interesting pattern. Normally, if you work with a piece of well-known software and something goes wrong, it’s your fault. But with Flash it’s not anything like that! If it doesn’t work, then it’s probably a bug in the compiler which was preserved for compatibility. Or the specification is plain wrong. Or it’s a bug in the compiler which no one noticed or attributed to cosmic rays instead.

I’ll give a few examples.

Specification is wrong

The official specification on AVM2 is often plain incorrect. Apart from examples already covered in semi-official Mozilla-authored errata, there are a few subtle mistakes. Like mixing up sign bit and sign extension: section 4.1 of spec mentions that signed integers are stored with sign extension, whereas in reality they’re stored with 31th bit set when the values are negative.

There are some other ones (e.g. pushliteral opcodes are screwed up in spec), but they’re not worth explaining.

Compiler generates dangerously invalid code

When working on support for lookupswitch opcode I wrote a small snippet to test my code with. Disassembling it yielded strange results; the code was seemingly invalid. I scratched my head on it for half a hour and then just went and tried to execute it. And you know what? It actually was invalid.

function propel_switch(q:int):Boolean {
  switch(q) {
  case 1:
    print("hoge");
  break;
  case 2:
    print("fuga");
  break;
  case 3:
    print("piyo");
  break;
  case 5:
    print("bar");
  break;
  default:
    print("baz");
  break;
  }
  return false;
}

//                   expected   actual
propel_switch(0); // baz        baz
propel_switch(1); // hoge       hoge
propel_switch(2); // fuga       fuga
propel_switch(3); // piyo       <nothing printed>
propel_switch(4); // baz        <infinite loop>
propel_switch(5); // bar        bar

(The “actual” results are derived from assembler listings. Tamarin shell refused to execute it due to verification errors.)

Update: As one Reddit commenter corrects me, recent versions of ASC no longer have this problem.

No optimization ever

ActionScript compiler does not optimize, period. This produces a lot of weird code and some pieces of modern art.

Consider this switch statement (taken from abcdump.as utility):

 switch (version) {
 case 46<<16|14:
 case 46<<16|15:
 case 46<<16|16:
     var abc:Abc = new Abc(data)
     abc.dump()
     break
 case 67|87<<8|83<<16|10<<24: // SWC10
 case 67|87<<8|83<<16|9<<24: // SWC9
 case 67|87<<8|83<<16|8<<24: // SWC8
 case 67|87<<8|83<<16|7<<24: // SWC7
 case 67|87<<8|83<<16|6<<24: // SWC6
     var udata:ByteArray = new ByteArray
     udata.endian = "littleEndian"
     data.position = 8
     data.readBytes(udata,0,data.length-data.position)
     var csize:int = udata.length
     udata.uncompress()
     infoPrint("decompressed swf "+csize+" -> "+udata.length)
     udata.position = 0
     /*var swf:Swf =*/ new Swf(udata)
     break
 case 70|87<<8|83<<16|10<<24: // SWF10
 case 70|87<<8|83<<16|9<<24: // SWF9
 case 70|87<<8|83<<16|8<<24: // SWF8
 case 70|87<<8|83<<16|7<<24: // SWF7
 case 70|87<<8|83<<16|6<<24: // SWF6
 case 70|87<<8|83<<16|5<<24: // SWF5
 case 70|87<<8|83<<16|4<<24: // SWF4
     data.position = 8 // skip header and length
     /*var swf:Swf =*/ new Swf(data)
     break
 default:
     print('unknown format '+version)
     break
 }

Not only it generates a piece of modern art in an IR dump, but also has a statement so beautifully useless it should be preserved for future generations:

  (ternary (false) (integer 15) (integer 15))

For those unaware of s-expressions and Lisp, not only does this conditional always execute the same branch, but its result also wouldn’t be different even if other one would be taken.

For extra horror, the “piece of modern art” above is executed from scratch each time the VM encounters it, including the constant expressions. Any doubt left why Flash is so slow and power-hungry?

Compiler intentionally generates invalid code

As I’ve already shown, ASC contains enough stupid errors (see this similar bug) to accidentally generate invalid code in not-so-rare cases. But it also intentionally generates invalid code in one very frequent case: a finally block.

Let’s compile this function:

    function c() {
      try {
        hoge();
      } finally {
        piyo();
      }
    }

The compiler will emit a shitload of bytecode (including two catch and two throw statements), but the relevant part is here:

; This is an exception handler. Stack is empty upon jump to an
; exception handler.
;  Address          Opcode    Args   Stack state, comments
           GetLocal0        ; [local0]
           PushScope        ; []
           GetLocal1        ; [local1]
           PushScope        ; []
            NewCatch        ; [catch]
                 Dup        ; [catch catch_dup]
           SetLocal2        ; [catch]
           PushScope        ; []
               Throw        ; I want an object to throw! Ouch!
            PopScope
                Kill     2
            PushByte    -1
                Jump   +32  ; Jump to rethrow

As you see, the opcode at addresses 0025 is invalid because it tries to pop an object from an empty stack. The virtual machine actually recognizes the finally clause by encountering these invalid opcodes. Think about it a little longer, and you’ll go insane.

Also, the recommended way to flow control after a finally statement is… using lookupswitch opcode. The PushByte -1 is actually a mark for that lookupswitch trampoline which makes it jump to a rethrow entry point.

There’s some more interesting stuff like jumps past the end of function (hardwired in VM to do the same as returnvoid opcode) or deliberately emitted dead code.

Freetronics: An introduction to Arduino by Jaycar Electronics and Freetronics

Sun, 06 May 2012 11:16:39 +0000

A little while ago Marc and I recorded an internal training video for Jaycar staff to explain what Arduino is all about, and a cut-down version has just been posted on YouTube. Check it out!

GNU Radio Blog: Broadcast FM reception with Gqrx and Funcube Dongle

oz9aec@gmail.com (Alexandru Csete) — Sun, 06 May 2012 10:58:41 +0000

Here is a short demo showing how to receive broadcast FM with Gqrx. This demo uses the Funcube Dongle, which is really not suited for broadcast FM reception. Gqrx does not employ any tricks to make it sound like it works properly – it just does straightforward FM demodulation with wide FM parameters and you will hear the lack of sufficient bandwidth as distortion on some stations (not all though).

Watch video on Youtube.

OggStreamer: #oggstreamer 24h Streaming Test

Fri, 04 May 2012 22:02:04 +0000

Some days ago I installed the first OggStreamer at the Remotestudio of the FRS – “Free Radio Salzkammergut” – the regional Radio. And I put the OggStreamer to stream for 24 hours non-stop – and it worked without interruption. So I think the next Live-Emission from the Remotestudio can be done using this Setup rather than the temporary Laptop-Setup they have used before.

Another OggStreamer shipped to Switzerland yesterday and it should arrive there early next week – I am quite curious how their reaction on this device will be.

The next OggStreamers from the first batch are already in the making - the list of customers receiving a device form the first batch is already defined. Currently I am evaluating possibilities to start another production run of maybe around 30 Devices. But before thinking that far – The device first has to pass the necessary EMC Compliance Tests …

Another issue what bothers me a little is the delivery time of XPortPro’s – I ordered 4 pcs. of them in the beginning of march and they are expected to be delivered in CW 21 – I am anyhow busy till CW 21 so nothing to worry about, but nevertheless it is quite a bit of time for such a small number.

By the way thanks to David Schleef for putting me on his website and on Planet GNOME – This blog received quite a number of hits via their websites.

Richard Hughes, ColorHug: Getting the ICC display profile

Thu, 03 May 2012 15:21:36 +0000

I’m at LGM this year, and so far it’s rocking pretty hard. The number one question people have asked is “how do I get the screen profile for a window“. I figured this should be easy to get using colord, and then spent a few minutes working on some proof-of-concept code. This ballooned into a couple of hours doing it properly asynchronously and making it work correctly on multihead, and the result was a few hundred lines of complicated code with quite a few exit points. I don’t want people to add 300 lines of boilerplate to their project just to map a GtkWindow to a .icc filename.

So I’m now shipping an additional optional colord-gtk helper library in colord that allow you to use one async function to get the profile a given widget should use. There’s a demo available here.

The alternative is of course to read the X11 _ICC_PROFILE atom, but that does not support multi-head, and really won’t work when we move to Wayland. It’s also not a lot of fun grabbing lots of binary data from the xserver in a GUI program. In the long term future we’ll be doing full screen color management in shaders, with full toolkit support using Wayland, but that’s a few years from being reality. If you’ve got any ideas or have comments about the API, let us know on the mailing list. Thanks.

Liu Xiangfu, openmobilefree.net: 质量差的电源插座

Thu, 03 May 2012 12:19:52 +0000

这个电源插座接了 41 个 Icarus（1000W），一台PC（200W），三个13口的USB HUB，运行了一个月后就变成下图的样子了。插座烧了后，问题是接在这个插座上的电脑的 USB 口全部不好用了。一点电都没有了。还好 Icarus 都还没问题。推荐 80 块以上的电源插座，并把家里质量不好的插座都扔掉。要不然。。。

在 ngzhang 那里学到了一条中国插座定理：插座不拆不能用，或者只买贝尔金的或者 APC 的。

Uwe Hermann: sigrok - cross-platform, open-source logic analyzer software with protocol decoder support

Wed, 02 May 2012 14:05:19 +0000

I'm happy to finally announce an open-source (GNU GPL), cross-platform (Linux, Mac OS X, FreeBSD, Windows, ...) logic analyzer software package myself and Bert Vermeulen have been working on for quite a long time now: sigrok (it groks your signals).

History

I originally started working on an open-source logic analyzer software named "flosslogic" in 2010, because I grew tired of almost all devices having a proprietary and Windows-only software, often with limited features, limited input/output file formats, limited usability, limited protocol decoder support, and so on. Thus, the goal was to write a portable, GPL'd, software that can talk to many different logic analyzers via modules/plugins, supports many input/output formats, and many different protocol decoders.

The advantage being, that every time we add a new driver for another logic analyzer it automatically supports all the input/output formats we already have, you can use all the protocol decoders we already wrote, etc. It also works the other way around: If someone writes a new protocol decoder or file format driver, it can automatically be used with any of the supported logic analyzers out of the box.

Turns out Bert Vermeulen had been working on a similar software for a while too (due to exactly the same reasons, crappy Windows software, etc.) so it was only logical that we joined forces and worked on this together. We kept Bert's name for the software package ("sigrok"), set up a SourceForge project, mailing lists, IRC channel, wiki, etc. and started working.

Overview, Features

You can get the lastest sigrok source code from our main git repository:

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok

Here's a short overview of sigrok and its features as of today. The software consists of the following components:

libsigrok, a shared library written in C, which contains the general infrastructure for handling logic analyzer data in a streaming fashion.

It also contains the individual hardware drivers which add support for various logic analyzers. Currently supported hardware includes: Saleae Logic, CWAV USBee SX, Openbench Logic Sniffer (OLS), ZEROPLUS Logic Cube LAP-C, ASIX Sigma/Sigma2, ChronoVu LA8, and others. Many more devices are on our TODO list (and we already own them), it's just a matter of time to reverse engineer the USB protocols and implement a driver for them.

Thanks ASIX for being open and helping with the ASIX Sigma driver, and many thanks to ChronoVu for being open as well and providing information about the ChronoVu LA8 protocol! Thanks to Håvard Espeland, Martin Stensgård, and Carl Henrik Lunde (who contributed the ASIX Sigma driver), Sven Peter and "Haxx Enterprises"/bushing (for contributing the ZEROPLUS Logic Cube LAP-C driver, ported from their zerominus tool). Also, thanks to Daniel Ribeiro and Renato Caldas who worked on the Link Instruments MSO-19 driver (still work in progress).

Finally, libsigrok also contains the individual input/output file format drivers. Currently supported are: sigrok session (the default format, which contains all metadata), bits, hex, ASCII, binary, gnuplot, the OpenBench Logic Sniffer format, the ChronoVu LA8 format, Value Change Dump (VCD) viewable in gtkwave, and Comma-separated values (CSV).

libsigrokdecode, a shared library written in C, which contains the protocol decoder infrastructure and the protocol decoders themselves, which are written in Python (>= 3.0).

The list of currently supported protocol decoders includes:

  dcf77                DCF77 time protocol
  lpc                  Low-Pin-Count
  mx25lxx05d           Macronix MX25Lxx05D
  jtag_stm32           Joint Test Action Group / ST STM32
  i2s                  Integrated Interchip Sound
  spi                  Serial Peripheral Interface
  edid                 Extended display identification data
  pan1321              Panasonic PAN1321
  mlx90614             Melexis MLX90614
  jtag                 Joint Test Action Group
  rtc8564              Epson RTC-8564 JE/NB
  transitioncounter    Pin transition counter
  usb                  Universal Serial Bus
  i2cdemux             I2C demultiplexer
  i2c                  Inter-Integrated Circuit
  i2cfilter            I2C filter
  mxc6225xu            MEMSIC MXC6225XU
  uart                 Universal Asynchronous Receiver/Transmitter

Many more decoders are on our TODO list, and we especially welcome contributed protocol decoders, of course! We intentionally chose Python as implementation language for the decoders, to make them as easy to write (and understand) as possible, even if that means that performance suffers a bit. Have a look at the SPI decoder for example, to get a feeling for the implementation.

Protocol decoders can be stacked on top of each other, e.g. you can run the i2c decoder and pipe its output into the rtc8564 (Epson RTC-8564 JE/NB) decoder for further processing of the RTC-specific, higher-level protocol. We also plan to support more complex stacking and combining of decoders in various ways in the nearer future.

sigrok-cli, is a command-line frontend, which uses both libsigrok and libsigrokdecode. It can acquire samples from logic analyzers and output them in various formats into files or to stdout, and/or run protocol decoders on the aquired data.

Example: Data acquisition with 1MHz samplerate into a file.

 $ sigrok-cli -d chronovu-la8:samplerate=1mhz --time 1ms -o test.sr

Example: Protocol decoding (JTAG).

 $ sigrok-cli -i test.sr -a jtag:tdi=5:tms=2:tck=3:tdo=7
 [...]
 jtag: "New state: EXIT1-IR"
 jtag: "IR TDI: 11111110, 8 bits"
 jtag: "IR TDO: 11110001, 8 bits"
 jtag: "New state: UPDATE-IR"
 jtag: "New state: RUN-TEST/IDLE"
 [...]

sigrok-qt, a Qt-based GUI for sigrok, using both libsigrok and libsigrokdecode.

This is intended to be a cross-platform GUI (runs fine and looks "native" on Linux, Windows, Mac OS X) supporting data acquisition and protocol decoding.

NOTE: The Qt GUI is not yet usable! We're working on getting it out of alpha-stage for the next release.

sigrok-gtk, a GTK+-based GUI for sigrok, using both libsigrok and libsigrokdecode (soon).

This is a cross-platform GUI contributed by Gareth McMullin (thanks!), supporting data aqcuisition (and soon protocol decoding).

NOTE: The GTK+ GUI is not yet fully usable (but it's more usable than sigrok-qt)! Consider it alpha-stage software for now.

We're happy to hear about other (maybe special-purpose) frontends you may want to write using libsigrok/libsigrokdecode as helper libs!

Firmware

Some logic analyzer devices require firmware to be uploaded before they can be used. As always, firmware is a bit of a pain, but here's what we currently do: For non-free firmware we provide instructions how to extract it from the vendor software or from USB dumps, if possible. For distributable firmware we have a git repo where you can get it (thanks ASIX for allowing us to distribute the ASIX Sigma/Sigma2 firmware files!).

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok-firmwares

Finally, for all Cypress FX2 based logic analyzers we have an open-source (GNU GPL) firmware named fx2lafw, started by myself, but most work (and finishing the firmware) was then done by Joel Holdsworth, thanks! The support list includes Saleae Logic, CWAV USBee SX, CWAV USBee AX, Robomotic Minilogic/BugLogic3, Braintechnology USB-LPS, and many others. Get the code from the fw2lafw git repository:

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/fx2lafw

Example dumps

We collect various captured logic analyzer signals / protocol dumps in the sigrok-dumps git repository:

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok-dumps

They can be useful for testing the sigrok command-line application, the sigrok GUIs, or the protocol decoders.

We're happy to include further contributed example data in our repository, please send us .sr files of any interesting data/protocol you may come across (even if sigrok doesn't yet have a protocol decoder for that protocol). See the Example dumps wiki page for details.

Packages, distros, installers

I'm currently working on updated Debian packages for sigrok (will be apt-get install sigrok to get everything), and we're happy about further packaging efforts for other distros. We have preliminary Windows installer files (using NSIS), but the Windows code needs some more fixes and portability improvements before it's really usable. On Mac OS X you can use fink/Macports to install as usual, fancier .app installer files are being worked on.

Future

Apart from support for more logic analyzers, input/output formats, and protocol decoders, we have a number of other plans for the next few releases. This includes support for analog data, i.e. support for (USB) oscilloscopes, multimeters, spectrum analyzers, and such stuff. This will also require additional GUI support (which could take a while). Also, we want to improve/fix the Windows support, and test/port sigrok to other architectures we come across. Performance improvements for the protocol decoding as well as more features there are also planned.

Contact

Feel free to contact us on the sigrok-devel mailing list, or in the IRC channel #sigrok on Freenode. There's also an identi.ca group for sigrok. We're always happy about feedback, bug reports, suggestions for improving sigrok, and patches of course!

Liu Xiangfu, openmobilefree.net: Automatic Camera by Using OpenWrt (用 OpenWrt 制作自动相机)

Wed, 02 May 2012 01:42:38 +0000

I setup the TP-Link MR11U with Logitech C270 as a automatic camera. it take picture every one second, TP-LINK_MR11U_C270_OpenWrt_mjpeg-streamer.tar.bz2 is the origin pictures in 30 minutes. brower online at here: http://downloads.openmobilefree.net/OpenWrt/TP-LINK_MR11U_C270_OpenWrt_mjpeg-streamer/

There are three different version of MR11U, Ver1.0/Ver1.1/Ver2.0, Ver1.0/Ver1.1 have power switch and two more buttons QSS and RESET, Ver2.0 have only one power switch. we can flash OpenWrt image from the web interface under Ver1.0/Ver1.1, but for Ver2.0 we have to flash OpenWrt under U-Boot command. which means you have to open the case connect the serial console to your computer. I have updated the OpenWrt MR11U wiki page for reflash detail.

Here is steps how to setup TP-Link MR11U as a automatic camera:

Flash this OpenWrt image to the MR11U 3G Router. this image included uvc driver for Logitech C270. here is more information about this image.
By default. it will stream the video. we needs change the /etc/init.d/mjpg-streamer line: –output “output_http.so –port $port” to “-o “output_file.so -f /tmp/ -d 1000″
Reboot the MR11U or restart mjpg-streamer service, then it will automatic take picture every second.

Those two pictures showed another device that we have removed case and try to make the C210 camera and MR11U on one small PCB, this one is not what I am using, I will upload my device picture tomorrow.

~~~~~~~~

今天早上，在去 Icarus 贴片工厂之前，我把我的 TP-Link MR11U 和 Logitech C270 配置成了一个自动的照相机，配置成第秒自动拍一张照片，TP-LINK_MR11U_C270_OpenWrt_mjpeg-streamer.tar.bz2 是 30 分种过程中拍摄的原始图片，没有经过加工。在线浏览： http://downloads.openmobilefree.net/OpenWrt/TP-LINK_MR11U_C270_OpenWrt_mjpeg-streamer/

MR11U 有三种不同的硬件版本 Ver1.0/Ver1.1/Ver2.0，Ver1.0/Ver1.1 有三个按键，一个电源，两个按键分别是 QSS 和 RESET，Ver2.0 就只有一个电源键，Ver1.0/Ver1.1可能直接从网页界面直接刷成 OpenWrt, 由于 Ver2.0 的网页界面增加了镜像检查，所以我们有能直接从 U-BOot 进行刷机，我们必须找开外壳找到串口，我已经把所有的刷机信息都更新到 OpenWrt MR11U 的维基页了

这里是 TP-Link MR11U 自动相机的配置过程：

将 MR11U 刷上 OpenWrt 镜像，这个镜像内置了 UVC 的驱动。直接支持罗技C270，这里有关于这个镜像的更多信息
默认我将 mjpg-streamer 配置成视频了。我们需要把安改成一秒存储一个图片。修改 /etc/init.d/mjpg-streamer 将这行 –output “output_http.so –port $port” 改成 “-o “output_file.so -f /tmp/ -d 1000″
重启路由器或者重启 mjpg-streamer 这个服务。就可以自动拍照了

这两张图片是 MR11U 和 C210 的图片，不是我用的设备。明天我会把我用的设备拍照发到这里。（阳光下拍照，效果会好一点）

Bunnie Studios: Interview with MAKE: The End of chumby, New Adventures

Mon, 30 Apr 2012 23:52:18 +0000

Last week, the Internet discovered the end of chumby as you have known it. My exit from the company five months ago was deliberately discreet. It was a good run, but it was also time for me to move on. Upon hearing the news, my good friend Phil Torrone reached out to do an interview, and I was happy to oblige. The interview encapsulates some of my experiences that may be applicable to others excited to get into the hardware business. Here’s some of the questions that I answer for Phil:

Can you talk about making a device from start to finish, from idea to factory to retail shelves?

What were the challenges with retail sales?

Did you get any patents? How do they work within the world of open-source?

Do you have any advice for a maker who is considering taking VC funding? Anything different if they’re doing open-source hardware?

What are your thoughts on Kickstarter for funding?

When you advise companies what do you most often suggest to the founders?

If you could do it over, how would you change the hardware of the Chumby? The software? The way Chumby was made?

Now that you’ve been part of a full cycle of a VC funded company that makes hardware, what suggestions do you have for company structure, from the people to the location, to the overall organization?

What’s next for bunnie, what are most excited about to do next?

If you’re interested, have a read at the jump!

Open Electrons: Milkymist: pushing further the limits of electronics openness

Mon, 30 Apr 2012 21:12:35 +0000

Everyone has heard of open source software, but can the same principles be applied to hardware?

Some people argue that hardware is so expensive to manufacture and modify that it prevents hobbyists from contributing, and thus stifles the development of an open source hardware community.

This isn’t entirely true. In fact, the huge popularity of community-developed microcontroller platforms (Arduino and its huge collection of add-on modules being the most famous examples) tends to show the opposite. Other examples include the USRP software-defined radio platform, Texas Instrument’s Beagleboard single board computer, or the Openmoko mobile phone (though the latter has enjoyed limited success).

But while those projects feature open and public hardware specifications, ”traditional” schematics, printed circuit boards and mechanical designs, the whole semiconductor design and manufacturing process remains a poorly covered area. There are a few pioneers like GRLIB (LEON3), OpenSPARC and OpenRISC. But all suffer from excessive complexity, slowness and large hardware resource usage – if not outright poor or unfinished design. These factors make them difficult to access and stifle their wide adoption, with a need for oversized FPGAs, modern semiconductor processes and advanced logic synthesis tools – all being very expensive.

The Milkymist project thus develops a high performance system-on-chip (SoC) design with the economy of resources and of complexity in mind. It is targetted at the demanding application of real time video effect rendering for embedded systems, and wants to prove that open hardware logic designs can compete in terms of performance.

The Milkymist SoC is based on Lattice’s Mico32 CPU core, and features a host of custom-developed peripherals, like a DDR SDRAM controller, various I/O interfaces and graphics acceleration.

But Milkymist’s founder, Sébastien Bourdeauducq, said that they are not stopping there. They are developing a complete open hardware product out of this system-on-chip, which includes software, schematics, PCB, and enclosure. The end product will be an “interactive VJ station”, a device meant to be used during concerts and artistic events to generate real time video effects and make them interactive thanks to the many built-in interfaces (MIDI, DMX, video input, Ethernet, OSC, USB, GPIO).

To foster development on this open hardware platform, Free Electronic Lab (formerly known as Fedora Electronic Lab) and Milkymist are collaborating to provide the smoothest and easiest to setup programming environment as possible.

At this time, the full system-on-chip design is complete (the current focus is on improving its documentation and fixing any bug that can be found) and the second batch of PCBs (hopefully based on the final design) is on its way to the fab. If everything goes well, some development kits will be available for sale at the end of December.

For more information, visit www.milkymist.org.

Freetronics: Controlling a Vacuum Fluorescent Display (VFD) from a LeoStick (Arduino compatible)

Mon, 30 Apr 2012 07:31:15 +0000

Prolific "repurposer" Matt Evans is well known for taking old or discarded electronics and giving it new life. When he departed for the UK earlier this year he was given a Vacuum Fluorescent Display (VFD) module as a parting gift - very appropriate!

He then combined it with a phone charger, some random bits of wire, and a Freetronics LeoStick:

Matt said: "The VFD has a row of 0.1" pins and is odd in that it's not serial nor HD44780-style, just ASCII over D[7:0] and Write/Busy handshake lines - the Leostick pushes straight onto the pins to drive it."

If you look to the left of the VFD you'll see the LeoStick connected to the side, driving characters to the display.

Nice work, Matt!

Open Hardware Repository: Simple PCIe FMC carrier (SPEC) - 25-04-2012: SPEC boards running in Siberia!

Erik.van.der.Bij@cern.ch (Erik van der Bij) — Mon, 30 Apr 2012 06:21:08 +0000

Transmaterial: Woven Stone

Fri, 27 Apr 2012 14:00:29 +0000

Woven Stone is part of the ASI Specialty Products Magna Mosaic Collection. Earth tones combined with dimensional, geometric features create a powerful and sculptured look, lending an artistic element to any space. The continuous, controlled texture of Woven Stone creates a sense of movement, suitable for the most modern of interiors, including retail, hospitality, healthcare and corporate projects.

Contact: Architectural Systems, Inc., New York, NY, USA.
Find more information in Transmaterial 3.

Open Hardware Repository: OHR Meta Project - 25-04-2012: Is open hardware creating a more open world?

Erik.van.der.Bij@cern.ch (Erik van der Bij) — Fri, 27 Apr 2012 12:17:03 +0000

Video Circuits: Spontaneous Symmetry Violation .01

noreply@blogger.com (Chris) — Tue, 24 Apr 2012 04:34:53 +0000

Spontaneous Symmetry Violation .01 (2003) :: Recursion VideoLab :: Boomin' Side

More madness from the VHS vaults of the VideoLab

Music: BOOMIN' SIDE / TRIPPER SIDE (Derek, mixed tape 1992, 0:00 - 42:00)
Music: Digital Division | Live @ Treewood (Derek & Eric, 1993, 42:00 - end)

[and for all you Digital Division fans, check out the part when they turn on the mics in the Treewood garage just after midnight on New Year's Eve (1:02:41) voices = Lovlin, Rowena, Jason, Eric, Derek, Adam, Ivy, et al]

https://vimeo.com/videoalchemy

Dieter Spaar: A bit of 3G Layer-1

Tue, 24 Apr 2012 02:00:00 +0000

While experimenting with my Node-B, I had the need to generate a RACH message without having to use a phone. Such an approach can for example be used for performance testing of the Node-B receiver or evaluating the RACH handling capacity of the radio network (no, I don't call it RACH DoS ;-)

First a little bit of theory: The RACH in UMTS works different than in GSM, its not just about sending a single RACH burst. Because WCDMA is very sensitive to interference, the phones have to send with a transmit power as low as possible. For the RACH procedure this means that the phone starts to send a short RACH preamble with very low power and looks for the acknowledgement if the preamble has been received by the Node-B on the AICH (Access Indication Channel) channel. If the phone doesn't receive the acknowledgement, it increases the transmission power and resends the preamble. If there is the acknowledgement from the Node-B, the phone sends the actual RACH message. The RACH message itself is not just a few bits containing the access cause and a random reference like in GSM, it is a complete message. "RRC Connection Request" is used for accessing the network but other message can also be sent on the RACH channel (e.g. "Cell Update" which is besides other things used for indicating unrecoverable RLC errors. One can see this message frequently when starting to implement an RNC ;-).

Now where to get a RACH preamble and message without having to use a phone? I started to look at Agilent's Signal Studio for WCDMA which should be able to generate a RACH messages with user defined content which can be replayed with a signal generator. However even after lots of trials I never managed to generate a RACH message which can be properly decoded by the Node-B, only the RACH preamble is detected without errors but the RACH message itself just produces garbage and CRC errors.

So I started to write my own code to generate the RACH message. The relevant 3GPP specification for WCDMA FDD is TS 25.212 (Multiplexing and channel coding) and TS 25.213 (Spreading and Modulation). Basically the steps to create a RACH message requires adding a CRC to the message bits, Convolutional encoding, 1st Interleaving, Rate Matching, 2nd Interleaving, Spreading, Scrambling and finally Modulation. I and Q signal on the Uplink carry different things, Data is on the I signal, Control (pilot bits and transport format information) on the Q signal. Luckily the RACH message does not require any fancy multiplexing and rate matching of multiple transport channels on a physical radio channel. This can get really funny, especially if Turbo Coding is involved which results in multiple bit streams (systematic and parity bits) which are treated differently. After some trial-and-error and lots of experimenting and testing I was finally able to create a well formed signal of a RACH preamble and message which the Node-B can properly decode.

After that I also tried to decode the RACH message generated by Agilent's Signal Studio to find out why it didn't work. It seems that the wrong scrambling code sequence is used (the scrambling code number looks OK, but the offset into the code bits is wrong). I really wonder why no one noticed this problem with Signal Studio before or maybe I am just doing something wrong. Anyway, I can now use my own code to generate RACH messages. Maybe in the future I will also look into generating a signal which a phone will consider as valid signal of a 3G cell, this requires generating the P-CPICH (Primary Common Pilot Channel), P-SCH/S-SCH (Primary/Secondary Synchronization Channel) and P-CCPCH (Primary Common Control Physical Channel) carrying the BCH.

OggStreamer: #oggstreamer jlGuiApplet replaces ffmp3

Mon, 23 Apr 2012 16:39:59 +0000

Sorry to say – but I’ve dropped support for ffmp3 – the main reason for this is that flash only processes audio at 44100Hz so streaming ogg and listening with ffmp3 wasn’t possible at 48000Hz (it was just play-backed at 44100Hz). So I needed another solution for this. Its name jlGuiApplet which implements an Winamp-style Ogg/MP3-Player as a Java-Applet and supports the 48000Hz sampling-rate as well. This software is almost 5 years old but it does the job.

As you can see on the ssh-terminal running on the XportPro – streaming to 1 client produces around 1% CPU-Load at 128kbps. Also note that we are using more than 8,5 Megabytes of RAM, which means that older XPortPros with just 8Megabytes in RAM total, won’t be able to run the full OggStreamer-Software including the builtin sighttpd streaming-Server.

Richard Hughes, ColorHug: Stop wasting time and money, make the Fedora 18 release name “Fedora 18″

Mon, 23 Apr 2012 14:22:07 +0000

Calling all Fedora users and developers. Please visit the official poll to choose the future of Fedora release names.

Nobody refers to “Running Fedora Verne” and choosing the name every few months is just a giant waste of time and waste of a very busy legal team that has to review and research each stupid name. I think “Beefy Miracle” is a ridiculous name that really takes the edge off an otherwise most professional release.

Just have the next release name as Fedora 18 and be done with the nonsense names once and for all.

Liu Xiangfu, openmobilefree.net: Icarus SMT factory(Icarus 贴片工厂)

Sun, 22 Apr 2012 15:32:12 +0000

~~~~~~~~

今天参观了 Icarus 的贴片工厂凯顺电子，工厂在北京北六环附近，成立有一年左右，目前有大约 40 人在这里工作。这是我第一次走进贴片工厂，几乎所有的东西对我来说都是未知领域，一进门的时候我就注意到了他们的铁制门帘，所有的门上都安装了这种铁制的门帘，从图片上你能注意到这种铁制门帘都是有接地的。每当有人进入操作间的时候都会很自然的碰一下铁门帘来放掉身体上携带的静电。

Icarus 安排在中午 11 点贴片，这里有三台SONY的贴片机（两台130，一台209），一台11区温度的回流焊。整个过程需要 4 个人完成其中 2 个人都是检查 Icarus 将结果／意见反馈给贴片机的操作人员，一但准备工作完成， 90 片 Icarus 会在2～3个小时内完成，其它的就是手工插焊的工作，被安装在明天进行。

整个参观的过程都由生产总监 Steven Lin 给我做介绍。这里要非常感谢 Steven Lin。

北京市凯顺电子技术有限公司，电话：010－89787870，邮箱：steven_lin01@126.com

~~~~~~~~

osPID: Wiki is Up

Sat, 21 Apr 2012 11:40:45 +0000

We now have our very own documentation wiki! It is still needs a lot of work, but the basic structure is there. Over time we hope this grows into a powerful resource for the osPID user-base.

Anyone is free to create an account and edit, so feel free to add content. Be advised however, that this is a moderated wiki; all edits are subject to moderator approval. We felt this was the best way to allow for user-modification, while protecting against spam.

Video Circuits: AFC: Work from the Experimental TV Center Archive/Television Delivers People

noreply@blogger.com (Chris) — Sat, 21 Apr 2012 08:49:22 +0000

I know it's a bit late now, I misse this but it's here for posterity :) also check out the ICAs current exhibition Remote Control that surveys the enormous impact that television has had upon contemporary culture and there other related live events Television Delivers People

Photo: James Richards

Next Thursday (13 April 2012), Artists’ Film Club presents a selection of ground-breaking works from the archive of New York’s Experimental TV Center. An insight into the recent history of artists using, exploiting and subverting new electronic media technologies.
In the early 1970′s, artists were moving outside existing organisational structures in attempts to create more utopian systems, in critique of television and mainstream media. However, until the 1990′s artists struggled to access these new media tools for their own uses. Founded in 1969 in Owego, New York state, the Experimental TV Center has been a hub for video engineering and experimentation ever since.

Created by artists for other artists the center has developed its own unique bank of radical editing and image processing equipment, worked with by such diverse artists such as Gary Hill, Ikue Mori, Nam June Paik and Abigail Child.

The Artists’ Film Club presents a programme of works from the ETC’s archive and is selected by artist James Richards, and Associate Curator of Artists’ Moving Image, Steven Cairns.

Find out more about the unique and peculiar resources hosted at the ETC.

Transmaterial: CarbonCure

Fri, 20 Apr 2012 14:00:11 +0000

CarbonCure is a precast concrete technology developed to sequester carbon dioxide. The CarbonCure Block System has been installed across North America at concrete manufacturing facilities to store CO2 within concrete masonry units during the production process, permanently locking away the greenhouse gas in the form of synthetic limestone. CO2 is injected into concrete through a modified core bar during the molding stage. The result is a more environmentally-responsible concrete product with equivalent performance and cost to traditional concrete.

In addition to sequestered CO2, CarbonCure blocks have a lower carbon footprint than traditional masonry units due to reductions in their steam curing temperature and cement content. As a result, the total CO2 emissions reduction is approximately 250 grams per block.

Contact: CarbonCure Technologies, Halifax, NS, Canada.

Freetronics: Low cost wireless environmental sensing with Arduino

Fri, 20 Apr 2012 12:47:58 +0000

Check out this great video showing how a group of people with different skills and backgrounds came together to build an environmental monitoring system. One of the key components is a Freetronics EtherTen, which acted as a communications gateway for the system by linking sensors to the Internet via a 3G connection.

From the video description:

On the 23 of February ScienceMob organised a sprint event with Gaia Resources, the JCU eResearch Centre and Townsville City Council. Many of us were strangers working with systems we were not familiar with.

The event took place at the Rowes Bay sustainability demonstration house, a pre-1980s concrete block home that has been retrofitted with energy efficiency measures and renewable energy solutions with a focus upon the benefits of maintaining biodiversity through planned urban landscapes.

Our plan was to make 8 subterranean enclosures and monitor their temperature with different types of covers. We chose galvanized iron as our roofing material and painted half of our roofs black and the other half white. We also used various thicknesses of insulation and left one black and white treatment un-insulated.

Temperatures were measured using the maxim DS18B20 1-Wire digital thermometer. These sensors were connected to a solar charged lithium ion powered Seedunio Stalker v2.1 board with XBee wireless communication. Data was transmitted to an XBee module on an EtherTen connected to a 3G modem via an ethernet connection.

Information was then sent by a web service to Gaia Resources' servers in Perth and visualized on the web using Google APIs.

Preliminary results showed that a plain white roof without insulation may be better than a black roof with insulation; we will make the visualization and setup details available to the general public in the coming months so that you can watch the progress of the experiment from wherever you have an internet connection.

Open Hardware Repository: OHR Support - OHWR maintenance on 2012-04-23 (Monday) 08:30 CEST

egarcia@splendeo.es (Enrique García) — Thu, 19 Apr 2012 17:38:08 +0000

Andrew Zonenberg, Silicon Exposed: PCB fab characterization - undercut in DorkbotPDX batch order

noreply@blogger.com (Andrew Zonenberg) — Thu, 19 Apr 2012 04:19:17 +0000

Most of the time people making PCB simply design the board exactly as they want it to look, send it off to the fab, and trust that they'll get back a board that matches what's on the gerbers. Unfortunately this is not actually the case! The gerbers are used to create a photomask, which is then exposed onto a photoresist-covered panel and etched.

Most PCBs are patterned using a ferric chloride or copper chloride based etch which is almost perfectly isotropic - it etches equally in all directions. This results in the mask being undercut by approximately the thickness of the copper layer (35 μm for 1oz copper).

PCB cross section showing sloped sidewalls from undercut (homemade board)

Ever since I did my first BGA board and noticed some of the pads looked a bit small I've wanted to do a formal study of mask undercut on this process so that I can design future boards with this in mind.

While the undercut is small and insignificant for many applications, it can become a significant issue when working with fine-pitch BGAs, 0201 sized passives, and other very small components!

This was my first time imaging PCBs at high magnifications (more than the 30x of my inspection microscope) so I fooled around a little bit with techniques. Somewhat surprisingly I found that darkfield illumination gave better results than brightfield - brightfield images tended to be far too bright due to reflections from the soldermask.

My first test was one of the leftover boards from my BGA test in January. In darkfield the pads stood out very well and were easy to measure to within a few μm. All dimensions were taken with the focal plane at the top of the trace. At some point in the future I plan to cross-section a board and measure edge profiles.

200 μm nominal diameter BGA pads (darkfield image). The circles below and to the left of the pads are damage to the soldermask from a misaligned BGA reflow attempt.

The pads are on 500 μm centers and are nominally 200 μm diameter with 300 μm space between them. A quick inspection shows that the pad size is much smaller than the space! Actual measurements show that the left-hand pad is 85 μm in diameter and the right is 67 μm, for undercut of 115 μm and 133 μm respectively!

Further inspection showed that one of the isolated pads (not connected to a trace) had been etched away entirely.

Brightfield image showing empty hole in soldermask where a pad was etched away. Note strong glare from soldermask in brightfield mode.

It is also interesting to note that the soldermask apertures are almost exactly 200 μm in diameter despite the gerbers including some clearance around the pad.

A higher magnification image allowed me to measure trace and pad sizes more precisely.

Higher magnification image of same area

The 200 μm nominal pad is actually 89.5 μm in diameter and the 152 μm trace is actually 57.9 μm. The undercut was over 50% in this case - 110.5 μm on the pad and 94.1 μm on the trace.

In order to verify that the undercut was not specific to this one board I tried a more recent one - my 0201 passive test panel from last week.

0201 capacitor footprint

Both pads are nominally 250 μm wide. Actual measured dimensions are 187 μm and 190 μm for undercut of 63 and 60 μm respectively.

Higher magnification view of a single pad

This pad measured 189 μm wide. Edge roughness was very small and hard to measure but it looks to be under 5 μm.

The same board also contained an 0.8mm BGA footprint. Pads are nominally 400 μm on 800 μm centers.

0.8mm BGA footprint

The results were consistent with previous measurements - actual pad sizes are (clockwise from top left) 329 μm, 329 μm, 331 μm, and 332 μm. Undercut values are 71 μm, 71 μm, 69 μm, and 68 μm.

In conclusion, the fabricator used by the DorkbotPDX batch order exhibits nontrivial undercut on small features. Observed undercut values ranged from 68 to 133 μm and were fairly consistent within a single board but varied from board to board. The 0.5mm BGA test board exhibited an average undercut of 113.5 ± 19.5 μm and the 0201 test board exhibited an average undercut of 67 ± 4 μm.

OggStreamer: #oggstreamer pictures of completed device

Wed, 18 Apr 2012 22:29:31 +0000

Mechanics and Electronics are completed (we will see what story emc-compliance testing will tell), but for now the “Hardware” is ready. The last piece to add to this puzzle was a countersunk-headed screw that holds the cinch-connector in place. I got the screw samples from Bossard – thank you.

Here some pictures:

Liu Xiangfu, openmobilefree.net: 41 Icarus 挖矿

Wed, 18 Apr 2012 16:16:23 +0000

Icarus is designed by ngzhang, it’s open source hardware. all design files can found at github, it’s support by Cgminer. more information can be found at this wiki page, 41 Icarus running at 15GH/s, it mine ~8~10BTC per day, every Icarus needs ~25W, there 16 Icarus connect to one ATX 650 W power. other are using the power adapter(12V 2A). the Cgminer status can be found here: http://downloads.openmobilefree.net/Icarus/ those Icarus information: http://downloads.openmobilefree.net/Icarus/README

It’s not only for bitcoin mining also can be used as FPGA develop/learning board.

~~~~~~~~

41 Icarus 同时可以达到 15GH/s , 一天可以挖出 10BTC，每个 Icarus 需要 ~25W ， 41 个 Icarus 当中 16 个接到了 ATX 650W 电源上。其它的用的自带的电源适配器（12V 2A），软件运行的详细信息见： http://downloads.openmobilefree.net/Icarus/ 硬件信息见：http://downloads.openmobilefree.net/Icarus/README

41 Icarus

41_Icarus_Dark

Liu Xiangfu, openmobilefree.net: 复古耳机

Wed, 18 Apr 2012 16:02:53 +0000

There are too many people says my phone call is not clear. they cannot hear me clearly. so I try to find some headphone on TaoBao. found this one, designed for iPhone. it needs some convert line for other phones. so I just order this headphone + convert line. after I receive those two interesting things. I know the seller didn’t tested the convert line at all just as the other taobao shop. they are just take information form other placae, no test at all. it’s better without this convert line. this convert line make the sound smaller and make the headphone button not working. but it’s good news that we don’t needs this convert line. after use this headphone, my wife no longer complain that the phone call is not clear. but if you use this headphone outside, people will think you are strange: ‘What the f**k!’

~~~~~~~~

由于有太多的人说的我手机不清楚。就在淘宝网上找了找有趣的耳机。发现了这个，从淘宝介绍上看是专门给 iPhone 设计的。需要一根转接线耳机。于是被坑爹下单买了这个复古听筒式耳机＋转接线。两天后收到货。玩了几下。发现没有转接线反而清楚。而且听筒上的按键也可以接／挂电话。接上转接线后声音明显变小。听筒上的按键也失灵。还好转接线只有 5 块钱。打电话给老婆再没有报怨不清楚的情况。就是外出有点过于拉风：’我操’

Headphone 2

Headphone 1

Tuxbrain: Superofertón Protoboard + Cables de conexión

Wed, 18 Apr 2012 08:29:29 +0000

Bueno, bueno, bueno... Lo que os hemos traido.

Si necesitas una Protoboard, quieres cambiar la que ya tienes o simplemente las coleccionas por que sí, esta es tu oportunidad de hacerte con todas las que quieras por un precio inigualable 3,99€ con el IVA incluido.

Además el modelo que os ofrecemos viene con una cajita de cables de diferentes medidas que os facilitará trabajar con esta placa de pruebas.

Aquí tenéis el link al producto y una fotico

Video Circuits: Tapescape Catford

noreply@blogger.com (Chris) — Wed, 18 Apr 2012 00:53:41 +0000

Thanks to my friend and co worker Owen for pointing this one out right under my nose
Tapescape Catford! can't believe I missed this one, even if my laptops heat sink is bust. Definatly heading down tomorrow. Not sure about the Video Amnesty, ill be haning on to my VHS videos and players ect :)

"About
Politics surrounding the videocassette
Description
We are taking over the now empty Blockbuster Video Store in Catford, South East London to explore the politics surrounding the videocassette.

Using art installations, soundscapes, spoken word, discussions, talks, screenings, dance, games and more, the intervention questions the impact video has made on all our lives, how it affected our behaviour and the huge environmental cost of our short lived innovations.

We will be holding a 'Video Amnesty' allowing Lewisham residents to bring in old video cassettes[1] and players to be returned to the shelves for one last time before heading off to be completely recycled and re-emerge as something new

FIRST VIEW OF THE LINE UP!

TUESDAY 17TH, 7.30PM
CASSETTIQUETTE
VH-ESSAY DIRECTED BY KAI CLEAR
EXT-1 INTERACTIVE AUDIO VISUAL INSTALLATIONS BY NATHAN HARMER
I LOVE VIDEOTAPE BY JONATHAN PIGRAM
MORE FILMS, AUDIO EXHIBITS AND BAR
TUNES BY DJ NOVA

THURSDAY 19TH, 7.30PM
PROVOCATION: HOW TECHNOLOGY MAKES OUR BODY ITS BUSINESS: JANE FONDA, LEISURE, AND THE EMBODIMENT OF THE GOOD CITIZEN BY ROANNA MITCHELL
HTTP://WWW.PLATFORM-7.COM/APPS/BLOG/SEARCH?Q=ROANNA
VISUAL ART RESPONSE BY DARREN SPERRING
HTTP://WWW.PLATFORM-7.COM/GALLERY#!__GALLERY/2011-EXHIBITIONS/VSTC27=DARREN-SPERRING
DANCE RESPONSE BY MELANIE SIMPSON
HTTP://WWW.YOUTUBE.COM/WATCH?V=UD4WRFWQLGU

FRIDAY 20TH (TBC) 8PM
RIOT ACT 2012 (TBC)
PERFORMANCE BY
TOM BRESOLIN & ALEXIS MILNE (TBC)
PIE N MASH FILMS – IF IT IS SAFE TO SHOW (TBC)
HTTP://WWW.PIENMASHFILMS.COM/
PRINCESS BRITANNIA - SHE KNOWS WHAT IS GOING ON (TBC)
HTTPS://WWW.FACEBOOK.COM/ PROFILE.PHP?ID=100001488826532
LIVE PERFORMANCE BY SCULPTURE
HTTP://TAPEBOX.CO.UK/

SATURDAY 21ST, 7.30PM
EXPLODING CINEMA
VHS EXPLOSION
HTTP:// WWW.EXPLODINGCINEMA.ORG/

SUNDAY 22ND
THE MARATHON MAN FILM QUIZ, 3-6PM
HOSTED BY DAN CALLADINE
HTTP:// DIGITAL-EXAMPLES.BLOGSPOT.CO.UK/2012/01/RETURN-OF-FERRIS-BUELLER.HTML
VJ LEPKE, 8.30PM (TBC)
AN ORIGINAL VHS VJ
HTTP://SOUNDCLOUD.COM/LEPKE-B

THE OLD BLOCKBUSTERS VIDEO STORE

95 Rushey Green, Catford , SE6 4AF [map]
www.platform-7.com

This event has been enabled due to the kind support of the London Borough of Lewisham and its Valuer Team for the building and the Waste Management Team and Environmental Recycling Services for supporting our Video Amnesty"

Freetronics: GyroStar marine rotation sensor interfaced with Arduino

Tue, 17 Apr 2012 13:19:31 +0000

Michael Carey's experience in the marine electronics industry and with amateur radio means his first ever Arduino project hasn't been the typical blinking LED: instead he interfaced a MuRata GyroStar rotational sensor to a Freetronics Eleven!

The GyroStar is a Piezo-electronic device that measures rotation, and they're used in marine autopilots to keep the boat travelling in a straight line. Michael's idea is to incorporate it into a robot project to help it go into a straight line. Check out his video demo:

Nice work, Michael!

Free Electrons: Free Electrons Quarterly 2012 Q2

Tue, 17 Apr 2012 09:14:01 +0000

The below message has been posted on our English and French newsletters. Don’t hesitate to subscribe to these newsletters if you are interested in getting these news by e-mail.

This is the second Free Electrons newsletter for 2012. We are happy to share with you the latest news about our projects, training courses and contributions.

New “Android system development” training

As announced in our previous newsletter, we have created a new Android system development training course.

This course targets engineers who need to develop embedded systems with Google Android. In four days, through theory and practical labs, the course makes you familiar with compiling and booting Android, with adapting Android to support a new embedded board (assuming that it is already supported by the Linux kernel), and with building a real system through accessing specific hardware, customizing the filesystem and using debugging techniques. More details and the complete agenda.

The first public session of this training will take place on June 11-14 2012 in Toulouse, France (session taught in English). There are still seats available for this session. See cost and registration details.

We will start giving on-site sessions of this course in July 2012. Do not hesitate to contact us if you want to organize on-site sessions.

Opening our training materials source code

Since Free Electrons’ creation in 2004, we have been releasing our training materials under the Creative Commons Attribution Share-Alike license, a free license that allows anyone to share, improve and use our embedded Linux and Linux kernel training materials. Since that time, our training materials were available as PDF files, and as OpenDocument files for the source code, but we were only updating their online version from time to time.

Now, we are proud to announce that our training materials are being converted to the LaTeX language, and their latest version is available at any time from our public Git repository.

For the moment, our embedded Linux slides have been published (about 500 slides) in this Git repository, as well as the instructions for the practical sessions of our embedded Linux and Linux kernel courses. In the near future, we will also publish in LaTeX the slides of our Linux kernel training (which remain available under PDF and OpenDocument formats) as well as the materials of our new “Android system development” course.

The creation of this public Git repository is a strong sign of our commitment for open training materials.

The LaTeX format and the public Git repository now make it easy for everyone to follow updates on our materials, to keep one’s knowledge up to date, and even to teach a training session using our materials (commercial use of our materials is welcome, as it helps to spread knowledge about Free and Open Source Software for embedded systems).

Upcoming public training sessions

Our next public training sessions dates and locations are:

Embedded Linux kernel and driver development
June, 4-8 2012
Toulouse, France
Session given in French
Details
Android system development
June, 11-14 2012
Toulouse, France
Session given in English
Details
Embedded Linux system development
June, 18-22 2012
Avignon, France
Session given in French
Details
Embedded Linux kernel and driver development
July 2-6, 2012
Avignon, France
Session given in French
Details
Embedded Linux kernel and driver development
October, 8-12 2012
Avignon, France
Session given in English
Details
Embedded Linux system development
October, 15-19 2012
Toulouse, France
Session given in French
Details
Embedded Linux system development
December, 3-7 2012
Avignon, France
Session given in English
Details
Embedded Linux system development
February, 4-8 2013
Lyon, France
Session given in French
Details

Projects

Since the beginning of the year, we have been involved in the following projects for various customers:

Boot time optimization and power management evaluation for a MIPS-based platform used in a payment terminal;
Filesystem size optimization, embedded Linux build system integration, Ethernet PHY driver development for an AT91 ARM platform used in satellite video processing;
Embedded Linux build system integration and generic embedded Linux debugging and support for an AT91 ARM platform used as a gateway between medical devices;
Starting in April, we will be working with a major ARM SoC vendor to help mainlining support for their latest SoC in the official Linux kernel sources;
Continued the creation of materials for our new “Android system development” course.
Continued our work on the Linux kernel driver for the Analog-to-Digital converters of the AT91 ARM SoC (see ‘Contributions’, below);
Continued our work on real-time Linux evaluation on AT91 ARM SoC (see ‘Contributions’, below.).

Career opportunities

Free Electrons is looking for a kernel developer in the the French Riviera, to be hired with a permanent contract. The job is open to English speaking people who do not speak French, but are ready to settle in the area of Nice, and be hired through a French contract. See details.

Conferences and contributions

Embedded Linux Conference and Android Builders Summit

Three engineers of Free Electrons attended the Embedded Linux Conference 2012 and Android Builders Summit 2012 in Redwood Shores, near San Francisco in California, on February. This strong participation of our engineers to technical conferences is a key factor to make sure we remain up to date on embedded Linux technologies and keep a close contact with the community.

During the conference, we have published daily reports about the various talks that we thought were interesting:

After the conference, we also posted videos of the talks:

Our scripts to encode videos to the royalty-free VP8 codec and add a title sequence to the videos are now available on on our public git server.

At this conference, our engineer Thomas Petazzoni has given a talk titled “Buildroot, a nice, simple and efficient embedded Linux build system”. Here are the slides and the video.

FOSDEM conference

Two of our engineers participated to the FOSDEM conference, a community-driven open-source conference, in early February.

Our engineer Maxime Ripard gave a talk on his work around the IIO kernel subsystem, which he used to write an ADC driver for the AT91 SoC. Here are the slides.

Our engineer Thomas Petazzoni gave a talk about “Using Qt for non-graphical applications”. Here are the slides.

AT91 Analog-to-Digital converter drivers

Details about the driver for the AT91 Analog-to-Digital converters driver written by Maxime Ripard from Free Electrons have been published on the Atmel Linux4Sam wiki. This driver relies on the IIO framework, and we are in the process of getting this driver merged upstream. See the Atmel Linux4Sam wiki page.

Real-time Linux benchmarks

A report of extensive real-time benchmarks conducted by Gregory Clement from Free Electrons on AT91 platforms has been published on the Atmel Linux4Sam Wiki. This report compares a vanilla Linux kernel, the PREEMPT-RT patches and the Xenomai co-kernel approach through timer-based and GPIO-based benchmarks. See the Atmel Linux4Sam wiki page.

Buildroot

Free Electrons’ involvement in Buildroot is still strong:

Maxime Ripard and Thomas Petazzoni participated to the Buildroot Developer Day organized in Brussels before the FOSDEM conference. A report of this meeting, which gathered several other Buildroot developers, is available at the Buildroot mailing list archives.
Since the beginning of the year, Thomas Petazzoni has contributed 64 patches that have been merged: support for the LTT-ng Linux tracing solution, support to represent host utilities in the menuconfig, many updates and fixes to external toolchain support and many other fixes.
In the same time-frame, Maxime Ripard has contributed 13 patches that have been merged: support for systemd, improvements to the package infrastructure and various fixes.
Thomas Petazzoni has implemented a Web interface that publicly shows the result of our random configuration builds, available at http://autobuild.buildroot.org. The Buildroot community is doing random configuration builds 24/7 on three machines, with various configurations. This Web interface collects the build results and sends a summary every day on the Buildroot mailing-list. This has already allowed to fix many build issues, and will help to improve Buildroot’s quality in the future.

Linux kernel course

Participants to our Embedded Linux kernel and driver development course have also started contributing to the Linux kernel sources during the course itself. Here are the patches which have been merged so far:

During our git lab, instead of asking people to make dummy code changes, we ask them to make real improvements to the Linux sources, and send them for real to the right maintainers and mailing lists. This way, people get a better understanding of how they can interact with the Linux kernel developers to merge their changes and contributions.

See our slides and practical lab instructions for our git lectures and lab.

Blog posts

Free Electrons has published several blog posts:

Buildroot Developer Day, Brussels edition
Announcing our Android system development training
Free Electrons at FOSDEM: two talks and video recording
Free Electrons at the Android Builders Summit and the Embedded Linux Conference: one talk and video recording
HOWTO – Mailing lists with Mailman on Ubuntu 10.04
Our blog posts on Android Builders Summit and Embedded Linux Conference listed previously
Linux on ARM: xz kernel decompression benchmarks
How to boot an uncompressed Linux kernel on ARM
Android gdbclient command
A new tool to ease kernel maintainer life
Experiment with Yocto
Report on extensive real-time Linux benchmarks on AT91
Linux kernel engineer job in Nice

You can follow Free Electrons’ news by reading our blog and by following our quick news on Twitter.

By the way, the right column of the Free Electrons blog now lists the most popular posts and pages. This can help you to find useful content that you may have missed.

Free Electrons remains available to help you in your embedded Linux projects, either through its development and support services or through its training sessions. Do not hesitate to contact us!

Gregory, Maria, Maxime, Michael and Thomas – Free Electrons

Dieter Spaar: 3G User Plane

Mon, 16 Apr 2012 02:00:00 +0000

Continuing with my Node-B experiments I started to implement handling the user plane. I can now do voice calls, video calls and data connections. Just to make it clear, those are the very first steps only without any optimisation for speed and far from being complete or ready for release. I consider it as the essential "building blocks" necessary for the next steps towards a small Open Source RNC.

So how does it work? One way to allocate a channel for user data is to modify the existing signalling channel by sending the RRC "Radio Bearer Setup" message to the phone and the NBAP "Radio Link Reconfiguration Prepare/Commit" messages to the Node-B. Besides being much more complex due to the number of possible parameters and options this is somehow comparable to TS 04.08 "Channel Mode Modify" and A-bis TS 08.58 "Mode Modify" in GSM. If the commands succeed the Node-B will allocate another UDP port for the User Plane data besides the existing UDP port for the Control Plane data (UDP ports because I use "Iub over IP" to talk with the Node-B).

The User Plane data are embedded in FP (Frame protocol, TS 25.427). For voice the data are the AMR class A, B and C bits. To ease testing with a single phone I use a loopback which simply sends the received uplink AMR class bits back to the downlink.

Signalling for a Video Call is very similar to a Voice call. The main difference is in the CC Setup message, the bearer capability indicates UDI (Unrestricted Digital Information) for Video. UDI is basically a 64 kbit/s channel which transports video according to the 3GPP umbrella protocol 3G-324M) for video telephony. Loopback is not as easy as for voice because first the four-way H.245 protocol handshake has to be completed to agree on communication parameters, after that the uplink video data can be resent to the downlink.

Although UMTS is generally much more complex than GSM/GPRS, handling of data connections is easier than for GPRS because there is no need for a PCU (Packet Control Unit) with all its complexity. There is the optional protocol PDCP (Packet Data Convergence Protocol, TS 25.323) on top of RLC which is used for things like header compression. But if you don't use it, you get the raw IP packets embedded inside RLC.

osPID: The Long-Awaited Firmware Update

Sun, 15 Apr 2012 15:42:51 +0000

I’ve just uploaded both firmware and front-end updates to github. There have been numerous tweaks and improvements, be here are the high points:

Setpoint-Profile Support

Rather than hard-coding a reflow profile, we went with a more flexible approach. Using 3 different commands (setpoint STEP, setpoint RAMP, input WAIT) you can piece together a sequence that gives you your desired result.

Different profiles are stored as files on the desktop side. One profile at a time may be loaded onto the osPID and executed. The profile is stored on the osPID EEPROM, so loading is only necessary when you wish to change the profile.

IO Card support

The previous version of the firmware was pretty much hard-coded for the digital output card and temperature input card. This firmware breaks out all the IO code into a separate file, where pre-compiler flags let you specify which cards are being used. This should simplify card-swaps and prototype-card usage.

Hackability

The previous version of the firmware made awful use of the osPID’s resources. It used WAY more RAM than necessary, and only left 5k of free program space. In addition to adding a bunch of new features, the new firmware is much better on RAM usage, and leaves over 9k of free program space. This means that if you have the itch to hack the osPID, there’s actually some room for you to do so.

There’s always more work to be done, but I’m pretty happy with what we’ve managed to accomplish with this revision. As always, let us know if we messed up; everyone will benefit.

Bunnie Studios: Name that Ware April 2012

Sun, 15 Apr 2012 11:28:00 +0000

The Ware for April 2012 is shown below.

And a nice side view, showing off the relays:

Thanks to Bruce Lane for submitting this month’s Ware!

Bunnie Studios: Winner, Name that Ware March 2012

Sun, 15 Apr 2012 11:27:46 +0000

The winner for March 2012 is MegabytePhreak! congrats, email me for your prize.

The ware is a Zhaoxin 868D hot air rework station, which combines both a soldering iron and a hot air gun into a single box. I purchased it for about US$19 in the Shenzhen electronic market.

When I travel to Shenzhen, I find it more economical to simply purchase equipment and dispose of it upon leaving, rather than the alternatives of paying bag check fees, or dealing with interrogation by security screeners. The iron actually has a nice bit of empty space on the inside, and the reason I had it opened up was to hide some valuables from cleaning staff while I was out. ‘Safes’ in Chinese hotels are often times not bolted to the walls, so putting your valuables in them is a bit like putting a big red arrow on your stuff that says ‘this is the box you should take’.

GNU Radio Blog: EzTV666 DVB-T dongle on the air

oz9aec@gmail.com (Alexandru Csete) — Sun, 15 Apr 2012 09:07:08 +0000

Last week I have tested the RTL2832U-based ezcap EzTV666 DVB-T dongle on the air using various VHF signal.

Already Saturday I attempted to receive APT from the NOAA-18 weather satellite. These satellites are always very strong and it was no different using the EzTV666 as you can see on the screenshot below. I was using a handheld ArrowII antenna using an extra adaptor cable, but nothing to match the 50 Ω from the antenna with the 75 Ω in the dongle.

Tuesday I took the RTL2832U SDR dongle with me to the weekly AMSAT meeting at IHK (the Engineering College in Copenhagen). Here we have some better antennas and in particular this one was much better for VHF reception:

The following videos show reception of broadcast FM and narrow band FM in the form of local APRS traffic and slow-scan television. In all cases I used existing GNU Radio flow graphs from the available examples and modified them to use the rtl_source_c from the gr-baz library.

I was using the relative gain feature of hte source, i.e. when the gain is adjusted between 0.0 and 1.0 regardless of dongle type. I found that the transition between too low, optimal and too high gain is not smooth but rather "jumpy" as if there were only these three values to choose from. Moreover, there appears to be some hardware AGC active somewhere, which is very annoying and can in many cases spoil reception.

Watch video on YouTube

Update: The gnuradio-companion GRC files used in these tests are available here: https://gist.github.com/2408228

Andrew Zonenberg, Silicon Exposed: Fab screwups, then taming the 0201 passive

noreply@blogger.com (Andrew Zonenberg) — Sat, 14 Apr 2012 18:23:07 +0000

Since I've already developed a reliable process for reflowing 0402 surface mount components, as well as 1mm pitch BGA, the next logical step was 0201 passives.

I made a 1x1 inch test board with a bunch of 0201 footprints plus several other test structures (I hope to fool with homebrew filled vias at some point so I included an 0.8mm BGA with drilled-out pads on the same dummy board) on DorkbotPDX's batch order. When I eagerly opened my purple envelope late last month I was quite annoyed to discover that my soldermask pattern was completely wrong!

Soldermask bugs

The component values on the silkscreen were a screwup on my part but the fab had totally borked the mask. The correct pattern had the via fence unmasked and all of the areas around components masked.

After emailing back and forth with Laen we figured out the problem - my soldermask polygon had gone slightly outside the board outline and a bug in his panelization script resulted in the offending vertex being deleted, rather than clamped to the board outline. He offered to make me a new batch of boards at no cost.

The new boards arrived today and I inspected them briefly under the microscope. As usual they were superb quality, with near-perfect registration between layers.

Pre-assembly inspection of 0201 footprints

My first attempt at applying solder paste using a 22 gauge needle was a complete failure. There was as much paste between the pads as on them.

Somehow I don't think this will work...

I tried scraping the paste around with a scalpel blade and managed to get something halfway decent, but it still wasn't nearly as clean as I wanted. After thinking for a bit I decided to try squirting paste onto a microscope slide, then picking up a tiny blob with the blade and touching it to the component pads. This actually worked out surprisingly well!

Paste applied with scalpel blade

I wasn't expecting to get any better than this (for scale, the traces between the pads are only 150 μm wide) so the next step was to place components.

After component placement

This took a few tries but my super-fine-point tweezers were a huge help. The pitch I used seems to be about the sweet spot - pretty dense, but not so close that my tweezers bang into the next component in line while placing one.

I ran the board through my standard reflow profile in a toaster oven, then inspected.

Post-reflow inspection looks good!

Everything looked good, there were no visible shorts (confirmed by electrical testing) and all connections seemed solid and low resistance. I took a few more photos at varying angles and magnifications to verify.

Angled view of a single component. Note the size of the component in relation to the 35 μm thickness of the 1-ounce copper trace!

One of these days I need to try using stencils for paste application. In the meantime, it looks like 0201 passives are labor-intensive but definitely within reach for high-density designs.

Free Electrons: Linux kernel engineer job in Nice

Fri, 13 Apr 2012 14:02:06 +0000

Free Electrons is looking for a embedded Linux and kernel engineer in the area of Nice in France (on the French Riviera). The contract will be home based, but will also involve working at customer locations in the same area, possibly for long periods of time.

See a detailed job description on our careers page.

For this particular job opening, we absolutely need someone with prior experience with kernel and driver development, and contributions to the official Linux kernel sources will be a strong advantage. This is because a customer of ours is looking for an engineer to develop new drivers and port the Linux kernel to pre-silicon and silicon platforms.

Once we find a candidate with the expected skills and profile, and once the customer agrees to contract this person for this initial project, the engineer will be hired by Free Electrons under a permanent contract, and will work on the customer site for at least 6 months.

Once the initial assignment is over, our engineer will continue to work on projects for other Free Electrons customers, and will also give embedded Linux and kernel training sessions to customers throughout the world.

Note that this position is open to people who do not speak French, but are ready to settle in the French Riviera and to be hired through a French contract.

If you are interested in this position, see our job description for details about how to apply.

Freetronics: Time lapse camera dolly with Arduino control

Fri, 13 Apr 2012 12:21:11 +0000

This very cool project was built by Steve Tester using an Eleven, a ProtoShield Short, a Terminal Shield, and various other bits of hardware.

The Eleven controls a stepper motor that "winches" the dolly along the tubes while the camera takes a series of photos, which can then be stitched together to form a time-lapse video.

Check out the details on Steve's blog, including a time-lapse video of the end result: http://tester.id.au/?p=248

Free Electrons: Report on extensive real-time Linux benchmarks on AT91

Fri, 13 Apr 2012 11:19:07 +0000

The real time page I wrote for Atmel was finally released on the Linux4Sam Atmel Wiki. The purpose of this page was to help new comers to use real time features with Atmel CPUs and to present the state of the real time support.

Here are some figures associated to this work:

On this page I present the results of more than 300 hours of benchmarks!

During the setup and the tuning tests ran for more than 600 hours.

Analysis and formatting took a few dozen hours of work.

The benchmarks have been run on 3 boards, 3 flavors of Linux (vanilla, PREEMPT-RT patches, Xenomai co-kernel approach), and 2 kinds of tests (timer-based and GPIO-based)

Fabricatorz: Milkymist Gets Rowdy and Jazzy In Warsaw

Thu, 12 Apr 2012 00:00:00 +0000

I spent the past week in Warsaw with some friends and the M1. I arrived on Wet Monday, an Easter tradition where Polish "boys awake girls by pouring a bucket of water on their head and striking them about the legs with long thin twigs". Apparently the tradition continues out into the streets where boys splash girls they have crushes on, but I didn't see anything of the sort. Probably because it was way too cold, but also because Warsaw has a tendency to take itself way too serious. (I was told plenty of flirtatious water fights would be happening in the smaller, more "traditional" towns outside the city.) Fortunately I was able to recoup the fantasy that evening when I did some (visual) splashing of my own with the Milkymist alongside Movie Star Junkies, an impressive blues/punk band from Torino, Italy.

Full disclosure: I've never vj'd previous to this show. But this goes to show how simple the M1 is to use: I just plugged it in, aimed the live-feed video camera at the band, toggled between its preset psychedelic patches, and Boom! an epic visual performance. Everything went so well that I got invited to perform again the next night at a different venue. Despite the change in setting and sound--from underground (literally in a basement) punk show to jazz/funk fusion jam band in a swanky loungey bar--it was just as easy to adapt and compliment the music due to the M1's smorgasbord of visual options. Check out the videos, see for yourself: http://vimeo.com/fabricatorz/videos

Michele's GNSS blog: Spring news in the GNSS and SDR domain

noreply@blogger.com (Michele Bavaro) — Tue, 10 Apr 2012 22:02:00 +0000

I have been following in the last few days interesting developments in the GNSS and SDR domain.

1. NV08C-CSM and dual constellation RAW measurements

It's recent news that NVS has lifted the constraints on the firmware with RAW data for GPS and Glonass on L1. In my opinion this is one of those rare times that the rules of the game are changed by one of its players.
Essentially the NV08C-CSM provides real-time kinematic capability at 10Hz, with a price point as low as 35EUR/piece in small quantities. It is already possible to download an unofficial version of RTKNavi.exe and RTKConv.exe here, but RTKLIB will officially support the receiver from next version anyway.
Below are some pics of what Denga10 and the navXperience 3G+C could do with the good old 2.4.1 "Static Precise Point Positioning" over three hours.. bringing down the error to less than 20cm in complete standalone mode (by using only broadcast products).

Rtknavi (NVS mod) doing static PPP with 14 sats

Rtknavi (NVS mod) available satellite close-up

Glonass broadcast navigation data

GPS broadcast navigation data

GPS/Glonass observations.. 21!

Satellites used in the fix

From cold start, first three hours, ground track

From cold start, first three hours, position

From cold start, third hour, ground track

From cold start, third hour, position

The likes of Novatel, Trimble, Hemisphere, etc are not going to like it I suppose. On the other hand, users have perhaps a cheaper option to enter the high-precision domain.

2. RTL-SDR

For once, the group of innovators is European.
These guys of osmocom are smart and -what's even better- their work with the open source team. RTL-SDR is, I believe, one of the freshest finds in the Software Defined Radio domain. The Fun Cube Dongle, developed in UK, is already a very clever tool. But finding the super-tuner Elonics E4000 (note, again a UK Company) in 25$ USB DVB-T dongles and being able to grab data in a 3MHz bandwidth between 64MHz and 1.7GHz... that is really cool.

I had to buy one! ...actually two before I found the E4000..

A Terratec Cinergy T Stick Black rev.1, with the FC0012 which is not suitable for GPS

A Newsky TV28T, with the E4000.

The Realtek RTL2832U demodulator uses a 28.8MHz crystal by default.. which has too poor accuracy for a GPS receiver.. but a SDR acquisition algorithm can easily handle 100+kHz of apparent Doppler shift in the frequency search :)
So for a nominal sky plot as the one below:

And a signal looking like as follows:

Power spectrum around GPS L1, FS=2.728MHz

The ADC is saturated.. the gain I set was too high.

I could acquire the following birds:

SV 9: Doppler +112000.0 CodeShift:     99 xcorr: 553566.6
SV12: Doppler +113500.0 CodeShift:    502 xcorr: 301126.3
SV15: Doppler +110000.0 CodeShift:   1847 xcorr: 871305.9
SV17: Doppler +110500.0 CodeShift:   2225 xcorr: 401100.6
SV18: Doppler +110000.0 CodeShift:     38 xcorr: 368766.1
SV26: Doppler +107000.0 CodeShift:   1779 xcorr: 511844.4
SV27: Doppler +110500.0 CodeShift:    264 xcorr: 650033.9
SV28: Doppler +107500.0 CodeShift:    203 xcorr: 320405.6

The next step is to have my new version of GPS-SDR processing the data in real-time.. won't be long!
I managed to upload the binary file which is long enough for everyone with a SDR receiver to calculate the position. I used FS=2.048MHz and a nominal IF of 0.0Hz (but because of the crystal inaccuracy the IF actually falls at about 110kHz). The data type is I&Q interleaved int8_t.

https://rapidshare.com/files/558977948/20120415_1714BST_fs2048_iq8.001.dat

https://rapidshare.com/files/2431212520/20120415_1714BST_fs2048_iq8.002.dat
https://rapidshare.com/files/4187716662/20120415_1714BST_fs2048_iq8.003.dat
https://rapidshare.com/files/107864226/20120415_1714BST_fs2048_iq8.004.dat

3. Open source FPGA receivers

I waited too long for the code from the University of Tampere: they were promising to licence the TUTGNSS and never happened.
Finally the Open Source community is bringing to the reality an Open Source FPGA implementation of a GPS receiver based on the Namuru / Zarlink GP2021 correlator structure and soft CPU cores (the LatticeMico32 Milkymist and the Altera NiosIIe). As also scientists at the University of Tokio (remember RTKLIB?) are involved, this time I know it is going to happen.
Some useful links:
http://gnss-sdr.ru/index.php?blogid=2
http://en.qi-hardware.com/wiki/GPS_Free_Stack
http://blog.goo.ne.jp/osqzss/

Stay tuned, GNSS is evolving rapidly!

Moxie Processor: Notes on a novel in-game CPU: the dcpu-16

Mon, 09 Apr 2012 15:35:57 +0000

The hacker behind the Minecraft phenomena, Notch, is working on his next game, most likely another hit. This one is interesting in that it includes an in-game 16-bit processor called the dcpu-16. Details are sparse, but it seems as though gamers will use this processor to control spacecraft and play in-game games. The dcpu-16 spec is currently available at http://0x10c.com/doc/dcpu-16.txt, and in the few days since its release there are already many community produced assemblers and emulators.

Like moxie, it’s a load-store architecture with variable width instructions (16 to 48 bits long). But the dcpu-16′s 16-bitness is pervasive. There are 8 16-bit registers, and the smallest addressable unit of memory is a 16-bit word. There are only about 16 unique opcodes in the 16-bit instruction, which means there’s room for 2 6-bit operands. With only 8 registers, a 6-bit operand can encode multiple addressing modes (direct, indirect, offset, etc) and still have room for small literal values.

If you poke around github you’ll find the start of a llvm backend as well as a tcc port. I haven’t looked into these compilers, but a C ABI for the dcpu-16 would certainly be unusual to most developers. You would likely have a 32-bit long, but char, short and int would all be 16 bits.

As far as GNU tools go, a binutils port would be pretty straight forward. I created a branch in moxiedev to try my hand at a dcpu-16 binutils port. It’s not very well tested, but gas, ld, objdump, etc all appear to work as advertised. All instructions with immediate operands, whether literal values or computed by linker relocations, are encoded in their long form. Taking advantage of the smaller encodings will require linker relaxation work. It’s not rocket science, but more work than the couple of hours I was willing to put into it. There appears to be one bug in GNU ld related to handling relocations for ELF targets where the smallest addressable memory value is 16 bits vs 8. I worked around it by making one small non-portable change to the target independent linker code.

I think GDB should be fairly straight forward as well. For most real targets GDB will want to insert breakpoint instructions in the text of a program, and it wants that instruction to be the same size as the smallest instruction available on the target. Alas, the dcpu-16 has no breakpoint instruction, 16-bit or othwerwise, so the simulator will have to include special hardware breakpoint emulation logic. My suggestion is to repurpose some of the 16-bit illegal instruction encodings. For instance, the ISA allows for nonsensical instruction like this:


  SET 5, 6

This means set the literal value 5 to 6. Setting a literal value makes no sense, and the spec currently says that these instructions are silently ignored. Rather than ignore them, you could use this class of instruction as special software interrupt/breakpoint/trap instructions like moxie’s swi.

A GCC port would be more challenging. It’s definitely possible, but would stretch GCC outside of its comfort zone. You’d end up excercising bits of the compiler that aren’t normally tested, and I imagine would end up spending a lot of time debugging some of the darker recesses of the compiler code. Best of luck to the brave soul who tries this!

I’m very curious to see how this all plays out. Given the massive success of Minecraft, I wouldn’t be surprised if we see an app store for in-game dcpu-16 based games. Good luck to Notch and the team at Mojang.

Harald Welte: Prototype smart card chips in DIL-40 case have arrived

Mon, 09 Apr 2012 02:00:00 +0000

Finally, the first samples of the smart card chip (for the Osmocom CardOS project) have arrived. As opposed to the final smart cards, this one has been packaged in a DIL case instead of the usual thin credit-card sized plastic. The reason for this is quite simple: This way lots of I/O pins for debugging as well as JTAG can be accessible during COS development.

Here you can see the first incarnation of a veroboard connected to an adapter pcb inside an Omnikey smart card reader:

After confirming it worked, I soldered the wires directly to the adapter PCB, as can be seen here:

There is already a real PCB design that is currently manufactured, i.e. in a week or so there will be a picture of a clean, professionally-produced/etched PCB with all of the prototype pins exported.

In terms of the COS, I haven't done much more work than compared to the last posting, mainly due to a large number of other projects. But we will get there...

Harald Welte: Name that UART: April 2012

Mon, 09 Apr 2012 02:00:00 +0000

It's sort of a cheap knock-off idea stolen from the Name that Ware on bunnies blog: I'm going to post one picture every month about a UART that I found on embedded hardware. Unfortunately I don't have much to offer in terms of a reward for whoever finds the true solution ;)

In any case, every month there are devices that I'm looking into either out of my own interest, or because the work at gpl-violations.org requires it. In most of them, you can find a UART to get to the u-boot / Linux serial console.

So here is the device that I just took apart earlier today:

The location of the UART pads was obvious, after looking at the PCB for a very short time. The entire unpopulated U1 footprint appeared suspiciously like a UART level shifter for true RS232 voltage levels:

You can see two signals going directly to a small unpopualted3-pin header
There are two other signals coming from somewhere under the main SoC
There are capacitors (C440, C441) directly connected to the U1 for the charge pump

Freetronics: Keep an Arduino-compatible board in your pocket: the LeoStick has landed

Sun, 08 Apr 2012 00:08:05 +0000

Our newest Arduino-compatible board is now available to the public after about 600 were distributed to hackers at linux.conf.au 2012 in Ballarat a few weeks ago as a sneak preview. It was a huge hit at the conference and we've since been inundated with questions about when it'll be generally available, so now with great pleasure I present the LeoStick:

The LeoStick is a tiny breakout board for the ATmega32u4 MCU that will be used in the forthcoming Arduino Leonardo. We're shipping it with a modified pre-release version of the Leonardo bootloader, so you can pop it into your USB port and load sketches right out of the Arduino IDE. The USB plug is part of the PCB so the whole thing is really tiny. It's hard to get a concept of how small it really is by looking at photos, but perhaps this will help give some perspective:

It's the size of a typical USB memory stick! I spent many, many late nights labouring over Eagle laying out the PCB trying to cram it all into the smallest space possible, and it's a seriously tight PCB. After long sessions working in Eagle with everything zoomed way in close I'd start to lose perspective on just how small it is, and every now and then I'd have to sit back, print out a hard copy of the PCB at 1:1 scale, and re-orient myself. Part of the reason for the cram-job was because we kept coming up with ideas for new features to add to it, so this isn't just equivalent to a full-size Arduino: it does more than a typical Arduino. Check this out:

We combined the power, TX, and RX LEDs onto different elements of a single RGB LED, which gives a really cool effect with the colour changing as you communicate with it via USB. We also replaced the normal single-colour LED connected to pin D13 with an RGB LED, so you not only get the usual red output on D13 but you also get green on D9 and blue on D10.

Then we added a Piezo module on the bottom so you can play sounds directly from the LeoStick without having to plug anything else in. It's ready to produce RGB light and sound output straight out of the box.

We're really proud of the end result, and there are already a bunch of people doing cool things with it. Within hours of them being distributed at linux.conf.au there were people using them to do things like play the "Raiders of the Lost Ark" theme on the Piezo speaker, and even to create a Morse code sender that takes text messages via the serial console and outputs them as Morse. We also saw one that had the connection to the Piezo cut and remapped to an analog input so it could be used as an input device to detect knocks and claps.

We can't wait to see what other things people do with the LeoStick, so please check it out and share your projects over on our forum!

Freetronics LeoStick product page

Freetronics LeoStick forum section

Fabricatorz: Wise Futures and Shared Hardware, Part II

Sun, 08 Apr 2012 00:00:00 +0000

If I were to write an allegory of the computer manufacturing industry in "Greater China", I might be tempted to call it Pingguo and Shanzhai.

Pingguo（蘋果）is the nickname by which Apple Computer is known in China. Its partner Foxconn (a Taiwanese company by the way) is the largest electronic component manufacturer in the world and the largest private employer in the PRC. Foxconn is the pinnacle of industrial scale electronics manufacturing in the Pearl River Delta (and, indeed, the world); and Apple would not be the Apple of today without Foxconn, and China.

Shanzhai（山寨）are the noble bandits of our little allegory: small-scale black market manufacturers who skirt regulations and quality control to produce affordable, relatively low yield, but surprisingly diverse electronics. (I should point out that these innovations were enabled by another Taiwanese company, Mediatek, which sells development kits that many Shanzhai products, such as mobile phones, are built on top of.)

Pinguo and Shanzhai are the well-known protagonists in the technological and social drama of the computer manufacturing industry that straddles the Taiwan Strait. But neither Pinguo nor Shanzhai tell the story of the kind of technology that I want in my life, or that I want to base my business on.

For me the real inspirational story is that of Qi Hardware. Qi Hardware is innovation built not at the cost of billions of dollars and legions of anonymous workers (Pingguo), nor at the cost of questionable legal and safety practices (Shanzhai). Rather, Qi Hardware is a collective dedicated to sharing knowledge, experience and technology, and represents the kind of wise future[1] I am looking to achieve.

In discussing Qi Hardware I am constantly looking for a language to describe this new style of innovation. I am reluctant to call it 'open' hardware for reasons I have already explained; and calling it 'copyleft' hardware (in contrast to 'copyright') puts too much emphasis on the legal underpinning.

I finally settled on the term 'shared' hardware to describe what I feel captures the spirit of the movement. By sharing, Qi Hardware aim to lower barriers to innovation, as well as to profit and pump out genuinely cool technology!

Let's keep telling this story.

Notes

[1] wise futures - I came by this term by listening to public talks by Rob van Kranenburg and Adam Greenfield in Taipei in February of this year. You can read Part I here.

The first photo in this post is of the Milkymist One, which I shot in my studio a couple of weeks ago. The second photo is of Adam Wang, when I visited him in Taipei, where he tests and assembles the Milkymist.

Video Circuits: Peter Chamberlain: Works

noreply@blogger.com (Chris) — Sat, 07 Apr 2012 09:43:21 +0000

1983 Peter Chamberlain
thanks to ode2oddvideo

Video Circuits: FALSE AWAKENINGS Celeste Byers

noreply@blogger.com (Chris) — Sat, 07 Apr 2012 09:35:52 +0000

VIDEO BY CELESTE BYERS

MUSIC BY DISAPPEARING PEOPLE
SCOTT JOHNSTON & LANDON BATES

FILMING ASSISTANCE BY

MIKO REVEREZA & DREW FEHLMAN

Video created using live action time-lapse photographs. I animated and edited in AfterEffects, then filmed the digital file on VHS

Freetronics: EtherMega giveaway on The Amp Hour podcast

Sat, 07 Apr 2012 06:19:16 +0000

Want a free EtherMega? Of course you do!

Marc and I are big fans of The Amp Hour podcast by Dave Jones and Chris Gammell, and when Chris made a comment in episode 85 about wanting to run some kind of contest or giveaway it seemed like a great way to support the show.

So, in episode 89 they put out the call: anyone who emails in a candidate for the Chip Of The Week segment will go in the draw for a Freetronics EtherMega (Arduino Mega2560 compatible) board with built-in Ethernet!

I won't give you all the details here of how to enter, because then you won't have to listen to the show ;-)

For all the info head on over to Episode #89: Dissimulated Demigration Dontopedalogy. Don't just listen for the contest though - it's a fun show so make sure you check it out!

Freetronics: Clock One project by John Boxall

Sat, 07 Apr 2012 03:46:26 +0000

John Boxall has been working on another very cool project, this time using our Dot Matrix Display (DMD) panel, which is a 32x16 LED array. He's created a slick display that uses a combination of an "analog" clock face plus text for the day and date. Watch the video to see the clever border that steps along one LED every second. It really looks stunning:

Read all the details on John's blog:

http://tronixstuff.wordpress.com/2012/02/02/project-clock-one/

Freetronics: Playing games on the Dot Matrix Display

Sat, 07 Apr 2012 03:45:50 +0000

The always-inventive Chris Debenham has used our 32x16 LED Dot Matrix Display panels in a very creative way: he's linked them together so that one is up the right way and the other is upside down, and modified the driver library to support inverted displays - all so the cabling would be more convenient when mounting one above the other instead of side by side!

But that was just the start. To really knock our socks off, he then used the resulting enormous 32x32 array (that's 1024 LEDs) as a display for games running on an Arduino, including Snake, Pong, Breakout, and Race. This is amazing:

Wow, nice work Chris! Check out all the details on his blog:

Freetronics DMD - Games

Freetronics: Sneak peek: white 32x16 LED Dot Matrix Display panel for Arduino

Sat, 07 Apr 2012 03:45:06 +0000

Our red 32x16 LED Dot Matrix Display Panel for Arduino has been very popular, but we've always wanted to do other colours too. Unfortunately the economics of LEDs means that red is by far the cheapest to buy, and when each panel has 512 LEDs even a slight increase in per-LED price has a big impact on the build cost. Nevertheless we really want to do it, so we prototyped a few other colours including yellow, blue, green, and white.

We gave a white prototype to our friend John Boxall of Tronixstuff fame, and he's made a funky video showing how cool it looks:

In the YouTube description John says:

"This example is being powered by the Arduino and therefore at low brightness. It was too bright to film when using external power - my camera just couldn't deal with the sheer intensity of the display. You have to see it to believe it."

Transmaterial: Terrazzo Lumina

Fri, 06 Apr 2012 14:00:09 +0000

Terrazzo Lumina Slabs and Tiles are refined concrete surfaces designed to propate and emit light. Illumination travels within the concrete via embedded light-guides and is emitted in pixelated form. The manufacturing process is quite flexible and various geometries and configurations of light terminals are possible. The placement of the light source relative to the emitting surface is also flexible (and serviceable), making the product versatile for use in bar tops, flooring, wall features, and infrastructural projects.

Contact: SensiTile Systems, Ypsilanti, MI, USA.
Find more information in Transmaterial 3.

OggStreamer: #oggstreamer Rev1.0b Gerberfiles published

Fri, 06 Apr 2012 11:29:29 +0000

The Rev1.0b PCBs look like the are working as they should – So it is time to publish the Gerberfiles as well, they are put in the pcb-design Repository of this project on Sourceforge. These files are licensed under CC SA-BY 3.0 and there is no warranty or liability or whatsoever.

Note that the some values of Rs and Cs already have changed (see Ticket #46) – these changes are reflected in the current Stückliste (partslist) but they are not reflected in the current Rev1.0b schematics neither in the BOM.

And be aware: It is most likely that some more adjustments around the OPA is going to happen. – and maybe I will flag the Output-Stage as optional.

OggStreamer: #oggstreamer Protocol defined for XPortPro => STM8 Communication

Thu, 05 Apr 2012 22:28:25 +0000

The firmware of the STM8 needed some enhancement in order to provide more controlling options for vorbis quality-settings and samplerate. I decided to implement a simple one-byte protocol. The specification for the protocol can be found on the wiki.

I also implemented the protocol today and now the STM8-Firmware can be considered something like RC1

Crypto Stick: Purchase Crypto Sticks with Bitcoins

Thu, 05 Apr 2012 04:19:31 +0000

Because the popular online payment solutions are expensive and privacy-unfriendly, we are happy to announce Bitcoin as a new payment method. From now on you can purchase the Crypto Stick in our online shop by paying with Bitcoins. Enjoy.

Free Electrons: Experiment with Yocto

Wed, 04 Apr 2012 21:24:17 +0000

I recently had the opportunity to use Yocto. I already practiced quite a lot with OpenEmbedded before. You can see Yocto as a project derived from OpenEmbedded even it is a bit more than that.

In fact, Yocto is made of Poky (a build system based on OpenEmbedded), a few added build tools (swabber, pseudo, etc.), as well as a set of meta data allowing to create embedded distributions for a number of targets.

The strength but also the weakness of OpenEmbedded is that it a very flexible build system. It can make production root filesystems, but also a complete distribution with its ready to use package repository, and this for multiple hardware platforms. It makes it a difficult system to get started and get efficient with. Even two years ago, the OpenEmbedded documentation contributed to making it difficult to get started. Indeed, OpenEmbedded did supply some documentation, but which only started to make sense once you start mastering it. This is quite a paradox for a piece of documentation. It lacked the elements allowing developers to understand its operation well.

With Yocto, I was pleased to realize that substantial progress had been made on this side. The project comes with documentation that is much more exhaustive and above all much more accessible for beginners. Getting started with it is still not completely straightforward, but this time, this is rather because of the complexity and the rich features of the tool.

In a few hours, I managed to develop a minimalistic BSP (Board Support Package) for a given board (in this case a AT91SAM9G20-EK). The concept of layer allows to have a configuration layer specific to a given piece of hardware. You can even support multiple hardware platforms at once and add specific packages. A layer is indeed just a set of packages and configurations (or configuration overrides). The BSP is just a layer specific to one or several pieces of hardware.

As you can see, even to support a simple embedded board, there is already a number of concepts to deal with. There are also multiple ways of achieving the same result but which will be easier or more difficult to maintain. The concept of “BSP” for Yocto is therefore a kind of guideline to allow the Yocto community to have a common point of reference. I will try to illustrate the use of a BSP on the AT91SAMG20-EK board here and/or on my Google+ page.

Another significant progress is optimizing build time for a “minimalistic” target, which went down from more than three hours to just over one hour now. It remains a long time for a very simple target.

To build a filesystem image with only a few components, Buildroot remains much more appropriate. For systems that require a great number of components, more advanced functionality is then often needed, such as managing a package repository and supporting multiple hardware platforms at once for example. In this case, Yocto remains the best (the only?) option, all the more as this project addresses the traditional weaknesses of OpenEmbedded.

Free Electrons: Embedded Linux Conference 2012 videos

Wed, 04 Apr 2012 20:15:12 +0000

The 2012 edition of the Embedded Linux Conference took place on February 15-17th 2012 at Redwood Shores near San Francisco in California. Three engineers of Free Electrons attended this conference, and we reported every day our impressions about the talks, see our blog posts for day 1, day 2 and day 3. We have now taken the time to encode all the videos we have recorded during this event, and are proud to distribute them today.

It is worth noting that for the first time, the Linux Foundation was also recording videos of the talks, the Linux Foundation videos are available from video.linux.com, and we included links to these videos below for the different talks.

We hope that those of you who couldn’t attend the conference will enjoy those videos, with many great talks on technical embedded Linux topics.

Jon Corbet
Editor at LWN.net
The Kernel Report
Slides
Linux Foundation video
Free Electrons video (53 minutes):
full HD (525M), 450×800 (154M)

Loïc Pallardy
Saving the Power Consumption of the Unused Memory
Slides
Free Electrons video (46 minutes):
full HD (378M), 450×800 (125M)

Bernhard Rosenkränzer
Linaro
What Android and Embedded Linux Can Learn From Each Other
Slides
Linux Foundation video
Free Electrons video (40 minutes):
full HD (370M), 450×800 (129M)

Ricardo Salveti de Araujo
Linaro
Ubuntu on ARM: Improvements and Optimizations Done By Linaro
Slides
Linux Foundation video
Free Electrons video (46 minutes):
full HD (301M), 450×800 (140M)

Zach Pfeffer
Linaro
Binary Blobs Attack
Slides
Linux Foundation video
Free Electrons video (50 minutes):
full HD (486M), 450×800 (157M)

Hisao Munakata
Renesas Electronics
Close Encounters of the Upstream Resource
Slides
Linux Foundation video
Free Electrons video (37 minutes):
full HD (394M), 450×800 (121M)

Daniel Hursh
IBM
Open Source Automated Test Framework
Slides
Free Electrons video (45 minutes):
full HD (303M), 450×800 (132M)

Saul Wold
Intel
The Yocto Project Overview and Update
Slides
Linux Foundation video
Free Electrons video (54 minutes):
full HD (543M), 450×800 (171M)

Sean Hudson
Mentor Graphics, Inc.
Embedded Linux Pitfalls
Slides
Free Electrons video (51 minutes):
full HD (483M), 450×800 (176M)

Vincent Guittot
Linaro
Comparing Power Saving Techniques For Multicore ARM Platforms
Slides
Linux Foundation video
Free Electrons video (57 minutes):
full HD (307M), 450×800 (154M)

Tim Bird
Sony Network Entertainment
Status of Embedded Linux
Slides
Linux Foundation video
Free Electrons video (49 minutes):
full HD (492M), 450×800 (159M)

Bruce Ashfield
Wind River
A View From the Trenches: Embedded Functionality and How It Impacts Multi-Arch Kernel Maintenance
Slides
Free Electrons video (54 minutes):
full HD (741M), 450×800 (222M)

R Durgadoss
Intel
PeakCurrent Management in x86-Based Smartphones
Slides
Linux Foundation video
Free Electrons video (50 minutes):
full HD (296M), 450×800 (141M)

Matt Porter
Texas Instruments
Passing Time With SPI Framebuffer Driver
Slides
Linux Foundation video
Free Electrons video (54 minutes):
full HD (565M), 450×800 (172M)

Wookey
Linaro
Multiarch and Why You Should Care: Running, Installing and Crossbuilding With Multiple Architectures
Slides
Free Electrons video (42 minutes):
full HD (453M), 450×800 (143M)

Amit Daniel Kachhap
Linaro/Samsung
A New Simplified Thermal Framework For ARM Platforms
Slides
Linux Foundation video
Free Electrons video (41 minutes):
full HD (226M), 450×800 (115M)

Tsugikazu Shibata
NEC
On The Road: To Provide the Long-Term Stable Linux For The Industry
Slides
Linux Foundation video
Free Electrons video (32 minutes):
full HD (304M), 450×800 (95M)

Thomas P. Abraham
Samsung Electronics
Experiences With Device Tree Support Development For ARM-Based SOC’s
Slides
Free Electrons video (44 minutes):
full HD (509M), 450×800 (155M)

Paul E. McKenney
IBM
Making RCU Safe For Battery-Powered Devices
Slides
Linux Foundation video
Free Electrons video (52 minutes):
full HD (506M), 450×800 (186M)

Mike Anderson
Chief Technology Officer at The PTR Group
The Internet of Things
Slides
Linux Foundation video
Free Electrons video (50 minutes):
full HD (580M), 450×800 (186M)

Thomas Petazzoni
Free Electrons
Buildroot: A Nice, Simple, and Efficient Embedded Linux Build System
Slides
Linux Foundation video
Free Electrons video (56 minutes):
full HD (594M), 450×800 (182M)

Steven Rostedt
Red Hat
Automated Testing with ktest.pl (Embedded Edition)
Slides
Linux Foundation video
Free Electrons video (102 minutes):
full HD (1,2G), 450×800 (354M)

David VomLehn
Cisco
Intricacies of a MIPS Stack Backtrace Implementation
Slides
Linux Foundation video
Free Electrons video (52 minutes):
full HD (345M), 450×800 (153M)

Edward Hervey
Collabora
GStreamer 1.0: No Longer Compromise Flexibility For Performance
Slides
Linux Foundation video
Free Electrons video (49 minutes):
full HD (540M), 450×800 (174M)

Tim Bird
Sony Network Entertainment
Embedded-Appropriate Crash Handling in Linux
Slides
Linux Foundation video
Free Electrons video (49 minutes):
full HD (292M), 450×800 (142M)

Arnd Bergmann
Linaro
ARM Subarchitecture Status
Slides
Linux Foundation video
Free Electrons video (49 minutes):
full HD (416M), 450×800 (140M)

Mark Gisi
Wind River Systems
The Power of SPDX – Sharing Critical Licensing Information Within a Linux Device Supply Chain
Linux Foundation video
Free Electrons video (49 minutes):
full HD (498M), 450×800 (164M)

Yoshitake Kobayashi
Toshiba
Ineffective and Effective Ways To Find Out Latency Bottlenecks With Ftrace
Slides
Linux Foundation video
Free Electrons video (37 minutes):
full HD (251M), 450×800 (108M)

Ohad Ben-Cohen
Wizery / Texas Instruments
Using virtio to Talk With Remote Processors
Slides
Linux Foundation video
Free Electrons video (54 minutes):
full HD (582M), 450×800 (182M)

Elizabeth Flanagan
Intel
Embedded License Compliance Patterns and Antipatterns
Linux Foundation video
Free Electrons video (44 minutes):
full HD (391M), 450×800 (144M)

David Anders
Texas Instruments
Board Bringup: LCD and Display Interfaces
Slides
Linux Foundation video
Free Electrons video (40 minutes):
full HD (207M), 450×800 (113M)

Rob Clark
Texas Instruments
DMA Buffer Sharing: An Introduction
Slides
Linux Foundation video
Free Electrons video (35 minutes):
full HD (306M), 450×800 (100M)

Ken Tough
Intrinsyc
Linux on eMMC: Optimizing For Performance
Slides
Linux Foundation video
Free Electrons video (52 minutes):
full HD (468M), 450×800 (165M)

Paul Larson
Linaro
LAVA Project Update
Slides
Linux Foundation video
Free Electrons video (52 minutes):
full HD (366M), 450×800 (159M)

Frank Rowand
Sony Network Entertainment
Real Time (BoFs)
Slides
Free Electrons video (77 minutes):
full HD (924M), 450×800 (288M)

Mike Turquette
Texas Instruments
Common Clock Framework (BoFs)
Slides
Free Electrons video (53 minutes):
full HD (333M), 450×800 (148M)

Hunyue Yau
HY Research LLC
Userland Tools and Techniques For Linux Board Bring-Up and Systems Integration
Slides
Linux Foundation video
Free Electrons video (51 minutes):
full HD (407M), 450×800 (136M)

Matt Weber
Rockwell Collins Inc.
Optimizing the Embedded Platform Using OpenCV
Slides
Linux Foundation video
Free Electrons video (37 minutes):
full HD (388M), 450×800 (125M)

Greg Ungerer
McAfee
M68K: Life in the Old Architecture
Slides
Linux Foundation video
Free Electrons video (46 minutes):
full HD (452M), 450×800 (166M)

Gary Bisson
Adeneo Embedded
Useful USB Gadgets on Linux
Slides
Linux Foundation video
Free Electrons video (43 minutes):
full HD (402M), 450×800 (129M)

Jason Kridner
Texas Instruments
GUIs: Coming To Uncommon Goods Near You
Slides
Linux Foundation video
Free Electrons video (52 minutes):
full HD (476M), 450×800 (166M)

Mike Anderson
The PTR Group
Adapting Your Network Code For IPv6 Support
Slides
Linux Foundation video
Free Electrons video (63 minutes):
full HD (485M), 450×800 (216M)

Koen Kooi
The Angstrom Distribution
Producing the Beaglebone and Supporting It
Linux Foundation video
Free Electrons video (42 minutes):
full HD (398M), 450×800 (126M)

Danny Bennett
basysKom GmbH
HTML5 in a Plasma-Active World
Slides
Linux Foundation video
Free Electrons video (34 minutes):
full HD (258M), 450×800 (75M)

Marcin Mielczarczyk
Tieto
Getting the First Open Source GSM Stack in Linux
Slides
Linux Foundation video
Free Electrons video (54 minutes):
full HD (439M), 450×800 (178M)

Pierre Tardy
Intel
PyTimechart Practical
Slides
Linux Foundation video
Free Electrons video (32 minutes):
full HD (260M), 450×800 (86M)

Linus Walleij
ST-Ericsson
Pin Control Subsystem Overview
Slides
Linux Foundation video
Free Electrons video (60 minutes):
full HD (638M), 450×800 (200M)

Khem Raj
OpenEmbedded Project
OpenEmbedded – A Layered Approach
Slides
Linux Foundation video
Free Electrons video (39 minutes):
full HD (227M), 450×800 (108M)

Lucas De Marchi
ProFUSION Embedded Systems
Managing Kernel Modules With kmod
Slides
Linux Foundation video
Free Electrons video (46 minutes):
full HD (443M), 450×800 (140M)

Jean Pihet
NewOldBits
A New Model for the System and Devices Latency
Slides
Free Electrons video (49 minutes):
full HD (431M), 450×800 (146M)

Free Electrons: Android Builders Summit 2012 videos

Wed, 04 Apr 2012 19:57:35 +0000

On February 13-14th 2012, the second edition of the Android Builders Summit took place in Redwood Shores, near San Francisco in California. While Free Electrons was not officially in charge of video recording for this conference, we recorded the talks we attended and that we are glad to share below. The Linux Foundation has also recorded those talks (except a few of them for which they had technical issues), and we provide those additional links below. You can also follow our reports from day 1 and day 2 of this conference.

You’ll find below our videos of the main talks we recorded, and also the videos of the lightning talks that took place on the evening of the first day of the conference. Enjoy!

Main talks

Karim Yaghmour
Opersys
Leveraging Linux’s History With Android
Slides
Free Electrons video (32 minutes):
full HD (386M), 450×800 (107M)

Arnd Bergmann, Tim Bird, Greg Kroah-Hartmann, Zach Pfeffer, moderated by Jonathan Corbet
IBM/Linaro, Sony Network Entertainment, The Linux Foundation, Linaro, LWN.net
Panel: Android and the Linux Kernel Mainline: Where Are We?
Free Electrons video (38 minutes):
full HD (525M), 450×800 (156M)

Marko Gargenta
Marakana
Customizing Android
Slides
Linux Foundation video
Free Electrons video (50 minutes):
full HD (409M), 450×800 (131M)

Tetsuyuki Kobayashi
Kyoto Microcomputer
How ADB(Android Debug Bridge) Works
Slides
Linux Foundation video
Free Electrons video (33 minutes):
full HD (365M), 450×800 (100M)

Andrew Boie
Intel
Android OTA SW Updates
Slides
Linux Foundation video
Free Electrons video (61 minutes):
full HD (698M), 450×800 (189M)

Benjamin Zores
Alcatel-Lucent
Android Device Porting Walkthrough
Slides
Linux Foundation video
Free Electrons video (69 minutes):
full HD (534M), 450×800 (179M)

Jason Kridner, Khasim Syed Mohammed
Texas Instruments
Using Android outside of the Mobile Phone Space
Slides
Linux Foundation video
Free Electrons video (34 minutes):
full HD (414M), 450×800 (120M)

Tom Moss
3LM
The Android Ecosystem
Linux Foundation video
Free Electrons video (27 minutes):
full HD (267M), 450×800 (82M)

Karim Yaghmour
Opersys
Headless Android
Slides
Free Electrons video (50 minutes):
full HD (462M), 450×800 (145M)

Tom Foy
Intrinsyc
Android on eMMC: Optimizing for Performance
Slides
Free Electrons video (34 minutes):
full HD (234M), 450×800 (90M)

Wolfgang Mauerer
Siemens
Real-Time Android
Slides
Free Electrons video (59 minutes):
full HD (418M), 450×800 (155M)

Jim Huang
0xlab
Improve Android System Component Performance
Slides
Linux Foundation video
Free Electrons video (54 minutes):
full HD (457M), 450×800 (152M)

Rodrigo Chiossi
Samsung
AndroidXRef: Speeding up the Development of Android Internals
Slides
Linux Foundation video
Free Electrons video (38 minutes):
full HD (313M), 450×800 (108M)

Mark Brown
Wolfson Microelectronics
Towards a Standard Audio HAL for Android
Slides
Linux Foundation video
Free Electrons video (47 minutes):
full HD (227M), 450×800 (123M)

Jen Costillo
Topics in Designing An Android Sensor Subsystem: Pitfalls and Considerations
Slides
Linux Foundation video
Free Electrons video (36 minutes):
full HD (238M), 450×800 (101M)

Aleksandar (Saša) Gargenta
Marakana
Android Services Black Magic
Linux Foundation video
Free Electrons video (61 minutes):
full HD (410M), 450×800 (169M)

Lightning talks

Dario Laverde
HTC
HTC Dev
Free Electrons video (3 minutes):
full HD (44M), 450×800 (13M)

Robert McQueen
Collabora
Integrating GStreamer and PulseAudio in Android
Free Electrons video (4 minutes):
full HD (49M), 450×800 (16M)

Mark Gross
Intel
Android build times and host tweakage
Free Electrons video (4 minutes):
full HD (37M), 450×800 (13M)

Tony Mansson
Linaro
Painless debugging of native code in Android-based device (using DS-5)
Free Electrons video (4 minutes):
full HD (32M), 450×800 (13M)

Paul Arssov
ARS Technologies Inc.
How easy is it to support external hardware on Android platform
Free Electrons video (4 minutes):
full HD (33M), 450×800 (13M)

Karim Yaghmour
Opersys
Cyborgstack
Free Electrons video (4 minutes):
full HD (60M), 450×800 (18M)

Yahya Mirza
Aurora Borealis Software
Towards a heterogeneous application for compute driver performance testing and analysis
Free Electrons video (3 minutes):
full HD (47M), 450×800 (14M)

Joe Born
Sonrlabs
Sonr, Serial headphone interface and hardware
Free Electrons video (4 minutes):
full HD (38M), 450×800 (13M)

Richard Hughes, ColorHug: colord-kde 0.2

Wed, 04 Apr 2012 11:30:03 +0000

Daniel released colord-kde 0.2 today. I’m really excited about the amount of progress he’s made in such a short amount of time. He’s has had a bit of rough ride with the loss of his daughter last year and this year he’s been hacking on colord-kde and PackageKit and trying to make open source a better place. If you’ve got a spare couple of dollars this month, he’d really appreciate a donation to buy hardware to test things on.

I was a strapped-for-cash geek myself a few years ago, and I know how hard it was to develop software when you don’t have the right hardware. I donated $25. Donate here. Thanks.

Kristian Paul: Congreso Itinerante by Free Software Foundation de Ecuador

Tue, 03 Apr 2012 22:14:33 +0000

/tmp/mutt-micro-1000-16715-896461972901d8d8fb0.html I'm going to give a talk about Copyleft Hardware, by April 11 at
Instituto Superior de Pedagogía, not too much info yet, just in case you
are at Ecuador at that time may be of you interest.

More info coming at http://softwarelibre.info/ (Agenda)

OggStreamer: #oggstreamer 12 Frontpanels produced

Tue, 03 Apr 2012 16:54:41 +0000

This morning I fetched the cnc-punched alu-cases from Johann, who did a great job concerning the mechanical work. Building the frontpanel, involves two main tasks:

deflashing of the punched holes
gluing the LED-PCB on the backside of the Frontpanel.

For the 2nd task I am using a transparent hot glue. In order to get a nice and plane look I put the Frontpanels on a glas plate first, mount them together with some handy little tools i don’t know the name of – then I quickly cover all the LED holes with plenty of hot glue (be sure the hotglue-gun is well heated) and in time I press the LED-PCB into the still liquid hot glue – after that I put the glasplate and frontplate into the freezer (-18 °C) for just 5 Minutes, which proved out to be a good number for descent results. It turned out that the results are better if I just swift of the glasplate (instead of using Spiritus), because if the hotglue doesn’t stick to well on the glass the frontpanel comes of more easy. If the finish of the so created light-guides doesn’t look smooth it can be reworked it with a hotair-gun, (but not to long)

Before trying this “hot glue”-technique, I was considering 3D printing the Lightguids with transparent PLA. But I think the hot glue-result is way better than I could print it our Prusa Mendel – Printing a plastic by layers also might have some effects on diffusion. Also the meltingpoint of the used hotglue (200 °C) is siginficantly higher than PLA (130 °C)

Village Telco: Meshed Potatoes

Tue, 03 Apr 2012 15:30:59 +0000

The following is a guest post from Carlo Nizeti and Glen Steedman. They’ve been doing some performance testing with the Mesh Potatoes. This is a re-post from their Nerd Polytechnic site which is worth checking out. Nerd Polytechnic is a technology collective in Sydney, Australia that gets together once a month to explore technology for the pleasure of finding things out.

Today was mesh day! Finally we had a few hours free to all get together and do some long distance mesh potato testing. There was a lot going on during the day, and we did some different tests so let me setup things by giving you details of the test environment and what we looked to get out of it.

The test we had in mind was to see how far we can throw decent signals with our stock mesh potato units. We have been playing with them in the confines of a single room for a while now and have them singing and dancing but out in the real world what kind of distances can we get. The ideal way for us to start was to challenge the god’s of wifi and set up our 3 units in a way where they had good spacing apart, and only two units could see each other at a time.

Site A was in Dee Why, being manned by Glen and Dave. This is where we started in the morning to do our testing. Site B was at Long Reef headland, manned by Geoff. Site C was in Collaroy, manned by Carlo. The idea was to get fairly equal spacing between us, but have site B as the man in the middle to mesh Collaroy and Dee Why together. We had 2meter amateur radio handhelds to use for comm’s (with Geoff acting as relay) until we had the mesh up and running for voice.

The setup was the same at each site, a Mesh Potato on a stick of some kind (Squid Poles), Analogue phones for voice and laptops for running network performance testing (iperf / jperf).

Setup

The prius is a little RF noisy, but it is a great car for field work. Very considerate of toyota to place a good quality battery in the back with a flat working surface and a good hatch back for sun protection.

Getting setup wasn’t too painful. All three units are using slightly different methods of power connection which is good for experimentation. The only hiccup was one mesh (the one I was holding onto) had a slightly different firmware to the other units, which may or may not be the reason why it didn’t want to mesh with the other two units. Glen re-flashed my unit with the same software and that resolved the issue. In field use it would be likely that we would all have the same code so no biggie on that one. One thing that we have noticed is flashing the units from a ubuntu virtual machine (with vmware fusion) can throw some funny errors, this time around it didn’t slow us down but it seems a switch in the middle of the equation may see the flashing process work better.)

Glen and Dave had site A up and running very quick. Located at the headland car park it was also one of our most visible sites. The guys got asked a few questions by the locals, some of which jokingly asked if we were installing the NBN. We of course answered yes whilst poorly attempting to hold a deadpan face (We recently found out our suburb’s are not included in the 3 year roll out plan…).

Site A – Dee Why

Site B – Long Reef Headland

Site C – Collaroy Beach

Testing & Results

So the plan was to get the mesh up and running, and once we could ping each other run some tests. Site A and Site B were around 2.1 km apart and connected up. Site B and Site C never connected even after the power was bumped up.

Here you can see the single node connected on the other side, along with Dave’s Mac connected up as a client.

Site A and Site B were able to chat away on the analogue phones with a little crackle and line quality issues. Glen being the resident voice comms guru tried a few different codec’s to see if he could improve the voice quality, but it seems most of the issue was the underlying link quality.

Glen making a voice call to Geoff at Site B. A member of the public was heard to be explaining to their companion that they had some idea of what we were up to until the point where Glen starts to make phone calls with an analogue phone.

The link speed bounced around a little too. It didn’t like TCP packets much, but could handle UDP packets much nicer.

Between Site A and Site B the maximum throughput was around 1Meg, but as you can see with the first image below it was short lived. The average generally was closer to between 250 – 500 KBit’s. Remember this is over a 2.1KM link with 2 standard mesh potatos with no external antennas etc etc. For the test Site A was connected to the Mesh Potato via Ethernet, but Site B was connected via wifi.

Dave did some other testing, here you can see ping results from his mac to Geoff’s PC. Not a bad response time when both computers where connected to their respective Mesh Potato’s via wifi. Dave’s Mac could also see Site B’s Mesh Potato in its wireless list, but he couldn’t connect to it.

Glen noticed a failure of the link at one stage during the testing, after looking up he quickly established a potential cause. This little guy really wasn’t too interested in giving up his vantage point.

So what did we learn?

That these things are great radios, and we took them to the edge of their performance today. 2.1km out of a little wifi AP is a great result, and we are very happy with the results. The main lessons learned could be summarised as

When operating in the field make sure all your units are on the same code.
2.1KM is a great result, but ideally these units would be placed closer together or have external antenna’s to improve gain.
Field operation probably takes a little more preparation on the testing we where going to run. Next time we do a prep hour or so indoors in ideal conditions testing the commands we are going to run and how we are going to record the results.

Things to try / improve

Run some more controlled area tests to figure out the max throughput of these units.
Make a prepared list of commands to run directly from the mesh. (Ie, Horst for wifi noise and wlan connection speeds between mesh units)
Same test as last time, but place Site C in the middle of Site A and Site B. That way we can see how the units mesh, and if they choose the faster path correctly.
Create a cheat sheet of commands, numbers, IP’s and passwords.
Figure out if we can write some scripts to query the units and dump results.
Do a debrief immediately after the tests to get it all down.

Lab Results

Glen ran some tests between his two units across his apartment and found that he could move 15mbit of traffic, so the hardware it self is great.

Here you can see the results Glen got when he did some two way tests between two computers connected to individual mesh potatos that had meshed together. As you can see they can get a very decent throughput, this is 15MBits both way with minimal jitter. Obviously they are in the same room but it shows the hardware is capable of nice things.

Ideal scenario, this is the results from Lab testing

Anyway it was a great day out, we had a lot of fun and it was great to nerd it up in the sun.

http://nerdpolytechnic.org/2012/04/meshed-potatoes/

Free Electrons: A new tool to ease kernel maintainer life

Mon, 02 Apr 2012 19:53:47 +0000

When you are involved in mainlining or maintaining some kernel code, a non negligible part of your time is spent checking patches or patchsets themselves . It is not the most interesting part but it is truly necessary to help merging in kernel code, or to make sure you don’t break anything, for example building with an incompatible configuration.

Aiaiai developed by Artem Bityutskiy is a tool to do most of this task for you! It uses other checking tools and scripts such as sparse, coccinelle and checkpatch.pl, and comes with its own set of tools and scripts. I don’t know what does “aiaiai” stands for, but in French it sounds like “Ouch Ouch Ouch”, the sound you could make if you forget to use this tool

PS: On my G+ post, Yegor Yefremov pointed that “aiaiai” means something like “tsk tsk!” (shame on you!) in Russian.

OggStreamer: #oggstreamer New Streaming Server sighttpd

Mon, 02 Apr 2012 09:42:17 +0000

I was trying really hard to get the IceCast-Server working under the XportPro-uclinux buildsystem but after more than a week of work I ended up in desperation. And I dropped the Idea of running an instance of IceCast-Server on the Device itselfs. – Of course support for upstreaming to an IceCast-Server still remains. That’s the bad news. But the good one is that I found a sleek little Streaming-Server, that just does the job as it should. It only took a few hours and the sighttpd – Server by Conrad Parker was up and running. First tests show that this Server should be able to serve around 20 Listeners directly (for really high bandwith vorbis; tested with 350kbps).

Building sighttpd is a great choice for embedded systems, as it only depends on LibOgg and LibOggz, whereas IceCast (at least) needs LibOgg, LibVorbis, LibShout, LibXML2, LibXSLT. May be it was the number of dependencies that complicated my attempts to get IceCast running. In fact it compiled just fine – but for some reason in this configuration pthread_create just didn’t work as it should… sighttpd also uses pthreads – but no problem with this configuration.

So let’s stick with sighttpd

GNU Radio Blog: RTL2832U based software defined radios

oz9aec@gmail.com (Alexandru Csete) — Mon, 02 Apr 2012 09:20:41 +0000

You may have noticed the recent buzz on the internet about using cheap DVB-T dongles as software defined radio receivers. It all started on this mailing list when V4L/DVB kernel developer Antti Palosaari discovered that the ezcap EzTV 668 DVB-T/FM/DAB USB dongle, which is based on the RTL2832U chip, can be used to stream raw I/Q samples to the host computer. It is in fact the way the device supports FM and DAB reception; raw I/Q is sent to the host where the application does the demodulation.

Once this was discovered it didn't take long before Steve Markgraf of OsmoSDR created the rtl-sdr package that could be used to tune the dongle and dump I/Q data do a file for post processing. A few weeks late later Balint Seeber could announce the existence of an rtl_source_c GNU Radio block in his gr-baz package.

Obviously, I had to get one myself.

I followed the link on the OsmocomSDR page and ordered a few pieces from Dealextreme. I got an email on March 22 saying that order has been created and payment confirmed but nothing since then. Anyway, since I have a natural born suspicion against sites with such bombastic names, I decided not to rely on a single source and tried to order a dongle from another place. Thanks to @uhf_satcom I found out that CosyCave also sells the EzTV 666 and at £9.50 incl. VAT it is even cheaper than the $20, to which I will have to add about 150% duties and VAT. Okay, I admit that a web shop that sells herbs, medicine and a DVB-T dongle is not much less fishy than something called Dealextreme... but I can tell you now that they shipped very fast and since it came from the UK I have received it within 4 working days.

It is really amazing how much crap you get for £9.50: A DVB-T dongle, antenna, remote control and even a CD with software:

Finally, a few close-ups of the dongle:

As you can see the EzTV 666 comes with the Elonics E4000 tuner chip. As you can see there is not much info about this tuner besides some basic properties and a generic block diagram of a direct conversion I/Q demodulator.

The RTL2832U seems to be more common than one would think. About a year ago I bought a DVB-T dongle in a local supermarket here in Denmark. The brand is called AGK and it worked well on windows but I never got it to work under Linux so I threw it in a drawer where it has been until now. I decided to open it up and take a look at what is inside.

Surprise, surprise! An RTL2832U chip:

The tuner, however, is something called FC2580 from a Korean company called FCI:

As with the E4000, there is not much data available but is appears to support similar frequency range, i.e. cover both VHF and UHF up to 1.7 GHz. Once I get my EzTV 666 (and 668?) working, I will also try this one. It does look like I am not the only linux hacker interested in the RTL2832U+FC2580 combination, see for example this repository on Github.

In the meantime there is a compatibility list in progress over at Reddit.

GNU Radio Blog: Gqrx and Pulseaudio

oz9aec@gmail.com (Alexandru Csete) — Sat, 31 Mar 2012 14:06:29 +0000

Just a quick note that Gqrx now uses pulseaudio for all audio I/O, which includes I/Q input from the Funcube Dongle.

The pulseaudio source and sink block have existed for some time now in a dedicated branch. Although it still needs testing and improvements I have decided to merge it into the master branch since pulseaudio is the way I want to go with gqrx.

Using pulseaudio allows better integration of gqrx into the linux desktop because pulseaudio is the default audio system used by most linux distributions today. Users can notice that gqrx now appears as a recording and playing application in the audio settings window.

The coolest thing, however, is that when gqrx uses pulseaudio for output, applications that use pulseaudio for capturing can be configured to capture the output of gqrx! The screenshot below shows the Masat-1 telemetry decoder configured to capture the audio output from gqrx (or anything else that plays on the main audio output):

The last screenshot shows Fldigi being connected to the output and decoding Morse code:

One can also do more advanced audio routing – even over the network. Unfortunately, the pulseaudio user manual is practically non-existent, so I don't know if anybody has a clue how to do such things :o)

Village Telco: Introducing the FitVT Part 1

Fri, 30 Mar 2012 15:08:55 +0000

After a few months working in our labs we want to introduce you to the FitVT, our low cost/low power server for the Village Telco based on FitPC2i low power computer.

After testing different low power solutions based on commodity laptops, we discovered the FitPC ¹. The Fitpc2i comes with two Gigabit network interfaces and the CompuLab SBC-FITPC2 series board that uses a fanless Atom Z550 32bits CPU.

In most of the scenarios the VT server will sit behind a village telco super-node and the Internet. Although we have tested commodity laptops using a USB-Ethernet converter as second interface, we have seen very bad performance in the data transfers of some USB dongles (USB 1.1). So if you plan to provide also Internet access from the mesh nodes, consider a solution with two built-in network interfaces.

Installing Ubuntu 10.04 in the fitpc2i ² was as easy as installing Ubuntu in any other computer. Use a bootable USB image or attach an external USB-CD Drive. Just make sure that you choose a 32 bits image as the Atom CPU runs 32 bits.

In our laboratory we have tested the Fitpc2i with a Intel(R) Atom(TM) CPU Z550@ 2.00GHz ³ and 2 GB of RAM. The unit runs at 35-40 C when idle so make sure that you do not forget it under a pile of books as I did. There are at least two revisions of this hardware but the process of installation should be the same.

CompuLab, the company behind the FiTVT provides support for Linux Mint as the hardware seems to be targeted to those that want to run a nice multimedia station at home (i.e. stream audio/video obtained from good friends to a television). We warned that the unit does not come with VGA output and has a DVI Digital output up to 1920 x 1200 through HDMI connector instead, so you will need a LCD/TV screen with HDMI or DVI input to connect the FitPC.

There are two useful accessories that you can consider, an analog VGA converter is powered from the DVI port and requires no external power source and the external heat-sink.

The main glitch in the installation process is that the stock kernel that ships with Ubuntu 10.04 has buggy R8169 network driver that has broken auto-negotation. In my case, only one of the interfaces was able to negotiate the speed, while the other interface required the ethtool to force the speed to 10 Mbps. Fixing the speed of the second card to 10 Mbps was the only solution so as you can upgrade your kernel.

Once you upgrade the kernel from version 2.6.32-33 to 2.6.32-38 you will discover that the DADHI drivers that are used Asterisk are now broken and you will have to rebuild them. The DADHI drivers depend on kernel version (i.e. wrong symbols). In a nutshell, in order to get the network cards to work you will have to (1) upgrade your kernel and (2) rebuild DADHI Asterisk drivers.

In the second part of this article we will describe how to get the Village Telco software bundle installed.

1 http://www.fit-pc.com/web/fit-pc/fit-pc2i-specifications/

2 http://www.fit-pc.com/wiki/index.php/Fit-PC2i_Revisions

3 http://www.cpu-world.com/CPUs/Atom/Intel-Atom%20Z550%20AC80566UE041DW.html

Transmaterial: Coco Tiles

Fri, 30 Mar 2012 14:00:34 +0000

Made from reclaimed coconut shells, low-VOC resins and sustainably-harvested wood backer material, Kirei Coco Tiles may be used as decorative tiles or panels both horizontally and vertically. Featuring multiple pattern and color combinations and available in light, dark and mixed textures, the coconut shell tiles create a variety of surfaces and enhance the sustainable material palette in residential, commercial, and hospitality applications.

Contact: Kirei, Solana Beach, CA, USA.
Find more information in Transmaterial 3.

Open Hardware Repository: FMC DEL 1ns 4cha - 15 V3 boards built

Erik.van.der.Bij@cern.ch (Erik van der Bij) — Fri, 30 Mar 2012 11:23:05 +0000

Open Hardware Repository: PPSi - PPTP is dead, long live PPSi

rubini@gnudd.com (Alessandro Rubini) — Thu, 29 Mar 2012 13:59:33 +0000

Open Hardware Repository: EtherBone Core - EtherBone goes BETA

m.kreider@gsi.de (Mathias Kreider) — Tue, 27 Mar 2012 12:28:16 +0000

Bunnie Studios: Name that Ware March 2012

Tue, 27 Mar 2012 07:55:05 +0000

The Ware for March 2012 is shown below.

Been on the road in China this past month, so I snapped this one with my camera while on the go!

Bunnie Studios: Winner, Name that Ware February 2012

Tue, 27 Mar 2012 07:54:54 +0000

The winner of Name that Ware February 2012 is mangel, for correctly guessing the ware as a BBN Safekeyper box, CP1 Series, c. late 1992. Congrats, and email me for your prize!

Thanks again to Ben for contributing this rare look inside such an interesting box!

Fabricatorz: New Milkymist Action Shots

Tue, 27 Mar 2012 00:00:00 +0000

There isn't much video out there that does the Milkymist justice, an unfortunate circumstance because it really is an impressive little machine. In an attempt to remedy this Barry and I recently shot some video with the hopes of mirroring the representation of the Milkymist with it's actual ability. We (actually, I, since I'm the one responsible for the editing) fell well short of this mark. But despite the poor editing (I haven't edited video since the VHS days!) and poor image quality (who knew high-quality video required so many damn GB's?), you'll get to see how non-intimidating the set-up is and how fast this little guy can get a party started.

The drum clips are meant to demonstrate the Milkymist's integration with electronic instruments and external sound, both of which stimulate the visuals when plugged directly into the Milkymist or intercepted via the onboard microphone. And the club shots, well, those are testament to the Milkymist's party credibility. We actually smuggled the Milkymist into that particular party at a warehouse-like venue in San Francisco's Mission District, then set it up guerrilla-style and proceeded to project on the walls and dance floor despite the fact that there was already a house VJ. I was actually surprised how well our slapdash performance compared. During the short 15 minutes we were there the crowd turned away from the DJ and VJ projection on the far wall and towards each other in the middle of the room where we were projecting. The dancing and interaction intensified, and at one point one of the VJ's assistants came over all starry-eyed and intrigued.

I have to say, I was a bit skeptical about the Milkymist until I saw it in action. It has some incredible psychedelic and dynamic capabilities that will only continue to expand. Keep your eyes peeled, kids.

Footage here: http://downloads.qi-hardware.com/people/bonewolf/ and more to come.

Richard Hughes, ColorHug: Building GNOME For Fedora 17

Mon, 26 Mar 2012 15:26:33 +0000

At the moment the GNOME updates in Fedora are a bit of chaotic affair. They mostly work, but only because of people like Matthias who spend hours and hours building packages and putting everything together manually.

For 3.3.92 I experimented doing a mega-bodhi-update and trying to get all the 3.3.92 builds in one place, and working with other people on a google spreadsheet to make sure everything was built in good time, and nothing was left behind.

For the GNOME 3.4.0 release, I’m asking people to copy this pattern, and try to get all the builds into *one* update rather than 90% of the builds in one mega-update and then 10% in random updates that other people have filed. If this works, I’m intending to do the 3.4.1 update as one update as well.

TL;DR. If you’re packaging a GNOME package that’s just had a 3.3.92 upstream release and is about to have a 3.4.0 release, please build the package like normal, but don’t file an update. Instead add the build ID to the spreadsheet and then I’ll pick up the build for the mega update for F17. Hopefully this makes the updates system easier to QA, as GNOME is more and more interconnected, and it’ just not possible to QA updates when you have a 3.3.91 version of gnome-settings-daemon and 3.4.1 version of gnome-screenshot.

Free Electrons: Android gdbclient command

Mon, 26 Mar 2012 07:56:02 +0000

Before you even start building Android, Google’s instructions tell you to source the build/envsetup.sh shell script.

This script exports a number of environment variables (that’s why you have to source it), mostly setting the PATH to your different toolchains and to your output directories.

It also defines a number of shell functions. Among them some functions are advertised, like the well-know lunch, that is used to configure to some extent the build system, or the grepping functions, but some are not, like pid, which uses adb to get the PID of a process running on the device.

Among the latter, one seems pretty useful: gdbclient. What gdbclient does is obviously gdb related but in fact it does more than that.

First, you run it by doing gdbclient <binary>:<port> <process_name>

Then it sets up adb with the forward command so that you use it as a transport layer to your device, while it appears as (in that case) opened TCP sockets both on your machine and on the device.

Then, it attaches a gdbserver to the process you gave as the third argument on the device.

Finally, it launches your cross-gdb on your workstation, loads the debugging symbols from the file passed as first argument, and sets up a remote debugging session. All of that through USB!

This is definitely useful, and I can’t say why Google doesn’t advertise it more, but hey, it’s there!

Harald Welte: h-online article covering OpenBTS and OpenBSC

Mon, 26 Mar 2012 02:00:00 +0000

You can find a 3-page article about OpenBTS, OpenBSC and related projects available from the h-online web site.

Harald Welte: OsmoDevCon 2012 is over...

Mon, 26 Mar 2012 02:00:00 +0000

We just finished the 4th and final day of the OsmoDevCon 2012. It contained four days of in-depth presentations and discussions related to Free Software communications systems, most notably OsmocomBB, OpenBSC, OpenBTS, OsmoNITB, SIMtrace, OsmoGMR, OsmoSDR, rtl-sdr and many more.

I think it was a great chance to make sure the key developers involved with those projects are up-to-date with what everyone else is hacking on. I was especially happy with the presentations of Holger's smalltalk implementation of certain GSM protocols/interfaces, and it seems my small informal Erlang intro has raised some interest.

If anything, the 4-day conference has shown that there is a massive amount of work going on in the various different projects, and that it has clearly grown beyond anything that a single person could still be involved in all the sub-projects.

Personally, I'm happy to see what has grown out of this "we have a BS-11, let's see what we can do with it" that Dieter and I started in 2008. Now we're no longer talking about BTS/A-bis/BSC, but about SS7, MSC, TCAP/MAP, SCCP, HLR, Erlang, smalltalk, DECT, SIM/USIM, COS, SDR, GMR/Thuraya, TETRA and more recently also femtocells as well as NodeBs.

In the spirit of that 2008 presentation Running your own GSM network using the BS-11, Dieter Spaar has now demonstrated his talk on Running your own UMTS network, using NSN or Ericsson NodeBs. I'm really excited to see where that will take us - despite the fact that due to the 5 MHz wide channels, it's pretty close to impossible to get the experimental spectrum licenses that most of us have been able to get in recent years for our work.

As an outlook, over the remaining year 2012, I see progress in the following areas:

osmo-nitb will get a VLR/HLR split (async database access)
we will build a stand-alone osmo-msc with A interface
the signerl TCAP/MAP implementations will be used in production
OsmoSDR firmware will be completed, the hardware will start shipping
a new card operating system (OsmoCOS) will emerge
a UMA gateway will be implemented
a Free Software GPRS/EDGE PCU and RLC/MAC implementation will appear
last but not least, sysmoBTS will start commercial shipment really soon now

I'd like to thank our host c-base for having us block their conference room for 4 days, as well as all attendees who have travelled from all parts of Europe, but even the United States and Russia to participate. There definitely will be another OsmoDevCon, though we don't know yet at which point in time.

Andrew Zonenberg, Silicon Exposed: Analysis of RadioShack Duster Spray

noreply@blogger.com (Andrew Zonenberg) — Sat, 24 Mar 2012 20:47:06 +0000

In research and industry, spraying with compressed gas (usually dry nitrogen) is the standard way to remove liquid from a specimen after solvent cleaning or rinsing. By blowing the liquid off rather than letting it evaporate, spots from dissolved contamination are reduced or eliminated.

I had been using RadioShack duster spray for a while but started noticing residue on samples dried with it. My hypotheses at this point were:

The solvent had contamination in it, either from cleaning the sample or a contaminant in my stock bottle, and was depositing the contaminant on my samples
The bitterant added to the duster spray (to deter people from using it as an inhalant) was less volatile than the gas (or not volatile at all) and leaving residue on the samples

Earlier today I decided to test the spray and see if I could find out whether it was the source of the contaminant. Since the labeling on the can indicated pretty clearly that breathing it wasn't a great idea, all of my work was done in the fume hood.


The subject of today's experiments

I began by inverting the can and spraying a liquefied sample of the duster (R-134A refrigerant, according to the label on the can) into a test tube. The tube was quickly coated in frost as the refrigerant evaporated.

Frost-covered test tube

After trying to place some of the liquid onto a microscope slide with little success (it boiled as soon as the pipette touched it) I ended up pouring it into a petri dish and leaving it on the hot plate to evaporate all of the refrigerant and condensed water.

R-134a and condensed water slush being evaporated on the hot plate

Non-volatile contamination deposited on petri dish

Non-volatile contamination deposited on microscope slide

The results were pretty conclusive - some non-volatile contaminant is definitely present in the spray. I'm not sure what it is, and see little point in trying to identify it, but I clearly need to find a new source of duster gas for my experiments.

I'm looking at CleanTex duster spray, from the vendors of Texwipe cleanroom wipers. According to the specs on the website it's particulate filtered down to 200nm and is pure compressed gas with no bitterant or other stuff added.

Video Circuits: Sabrina Ratte EXPERIMENT III

noreply@blogger.com (Chris) — Sat, 24 Mar 2012 16:20:23 +0000

Video feedback, AZDEN VPC-10, LZX Video Synthesizer

Electronic sounds -Roger Tellier-Craig

GNSS-SDR: Improving the precision of the software receiver GLONASS L1

Fri, 23 Mar 2012 14:35:50 +0000

Some time ago I became interested in improving the precision of GLONASS Scilab receiver. The difference between mean value and max/min values of coordinates up to ±35 m for stationary receiver – is too big.

Figure 1 PVT solution of GLONASS L1 Scilab receiver

After improving several weak parts of the code the difference between mean value and max/min values of coordinates lowered to ±6 m, i.e. almost in 6 times. Results from the updated version of the receiver is on the figure 1. The same signal record as in the post GLONASS - frist experiments was used.After analysis of the original GNSS-SDR source code several weak places were found. Their improvement could increase receiver's precision. Here is the list of these weak places:
1. High variance of DLL-discriminator data;
2. Pseudorange calculations are based on round-off measurements;
After reducing correlator's arms spacing from 0.5 to 0.05 chips and after lowering DLL loop filter bandwidth from 2.0 to 0.5 Hz with additional adding assistance from PLL-assisted-FLL variation of DLL discriminator data was lowered. This fact with additional refuse from round-off during pseudorange calculations allowed to receive results that are shown on figure 1.

Open Hardware Repository: OHR Support - OHWR maintenance on 2012-03-26 (Monday) 08:30 CEST

egarcia@splendeo.es (Enrique García) — Fri, 23 Mar 2012 09:31:22 +0000

Bunnie Studios: MicroSD card FAQ

Fri, 23 Mar 2012 08:05:45 +0000

A while back I wrote an analysis of fake microSD cards. As a result of the post, I’ve received this question regularly via email:

“I’m trying to buy a thousand microSD cards for my embedded controller project. How do you qualify a microSD card?”

So, I thought it might be helpful to share my answer here.

There’s this awkward phase between the weekend project (where you buy your microSD card from Best Buy for $20 and have a no-questions return policy) and being Nokia (where you buy the same cards for $2 in quantities large enough to actually have leverage over vendors). When you source a few thousand cards at a time on the wholesale spot market, you’re basically on your own to control quality.

As far as process control, some vendors are easier to work with than others. Samsung will bump their part numbers based on die revs or other significant internal changes to the card. Sandisk, on the other hand, uses a very short part number for their cards, so you have no idea if the NAND on the inside is MLC or TLC, etc.; you just know the capacity and the card is simply guaranteed to perform to spec. To wit, Sandisk is very thorough about ensuring they meet the spec. However, it’s the edge cases that usually bite you in production; regardless of the spec, every die/controller combo has some character and your embedded controller may bring out some of that color. And, of course, there’s the fakes — Sandisk is a huge target for fakes, people who want to borrow their good name to sell you a batch of shoddy cards.

If you’re working with a distributor, get a copy of their authorization letter that certifies the relationship with the brand they are selling. It’s easy to fake the certificate, but it’s a good formality to pursue anyways. If you can, get the upstream brand to confirm the distribution relationship.

Aside from these supply-chain side things, here’s a check-list of technical tests to run on your cards:

For each new distributor:

1. I read out the CID and CSD registers and decode them. This is easy to do on linux with a directly connected microSD card. You cannot do this if the card is plugged into a USB adapter — you need to have the card plugged into a direct SD interface. The CID and CSD should look “right” i.e., the manufacturer ID should make sense (unfortunately the manufacture ID codes are all secret, but I can assure you it’s not supposed to be FF or 00), serial numbers should be some big number, date codes correct, etc.

2. Do a “full write” test at least once. i.e., create a random block of data that’s the putative size of the card, and dd it into the card. Then, do an md5sum of the contents of the card. This will identify loopback tricks that fake capacity. This is a relatively common trick that is surprisingly hard to detect, because many cards are only used to less than 50% capacity in real life.

3. Do a reboot test, to understand the behavior of the controller/die combo during ungraceful powerdown. It’s less important on systems that can never have their battery removed.

Before the test, I do a recursive find piped to md5sum to get a full map of all the files in the card. Then, I use a script that writes a random amount of /dev/urandom data in odd-sized blocks (ranging from a couple hundred bytes to a couple megabytes) to the card and then calls sync, in a constant loop after boot. For each block written, the md5sum is recorded. At boot time, all old blocks are checked for md5sum consistency and then deleted. The system under test is automatically power cycled by cutting the AC power about once very 2-3 minutes plus some random interval (depends on how long it takes your device to boot). I cut on the AC power side to capture the effects of the power decay curve of the wall adapter; the logic goes that a clean power down is less likely to cause problems than a gradual powerdown. I run the test on a cohort of at least 2 systems for 2 days straight. If you want to get fancy, you have the system upload its statistics to a server so you can see exactly when it starts to fail. After a couple of days, I extract the card from the system and redo the recursive find with md5sum to verify that no non-critical files have been corrupted that would be difficult to notice without the comprehensive check. Be sure, of course, to ignore files that naturally vary.

I still don’t have a straight answer on why some cards perform better under this test and others fail miserably. Ultimately, however, every card I’ve encountered eventually corrupts the filesystem after enough cycles, it’s just a matter of how long. I feel comfortable if I can reliably get to ten thousand ungraceful reboots-while-writing before failure. Note that supposedly eMMC has design features that harden cards against these problems, but I’ve never had the luxury of building such high volume systems that eMMC becomes an affordable option. Besides, I consider giving users the ability to remove the firmware card and reflash it with new code using a common USB adapter an important feature, at least in the systems I design. Mobile phone carriers would think differently.

Of course, once a vendor is qualified, they can still send you bad lots.

For each new lot I get, I take a few cards and burn them myself and check they boot the system before handing them over the factory. I also manually inspect the CID/CSD to ensure that the manufacturer’s IDs haven’t rotated and I inspect the laser markings to ensure that the lot number changes (it should — if it doesn’t then they are pulling something wonky on you). I also compare the circuit trace pattern on the back, visible through the reliefs in the solder resist coating. If you have easy access to an X-ray machine (some CMs have them on site) you can go so far as to compare the internal construction in the x-ray to see if the dies have been revved. If all these are the same you’re probably good to go on the new lot, but I do pay attention to the failure rate data in the first couple hours of production just to make sure there isn’t something to worry about.

There’s probably a bunch of other tests, techniques and good ideas that I should be aware of…look forward to reading the comments!

OggStreamer: #oggstreamer THT components soldering

Thu, 22 Mar 2012 15:20:47 +0000

I just soldered the remaining THT components for 3 OggStreamers, and I want to share the following picture with you:

For those of you, who are unfamiliar with the terms THT and SMT. I want to briefly explain the difference: THT (through hole technology) are components that are mounted by sticking the lead through a drilled hole. Where as SMT (surface mount technology) components are placed on the surface of the PCB-Board. In this project the soldering of the SMT was done by a Pick’N'Place machine, and the THT components were soldered by hand (by me )

Bunnie Studios: China: Crowdsourced Tax Enforcement

Wed, 21 Mar 2012 19:48:34 +0000

Riddle me this: how does a government enforce tax collection in a cash-only society? Cash has the wonderful property of being anonymous, and therefore hard to track. As a result, cash businesses often under-report revenues, thereby dodging a portion of tax payments.

China is primarily a cash-driven economy; few local places will accept payment cards of any kind (event rent payments are made in cash — a big, fat stack of cash, as the largest bill in China has an equivalent value of about US$15). As such, China has a big challenge around collecting taxes.

A solution to the problem is to go with a tax pre-payment system. At the beginning of every month, every business is required to pay an estimated tax. Proof of tax payment is issued in the form of “fapiao” (发票). They look a bit like the one below:

This fapiao represents tax paid on 10元 (元 is like the $ symbol, and colloquially pronounced “kuai”), so the restaurant I got this from probably paid about 1-2 kuai for this fapiao. When you settle your bill in a restaurant, in addition to getting the itemized receipt, you are supposed to receive a stack of fapiao of equivalent face value.

At the end of the month, the restaurant claims a tax refund on any remaining fapiao. As a result, fapiao are basically as good as money to the restaurant; hence, the fapiao are printed on watermarked paper with anti-counterfeiting measures, and employ serial numbers you can validate by sending an SMS to a government hotline. Also, restaurants have a strong incentive to omit a few fapiao from your stack, or completely forgo giving you the fapiao (they love it when foreigners dine, because they don’t know about fapiao — they get big business and they get the tax refund on it!).

So, how does one enforce the distribution of fapiao to customers? China’s clever solution is to make every fapiao a lottery ticket. If you look at the above photo carefully, you’ll see two metallized patches on the fapiao. You can scratch these off, and underneath might reveal a prize! Of course, the one I have above is a losing ticket — it just says “thank you”, with a serial number; but the prize can be thousands of kuai.

And so, China has crowdsourced tax enforcement, by potentially rewarding citizens with a cash reward for asking for all of their tax pre-payment receipts, and using them up by scratching off the prize areas. The cost of this massive force multiplier is vanishingly small, as all they are offering is the chance to win; I have only ever seen one winning ticket in the past couple of years, and it was for about 2 kuai. Still, it is a nice cultural touch to the end of a big meal, everyone sitting in a circle, scratching their fapiao to see if they won a prize for playing the part of a Chinese tax enforcement agent.

Of course, with every new system, new problems come in. One is that the waitstaff might nick a couple of fapiao en route to the customer. So now, to get your fapiao you usually have to go in person to a special counter that manages its distribution. And, of course, the restaurant can offer a bribe in place of the fapiao. Just this past month when I was visiting Harbin, I went to collect my lottery tickets and the lady at the register glanced at my 80 kuai receipt and offered to pay me 4 kuai instead of giving me fapiao! I was a bit surprised at how brazen the offer was, but in retrospect, I clearly was not from around there, and thus unlikely to be an auditor.

GNSS-SDR: Successful usage cases of published projects

Wed, 21 Mar 2012 19:32:15 +0000

Not long time ago I have noticed master's thesis in which materials from my blog are used :) Here is the link: https://dspace.ist.utl.pt/...

This is the second successful copy of front-end project published on my blog that I know about. In this work author didn't just copy the design but also tried to improve it and to simplify it. I should notice that it's pleasant to know that someone is interested in my project. It's even more pleasant to see how someone else improved it.

PS I hope that in the future this note will grow bigger and bigger. :)

OggStreamer: #oggstreamer 12 pcs. SMT soildered

Wed, 21 Mar 2012 17:42:51 +0000

Yippie – the kind and helpfull people at Abatec did the pick’n'place of 12 OggStreamer-Boards. The next step is the assembling the devices, the mechanical works are already on their way – so maybe next week their will be 12 fully assembled OggStreamer devices. I have to note that from this first batch only selected Beta-Testers will get a device.

The software still needs some improvement, currently I am facing problems running the icecast2 Server under uclinux. icecast2 consists of 4 threads and only 2 of them start when I start the program. It could be a out-of-memory issue, but some how I doubt that. It definitely needs some remote- or printf-debugging to get the program running – apart from that I am thinking of fine tuning the Input- and Output amplifiers. Maybe I will take away the output OPA, as the VS1063 already handles about the same current. The OPA was placed in the design, mainly for ESD-Protection, but I will experiment, whether the R-C combo is good enough.

If anybody of you is interested in the obtaining a Bare-PCB of the current Rev1.0b design, there are five pieces, which I would give away for a small project donation.

Crypto Stick: We are in Google Summer of Code 2012

Wed, 21 Mar 2012 14:04:13 +0000

For the second time we are in Google Summer of Code (GSoC) as a subproject of FOSSASIA. This means students can get scholarship to code for the Crypto Stick. Here are a couple of ideas of interesting projects but you are free to suggest your own as well. If you are a student and want to join our project, register at Google Melange and apply for FOSSASIA.

Richard Hughes, ColorHug: The first colord-kde release!

Wed, 21 Mar 2012 11:11:15 +0000

Great news this morning when I saw that Daniel had released the first version of colord-kde.

If you’re a KDE dude, please try out the tarball and let us know what you think!

LZX Industries: LZX Industries at Moduluxxx/Dorkbot Sydney

Tue, 20 Mar 2012 14:51:37 +0000

Moduluxxx is a modular synthesis mini-festival being held in Sydney, Australia on April 27th and 28th. Ed Leckie from LZX Industries will be presenting our modules as part of its Dorkbot Sydney event on 28th April, 3pm – 6pm at Serial Space. We’re very excited to be part of this fantastic event! You can discover more details about the event at their website, https://sites.google.com/site/moduluxxx.

Zedstar: An XML Compression Scheme

Mon, 19 Mar 2012 07:28:23 +0000

There are different ways of compressing XML but I like the idea of doing it with a schema. Using a schema you always have the advantage of validation but you can also produce very efficient encoding of the XML data. I have been working on an XML layer for packedobjects to allow compression of XML data. Currently it takes XML data with a schema written in packedobjects and produces binary data. This is very similar to XER but everything happens at runtime. This means I could support a subset of XML Schema and dynamically map to the packedobjects schema. Doing this the end user will only see an XML world. Everything is handled by embedding Scheme to take care of the mapping between XML and s-expressions. From C you will not see this but you still have the advantage of working directly within a REPL to design your schema if you want. The Scheme layer could also be extended to handle other data formats.

Running the example will show that the packedobjects compression is about 3 times smaller than gzip based compression. In similar tests I have seen similar gains over encoding with Protocol Buffers.

OsmoSDR: Introducing RTL-SDR

Sun, 18 Mar 2012 18:00:20 +0000

While the OsmoSDR is still not available, some Osmocom team members (notably Steve Markgraf) have been hacking away on an alternative least-cost solution: rtl-sdr.

So what is rtl-sdr? It is a creative form of using consumer-grade DVB-T USB receivers, turning them into fully-fledged software defined radios.

Those DVB-T receivers supported by rtl-sdr are based on the Realtek RTL2832U chipset plus a tuner IC like the Elonics E4000.

The RTL2832U has some undocumented commands/registers, by which it can be placed into a mode where it simply forwards the unprocessed raw baseband samples (up to 2.8 MS/s 8-bit I+Q) via high-speed USB into the PC, where they are routed into gnuradio.

At a street price of about USD 20 to USD 25, they are undoubtedly the most capable low-cost SDR hardware that can be bought. So now there is really no more excuse for anyone to not learn gnuradio. You don't have to buy a USRP, not even a FCDP or an OsmoSDR: A USD 20 device is all that's needed for receiving signals like GSM, GMR, DECT, TETRA, APCO25 and many others.

Harald Welte: Using a cheap (USD 20) DVB-T USB stick as SDR receiver for (not only) gnuradio

Sun, 18 Mar 2012 01:00:00 +0000

Fellow Osmocom hacker Steve Markgraf has been working on what now seems to be the cheapest way to receive real-world radio signals for PC-based SDR like gnuradio: rtl-sdr. RTL refers to the RTL2832U chipset frequently used in such devices. It can be used to obtain 2.8 Ms/s of 8-bit I+Q samples.

Below is a picture (courtesy of Steve) how the hardware looks like:

Antitronics: Let’s centralize the knitting machine technical discussions

Fri, 16 Mar 2012 18:59:56 +0000

There are more and more people diving into hacking on knitting machines, which is really great!

It’s getting to the point where there are too many people to thank for carrying this forward, you know who you are.

But, the increasing popularity has led to some problems and frustrations for people.

Recently I discovered an old thread on a Ravelry forum about the PDDemulate.py disk emulator that I wrote. People were frustrated by problems they were having. By the time I discovered the thread, I had already been contacted by one of the people with the problem, and I discovered a bug in the emulator. It’s now fixed in the repository. But months had gone by between the forum postings and email contact. The forum thread is still out of date, because a solution has been found but that’s not indicated.

I try to be responsive to people when they have problems with the code – I help when I can and try to be up front if I’m too busy to dive in deeply or if the problems are with an environment I don’t have (I only have a KH-930, and only run the emulator under Linux). But I don’t have time to find and follow every forum where this is being discussed.

Through email from people using the software, I’m becoming aware of more people who are working on this but unaware of others doing the same thing. It feels like there’s a larger community forming around this, but it’s fragmented.

Therefore, I’d like to respectfully suggest that we centralize the resources used for these projects, so that we can help each other, and keep a record in one place of the existing knowledge. Other forums are great, and I know there are communities with forums which reach and help the people who participate in them. Those should continue of course, but for people with deeper interest it may be appropriate to point them to this blog entry.

The definitive repository for the knitting machine disk emulator and related files is here:

Adafruit knitting machine rep on Github

If you’d like to fix or improve the code, or add information about different models of knitting machine, please fork that repo and then make pull requests to have your changes incorporated.

Technical information about connecting to Brother knitting machines and about the KH-930 is here:

Antitronics Knitting Machine Wiki Page

Discussion about the software and reverse engineering of the data formats is taking place here:

Yahoo kminternals group

The Yahoo group and git repository are the only places that I’ll regularly follow, and try to respond to questions.

I’ll still respond to email, my email address is in the code in the repository. But I’ll probably ask you to go to the Yahoo group. Still, if you’re self conscious about the question or whatever, you can use email.

Now, let’s all make great things!

Transmaterial: Mercury Glass

Fri, 16 Mar 2012 14:00:49 +0000

Silvered glass “Mercury Glass” was invented in the nineteenth century as a decorative substitute for more expensive silver tableware. Where traditional Mercury Glass has a thin glass wall, however, Suzan Etkin Enterprises creates hand blown silvered glass with thick, undulating walls and deposits a film of pure silver into the vessel interior. The thick, undulating wall gives the glass the appearance of liquid metal, transforming a 19th century technology into a 21st century material with unmatched light reflection and refraction properties.

Suzan Etkin engineers and tests each project for safety. Overhead glass vessels can be filled with anti-shatter foam or resin, and Mercury glass elements can assume structural properties when reinforced with steel embedded in structural foam or resin.

Contact: Suzan Etkin Enterprises, New York, NY, USA.
Find more information in Transmaterial 3.

Richard Hughes, ColorHug: Zif wants new blood

Fri, 16 Mar 2012 08:57:39 +0000

A few years ago I wrote Zif, which is basically a package tool that works with librpm and the Fedora metadata. Zif is very much of a side project for me, mainly written out of curiosity and to try and make things work a bit faster just when using PackageKit. It seems most people try to write a package manager at some stage of their open source career.

So, fast-forward a few years. Quite a few people are using Zif now, and there are even a few people writing new code and fixing bugs. I’m wondering if anybody new to programming or new to open source wants to help me improve Zif, and to try to fix little-but-important self contained bugs like this.

Anyway, if you’re interested, let me know. Thanks.

Harald Welte: Osmocom GPS timing source with u-blox LEA6-T

Fri, 16 Mar 2012 01:00:00 +0000

Recently we have been looking for an inexpensive way to generate a high-accuracy clock source for E1 lines, as it is required by a number of classic BTSs that don't have a sufficiently accurate OCXO built-in.

Luckily, the Digium E1 cards like TE-410P have a timing connector, to which an 8.192 MHz signal can be injected. Unfortunately, there don't seem to be any OCXOs around for that frequency. That's where the u-blox LEA-6T comes into play: It has a configurable TIMEPULSE2 output that can generate any frequency up to 10 MHz. We use this in our board to generate 8.192 Mhz and want to feed that into the Digium card.

So all we had to do is build a small board that contains the module and connector for antenna input, clock output and the obligatory 2.5mm stereo jack for the OsmocomBB-style UART:

Thanks to Sylvain for doing the schematics/PCB design, and thanks to Pablo for writing the code to configurea and activate the 8.192MHz output.

Once the design is verified, the schematics + gerber will be available, as well as board from the sysmocom webshop.

Tuxbrain: Realidad Aumentada + processing 1.5 + Ubuntu 10.04

Thu, 15 Mar 2012 17:00:06 +0000

Estos días nos ha entrado el gusanillo de trastear con Processing y la Realidad Aumentada (AR) y la verdad que le hemos tenido que dar más de una vuelta al tema ya que los tutoriales que hemos encontrado por la red utilizan normalmente versiones de Processing anteriores y la instalación es algo diferente.

Bueno, aquí va este minitutorial de nuestra ficticia serie "Notepartaslacrisma" para intentar allanaros el camino.

Bunnie Studios: Safecast Geiger Counter Reference Design

Wed, 14 Mar 2012 20:08:44 +0000

This past weekend marked the anniversary of the Tohoku-Oki earthquake that devastated Japan. I had not felt my blood so cold since I watched the twin towers fall almost a decade earlier. I still vividly remember the twisting knots I felt in my stomach as I watched the footage of a tsunami wiping out huge swathes of Japanese countryside. In a matter of hours, entire cities were washed off the map, leaving an eerie post-apocalyptic landscape of a few survivors weeping amongst twisted wreckage. Then, in the ensuing days, Fukushima Daiichi melted down, leaving in its wake one of the worst on-going radiation contamination crisis since Chernobyl.

I have good friends in Japan, and I visit often. I wanted to do something to help, but I didn’t know what I could do. I was connected by Joi Ito to Safecast, and I joined the effort to build an open sensor network that could aggregate trustable, source-neutral radiation monitoring data. Safecast itself has many talented and hard working volunteers who have done a remarkable job of achieving their goals by instrumenting Japan with radiation monitors and aggregating data through cleverly designed and rapidly deployable mobile monitoring capabilities.

I decided my tiny contribution to the effort would be to design a radiation monitor suitable for everyday civilian use. This is a preventative/preparedness measure, addressing the long-term issue of empowering a civilian population with few available options for power generation to self-monitor their environment. The problem with the current crop of radiation monitors is that they are basically laboratory instruments: accurate & reliable, but bulky, expensive, and difficult to use, requiring a degree in nuclear physics to understand exactly what the readings meant. Another problem with crises like these is that while radiation monitoring is important, it’s something that is typically neglected by the civilian population until it is too late.

Therefore, the challenge set out before me was to design a new Geiger counter that was not only more intuitive and easier to use than the current crop, but was also sufficiently stylish so that civilians would feel natural carrying it around on a daily basis. Furthermore, it had to provide extensive logging capabilities, as radiation monitors are typically not turned “on” until after the fact. It also had to operate effectively in catastrophic conditions, i.e. in scenarios where internet and power have been cut for days. Finally, the data collected by the instrument had to pass any scrutiny thrown its way, and the collected data had to be traceable to a given instrument so that if its calibration is incorrect, its data can be selectively excluded without poisoning the entire dataset. Radiation monitoring is a politically sensitive subject, and certain parties have interests to manipulate the data one way or the other to promote their views with the public. Ad-hoc data collection networks suffer from the possibility that their efforts can be discredited by institutions with big budgets who find that the readings represent an inconvenient truth.

Radiation sensing primer

Radiation measurements are subtle, partly because radiation comes in many flavors. Many Geiger counters can only efficiently detect the most energetic kind of radiation, gamma radiation. This includes the Geiger counters frequently favored by government and regulatory agencies. However, there are weaker forms of radiation (alpha and beta) which often go overlooked that can also pose a human health risk, particularly if they are ingested or inhaled. These weaker forms of radiation are also by-products of a nuclear meltdown, and because they come from different isotopes they have different patterns of distribution and absorption in the environment.

Because of the diversity of radiation sources and their varying biological impact, it is very hard to determine if an environment is safe in the face of an elevated Geiger counter reading. However, improved historical and spatial distribution records of background radiation measurements can help identify when there is a spike in radiation, which is a clearer cause for concern.

In the interest of creating a complete solution for public health needs, a core design requirement of the new Geiger counter is to incorporate a sensor that could detect all three forms of radiation. This type of sensor is a “pancake” style Geiger tube, which has a large mica window that enables sensitivity to all three kinds of radiation. The ultimate selection of the LND7317 pancake tube plus iRover HV radiation sensing core influenced every aspect of the industrial design (ID) and internal electronics.

There and Back Again: a Hacker’s Tale

I thought it would be interesting to share not only the final design, but also the intermediate designs that were scrapped en route to achieving a final design. Design is an iterative process, where one has to make difficult choices about what to include and more significantly what to leave out. It’s extremely rare to see what got left on the cutting room floor, but I saved my notes along the way so I could share them with you now.

Initial Design Sketch

Above is a rendering of the first design sketch, made back when Safecast had the name of “RDTN”. I do all my industrial design using Solidworks, a survival skill I picked up during my tenure at chumby designing consumer electronics. I came up with this in the first couple of weeks after the disaster. This design incorporated a low-sensitivity tube from Sparkfun, because at that time I did not understand the importance of using a pancake tube.

The biggest problem I wanted to solve with this design is user abandonment. Radiation leaks are thankfully rare events. However, this also means that when an event happens, there is typically a lack of pre-crisis background data against which to compare the post-crisis readings. Therefore, I wanted to build a device that people would be compelled to carry around every day and use for years at a time.

My thought is that the average consumer would have a hard time justifying carrying around yet another gadget in their pockets or purses for the sole purpose of measuring radiation. Within weeks or even days of getting nothing but “safe” readings, the Geiger counter would be forgotten and left at home to languish until after the next crisis.

One way to compel users to carry around a Geiger counter is to put it into something they already carry all the time. While it would be tough to convince a smartphone vendor to incorporate a very expensive and bulky Geiger tube, many smartphone users also carry around a spare battery pack, which they use almost every day. So, I thought it might be a good idea to trojan horse a Geiger tube into such a battery pack.

The sketch above demonstrates such an incarnation. This design is basically a battery pack that can charge a smartphone, but also incorporates a Geiger tube, an LED flashlight (handy in an emergency when there is no power), and some logging circuitry. The Geiger counter would upload its log data to the Safecast network whenever a user plugged in to charge the phone.

The design itself is minimalist, with a shape inspired by the steam cooling towers frequently used to iconify nuclear power in western media. The shape was chosen to remind us that sometimes we have no choice but to harvest the power of the atom, and a well-equipped and informed civilian data collection network is a key factor in trusting the safety of our power sources.

A second iteration

The first sketch had to be abandoned, primarily because the sensor it was designed around was too small to effectively measure alpha and beta radiation. After Safecast settled on the LND7317 Geiger tube as the standard reference sensor, I started re-designing the sensor around the new tube.

The problem with the larger, more sensitive sensor is that it was big – over a half-inch thick, and a couple inches in diameter. Below is a sketch of a design study aimed at creating the smallest possible Geiger counter that could also incorporate the large pancake tube. It’s about the size of a hockey puck, but a bit thicker. In order to keep the size and weight of the Geiger counter reasonable, I had to abandon any notion of a dual-purpose as a battery pack. Instead, I had to rely on “sex appeal” alone to compel users to carry the device around. I wanted to make the Geiger counter something unique and aesthetically pleasing, something you would enjoy carrying around frequently. I started from a minimalist design – the puck – and endeavored to design-out any outward indicators or displays. Hence in this sketch, the radiation measurement is provided by a set of super-high efficiency 7-segment LEDs that could shine the numbers through a seemingly opaque white shell. The design’s shape and feel was meant to be somewhere in between “Eve” from WALL-E and an egg.

Unfortunately, this design, too, had to be abandoned because at the time when I was drawing up the sketches, I didn’t have detailed mechanical drawings of the LND7317 tube. When I was finally given a sample of the tube and drawings for it, I discovered there was not only the puck-like body, but also a nearly 1″ long protrusion for the cathode and anode. This completely destroyed any notion of building a puck-like sensor.

Closing in on the final design

Below is a rendering of an attempt to accommodate the accurate CAD model for the LND7317 into an ID that stayed faithful to the Eve/egg design inspirations. The puck was elongated to the minimum dimensions required to house all the internal components. Again, the hidden 7-segment LED display motif was employed.

The final design

After much discussion and review with the Safecast team, we decided that a key component of the user experience should be a graphic display, instead of a 7-segment LED readout. Therefore, a 128×128 pixel OLED panel was incorporated into the design. The OLED panel would be mounted behind a continuous outer shell, so there would be no seams or outward design features resulting from the introduction of the OLED. However, as the OLED is not bright enough to shine through an opaque white plastic exterior shell, a clear window had to be provided for the OLED. As a result, the naturally black color of the OLED caused the preferred color scheme of the exterior case to go from light colors to dark colors. User interaction would occur through a captouch button array hidden behind the same shell, with perhaps silkscreen outlines to provide hints as to where the buttons were underneath the shell. I had originally resisted the idea of using the OLED because it’s very expensive, but once I saw how much an LND7317 tube would cost in volume, I realized that it would be silly to not add a premium feature like an OLED. Due to the sensor alone, the retail price of the device would be in the hundreds of dollars; so adding an OLED display would help make the device “feel” a lot more valuable than a 7-segment LED display, even though the OLED’s presence is largely irrelevant to the core function of the apparatus.

The design also lacks any integrated radio connection. A popular request for the design was the incorporation of a bluetooth or zigbee style radio; however, a combination of a very stringent battery life goal (several months of standby time) and low manufacturing volumes meant that it was impractical to incorporate a radio into the device. It’s a slippery slope to start adding features like GPS and bluetooth – to add those features, you’d need to upgrade the microcontroller, at which point you’re basically building a very expensive, heavy and large cell phone with a geiger counter in it. Furthermore, the entire development effort was being done by an unpaid volunteer operating on a shoestring budget – Safecast isn’t Apple. So, rather than build a buggy cell phone that can sense radiation, I’d rather build an outstanding Geiger counter; hence the decision to focus efforts and resources on core functionality, with the sole allowance being the inclusion of the OLED + captouch array for improved UI. This is a controversial design decision and I fully expect to be chastised for it.

The Prototypes

Once the design was finished, the next step was to build prototypes. This is the really fun part, where you turn your ideas into something you can touch and hold.

The prototypes are made out of CNC-machined ABS (even the clear part!). The cosmetic moldings that go over the connectors were also built and they do fit, but because of their expense and fragility (CNC milled ABS lacks the robustness of injection-molded ABS), I try not to install them, even for glamor shots. To wit, the whole thing was done on a shoestring budget, as Safecast is a non-profit; two full prototypes were built, including PCB fab, assembly, and CNC milling for one and a half revisions of the cases, for a bit under $3k total.

An important point readers should note about this design is that I’m not manufacturing this Geiger counter reference design. My contribution is limited to design IP only. Practically speaking, I’d make a terrible Geiger counter supplier, because I don’t have the credibility or history in the industry. Instead, the design has been donated to the community, thereby enabling International Medcom, a business that has spent decades specialized in producing high-quality Geiger counters, to bring this to the market. If you’re interested in getting one of these, keep an eye on their website.

The final design features include:

LND7317 pancake tube + iRover HV board

STM32-based microcontroller; sufficient CPU power to digitally sign logs with a unique private key as a non-repudiation/anti-tamper measure

450 mAh Li-poly battery

3-axis accelerometer so sensor orientation can be recorded

128×128 color OLED display

6-button captouch array

“hold” button on the back to lock the captouch array and prevent false triggering of the power-hungry UI elements

lanyard attachment (important for the Japanese market)

microUSB port for charging and data upload interface, featuring an FTDI-based serial chipset capable of loading firmware into the microcontroller

3.5mm jack capable of bidirectional audio

embedded hall-effect sensor (to detect attachments, e.g. for occluding alpha or beta radiation)

audible event notification via piezo buzzer

low-power visual event notification via conventional LED

real-time clock

a high-quality entropy source ;-)

I am a proponent of open source hardware; so here’s the source files for my design! All of the following source files are licensed under CC3.0-BY-SA with my XL1.0 automatic patent cross-license rider (CC doesn’t address patents, so I invented my own rider that piggybacks on CC to ensure that any patents that may arise from this or its derivatives are automatically cross-licensed to the community).

Altium design source / schematics / gerbers / BOM for the mainboard electronics

Altium design source / schematics / gerbers / BOM for the buttonboard electronics

Solidworks design source / IGES / STEP for the industrial design

For those who don’t have 3D design tools, you can install Solidwork’s free e-drawings viewer and look at the easm file, or if you run windows you can download this executable and just run it

Of course, a hardware prototype is only the beginning – there’s a huge amount of effort remaining on the software. To bootstrap things, xobs and I have coded up a core demonstration system based on Leaf Lab’s libmaple. You can peruse the code and/or download it at github. Basically, this demo system provides an architecture to easily register drivers and facilitate power management. The validation demo shown running on the prototype photos above indicate that all of the hardware features work. But, the software has yet to have a layer of polish and shine added in terms of the UI and power management optimization.

A key design goal electronics’ system design was to enable community participation. As such, I eschewed the use of JTAG adapters during development. Instead, hooks were provided in the hardware to enable the integrated FTDI USB-serial controller to flash the microcontroller’s firmware via a “bitbang” interface. As a result, anyone who has an interest in developing for this Geiger counter can simply plug it into their laptop’s USB port and start coding without any need for proprietary JTAG adapters or proprietary software to purchase, as the entire developer’s toolchain is available in source form. We were able to code up and test the entire functionality demo (including sleep/stop/standby power management) using nothing more than the USB-serial capability built into the design. As I write this, I realize I had neglected to upload the firmware loader to github, so here’s a tarball for it; currently, the loader only runs under Linux and OSX.

I think there’s some fun things the community could do with the UI on a Geiger counter. At the very least, the microcontroller has sufficient power to play Tetris. Another whimsical thought was to build a subsystem that would play music out the audio port based upon the current radiation level — calm, ambient music in low-radiation environments escalating to death metal and the sound track of “Run Lola Run” at dangerous levels.

So that’s it! I hope that the design ultimately helps the people of Japan – or people anywhere in the world where radiation contamination may be a concern – to feel more empowered and in control of their situation.

Video Circuits: Mantra - My Panda Shall Fly + Benjamin Jackson

noreply@blogger.com (Chris) — Wed, 14 Mar 2012 17:30:46 +0000

New video I worked on

Music By My Panda Shall Fly + Benjamin Jackson

Directed by Andrew Corrigan

Andrew Corrigan - D.O.P
Chris King - Animation
nickin - Animation and Technical Advisor

Natalie Tabony - Choreographer
Rachel Ensor - Dancer
Stuart Winter - Dancer

Jerry Fleming - Sound Technician
Stuart Pardoe - AV Technician

Special thanks to: Sam Taylor, Tom Loughlin, Jowey Roden

Video Circuits: Spiral 1, Interactive Electronic Visualization Event 1

noreply@blogger.com (Chris) — Wed, 14 Mar 2012 17:06:41 +0000

This is a document of the performance of spiral 1 performed live at the Interactive Electronic Visualization Event 1 in 1975
Performance by:
Tom DeFanti, Digital computer
Dan Sandin, Analoge Image Processor
Bob Snyder , Fender Rhodes piano

Excerpts from video document "EVE Aura" by:
Raul Zaritsky & Jim Morrissette

The last performance of Spiral os Spiral aka Spiral PTL is on the Dan Sandin YouTube channel

Village Telco: New firmware release Version 1.1 RC2

Wed, 14 Mar 2012 11:57:59 +0000

Thanks to the amazing work of Terry Gillett, Keith Williamson, and Elektra, I am happy to announce version 1.1 (RC2) of the SECN firmware. SECN is the firmware developed by Terry Gillett which features the use of batman-adv instead of batman mesh protocol as well as easy configuration of a WiFi hotspot for the Mesh Potato. From an interesting alternative, the SECN firmware has gone on to become the default firmware for the Mesh Potato. Here is a list of features that you can find in the 1.1 firmware. So what’s new in the 1.1 version?

A Simple Configuration User Interface (UI)

While LuCI is tremendously powerful, we have found that it can be intimidating for new users. It also doesn’t offer the VoIP configuration features that are key to Village Telco. The new configuration UI in version 1.1 offers the most important basic options including: setting the IP address and gateway, the WiFi hotspot, and configuring your VoIP provider details. The UI is smart enough to stop you putting in a malformed IP address or from choosing a WPA key for your hotspot that is too short, etc. It can also try to guess your gateway for you. Of course you don’t HAVE to use the web interface to configure your Mesh Potato. You can also configure it by phone.

Easy VoIP Setup

Previously you were obliged to edit the Asterisk configuration files in order to set up a SIP account with your VoIP Service Provider. Now all you need is the URL of the the SIP provider and your username and password. The UI also indicates when the Mesh Potato is successfully registered to the SIP provider. This is set to work with the most common default setting of VoIP services providers. You can go to the Advanced setting page if you require custom VoIP options.

Simple Access Point Configuration

Setting up the Mesh Potato as a WiFi access point is a breeze. Simply enter your preferred name for the WiFi network (the SSID) and then choose the form of encryption you prefer for the network. By keeping the SSID the same for all of the Mesh Potatoes on your network, you can create a large, seamless hotspot. Most WiFi-enabled devices will hand-off from access point to access point if you move around in the network allowing you limited mobility within the network.

Security Options for your Mesh Potato

Once you’ve configured your Mesh Potato, you may not wish to make it so easy to access the configuration options for your Mesh Potato. You have to consider the fact that your Mesh Potato can be reached by anyone on the mesh network. The new firmware offers three options for securing your Mesh Potato.

Encryption. You can turn on the encrypted web interface which will secure all traffic to the Mesh Potato making it extremely difficult for anyone to intercept configuration traffic to the Mesh Potato. This means that you would access the same web UI but using the HTTPS protocol.
Password. You can require a username and password to access the UI. This is based on the root or admin user accounts on the Mesh Potato.
Limit IP addresses. You can also make the webserver accessible only through the fallback IP address.

You can also disable the web interface entirely via the phone interface.

Integrate Smartphones with your Village Telco

The Mesh Potato is entirely standards-based which means that you can connect the Mesh Potato to any SIP server whether local or international. But what if you don’t have the luxury of an Internet connection? Well of course Mesh Potatoes are designed to make local calls to each other with or without an Internet connection or SIP server but what about using your WiFi-enabled smartphone on a local Village Telco network with no Internet connection? This is now possible with version 1.1. You can designate one of the Mesh Potatoes on your network to offer both DHCP and SIP services so that any WiFi-enabled smartphone can connect to the mesh network and dial the Mesh Potatoes and vice versa. This has relevance for rapid deployment of Mesh Potatoes where you may not have time or resources to establish an upstream connection but still wish to make maximum voice use of the network.

Wireless Status Page

There is now a Wireless Status page that shows you the other mesh nodes in the network and devices that are connected to the WiFi hotspot on the Mesh Potato. It is still a little cryptic. In version 2 of the Mesh Potato firmware we’ll have a less technical status page although the more detailed stats will still be available.

How to Get It

You can download version 1.1 RC2 of the SECN firmware from:

http://villagetelco.org/download/firmware/secn/unstable/mp/SECN-1.1/RC2/

If you have never flashed a Mesh Potato with a new firmware, please follow this guide. The default IP address for the 1.1 RC2 firmware is 10.130.1.20 or you can use the fallback IP address of 172.31.255.254. You’ll note that this release is RC2 or Release Candidate 2 which means that the feature set is stable and we are not aware of any bugs but further testing is required to confirm this.

But Wait There’s More

The SECN firmware doesn’t just run on Mesh Potatoes. It is also available for the TP-Link WR703N and the TP-Link MR-3020 so you can mix and match devices in your network. The devices are completely interoperable with Mesh Potatoes running this firmware. You can download those firmwares from:

http://villagetelco.org/download/firmware/secn/unstable/tp-703n/SECN-1.1/factory/ http://villagetelco.org/download/firmware/secn/unstable/tp-3020/SECN-1.1/factory/

Finally, I can’t thank Terry, Elektra, and Keith enough for what they’ve accomplished. All this progress is directly attributable to their hard work.

Coming Next

Elektra, Terry, and Keith are already working on Version 2 of the Mesh Potato firmware which will include an upgrade to OpenWRT Attitude Adjustment and to the latest and greatest version of batman-adv. We also have plans for a simple UI for switching between mesh, client and master WiFi mode for those who want to do different things with their Mesh Potatoes. Suggestions, requests are welcome.

Liu Xiangfu, openmobilefree.net: Cgminer web monitor

Wed, 14 Mar 2012 09:55:46 +0000

My Icarus + Cgmienr is here:
http://downloads.openmobilefree.net/Icarus/

For setup miner.php:
1. change the $miner to your hostname or IP address
2. change the $readonly to true for read only.
3. start cgminer with two more parameters: –api-network –api-listen
4. if you want access from public, don’t forget forward the 4028 port from your router

The source code is here, Thanks to kanoi.
https://github.com/kanoi/cgminer/blob/master/miner.php

Harald Welte: Alcatel MTK phone UART pinout

Wed, 14 Mar 2012 01:00:00 +0000

The Alcatel OT-890D is a MT6573 based smartphone. It seems one of the UARTs is available on test pads as seen in this picture:

The voltage level is still 3.3V, so no fancy 1.8V gear is required.

During boot, the UART is first used at 19200 bps, where it prints the strings "MW01" and "MW02". I then switches to 115200 bps where it prints "READY", and finally switches to 921600 bps, where it seems to output some mixed binary/text messages containing AT commands and responses between AP and BP, as well as some debug information:

�Ue� � � T+CREG=2
�Ue�!�!�!T+CSQSQ=1
�Ue�!�!�!AT+CREG=2
�Uew�"w�"w�"SQSQ=1
'Ue"""      AT+EFUN=1
      SML: Load!_Ue""""""
                         SML: Load!hU("("("

I haven't yet investigated if the binary between the text is some standard HDLC framing or a TS 07.10 multiplex.

If anyone knows more about the boot process (MW01/MW02/READY) or the binary protocol, please let me know.

Video Circuits: David Hall, End Piece

noreply@blogger.com (Chris) — Tue, 13 Mar 2012 04:56:52 +0000

1001 analogue television sets left on to document the end of PAL transmissions in the UK

The exhibition runs from 16 March - 22 April, Opening hours: Wed-Fri 11am-7pm, Sat-Sun, 12pm-6pm.
Ambika P3, 35 Marylebone Road, London NW1 5LS

http://www.davidhallart.com/

also

this conference on video art to accompany
http://www.westminster.ac.uk/research/a-z/cream/events/exhibiting-video-conference

Richard Hughes, ColorHug: SANE crashy crashy

Mon, 12 Mar 2012 10:12:28 +0000

I spend quite a lot of time triaging bugs in Fedora for stuff I maintain upstream. The most common crasher bug I come across is colord segfaulting deep in libsane. Digging even more, 99% of those libsane crashers are when the user has installed closed source binary drivers to make the scanner “work”.

Of course, segfaulting colord just because it automatically assigns color profiles to scanners is not a good idea, even if we can blame non-free code. Something had to be done, as it was starting to make colord look bad as all the display and print color management would suddenly stop working in quite a dramatic way.

Now, in an ideal world, there would be a scanner daemon, scannerd, that I could patch for colord support, just like we’re doing for printers and dispays. This would then register devices with colord, and if it crashed, it could be autorestarted. Such a thing doesn’t exist, and so I had to do something that involved separating the libsane code from the main colord process.

In git master I’ve added a tiny dbus daemon called colord-sane, that basically does nothing except for rescanning sane whenever a USB device is plugged in and creating and deleting devices in colord. It only has one method “Refresh” and it is started when colord is started (usually in early boot) if the UseSANE=true option is specified in /etc/colord/colord.conf

In an ideal world, someone could take that code, and make a proper scannerd or saned project that adds some DeviceAdded and DeviceRemoved signals, a GetDevices() method and some more properties on each device, hopefully using something l33t like GDBusObjectServer. This would mean that the session could just use that for device discovery (e.g. in Simple Scan) and the world would be a much nicer place.

So, if you see a tiny colord-sane process show up in your system that’s not doing anything, don’t panic. You can disable the functionality if you know you’ll never have a scanner attached.

Dan Reetz: Home Switches for CNCRouterParts.com CRP4896

Sun, 11 Mar 2012 21:02:05 +0000

I’m outfitting my CNCRouterParts.com CRP4896 CNC router with home switches. The idea is to set up sensors such that the router can start from the same place every time, automatically.

I’m using these sensors. They are compact, encapsulated Hall Effect switches. They pull low when in the presence of a magnetic field.

Today’s work was mounting these onto the router. I have the X axis done.

First, I measured out the extrusion on the router as well as the distance between the brush support bolts on the gantry stand. In each case, the distance was 1.5″. I drew up some adjustable braces in Corel Draw. I lasered a quick prototype from MDF to test the fit:

It fit well, and it worked, save for one thing – it was resting on top of the nuts that were holding the sweeper brushes in place. I adjusted the artwork to compensate.

I then cut the corrected art from 1/4″ clear acrylic on my Epilog Zing and mounted it.

I secured the magnet in the slot with cyanoacrylate and tested the part. Worked. Now to connect it to Mach3 and the main driver board.

Tested out perfectly.

The artwork for the laser cutter is here. It’s Open Hardware.

osPID: A Forum of Our Very Own

Sun, 11 Mar 2012 12:19:32 +0000

With actual osPID units being spotted in the wild, we felt is was time to create a forum.

The goal here is a create a central place where people can get information, show off their awesome projects, and help to improve the osPID for everyone’s benefit.

So stop by when you get a chance. Help us leverage the power of open source to turn the osPID into the best PID Controller it can be.

osPID: osPID in the Wild

Fri, 09 Mar 2012 12:41:01 +0000

Huge thanks go out to Phil, who apart from identifying some early bugs has presented us with our first “in the wild” pictures!

He spent an hour or two the last couple of nights setting up a sous-vide rig: Two immersion heaters, a circulation pump, and a k-type thermocouple.

It’s hard to argue with results my friends. Being an engineer, there’s always a part of me that’s waiting for that huge flaw that I missed, the thing that will make what I did a complete failure. But it has not come to pass. osPID = tasty results. I’m over the moon.

Fabricatorz: Wise Futures and Shared Hardware, Part I

Fri, 09 Mar 2012 00:00:00 +0000

A couple of weeks ago I was invited to Academia Sinica in Taipei to address an audience of the Culturemondo forum on Smart Cultures, held alongside TELDAP and convened by Ilya Li. Ilya had asked me to prepare some remarks about open hardware culture, particularly as it relates to recent developments in Taiwan and China.

The Fabricatorz are often asked about "free and open" hardware. Jon shared his views on open hardware manufacturing during a talk he gave in Miami last December. It is not an idle topic for us, as we believe that investing in our own hardware platforms is just as important to the future of our business as is the software we create.

Can Hardware be Free?

The term 'open' hardware is used by way of analogy to free and open source software. The freedoms of 'free' software comprise the right to use, study, duplicate and improve that software. These freedoms as they relate to hardware apply not to the physical device itself, but rather to its design; for it is only the hardware design that can be truly studied, duplicated, and, most important, improved.

However, a process which begins with a free hardware design and ends with a finished product requires a non-trivial provision of capital, resources, skill, and time. This plain fact leads the founder of the free software movment, Richard Stallman, to conclude that "freedom to copy hardware is not as important, because copying hardware is hard to do."

I think the logic of that assessment is backward. The difficulty that hardware presents to our freedoms makes the issue more important, not less. It is the reason that we at Fabricatorz are investing time, money and talent to find solutions to the hardware dilemma. Recall the famous words of Alan Kay: "People who are really serious about software should make their own hardware."

Is Richard Stallman serious about software? I know we are.

Credits (images remixed by me on an M1):
Richard_Matthew_Stallman_working_on_his_Lemote_Machine
Alan_Kay_and_the_prototype_of_the_Dynabook

Free Electrons: Linux on ARM: xz kernel decompression benchmarks

Thu, 08 Mar 2012 13:33:43 +0000

I recently managed to find time to clean up and submit my patches for xz kernel compression support on ARM, which I started working on back in November, during my flight to Linaro Connect. However, it was too late as Russell King, the ARM Linux maintainer, already accepted a similar patch, about 3 weeks before my submission. The lesson I learned was that checking a git tree is not always sufficient. I should have checked the mailing list archives too.

The good news is that xz kernel compression support should be available in Linux 3.4 in a few months from now. xz is a compression format based on the LZMA2 compression algorithm. It can be considered as the successor of lzma, and achieves even better compression ratios!

Before submitting my patches, I ran a few benchmarks on my own implementation. As the decompressing code is the same, the results should be the same as if I had used the patches that are going upstream.

Benchmark methodology

For both boards I tested, I used the same pre 3.3 Linux kernel from Linus Torvalds’ mainline git tree. I also used the U-boot bootloader in both cases.

I used the very useful grabserial script from Tim Bird. This utility reads messages coming out of the serial line, and adds timestamps to each line it receives. This allow to measure time from the earliest power on stages, and doesn’t slow down the target system by adding instrumentation to it.

Our benchmarks just measure the time for the bootloader to copy the kernel to RAM, and then the time taken by the kernel to uncompress itself.

Loading time is measured between “reading uImage” and “OK” (right before “Starting kernel”) in the bootloader messages.

Compression time measured between “Uncompressing Linux” and “done”:

~/bin/grabserial -v -d /dev/ttyUSB0 -e 15 -t -m "Uncompressing Linux" -i "done," > booting-lzo.log

Benchmarks on OMAP4 Panda

The Panda board has a fast dual Cortex A9 CPU (OMAP 4430) running at 1 GHz. The standard way to boot this board is from an MMC/SD card. Unfortunately, the MMC/SD interface of the board is rather slow.

In this case, we have a fast CPU, but with rather slow storage. Therefore, the time taken to copy the kernel from storage to RAM is expected to have a significant impact on boot time.

This case typically represents todays multimedia and mobile devices such as phones, media players and tablets.

Compression	Size	Loading time	Uncompressing time	Total time
gzip	3355768	2.213376	0.501500	2.714876
lzma	2488144	1.647410	1.399552	3.046962
xz	2366192	1.566978	1.299516	2.866494
lzo	3697840	2.471497	0.160596	2.632093
None	6965644	4.626749	0	4.626749

Results on Calao Systems USB-A9263 (AT91)

The USB-A9263 board from Calao Systems has a cheaper and much slower AT91SAM9263 CPU running at 200 MHz.

Here we are booting from NAND flash, which is the fastest way to boot a kernel on this board. Note that we are using the nboot command from U-boot, which guarantees that we just copy the number of bytes specified in the uImage

In this case, we have a slow CPU with slow storage. Therefore, we expect both the kernel size and the decompression algorithm to have a major impact on boot time.

This case is a typical example of industrial systems (AT91SAM9263 is still very popular in such applications, as we can see from customer requests), booting from NAND storage operating with a 200 to 400 MHz CPU.

Compression	Size	Loading time	Uncompressing time	Total time
gzip	2386936	5.843289	0.935495	6.778784
lzma	1794344	4.465542	6.513644	10.979186
xz	1725360	4.308605	4.816191	9.124796
lzo	2608624	6.351539	0.447336	6.798875
None	4647908	11.080560	0	11.080560

Lessons learned

Here's what we learned from these benchmarks:

lzo is still the best solution for minimum boot time. Remember, lzo kernel compression was merged by Free Electrons.
xz is always better than lzma, both in terms of image size. Therefore, there's no reason to stick to lzma compression if you used it.
Because of their heavy CPU usage, lzma and xz remain pretty bad in terms of boot time, on most types of storage devices. On systems with a fast CPU, and very slow storage though, xz should be the best solution
On systems with a fast CPU, like the Panda board, boot time with xz is actually pretty close to lzo, and therefore can be a very interesting compromise between kernel size and boot time.
Using a kernel image without compression is rarely a worthy solution, except in systems with a very slow CPU. This is the case of CPUs emulated on an FPGA (typically during chip development, before silicon is available). In this particular case, copying to memory is directly done by the emulator, and we just need CPU cycles to start the kernel.

Free Electrons: How to boot an uncompressed Linux kernel on ARM

Thu, 08 Mar 2012 13:26:49 +0000

This is a quick post to share my experience booting uncompressed Linux kernel images, during the benchmarks of kernel compression options, and no compression at all was one of these options.

It is sometimes useful to boot a kernel image with no compression. Though the kernel image is bigger, and takes more time to copy from storage to RAM, the kernel image no longer has to be decompressed to RAM. This is useful for systems with a very slow CPU, or very little RAM to store both the compressed and uncompressed images during the boot phase. The typical case is booting CPUs emulated by FPGA, during processor development, before the final silicon is out. For example, I saw a Cortex A15 chip boot at 11 MHz during Linaro Connect Q2.11 in Budapest. At this clock frequency, booting a kernel image with no compression saves several minutes of boot time, reducing development and test time. Note that with such hardware emulators, copying the kernel image to RAM is cheap, as it is done by the emulator from a file given by the user, before starting to emulate the system.

Building a kernel image with no compression on ARM is easy, but only once you know where the uncompressed image is and what to do! For people who have never done that before, I’m sharing quick instructions here.

To generate your uncompressed kernel image, all you have to do is run the usual make command. The file that you need is arch/arm/boot/Image.

Depending on the bootloader that you use, this could be sufficient. However, if you use U-boot, you still need to put this image in a uImage container, to let U-boot know about details such as how big the image is, what its entry point is, whether it is compressed or not… The problem is you can’t run make uImage any more to produce this container. That’s because Linux on ARM has no configuration option to keep the kernel uncompressed, and the uImage file would contain a compressed kernel.

Therefore, you have to create the uImage by invoking the mkimage command manually. To do this without having to guess the right mkimage parameters, I recommend to run make V=1 uImage once:

$ make V=1 uImage
...
  Kernel: arch/arm/boot/zImage is ready
  /bin/bash /home/mike/linux/scripts/mkuboot.sh -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n 'Linux-3.3.0-rc6-00164-g4f262ac' -d arch/arm/boot/zImage arch/arm/boot/uImage
Image Name:   Linux-3.3.0-rc6-00164-g4f262ac
Created:      Thu Mar  8 13:54:00 2012
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    3351272 Bytes = 3272.73 kB = 3.20 MB
Load Address: 80008000
Entry Point:  80008000
  Image arch/arm/boot/uImage is ready

Don’t be surprised if the above message says that the kernel is uncompressed (corresponding to -C none). If we told U-boot that the image is already compressed, it would take care of uncompressing it to RAM before starting the kernel image.

Now, you know what mkimage command you need to run. Just invoke this command on the Image file instead of zImage (you can directly replace mkuboot.sh by mkimage):

$ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n 'Linux-3.3.0-rc6-00164-g4f262ac' -d arch/arm/boot/Image arch/arm/boot/uImage
Image Name:   Linux-3.3.0-rc6-00164-g4f262ac
Created:      Thu Mar  8 14:02:27 2012
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    6958068 Bytes = 6794.99 kB = 6.64 MB
Load Address: 80008000
Entry Point:  80008000

Now, you can use your uImage file as usual.

Video Circuits: New Complexity from LZX

noreply@blogger.com (Chris) — Thu, 08 Mar 2012 00:05:23 +0000

New Vids from LZX

osPID: Quick-Start Guide

Wed, 07 Mar 2012 22:41:34 +0000

With the first osPIDs making their way to customers, we’ve started receiving our first feedback emails.

The most obvious point made so far is that we were lacking a quick-start guide. I’ve since created a preliminary page for this here. This is a work in progress, but should give you everything you need to get up and running.

The second prominent issue was that the input card wasn’t reading correctly. This is strictly a firmware issue related to the switch from the MAX31855 back to the MAX6675. What this means is that everyone will need to update their firmware. DOH! The quick-start explains how to do this.

There will undoubtedly be more issues as the days go by. PLEASE complain to us. We will fix it and everyone will benefit. The only way we will be great is if we are told when we suck.

LZX Industries: A quick look at Triple Video Multimode Filter

Tue, 06 Mar 2012 21:11:49 +0000

Video Circuits: Unmute Collaboration

noreply@blogger.com (Chris) — Tue, 06 Mar 2012 10:27:03 +0000

I made a new glitchy video for an interesting site unmute.eu which pairs an audio and visual practitioner every fortnight around a theme and displays their work next to each other, an interesting idea!

my theme was interference and the audio half was compiled by Paul Nevermind

thanks to Sandra who asked me to be a part of the project, it's a great idea.

osPID: Pre-Orders Have been shipped

Mon, 05 Mar 2012 13:06:05 +0000

To Everyone who pre-ordered: Thank you, your unit is in the mail.

There are a few extra units that are being assembled as I write this. we’ll announce on twitter when orders are open.

We’re also working on our 2nd (larger) batch. hopefully this will remove availability as an issue.

Tuxbrain: Taller de iniciación a Arduino próximo 17/03/2012

Fri, 02 Mar 2012 16:00:55 +0000

Aquí estamos de nuevo, cual primavera tempranera, para ofrecerte una actividad de introducción al maravilloso universo de Arduino, el "taller de Iniciación a Arduino".

El próximo día 17/03/2012 de 11:00 a 14:00 horas realizaremos el taller en las instalaciones del centro Hangar

HANGAR.ORG
Passatge del Marquès de Santa Isabel, 40 (Can Ricart)
08018 Barcelona

Open Hardware Repository: White Rabbit Switch Testing - Jabber Meeting 22/02/2012

c.prados@gsi.de (Cesar Prados) — Fri, 02 Mar 2012 14:14:27 +0000

Open Hardware Repository: FMC DEL 1ns 4cha - 02-03-2012: review of V4 held

Erik.van.der.Bij@cern.ch (Erik van der Bij) — Fri, 02 Mar 2012 09:24:25 +0000

Harald Welte: The next project on the horizon: A Free Software CardOS

Fri, 02 Mar 2012 01:00:00 +0000

Now that we have a 100% free software GSM protocol stack and baseband firmware for the network and mobile phone side, the only remaining proprietary part is the SIM card. And what is a SIM card? It's a small embedded computer / SoC with integrated flash + RAM.

Once again, like in many other areas of the telecommunications industry, development of Free Software has been hampered by lack of available register-level hardware documentation. Without such information, how should you be able to program? Hardware without such documentation is an insult to every software developer.

The next problem is that typically, the Card Operating System (COS) is written into mask ROM of the smartcard SoC. Making such a mask is quite expensive, and it means that for every software version, different silicon will have to be produced. So unless you are going to have millions of units in quantity, it is unlikely that it would make economic sense.

However, in recent years, purely flash based smartcard chips have been available and getting less and less expensive. However, none of them (like the Atmel AT90SC7272 or similar devices) have freely available documentation. Furthermore, availability on the open market is somewhat of a problem, mainly because they have been used extensively by people cracking encrypted satellite TV channels. In recent years, the smartcard industry is trying hard to cut any kind of supply to that group of users.

However, luckily, we now see small/independent chip design houses in China picking up and producing their own smartcard chips. They are not only cheaper, but they simply hand out the documentation to anyone who asks them. No questions asked, no NDA required. Welcome to the promised land! That's what Free Software developers like:

Free access to documentation without any confidentiality agreements
development samples available at the same price as quantity pricing later on
inexpensive development hardware with JTAG access
reference source code provided without NDA
they are happy that somebody wants to develop for their hardware

As you can see, I am quite enthusiastic about this. I like this no-bullshit approach. No stupid marketing and sales droids who charge ridiculous fees for proprietary development tools that are inflexible and force developers to use one particular OS/IDE/toolchain.

I'm not sure how much time there will be, given the multitude of other projects that are all asking for attention. However, I think this is a chance that the Free Software community doesn't get every day. Let's hope some other people like bare iron programming in small embedded systems can get excited and we can create a FOSS COS. It doesn't have to be something serious. Something quite simple would be sufficient for the beginning. I'm not thinking of EAL4+ certification, multiple channels and public key crypto. SIM/USIM cards are simple, they just require a bit of filesystem read/write operations plus authentication. And luckily, SIM toolkit development doesn't have to be done in Java this way, either ;)

Harald Welte: OsmoSDR status update

Fri, 02 Mar 2012 01:00:00 +0000

It has been two months since I first was able to play with the OsmoSDR hardware prototypes. Back at that time, there was no FPGA code yet, and some hardware bugs still had to be resolved. Nonetheless, the e4k tuner driver could already be implemented and tuning was confirmed by looking at the analog i/q spectrum.

Meanwhile, the hardware has been re-worked by SR-Systems and FPGA VHDL code written by maintech.de. Ever since that, they dropped the ball again with me as I had been careless enough to volunteer for writing the firmware.

And that's what I did or at least tried to do for quite some time during the last two weeks. The main problem was that I didn't have much time. The second problem was that I never was able to get the SSC (synchronous serial controller) receive DMA working.

This was a really odd experience, as I've worked a lot with that very same SSC peripheral before, while writing firmware for the OpenPICC some 6 years ago. However, this was in an at91sam7s, where the SSC is interfaced with the PDC (Peripheral DMA Controller). In the at91sam3u of OsmoSDR, it interfaces with a more modern DMAC/HDMA controller, capable of scatter-gather DMA and other fancy stuff.

Atmel has provided reference code that uses the SSC DMA in transmit mode (for a USB audio device playing back music via the Wolfson codec on the SAM3U-EK board). After thoroughly studying the DMAC/HDMA documentation I set out to write code for DMA-based SSC receiver. And it never worked.

I actually wrote two independent implementations, one from scratch and the other based on Atmel reference code. Neither of them worked. It seemed to be a problem with the hardware hand-shaking between SSC and DMAC. The SSC was successfully receiving data, and that data could be read out from the CPU using a polling or IRQ based driver. But if you're running at something like 32 Mbps and don't have a FIFO, you desperately want to use DMA. When the DMA handshaking was turned off, the DMA code worked, but of course it read the same received word several thousand times before the next data arrived on the SSC.

In the end, I was actually convinced it must be a silicon bug. Until I thought well, maybe they just connected the flow controller to a different ID in Rx and Tx direction. Since there are only 16 such identifiers, it was relatively easy to brute-force all of them and see if it worked. And voila - using the identifier 4, it worked!

So what had happened? The Atmel-provided reference code contained a

 #define BOARD_SSC_DMA_HW_SRC_REQ_ID      AT91C_HDMA_SRC_PER_3

and that was wrong. 3 is valid for SSC TX but not for SSC RX. Unfortunately I never found any of those magic numbers in the SAM3U manual either. They are not documented in the chapter of the SSC, and they are not documented in the chapter about HDMA/DMAC either. And they are not identical with the Peripheral Identifiers that are used all over the chip for the built-in peripherals.

In case anyone else is interested, a patch can be found at my at91lib git repository.

I filed a ticket with Atmel support, and they pointed out in fact there was a table with those identifiers somewhere in the early introductory chapters where you can see a brief summary of the features of each integrated peripheral. Unfortunately they use slightly different naming in that chapter and in the DMAC, so a full-text search also didn't find them. Neither is that table visible in the PDF index.

So about four man-days later it was finally working. Another day was spent on integrating it with the USB DMA for sending high-speed isochronous transfers over the bus into the PC. And ever since I'm happily receiving something like 500,000 or 1,000,000 samples / second from an alsa device, using snd-usb-audio. Luckily, unlike MacOS or Windows, the Linux audio drivers don't make arbitrary restrictions in the sample rate. According to the USB Audio spec, the sample rate can be any 24bit number. So audio devices with 16.7 Ms/s are very much within the spec. I hope some of the other OS driver writers would take that to their heart.

One of the first captures can be found at this link, containing a bzip2ed wave file in S16LE format Stereo (I/Q). It contains a FM audio signal transmitted using a small pocket-sized FM transmitter.

There is no I/Q DC offset calibration yet, but once that is done we're probably able to finally put the design into production.

Harald Welte: More research into the Motorola Horizon macro and Mo-bis

Thu, 01 Mar 2012 01:00:00 +0000

Once upon a time there was an Americans company called Motorola, and they decided to implement GSM. Unfortunately they decided to deviate significantly from the specification and implement their own proprietary back-haul protocol between BTS and BSC, called Mo-bis. It replaces the standardized A-bis interface.

Today, There are plenty of phased-out Motorola Horizon / Horizon II macro BTSs that have been phased out. Basically you can get them for scrap value, which makes them an ideal target for GSM enthusiasts willing to run a single-cell network with little investment. So while there are actually people who are interested in operating a power-consuming device roughly the size of a washing machine in their home/office - they are normally not interested in running a 19" rack sized Motorola BSC with it. Also, the BSCs are much less frequently to be found compared to the BTS.

So it would be great to support Mo-bis from within OpenBSC. A couple of brave young men have set out to try the seemingly impossible. There's absolutely zero documentation available on that protocol, and no wireshark support either. However, the University of Brno (Czech) has a functional Motorola BTS + BSC setup, and I was able to obtain protocol traces from them and actually experiment with the equipment in their lab.

The entire Motorola GSM architecture seems to be over-engineered without end. Basically you are looking at a distributed computer from the early 1990ies. Lots of processor cards (m68k, ppc) interconnected by HDLC links on top of synchronous 2Mbps links with 64k timeslots. Those links are available e.g. on the backplane of the BTS as a TDM highway. So basically even inside the BTS, the individual processors talk over E1 to each other. In the BSC, there is a token ring based LAN between some of the cards instead. And the MCUF in the BTS even supports to transport those proprietary inter-cpu links via fiber optic (!).

Each processor has a 16bit identifier by which it can be addressed in form of physical addresses. Individual processes on the processors have fixed process identifiers, and they allocate a variety of mailboxes in which they can receive messages from remote processors. There are routing functions at intermediate notes.

So any process on any processor card can send messages to any mailbox of any other process on any other processor, independent of its physical location (locally at the BTS, or at the remote BSC, or even at remote BTSs).

Besides physical addresses, there are also functional addresses. Thos addresses are used particularly to support fail-over. Every board in a BTS and BSC can be fully redundant, and if you use physical addresses, you would address one of the two redundant boards. Using functional addresses, you address the function they both can perform, and some routing magic will make sure it ends up at the current active node in the pair.

There are multiple processors in every TRX, and a couple of processors for each BTS, processors in the E1 line cards, etc. Now speaking of the actual Mo-bis interface: It seems to be a weird mixture between 08.58 (RSL) and 08.08 (BSSAP/BSSMAP). However, after staring at the messages sufficiently long, I have been able to write a more or less complete wireshark dissector for them. Radio Channel Activation (RACH/IMM.ASS) are for example handled directly inside the BTS, they don't exist as transactions on the Mo-bis like they do in A-bis.

So implementing the actual location update / MO+MT voice call and SMS related transactions is actually not all that hard. What makes things really difficult is the way the BTS is initialized at startup. Basically what resembles the OML part of standardized A-bis.

There is a lot of low-level management and bring-up of the individual processes and boards, and the download of a large 500 kByte-sized BLOB simply called database. This binary database contains literally hundreds of configuration parameters for the BTS and its neighbors. It also contains sophisticated configuration of the message routers, the switching/multiplexing of 64k timeslots on the various links, information on redundant paths within the back-haul network, etc.

Interestingly, using the password combination 3beatles and 4stooges on any of the serial consoles of the BTS or BSC, you can enter into a "god-mode" which permits you to enter the executive monitor (EMON). The executive is the operating system they run on both m68k and ppc processors. It provides access to something like a syslog of messages from the various processes, and you can manually generate messages that are to be sent to mailboxes of processes. You can inspect the object table (application programs an databases), read/write to PCMCIA flash cards, read and write to logical and physical memory, inspect CPU and I/O usage and much more. In fact, the integrated Code Object Manager (COM) even allows the processors to synchronize their code versions and remotely boot other CPUS via HDLC channels.

For a communications system geek like myself, it's extremely fascinating to see such a sophisticated and versatile system. I only wonder why on earth somebody would come up with something as complex, only to connect a couple of BTSs to a BSC. Thus, the only logical explanation is that Motorola has developed this distributed proprietary computing system way before they went into GSM, and they probably just recycled it as it already existed.

If anyone knows more about the history of this, I would be excited to hear about it. It literally feels like being an archaeologist. Analyzing ancient technology from our forefathers. But then, it only is 20 odd years old. The only time I had a similar feeling was when I briefly came in touch with IBM mainframes in 2001 and looking at IBMs SNA protocol stack.

Video Circuits: THAT'S INTERESTING

noreply@blogger.com (Chris) — Wed, 29 Feb 2012 14:12:19 +0000

Jennifer Juniper Stratford

Video Circuits: octal_hatch (excerpts)

noreply@blogger.com (Chris) — Wed, 29 Feb 2012 14:10:51 +0000

Brian O'Reilly

Chitlesh Goorah: [FEL]: New stable release of perl-Verilog-Perl

Tue, 28 Feb 2012 19:36:13 +0000

Verilog-Perl 3.314(15926 – the PI version!) is released and pushed to Fedora and EPEL6 testing repositories.

Verilog::Language 3.314 2012/02/27 ChangeLog
- vhier –forest and –instance. [by John Busco]
- Fix expansion of back-slashed escaped macros, bug441. [Alberto Del Rio]
- Fix -F relative filename parsing, bug444. [Jeremy Bennett]
- Fix c style var array declarations. [by Jack Cummings]
- Fix –debug parsing after -f files, bug442. [Jeremy Bennett]
- Fix hang on recursive substitution `defines, bug443. [Alex Solomatnikov]

Bunnie Studios: “The Amp Hour” Podcast

Tue, 28 Feb 2012 08:55:25 +0000

I was a guest on this week’s The Amp Hour radio show. It was good fun having a chat with show hosts Dave Jones and Chris Gammell — talked about everything from PCB design at 35,000 feet to life in Asia to NeTV and the legal challenges of system design.

Richard Hughes, ColorHug: colord-kde progress

Mon, 27 Feb 2012 17:37:54 +0000

In a few short days we’ve already got the colord-kde repo up, and Daniel and I have been writing some initial code. Several more people have offered to help this week too.

If you know C++ and Qt please send me a patch for one of the TODOs in the kded module. Most are simple, for instance //TODO: get the md5 checksum of the data

Video Circuits: Protothon Article "I got 99 problems but a glitch 'aint one"

noreply@blogger.com (Chris) — Mon, 27 Feb 2012 13:51:58 +0000

So my friend Joe who runs creative coding hackathons, talks & workshops did a nice write up of my work including my series of images "I got 99 problems but a glitch 'aint one" as a kick off of the new blog on the Protothon site

anyway the next Protothon event is based on WebRTC at Google Offices in Stockholm on the 24.03.2012 and looks like it's going to be allot of fun, WebRTC is basically enables web browsers with real time communications functions like in browser skype. However the fun doesn't stop there as it opens up all sorts of creative possibilities to anyone willing to experiment with the Javascript APIs and HTML5!

GNSS-SDR: From a Bundle of ARM+FPGA to FPGA only

Mon, 27 Feb 2012 13:51:32 +0000

In one of the previous posts I have described a simple project that realized a basic block of any GNSS-receiver. This block realized the following tasks:
1. Signal acquisition;
2. Confirmation of signal acquisition;
3. Pull-in process during which rough estimates of signal delay and Doppler shift were specified.For that project I used a hardware that included two main chips: FPGA and mcu. Correlator was made in FPGA and ARM7-based mcu was used to control correlator.
But modern FPGA allow to build SoC in them. SoC = System on Chip is an integrated circuit that integrates all components of a computer or electronc system on a single chip.
Typical SoC incorporates the following components:
- one or several microprocessors/microcontrollers/digital signal processors;
- memory blocks including ROM/RAM/EEPROM/FLASH;
- timing sources including oscillators and phased locked loops (PLLs);
- timers;
- external interfaces: USB/FireWire/Ethernet/USART/SPI/and so on;
- ADCs/DACs;
- interface bus that connects all blocks (wishbone/AMBA/so on).

So the step from a FPGA+MCU towards FPGA only seems very attractive.

There are several open-source SoCs that can be implemented in FPG:
1. GRLIB IP LIBRARY – project of european company Gaisler ( http://www.gaisler.com... );
2. MILKYMIST (MM) SoC – open-source community project, headed by Sebastien Bourdeauducq ( http://milkymist.org/wp/for-developers/ ).
Due to a number of resons the later project was chosen:
1. MM SoC demands less FPGA resources;
2. Digilent s3e500 port was found in internet and I have this board;
3. Cristian Paul Peñaranda Rojas could make me interested in this project ;)
4. This SoC is used in commercially available device Milkymist One;
5. SoC is written in verilog for Xilinx FPGA Spartan6 but ports for spartan3e, spartan3a and for Altera's FPGAs also exist.
Digilent s3e500 MM SoC port is available through the link: http://code.google.com/p/gnsssdr/source... . This project is based on the source code published on the forum ( http://electronix.ru/forum/index.php?showtopic=96942&hl=milkymist ).

Besides moving to MM SoC also program that realizes a basic block of any GNSS-receiver was upgraded. The program can now work with several channels in parallel (with 2 channels in the current version). Information about each channel is displayed on the terminal-screen now.:
1) SV number of the current channel;
2) Channel state (1 - acquisition; 2- acquisition confirmation; 3 - pull-in process; 4 - signal tracking);
3) Delay in each channel (in PRN half-chip units);
4) Doppler frequency of each channel (without tacking into account TCXO instability).

Program output is shown on figure 1.

Figure 1 Program output.

The source code is available through the link: http://code.google.com/p/gnsssdr/source...

05.04.2012 UPD! Similar results with single channel tracking with the help of Namuru-correlator and Altera FPGA based SoC are received by Tukuji: http://blog.goo.ne.jp/osqzss/...

Video Circuits: Felisha Ledesma

noreply@blogger.com (Chris) — Mon, 27 Feb 2012 13:50:45 +0000

Good Amount - Orange Pack from Felisha Ledesma on Vimeo.

Good Amount - Data Time from Felisha Ledesma on Vimeo.

Felisha Ledesma

Tuxbrain: SmartTop Efika MX "Poor Man" VESA Mount

Sun, 26 Feb 2012 23:31:26 +0000

Topic says all :), we have found a cheap and easy way to mount the Efika MX SmartTop in the back off a monitor/TV with a free Vesa mount , the solution is so cheap that we will include a a kit with the necessary if you buy one from our shop :) here is the HOWTO:
The key is this little piece of plastic:

Antitronics: Latest work on the knitting machine stuff

Sun, 26 Feb 2012 20:20:21 +0000

Lately I’ve been working on the knitting machine code some more. First, the thing that will affect fellow hackers and knitters the most -

Update 3/1/12: After some more thought, I’m recommending against simply using a serial adapter, as I had previously written here. My reasoning is this -

While I’d like to make it as easy as possible for people to connect to their knitting machines, I’ve only tested this on one model of machine. A standard USB serial module may present voltages to the knitting machine which are outside the range that the external drives do. While I’ve determined that this is probably safe for the one model of knitting machine that I have, I can’t be sure that it’s not going to stress the input circuitry on some models. The absolute safest way to do this is to use the exact same signal voltages that the external disk drive does. In order to do this, using an FTDI interface is the best way. The cost for using adafruit’s “FTDI Friend” is only about $5 more than using a standard serial interface, and since these old knitting machines are irreplaceable and often very expensive when you can find them, I’d rather do this the absolute safest way. I have no reports of problems from using regular serial interfaces, but I think that this is a case where absolutely correct engineering is more appropriate than a hack to save a few dollars.

I’ll be updating the wiki page very soon with directions for how to use the FTDI Friend to interface with the knitting machine.

I’ve now thoroughly tested connecting a PC to the knitting machine using only a standard USB serial adapter. This means that you don’t have to fool with FTDI interfaces, inverting signals, etc. All it takes is a serial adapter, a female DB-9 connector, and four jumper wires. That’s documented on the wiki page.

This makes it much easier for the less technical among us to connect their machine to a computer.

The rest will have more impact in the long run . . .

I’ve obtained an actual Brother FB100 external floppy drive, and successfully connected it through a serial adapter. It requires a 5V adapter – I’m using the adafruit FTDI friend. It’s a little complex – you have to rejumper and reprogram the FTDI friend. That’s also documented on the wiki page here.

There are some files currently in the ‘experimental’ directory in the source repo which communicate with the disk drive, and extract information from knitting machine disks into the format used by my disk emulator. I’m planning to use these to help fill in some gaps in knowledge about the file format used by the knitting machine.

Most people won’t have use for this code to interface with the floppy drive, as the drives are rare.

I have other plans for this investigation, so I may have more to say about it soon.

Geoffrey L. Barrows - DIY Drones: New ArduEye using Stonyman image sensor chips

Sat, 25 Feb 2012 21:25:30 +0000

Awhile ago we (Centeye) started ArduEye, a project to implement an open source programmable vision sensor built around the Arduino platform. The first ArduEye version used a simple Tam image sensor chip and a plastic lens attached directly to the chip. After much experimentation and some feedback from users, we now have a second generation ArduEye.

The second generation ArduEye is meant to be extremely flexible, ultimately allowing one to implement a wide variety of different sensor configurations. A basic, complete ArduEye is shown below, and contains the following basic components:

An Arduino- Currently we are supporting Arduino UNO-sized boards (e.g. UNO, Duemilanove, Pro) and the Arduino MEGA. When the ARM-driven DUE comes out, we will surely support that as well.

A shield board- this board plugs into the Arduino, and has a number of places to mount one or more image sensor breakout boards. This shield also has places to mount an optional external ADC as well as additional power supply capacitors if desired.

A Stonyman image sensor on a breakout board- The Stonyman is a Centeye-designed 112x112 resolution image sensor chip with an extremely simple interface: 5 digital lines in, which are pulse in predefined sequences, and one analog line out, which contains the pixel. The Stonyman chips are wirebonded directly to a 1-inch square breakout board, which can plug into the shield.

Optics- Possibilities include printed pinholes, printed slits, and cell-phone camera lenses, depending on what you want to do.

Example application- The "application" is an Arduino sketch programmed into the Arduino. This sketch determines what the ArduEye does. One sketch can make it track bright lights, another sketch can measure optical flow, and so on. We are releasing, initially, a base sketch that demonstrates light tracking, optical flow, and odometry. Let us know what other example applications you would like to see.

ArduEye libraries- These libraries are to be installed in your Arduino IDE's "libraries" file, and include functions to operate the Stonyman image sensor chip as well as acquire and process images, including measuring optical flow.

GUI- Finally, we created a basic GUI that serves as a visual dump terminal for the ArduEye. You can now communicate with the ArduEye via either the GUI or the basic Arduino IDE's serial terminal. The GUI was written in Processing.

We designed the system to allow easy hacking to implement a wide variety of vision sensors by exploring combinations of optics, image sensing, and image processing. I personally find it useful, and actually use this system for prototyping things at Centeye- I can prototype a new vision sensor in just a couple hours. The target applications are quite broad and include just about anything that may use embedded vision, whether robotics, sensor nets, industrial controls, interactive electronic sculptures (yes this has come up), and so forth.

The video at the top shows some of the basic things you can do with this ArduEye. You'll see the ArduEye interfacing with a host PC using both the Arduino IDE's serial terminal and the ArduEye GUI. For more details, including links to the hardware design files and source code, go to the ArduEye wiki site. The site is a work in progress, but is adequate to get people started. The sample "first application" and GUI is what was used to generate the above video.

Right now we are having 200 Stonyman breakout boards being assembled- they should be ready within a month. We'll make more if this is well-received. We can assemble a few in-house at Centeye- I'll do this if enough people twist my arm and promise to really play with the hardware. :)

Please let me know your thoughts. In particular, are there any other "sample application" sketches you'd like us to implement?

Free Electrons: Embedded Linux Conference day 3

Sat, 25 Feb 2012 05:30:54 +0000

Finally, the last day of the 2012 edition of the Embedded Linux Conference has arrived. Including the Android Builders Summit, it was a very busy week with five full days of presentations, a very intensive learning session, but also highly motivating and refreshing. Here is, with a little bit of delay, the report of this last day.

Thanks to the kind help of Benjamin Zores (from Alcatel/Lucent, the GeeXboX and OpenBricks projects) who kindly accepted to record the Userland Tools and Techniques For Linux Board Bring-Up and Systems Integration, both Grégory and myself could attend the talk from Greg Ungerer titled M68K: Life in the Old Architecture. Greg started with a very nice and clear explanation of the history of the 68k architecture from a hardware perspective, and detailed its evolution into the Coldfire architecture. The history is quite complicated: the first 68k processors had no MMU, and then MMU was added starting at the 68030 family. However, when Freescale started with Coldfire, which uses a subset of the 68k instruction set, they removed the MMU, until Coldfire V4e, on which an MMU is available. Originally, the Linux port in arch/m68k only supported the classic 68k with MMU, and support for non-MMU Coldfires was added in uClinux. Later, support for non-MMU Coldfires was added into the mainline kernel in arch/m68knommu, with unfortunately a lot of duplication from arch/m68k. The two directories have been merged again some time ago: the merge had already been done in a mechanic fashion (merging identical files, renaming different files that had similar names), and a huge cleanup effort has taken place since then. The cleanup effort is not completely done yet, but it’s getting close, according to Greg Ungerer. At the end of the session, there has been a question on how m68k/coldfire developers typically generate their userspace, and Greg said he uses something similar to Buildroot, which in fact is uClinux-dist. I jumped in, and said that we would definitely like to have Coldfire support, especially since the activity on uClinux-dist isn’t very strong. I also asked what were the remaining differences between the uClinux kernel and the mainline kernel, and according to Greg, there is almost no difference now except maybe support for a few boards. Greg only uses the mainline Linux kernel now for his m68k and Coldfire developments.

The next conference I attended was the talk from Gary Bisson (Adeneo Embedded) titled Useful USB Gadgets on Linux. I rescued the speaker by lending my laptop because his laptop had no VGA output. Fortunately, the speaker was French, so he could adapt quickly to our bizarre azerty keyboard layout. Gary gave quite a bit of context on what USB is, and explained the USB terminology such as interfaces, end-points, configurations, etc. He then quickly described the Linux USB Gadget stack and gadgetfs for the implementation of USB gadget drivers in userspace. He then presented the existing USB gadget drivers in the kernel, mainly the zero gadget driver (for testing purposes), the mass storage gadget driver, the serial gadget driver and the Ethernet gadget driver. At the end of the presentation, he made a demonstration on a BeagleBoard-XM with the gadget multi driver, which allows to expose multiple gadget interfaces at the same time. So he showed that he could expose the Ethernet interface, the Mass Storage interface and the Serial interface, and demonstrated their usage from the host machine. Overall the talk was good, but I was personally expecting a more in-depth look at USB Gadget driver development, and not only usage: I have already been using gadget drivers for some time now, and I was more interested in having details on developing custom gadget drivers rather than simply on using the existing ones.

Free Electrons engineering team (missing: Michael Opdenacker). From left to right: Grégory Clément, Maxime Ripard and Thomas Petazzoni

After a quick break, Grégory and I attended the Getting the First Open Source GSM Stack in Linux talk by Marcin Mielczarczyk from Tieto. It was an absolutely excellent talk. Marcin described the work he and one of his colleague did to reverse engineer a cheap Chinese phone and port U-Boot and Linux on it. Marcin started by giving details about the landscape of those cheap Chinese phones, and it was quite funny: there are brands like Nokla, Sany Eracsson or SciPhone that create phones that are similar in shape and design to phones from the original brands, but with completely different hardware, and usually completely different software. Marcin said that the great thing about those phones is that they are really cheap (which is nice when you need to do some hardware modifications on them for reverse engineering purposes), can easily be bought from auction sites like eBay, and usually do not use any sort of encryption or signature mechanism to prevent the execution of a different operating system or bootloader. The motivation of Marcin in getting Linux to run on such a phone was to ultimately be able to run the complete OsmocomBB software GSM stack inside the phone. OsmocomBB is a free software implementation of a GSM communication stack, lead by Harald Welte. For the moment, the OsmocomBB project uses phones based on the Calypso based-band processor, and only use the phone for the layer 1 (physical layer) of the communication, while the above layers (layer 2 and 3) are implemented in a PC that communicates with the phone over a serial port. Marcin would like to integrate everything inside the phone itself, in order to make the free software GSM stack completely autonomous and fully usable directly on the phone. Marcin decided to pick the SciPhoneDreamG2, a phone that uses the Mediatek 6235 processor, which has the great advantage of being an ARM9 processor, allowing to run a full-blown Linux, and having a datasheet available on the Web. The original operating system of the phone is Nucleus, on top of which the Chinese brand has added an interface that completely mimics Android but is not Android at all. Marcin described the work he did to understand where the UART port and JTAG port was connected (for this work, he mentioned the usage of the JTAG finder project, a software one can run on a micro-controller and that automatically finds which pins are the JTAG pins of a processor). Once he had access to a serial console and the JTAG, he dumped the memory, and started understanding how the boot process was working, and how the existing boot loader was initializing the DRAM. This work was completely done by disassembling the code, which required quite some effort, according to Marcin. Once this was done, he said that porting U-Boot only required creating a basic UART driver and a timer driver, and porting a basic Linux only required a similar UART driver and timer driver, but also an interrupt driver. Marcin and his colleague then went one in developing the other drivers, such as SD, USB, GPIOs and more, and they detailed some of the issues they faced and the time required for these different tasks. In the end, the project is not yet finished, since OsmocomBB does not run on the phone yet, but this is the next goal for Marcin and his colleague. In the end, it was a very interesting goal, detailing in an informative and amusing way an absolutely excellent reverse-engineering effort conducted by Marcin. I would strongly recommend watching the video of this talk.

Pin Control Subsystem Overview Linus Walleij

The last afternoon of ELC started with a talk from Linus Walleij from Linaro, Pin Control Subsystem Overview. Linus Walleij started by describing with lots of details how I/O pins are implemented from a hardware perspective. He first described a basic I/O pin, on which the software can just control the level. On top of this, he explained the hardware logic used to generate interrupts and wake-up events from I/O pins. And finally, he added that those I/O pins are nowadays commonly multiplexed since the SoC do not have enough pins to expose all their possible features, so a given pin can be used either for one function (say, one pin of a I2C bus) or another function (say, one pin of a parallel LCD interface) or as a general purpose I/O. Since this multiplexing is controlled by software, the code for the various ARM sub-architectures in the Linux kernel have each implemented their own little framework and API to solve that problem, and it’s up to each board file to set their I/O multiplexing settings. Unfortunately, since each ARM sub-architecture has its own implementation, there is no coherent API, and there is code duplication. Linus Walleij’s pin mux subsystem intends to solve that. It has already been merged in mainline, in the drivers/pinctrl directory, and a few ARM sub-architectures have started using it, with more to come in the near future, said Linus. Basically, the pinmux subsystem allows to describe which pins are available on the SoC, how they are grouped together in functions, and how drivers can select which function should be activated at an I/O multiplexing level. Of course, the pinmux subsystem detects conflicting usage of I/O, for example if two different drivers want to use the same pin with a different function. Linus also clarified how drivers for I/O pins block should be implemented in the kernel now. If what you have is a simple GPIO expander, then the driver for it should lie in drivers/gpio and it should use the gpio_chip structure. If this simple GPIO expander is also capable of generating interrupts, then the driver should still be in drivers/gpio, but in addition to the gpio_chip structure, it should also register an irq_chip structure. And finally, if instead this I/O pin controller supports multiplexing, then the driver for it should be implemented in drivers/pinctrl, and it should register into the GPIO subsystem (through the gpio_chip structure), into the IRQ subsystem (through the irq_chip structure) and into the pinmux subsystem (through the pinctrl_desc and other related structures). All in all, Linus’s presentation was a great talk, but I wished he would have put more details on the actual API and data structures: his description of the data structures through UML diagrams were a bit hard to follow.

For the last session of the day, I initially planned to attend Pintu Kummar’s talk on Controlling Linux Memory Fragmentation and Higher Order Allocation Failure: Analysis, Observations and Results, but this session was unfortunately canceled. Therefore, I joined my colleague Maxime Ripard and attended Lucas de Marchi talk about Managing Kernel Modules With kmod. Basically, about a year ago, Lennart Poettering, developer of the systemd new userspace init implementation for Linux, listed a set of topics that he wanted to see improved in Linux to make the initialization sequence perform better. Amongst them was the development of a userspace library to manage kernel modules (query information, insert and remove modules). The problem is that until now, the only way to load and remove modules was to call the modprobe, insmod or rmmod programs, which for each module load operation, required a costly sequence of fork/exec. Since udev tries to load up to 200-300 modules at startup (sometimes just to discover that the module is already loaded), this takes a significant amount of time. So Lucas de Marchi, who works at ProFUSION, decided to step up, and did the implementation of kmod. kmod is composed of a C library which implements the core logic of the module information query, module loading and module removal operation, supporting all the fine details that modprobe was supporting (such as dependency handling, module aliases and the configuration files in /etc/modprobe.d/ with options for modules, blacklisted modules). kmod also contains replacement programs for the insmod, lsmod, rmmod and modprobe programs, directly inside a single kmod binary, with symlinks pointing to it for the various commands. kmod is now a full replacement for the old module-init-tools, which has been marked as obsolete by his former maintainer, Jon Masters (who has joined the kmod project). Desktop distributions have started to pick up kmod (Arch Linux, Fedora, and Debian in experimental), as well as embedded Linux build systems. Lucas mentioned that Buildroot had the latest version of kmod, while OpenEmbedded had a slighly older version, and that he didn’t know about other build systems. In the end, this kmod project does not bring a lot of new features or innovations, but is a well-appreciated initiative to make module management better in Linux. What’s very impressive in the time frame in which the project was done: in about a year, the project got started, the development was done, and it is now a full replacement of the old solution, which has been marked deprecated. Great job!

Managing Kernel Modules With kmod, Lucas De Marchi

Finally, as every ELC, the conference was closed with a game involving all the attendees, and allowing to win nice prizes such as development boards, USB scopes, audio/video portable players (PMPs), and more. The game started with a set of geek questions (such as “Will the Linux kernel in version 3.3 have more or less than 15 millions lines of code ?”, or “Is the distance from the Earth to the Moon smaller or higher than 150.000 miles ?”), and then a rock/paper/scissors game, and finally a raffle. This closing game is always a nice way of ending ELC.

This year’s edition of the Android Builders Summit and the Embedded Linux Conference have been great, with lots of interesting technical talks, and lots of side discussions with various developers. Many thanks to the conference organizers and speakers!

Embedded Linux Conference Europe 2012

We hope that those five blog posts reporting some details about those conferences have been interesting to those who didn’t have the chance to attend, and we are definitely looking forward the next edition of the Embedded Linux Conference Europe, which will take place in Barcelona from November 5th to November 7th. Note that the call for paper has already been published. It’s time to think about what you’re doing in the embedded Linux world, and to propose a corresponding talk!

Elphel: HomeSide 720° – A helmet mounted panoramic camera

Sat, 25 Feb 2012 00:18:34 +0000

Seeing the impressive images of the Elphel-Eyesis 4pi camera I thought it’s time to tell you about the HomeSide 720°. Like the Eyesis its purpose is to capture panorama frames with a framerate of 5fps. The major difference is that the HomeSide 720° is mounted on a helmet. To have an acceptable weight it consists of only two instead of eight Elphel 353 delivering one forth of the resolution the 4pi does. Thus the camera is able to record 30MPix frames before stitching. Additionally it’s reconfigureable to enable HDR panorama frames. More interesting probably is the purpose it was built for. We created the assembly for indoor virtual tours. After several drawbacks we finally have an approach which works very well. We do auto leveling, auto stabilization and path extraction by image analysis only. Furthermore we recognize crossing points where the user can decide where to go when the tour is shown in the player. This is not so easy since we neither have GPS nor IMU data. Nevertheless its possible. All this information goes into our new webplayer which reassembles the images to a virtual tour. Have a look at the HomeSide 720° Virtual Tour [1] Click into the player and use the cursor keys to navigate. You may also click and drag to change the point of view. This tour was recorded with 10MPix i.e. one Elphel 353 with two sensors. Important: The pi symbols shows a rendered tour, not recorded by the camera At the moment we are improving the image quality. We are also looking for a partner to drive the development even faster to create stunning indoor virtual tours. [1] https://homeside.at/html/inside-demo.html

Elphel: Run ImageJ plugins from the command line in Ubuntu

Sat, 25 Feb 2012 00:18:34 +0000

1. Get X Virtual FrameBuffer [1] sudo apt-get install xvfb 2. Launch ImageJ ("cd" to the ij.jar directory): Xvfb :15 & DISPLAY=:15 java -Xmx12288m -jar ij.jar -run "TestIJ Plugin" Comments: TestIJ Plugin is the name of the compiled plugin in the ImageJ menu. No need to specify a subfolder. :15 is an example. Links that helped: Source 1 [2] Source 2 [3] Source 3 [4] [1] http://en.wikipedia.org/wiki/Xvfb [2] http://stackoverflow.com/questions/4599618/how-to-add-3rd-party-jars-to-compile-time-classpath-in-jgrasp [3] http://imagej.1557.n6.nabble.com/How-to-set-DISPLAY-environment-variable-when-running-ImageJ-with-NO-SHOW-option-td3686181.html [4] http://cmci.embl.de/documents/100922imagej_cluster

Transmaterial: Power Felt

Fri, 24 Feb 2012 15:00:46 +0000

Scientists at the Center for Nanotechnology and Molecular Materials at Wake Forest University have developed a thermoelectric fabric that converts body heat into electricity. The material is made of layers of interlocking carbon nanotubes and plastic fibers, and feels similar to felt. The thermoelectric technology develops electric current from temperature differences, such as the difference between anatomical temperature and room temperature.

According to Wake Forest researcher Corey Hewitt, “We waste a lot of energy in the form of heat. For example, recapturing a car’s energy waste could help improve fuel mileage and power the radio, air conditioning or navigation system. Generally thermoelectrics are an underdeveloped technology for harvesting energy, yet there is so much opportunity.”

The first prototypes of Power Felt yielded 140 nanowatts of power from 72 layers of nanofabric, and the researchers are currently attempting to increase the output of the technology.

“I imagine being able to make a jacket with a completely thermoelectric inside liner that gathers warmth from body heat, while the exterior remains cold from the outside temperature,” says Hewitt. “If the Power Felt is efficient enough, you could potentially power an iPod, which would be great for distance runners. It’s definitely within reach.”

Contact: Wake Forest University, Winston-Salem, NC, USA.

Richard Hughes, ColorHug: Looking for a cool KDE person

Wed, 22 Feb 2012 09:49:28 +0000

GNOME has been a color managed desktop by default for two releases now, and I deliberately designed colord to have an open Freedesktop DBus API that could be used by both desktops. I am a little disappointed in KDE that it hasn’t made the jump too. Really, KDE just has to include a KCM module to do the 6 things on this list and also perhaps include a simple control center panel to configure it.

Basically, I need a KDE dude. Of course, I can help quite a lot and mentor the project, but I’ve never really coded Qt or C++ in anger, so to speak. If you’re interested, I could maybe even set up a Google summer of code place as well, although I’d prefer it to be an existing person familiar with the KDE community so there is some ongoing maintainer.

If anybody is interested, let me know and I’ll set up a meeting and we can talk and discuss details. Thanks.

Freetronics: Arduino digital clock using the Dot Matrix Display

Tue, 21 Feb 2012 09:52:58 +0000

Forum member "Buzbot" has posted a cool video showing a digital clock he created based on John Boxall's clock code. Check this out:

Read more in our forum: http://forum.freetronics.com/viewtopic.php?f=26&t=187

Open Hardware Repository: FMC Projects - 21-02-2012: XTech FMC front-panel kit eases ordering

Erik.van.der.Bij@cern.ch (Erik van der Bij) — Tue, 21 Feb 2012 08:35:04 +0000

Free Electrons: Embedded Linux Conference day 2

Tue, 21 Feb 2012 04:44:41 +0000

Day 2 of the Embedded Linux Conference started with a keynote titled The Internet of Things, given by Mike Anderson. With such a title, one could have feared some kind of very fuzzy-marketing-style kind of keynote, but with Mike Anderson as speaker, it clearly couldn’t be the case. Mike is well-known at ELC and ELCE for all its highly technical presentation on kernel debugging, JTAG, OpenOCD and more. This keynote was not really related to embedded Linux directly, but about all the potential applications that modern technologies such as RFID, nano-robots, wireless communications have. As Mike pointed out, there are lots of potential opportunities to optimize energy usage, make our lifes easier, but there are also lots of dangers (surveillance, manipulation of information, reduction of private life, etc.).

The Internet of Things, Mike Anderson

Right after Mike’s keynote, it was the time for me to give the presentation Buildroot: A Nice, Simple, and Efficient Embedded Linux Build System. As a presenter, I am obviously not objective, but I think the presentation went well. I filled the entire time slot, leaving the time for about five questions at the end. Around 60-70 people were in the room, quite a good number considering the fact that there was a talk from the excellent Steven Rostedt in another room at the same time. I will put the slides of this presentation on line very soon, which was a general presentation of Buildroot, trying to emphasize all the cleanups and quality improvements we have done since the last three years, and also trying to highlight the fact that Buildroot is really easy to understand, it is not a magic black box contrary to some other embedded Linux build systems. That’s the reason why I gave some details about how our package infrastructure works internally, to show that it is really simple. There were several questions about why we do not support binary packages, and of course I replied that it was a design decision in order to remain simple. At the end of the presentation, a guy from Mentor Graphics came to tell me that saying no was an excellent thing and that too many projects fail to say no to new features, and therefore they get more and more complicated.

At the same time as my Buildroot’s talk, Steven Rostedt from RedHat was presenting Automated Testing with ktest.pl (Embedded Edition) and Grégory attended this conference. Grégory reports: “As indicated in the title it is the “embedded” version of a former conference. I don’t know if Steven is really new in the embedded field or if he just pretends to, but the result is that for a newcomer in embedded Linux, this talk is really well detailed. He shows how to setup the board step by step, showing the problems you usually have. But the real topic is the ktest.pl script and how to use it. After two hours of presentation I was totally convinced by the usefulness of this script. It will help a lot to automate the tasks we usually do by hand such as git bisect, check that the stack of patches we have don’t break anything, check that we don’t have any regression at runtime or just at build. All these tasks can be done with ktest.pl and in a very simple way!”

Automated Testing with ktest.pl (Embedded Edition), Steven Rostedt

Then, I went to Tim Bird’s talk about Embedded-Appropriate Crash Handling in Linux. The initial problem that Tim wanted to solve is how to get and store information about applications that have crashed on devices in the-field. The major issue is that to debug and understand the crash you theoretically need to keep a lot of information, but in practice you cannot do this due to space constraints. Typically, a way of doing post-mortem analysis of a crashed application is to use the core file that the kernel generates after the crash, and use it with gdb. Unfortunately, a core file is typically very large. Tim looked at the crash report mechanism of Android, and discovered that it was directly registering a handler for the SIGSEGV signal (and other related signals indicating an application crash) into the dynamic library loader in Bionic. This signal handler communicates with a daemon called debuggerd over a socket, and this daemon then uses ptrace to get details about the state of the application at the moment of the crash (register values, stack contents, etc.). Tim didn’t want to require modifications at the application level or at the dynamic library loader, so instead he used the core pattern mechanism provided by the Linux kernel: by writing to some file in /proc, you can tell the kernel to start a userspace program when an application crashes, and the kernel dumps the core file contents as the standard input of this new process. Based on debuggerd, Tim implemented such a program that also uses ptrace and /proc to get details about the crashed application. Tim also discussed the various ways of getting a backtrace: using the frame pointer (but this is often not available, as many people use the -fomit-frame-pointer compiler option), using the unwind tables, using a best-guess method (you just go through the stack, and everything that looks like a valid function address is assumed to be part of the call stack, so this method shows some false positive) or using some kind of ARM emulation (but I don’t recall the name of this solution at the moment). All in all, Tim’s talk was great, a good report of its experiment and good technical information about this topic.

Everybody at Free Electrons wanted to attend to the “ARM Subarchitecture Status” presentation given by Arnd Bergmann, but we couldn’t since we were responsible for recording videos of all talks. This time, it’s Grégory who had the privilege of attending what looked like the most interesting talk of the slot. In fact as we follow the ARM Linux community in a close way through the mailing lists or the LWN.net website, nothing was really new for Grégory in Arnd’s presentation. Nevertheless it was good to take the time to have a status. The interesting part for Grégory was to see how Arnd works with all the git trees coming from SoC vendors or from community and how he merges them together and merges the conflicts. It is more manual than we imagined and honestly is certainly a very hard job to do.

ARM Subarchitecture status, Arnd Bergmann

Later in the day, I went to David Anders talk about Board Bringup: LCD and Display Interfaces and it was really a great talk. David explained very well the hardware signals between the LCD controller that you have in your SoC and the LCD panel you’re using, and how those signals affect the timing configuration that you have to set in your kernel code. He clearly explained things like pixel clock, vertical and horizontal sync, but also more complex things like the front porch and the back porch. He then went on to describe LVDS, which in fact is a serial protocol that uses two wires per-color in a differential mode to transmit the picture contents, and also talked about EDID, which is basically an I2C bus that can be used to read from the display device what display modes are available and what their timings are. He also described some of the test methods he used, from a logic analyzer up to a program called fb-test. David’s talk was really great because it provided the kind of hardware details that a low-level software engineer needs to understand, and David explained them in a way that can be understood by a software engineer. Following the talk, I met David and asked some more questions and he was very nice to answer them, in a very clear way. David slides are available at http://elinux.org/Elc-lcd, and you can also check out other things that David is working on at TinCanTools, such as the very nice Flyswatter JTAG debugger for ARM.

At the end of day, Grégory attended the Real-Time discussion session, Maxime attended the Yocto Project discussion session and I attended the Common Clock Framework discussion session. This last discussion session was about work done to consolidate the multiple implementations of the clock APIs that exist in the kernel: at the moment, each ARM sub-architecture re-implements its own clock framework and the goal is to have a common clock framework in drivers/clk/ that can be shared by all ARM sub-architectures but also potentially by other architectures as well. The discussion lead by Mike Turquette from Texas Instruments/Linaro showed that a great deal of work has already been done, but a lot of questions remained opened. Each ARM sub-architecture has different constraints, and finding the right solution that solves the constraints of everybody isn’t easy.

And finally, there was the usual Technical Showcase, with demonstrations of the Pandaboard, but also the newer BeagleBone platform which looks really exciting. David Anders was demonstrating his LCD bring-up setup, another person was demonstrating an open-source GSM access point based on USRP, etc. Lots of interesting things to see, lots of nice people to discuss with.

Free Electrons: Embedded Linux Conference day 1

Tue, 21 Feb 2012 04:43:13 +0000

The first day of the Embedded Linux Conference started on Wednesday here at Redwood City, California.

The day started with the usual Kernel Report from Jonathan Corbet. It was, as usual with Corbet’s talk, a very interesting summary of what happened in the kernel through the last year, with highlights of the major new features per release, thoughts about issues like the kernel.org security problem and subsequent outage, etc.

The Kernel Report, Jonathan Corbet

After this talk, Grégory went to the Saving the Power Consumption of the Unused Memory, given by Loïc Pallardy, who works for ST Ericson in France. The purpose of the talk was to detail the kernel modifications they made to support the fact of powering down portions of the memory that are unused. In fact, DDR memories these days are capable of powering off some their areas, which allows to save power. Of course, when an area of the memory is powered off, its contents are lost, so the kernel needs to ensure that nothing valuable remained on this area of memory. Their kernel modifications allow to describe how the memory is organised (which address ranges are available and can be powered down independently) and introduce some kernel memory allocator changes to reference count those banks of memory. Of course, the next problem is that physical memory is usually highly fragmented, so they detailed how they re-used some of the existing kernel mechanisms to group unmovable pages on one side and movable pages on the other side and that allow to defragment the movable pages. This topic has been worked on since quite a long time in the kernel, as can be found in this LWN article from 2006.

Saving the Power Consumption of the Unused Memory, Loïc Pallardy

On my side, I attended the What Android and Embedded Linux Can Learn From Each Other talk. The speaker detailed many of the Android kernel additions and how they could, theoretically, be re-used in non-Android embedded Linux systems. Things like re-using the Binder inter-process communication mechanism, or simple things like the RAM-based Logger mechanism. Unfortunately, none of the speaker’s suggestions were backed by any sort of real experimentation, so those suggestions were mostly speculations. For example, he suggested the possibility of re-using the Android graphics stack on a non-Android system, but most likely this is a very difficult task to achieve and not necessarily worth the effort. At the end of the talk, the speaker suggested that the embedded Linux community and the Android community should talk more to each other, but looking at how Google is driving Android development, it is difficult to see this happening in the near future.

Then, the talk from Hisao Munakata about Close Encounters of the Upstream Resource was an interesting and good summary of the tensions that exist within embedded companies between the product teams (who have deadlines and need the product to work, and don’t want to worry about upstreaming things) and the community teams (who are in relation with the community and try to upstream modifications). He had really nice slides to show the multiple issues that a company faces when it produces major modifications to open-source components such as the Linux kernel, without any effort to upstream them. But he also said that things are improving, and that with Android using fairly recent kernel versions, the embedded Linux system makers are now much closer to mainline versions, which helps in getting changes merged in the official Linux kernel. He advocated that embedded Linux developers should be proficient with git, because it allows to easily track the modifications, find out whether bugs have been fixed in later versions of the Linux kernel, etc. He also quickly presented the LTSI, an initiative that offers long-term support around the Linux kernel. He presented it as the way of solving the fragmentation between the vendor BSPs kernel versions, the Android versions, and all other kernel versions that are floating around. However, how those versions will get merged into the official Linux kernel was not really clear.

In the afternoon, Grégory went to the talk Comparing Power Saving Techniques For Multicore ARM Platforms, presented by Vincent Guittot was an other talk presented by a French guy from ST Ericson. As the one Grégory saw in the morning about power management of memories, this one was also very instructive, well documented and the speaker seemed to really know his topic. He worked the right way on Linux: only very minimal changes inside the kernel, tried to reuse the existing components, provided a git tree available and proposed some improvements on the mailing lists: good job!

Grégory also attended the traditional talk from Tim Bird entitled Status of Embedded Linux. Very pleasant talk (as usual with Tim Bird). It was a very good overview of the state of embedded Linux. If you want to start working on embedded Linux this talk is a must see. Moreover Tim mentioned the valuable work done by Free Electrons by recording and sharing the conferences for many years!

The Status of Embedded Linux, Tim Bird

Later in the day, I attended the talk Passing Time With SPI Framebuffer Driver given by Matt Porter, who now works for Texas Instruments. His talk was feedback from real-life experience developing a driver for a SPI framebuffer controller. Initially, the problem was that a customer had started developing a driver, but that driver violated all the Linux development rules: no usage of the GPIO APIs, no usage of the SPI infrastructure, no usage of the device model, everything was done through a basic character driver directly manipulating the hardware registers. This is something that we also see quite sometimes at Free Electrons in the kernel code of some customers: this happens when the code has been written by developers who have only started reading the Linux Devices Driver book, but didn’t go far enough in the Linux code to understand the device model and the principle of code re-usability. So clearly, Matt’s experience resonated with our own experience. So, Matt went on to describe how the driver worked, modifications needed at the board configuration level, the driver itself, its integration in the device model. He also clearly detailed how a SPI framebuffer can work. On a normal framebuffer integrated into the SoC, the framebuffer memory is directly mapped into the application address space so that the application can directly draw pixels on the screen. However, when the framebuffer controller is over SPI, it is clearly not possible to map the framebuffer memory into the application address space. But fortunately, the kernel has a dedicated mechanism for such case: FB deferred I/O. What gets mapped into the application address space is normal kernel memory, but the kernel detects thanks to page faults when a portion of this memory has been changed, and calls the framebuffer driver so that the driver has an opportunity to push these changes over SPI to the framebuffer controller. Of course, this mechanism run at a configurable frequency. The device that was used by Matt Porter was a 1.8 screen available from Ada Fruit, this might also been a good device to use in our future kernel courses, to let participants exercise with driver development.

At the end of the day, I attended the Experiences With Device Tree Support Development For ARM-Based SOC’s by Thomas P. Abraham, from Samsung Electronics, but also from Linaro. It was clearly an excellent presentation about the device tree and how it works. It showed, with lots of code examples, how to compile the device tree source into a device tree blob, how to configure and use U-Boot to get this device tree blob loaded and passed to the kernel, how the board files in the kernel are changed to use the device tree, how device drivers are modified, how the platform data mechanism is changed with the device tree, and more. Definitely a must-see for anyone doing ARM development these days.

My colleague Maxime went to the talk from Paul McKenney about Making RCU Safe For Battery-Powered Devices. Maxime reported that it was an excellent introduction to RCU: Paul introduced very progressively the various issues, so it was possible even for an RCU-newbie to follow that talk. Definitely a presentation I will watch thanks to the video recording!

In the evening, there was the traditional social event of the conference. It took place at the Hiller Aviation Museum, they have lots of strange aircrafts or helicopters, such as a piece of the supersonic Boeing prototype plane, or other bizarre flying devices such as this flying platform.

Michele's GNSS blog: Low cost RTK performance round-up

noreply@blogger.com (Michele Bavaro) — Mon, 20 Feb 2012 14:25:00 +0000

Having done quite a bit work since the first Yuan10 was built, I think it's time to write a small summary.

I recently put up a navXperience 3G+C antenna that will serve as reference for all future RTK work in this area. With the support of the reference station University of Pisa and their reference observations at 0.2Hz I run RTKLIB (RTKNAVI and RTKPOST) for several days using several low-cost receivers that I assembled.
This should be somehow considered the best possible scenario, having a short 1.5Km baseline.. nevertheless the results are quite exciting I believe.

Figure 1: Yuan10: Skytraq S1315F-RAW

The plots above show solving of the integer ambiguities in about 5 minutes and reaching an accuracy of about 4cm square.

Figure 2: Rappen10 mMCX version: uBlox NEO-6P (RTK mode)

Again, the NEO-6P brings the position down to 4cm square accuracy in less than 10 minutes.

Figure 3: Denga10: NVS NV08C-CSM

The NV08C-CSM solves the carrier phase integer ambiguities and also brings down the accuracy to about 4cm square.

Each of these receivers has his specialty:

the S1315F-RAW has 20Hz raw measurements update rate, which is still unmatched performance by other low-cost receivers
the uBlox NEO-6P has integrated PPP for high accuracy standalone mode, no other low-cost receivers claims that
the NVS NV08C-CSM has Glonass!

Cheers,
Michele

P.S.: I attached a trimmed version of the data used to obtain these results here. Please note how the NVS observations are covered by NDA and therefore not included.

P.P.S.: The latest FW from NVS (dated 27 Feb 2012) improves dramatically the quality of the NV08C-CSM raw measurements: results above are not representative anymore.

osPID: And So It Begins

Mon, 20 Feb 2012 13:40:28 +0000

Just a quick post to let everyone know that shipping has started. The first units went out today! all boards are re-flowed/assembled, Just need to test, pack, and ship. Here are some pics to tide you over until your osPID arrives:

Video Circuits: Aaron Zarzutzki and the Gdeip Video Synth

noreply@blogger.com (Chris) — Mon, 20 Feb 2012 06:54:36 +0000

Here is a rare outing for Aaron's interesting video synth the Gdeip

this old post has more
his flickr here

OggStreamer: #oggstreamer Rev 1.0b Schematics

Sun, 19 Feb 2012 17:02:47 +0000

We were quite busy testing the prototype and fixing all the issues for our next Version Rev 1.0b – the schematics are now online as PDFs and after the PCB manufacturing proves alright, I will release the PCAD and Gerber Files as well. For now the PDFs of the adapted schematics:

oggstreamer_REV1_0b_digital_and_power

oggstreamer_REV1_0b_analog_and_vs1063

Liu Xiangfu, openmobilefree.net: Icarus mining software compare(miner.py VS cgminer)

Sun, 19 Feb 2012 12:41:43 +0000

Bug fixed Cgminer: (655 shares in 2 hours):
cgminer version 2.2.5 – Started: [2012-02-19 18:40:12]
(5s):696.2 (avg):360.8 Mh/s | Q:1285 A:659 R:1 HW:0 E:51% U:5.45/m

Cgminer (397 shares in 2 hours):
(5s):655.2 (avg):514.8 Mh/s | Q:1323 A:394 R:1 HW:0 E:30% U:3.25/m
before start cgminer
the deepbit shows: “xiangfu.z@gmail.com_0″:”shares”: 292939,
after mining 2 hours,
the deepbit shows: “xiangfu.z@gmail.com_0″:”shares”: 293336,

Miner.py (608 shares in 2 hours):
before start cgminer
the deepbit shows: “xiangfu.z@gmail.com_1″:”shares”: 144101,
after mining 2 hours,
the deepbit shows: “xiangfu.z@gmail.com_1″:”shares”: 144709,

Dan Reetz: Droid 2 Global Cyanogenmod USB not working FIX

Sun, 19 Feb 2012 02:32:57 +0000

So, I just upgraded my D2G to Cyanogenmod 7.1.0. Like many other people, I had immediate problems with USB.

The symptoms are as follows:

I plug the USB cable into my computer and into my Droid 2 Global.

The Droid 2 Global does not respond in any way. No charge light, no hardware response from the PC.

HOWEVER, if the phone is rebooted with the cable connected, then

The USB mass storage dialog will appear and the phone will connect ONCE

But if disconnected it will not reconnect again.

After wasting an entire afternoon trying to get USB Mass Storage to work on CM for D2G, I called my friend Aaron Marback who has better Android and Google-fu than I do.

Aaron pointed me to this post by dateno1. Attached is a rar file containing two files: usbd and Usb.apk.

To fix the USB problems with Cyanogenmod 7.1.0 on Droid 2 Global, do the following:

Download the files linked in dateno1′s post.

Connect your phone to your computer and reboot it to establish a connection. Alternately copy files to SD card using card reader.

Copy the files onto the root dir of your SD card.

Install the app Root Explorer.

Open Root Explorer. Navigate to the root directory of the SD card.

Press and hold on the file “usbd”. Choose “copy”.

Navigate to /system/bin/. Paste.

Set permissions to rwxr-xr-x or just give permissions to everyone.

Navigate back to the SD card root directory.

Press/hold and Copy “Usb.apk”.

Navigate to /system/apps/ and paste.

Again, set permissions the same way.

Reboot phone and enjoy USB access.

Thanks to Dateno1 and Aaron Marback.

Video Circuits: Jonathan Brainin

noreply@blogger.com (Chris) — Sun, 19 Feb 2012 01:07:09 +0000

Jonathan Brainin's excellent camera an pendulum based feedback experiments /artworks

Video Circuits: Jeff Donaldson

noreply@blogger.com (Chris) — Sun, 19 Feb 2012 00:55:49 +0000

check http://vimeo.com/notendo and the excellent glitchsafari

Video Circuits: Jason Akira Somma

noreply@blogger.com (Chris) — Sun, 19 Feb 2012 00:49:02 +0000

Super FX-8000 (Video Circuit Bending) from Jason Akira Somma on Vimeo.

AEG-1 (Custom Video Mixer/Glitcher) from Jason Akira Somma on Vimeo.

http://vimeo.com/jasonsomma

Open Hardware Repository: White Rabbit Switch Testing - Test Framework comparsion

c.prados@gsi.de (Cesar Prados) — Fri, 17 Feb 2012 18:27:01 +0000

Open Hardware Repository: White Rabbit Switch Testing - Jabber Meeting 07/02/12

c.prados@gsi.de (Cesar Prados) — Fri, 17 Feb 2012 17:54:50 +0000

Open Hardware Repository: White Rabbit Switch Testing - Design Proposal for the Networking Testbencher

c.prados@gsi.de (Cesar Prados) — Fri, 17 Feb 2012 17:53:34 +0000

Transmaterial: ExoSkeleton

Fri, 17 Feb 2012 15:00:10 +0000

ExoSkeleton is a quilted concrete panel made from organic duck cloth canvas and cast concrete. Two layers of the canvas are quilted using reinforced stitching in a structurally stable configuration. The reinforced stitching is engineered to withstand the fluid lateral forces specific to the amount of uncured concrete relative to the diameter of the pocket created by the sewn fabric. The formwork is then hung in a vertical configuration supported at the top, similar to the arrangement of a shower curtain. At the base of the fabric, friction pilings or a trough are set plumb to the supports at the top of the fabric and serve as the foundation of the cured form.

Developed by Thompson Young Design, ExoSkeleton’s canvas fabric is configured to allow pumped concrete to self-support in compression and framed laterally by the tensile strength of the fabric within the diamond shaped quilted pockets, which are connected to a foundation. The canvas can be removed once the concrete is cured, or it can be incorporated into the finish.

Concrete supports more than its own weight in compression, and the material nature of fabric offers a high strength in tension. As long as the balance of concrete in compression relative the tensile strength of the fabric is stable, concrete will stack. When coupled, the compressive stability of concrete and the tensile strength of fabric combine to frame the curing process of concrete to achieve infinite concrete configurations.

Contact: Thompson Young Design, Charleston, SC, USA.

Liu Xiangfu, openmobilefree.net: Icarus with cgminer mining pool compare (deepbit VS p2pool)

Fri, 17 Feb 2012 12:06:45 +0000

Connect to deepbit: ~180 Shares/Hour
Connect to p2pool : ~150 Shares/Hour

The networks is 2MB ADSL, cgminer running under TP-LINK WR1043ND router with OpenWrt system. Icarus connect to TP-LINK WR1043ND USB prot.

Why p2pool is slow which V3 bitstream of icarus:
P2pool’s idea of a “block” changes every 10 seconds instead of 10 minutes, on p2pool you have on average 10sec to do work, so if you doing U:3/m then it takes 20sec to do the work. the block changes in that time so you’re never working on the current block, this is a big problem.

Command:
(deepbit) cgminer -Q 4 -S /dev/ttyUSB0 -o http://pit.deepbit.net:8332/ -O xiangfu.z@gmail.com_0:1234
(p2pool) cgminer -Q 4 -o http://www.openmobilefree.net:9332/ -O 1AUuX4auVWUYByhLGP1okhWsHsSm9zxqmz:x -S /dev/ttyUSB0

More Info:
26 hours on deepbit:
cgminer version 2.2.5 – Started: [2012-02-15 19:35:52]
——————————————————————————–
(5s):59.5 (avg):524.4 Mh/s | Q:17086 A:4765 R:26 HW:0 E:28% U:3.02/m
TQ: 1 ST: 1 SS: 27 DW: 272 NB: 160 LW: 0 GF: 483 RF: 8
Connected to http://pit.deepbit.net:8332/ with LP as user xiangfu.z@gmail.com_0

1 hour on p2pool:
cgminer version 2.2.5 – Started: [2012-02-17 11:57:21]
——————————————————————————–
(5s):655.5 (avg):306.9 Mh/s | Q:367 A:146 R:40 HW:0 E:40% U:2.50/m
TQ: 1 ST: 2 SS: 36 DW: 294 NB: 6 LW: 657 GF: 0 RF: 0
Connected to http://www.openmobilefree.net:9332/ with LP as user 1AUuX4auVWUYByhLGP1okhWsHsSm9zxqmz
Block: 00000a20ebe31a4c1fb65aaca47e691c… Started: [12:48:08]

Crypto Stick: Exhibition at the Embedded World Fair in Nuremberg, 28.2.-1.3.2012

Fri, 17 Feb 2012 08:18:42 +0000

As in the previous years, also in 2012 we will have a booth at the Embedded World fair. Guests are welcome to get information about the status, latest developments, and outlook of the Crypto Stick project. Developers will be available to discuss even in-depth technical aspects such as adapting or integrating the Crypto Stick into other products and systems. The Embedded World will be held from 28th February to 1st of March in Nuremberg, Germany. See you there! Update: The exact location is hall 4A/4A-308l at Dridger & Schwenke's booth.

Update 2: A few pictures of the now already past event.

Liu Xiangfu, openmobilefree.net: 北京的 p2pool: www.openmobilefree.net:9332

Fri, 17 Feb 2012 02:46:47 +0000

把我的　p2pool 发布出来，服务器在北京，会长期运行，使用方法：
　./cgminer -o www.openmobilefree.net:9332 -O YOUR_BITCOIN_ADDREE:x

用户名是你的bitcoin 地址，密码任意。

p2pool 使用的是:
git://github.com/forrestv/p2pool.git, commit: 5ca5a69b6cb7d6633de8c31ea8b9747bddc4eb7f

Video Circuits: Moog Little Phatty and the Scanimate

noreply@blogger.com (Chris) — Thu, 16 Feb 2012 23:49:20 +0000

experimentalsynth

Free Electrons: Android Builders Summit: day 2, and Yocto Developer Day

Thu, 16 Feb 2012 20:48:11 +0000

It’s now Thursday morning here in Redwood City, California, and I didn’t had the time yesterday morning to do a write-up about our second day at the Android Builders Summit. Hopefully the following write-up will give our readers some details about what happened during this day.

This second of Android Builders Summit was co-located with the Yocto Developer Day, and as my colleagues Maxime Ripard and Grégory Clément were attending the two tracks of Android Builders Summit, I decided that I would attend the Yocto Developer Day.

Yocto Developer Day

Yocto is an umbrella project that consists in creating an embedded Linux build system, called Poky and some associated development tools. Poky takes its roots into the OpenEmbedded community: it re-uses the bitbake recipe processor, and a set of recipes for building packages that are now shared between Yocto and OpenEmbedded through the openembedded-core repository. At Free Electrons, we are strong contributors to the Buildroot build system, and we use it for many of our customer projects. However, being pushed very strongly by Intel and the Linux Foundation, Yocto is gaining traction, and the fact that Yocto provides stable releases every 6 months now makes it a lot more usable than OpenEmbedded, which had to be checked out through Git, leaving the user with the uncertainty on whether the version (s)he got would actually work or not. And moreover, Buildroot and Yocto are not really competing projects: Buildroot is a simple root filesystem image generator, while Yocto is more a cross-distribution generator, they target projects of different sizes.

I started attending the Yocto Developer Day with a general presentation talk about what Yocto is and why it is necessary. Nothing really new in this talk for someone who already uses embedded Linux build systems and understands the need for such tools. However, the thing that always surprises me is that the Yocto project claims everywhere to solve the fragmentation problem in the embedded Linux build system space (there are too many tools in this area) by creating the tool, and that they envision that in 5 years, everybody will link embedded Linux build with the Yocto project. It’s quite funny because at the moment, they have just created yet another build system But it’s true that the project is gaining traction and seems to attract the SoC vendors, which is a good thing because having a standard build system is so much better than having crappy vendor-specific build systems.

Yocto Developer Day: Yocto introduction by Saul Wold from Intel

The second talk, by Saul Wold, from Intel, went more into the details on how to use Yocto: what the different components are, how recipes are written, how configuration is defined, what tasks, images, recipes, etc are. I would have liked if the talk went a bit further into the details, but it gave a very good introduction to the Poky build system.

In the afternoon, I attended a hands-on session for new users to Yocto. The room setup was very impressive: about forty high-end PCs provided, each having a development board next to it. The first part of the hands-on session consisted in using Yocto to produce a basic filesystem image which we booted into Qemu. In order to solve the very long first build problem that all OpenEmbedded and Yocto users face, they had pre-built a number of packages and stored them into a shared state directory. Interestingly, the size of the Yocto output directory was about 30 GB, just to build an embedded Linux system with BusyBox and a few minor things. Once this was done, we went ahead in creating our own layer, in order to define our own image and its contents it terms of packages. We used it to add a graphical splashscreen, and I also extended it to include Dropbear into the build. The whole thing went quite well. One thing that worries me is that bitbake and the build process really looks like a black box, and it seems hard to understand what’s going on behind the scenes. With Buildroot, I am used to a very simple build system with which it is very easy to fully understand what’s going on. Here, even the people that give speeches about Yocto or deliver a bit of training, seem to not fully understand what’s going on. This impression is also validated by the complexity of the output directory (where all the build results are). But maybe it’s just a matter of spending some time using it and reading some code, but the fact that people that have been developing/using Yocto for a while still do not really understand its internals is a bit surprising. Or maybe it’s just a wrong impression on my side.

Yocto Developer Day: hands-on session starting

The next part of the hands-on was around the Eclipse integration of Yocto. First with ADT (Application Development Toolkit), which integrates the cross-development thing into Eclipse. Thanks to an agent running into the target, Eclipse is able to push the application binary to the target and start gdbserver on it, and therefore transparently start a debugging session for the user. I am not a big fan of Eclipse (I have been an Emacs user for a huge number of years), but it’s true that for people used to Integrated Development Environments, this ADT thing provides a quite nice experience. Then, we went ahead in trying to use HOB, which integrates into Eclipse the possibility of selecting which packages should be built and integrated into the image. Unfortunately, it seems it didn’t work for anybody (even though we were selecting the package in the GUI, it didn’t appear in the final filesystem image), but that wasn’t a big problem since I don’t really see the point in a tool such as HOB: editing configuration files is something that shouldn’t scare any embedded Linux developer.

Regardless of the contents of the hands-on, I was quite interested by how it was conducted. Instead of having some written lab instructions, and having everyone following, alone, those lab instructions, the instructor was simply demoing the various steps to be done on the video-projector screen, which we simply had to replicate. It makes the session quite interactive, with of course the drawback that everyone needs to progress at the same pace.

All in all, this Yocto Developer Day was interesting, and I hope to find some time soon to experiment further with Yocto.

Android Builders Summit

My colleagues attended multiple talks about Android during this second day of the conference. In the morning, they attended Headless Android, Towards a Standard Audio HAL for Android, Android on eMMC: Optimizing for Performance.

Android Builders Summit: Real-time Android

In the afternoon, Grégory attended the Real-Time Android talk, which he said, was interesting. It showed that it was possible to integrate the PREEMPT_RT patches together with the Android kernel modifications, and provide a system having real-time capabilities for native (C/C++) applications and still the nice aspect of the Android user interface. During the same slot, Maxime attended the Android Services Black Magic, given by Aleksandar (Saša) Gargenta from Marakana. As usual with the Gargenta brothers, the talk was highly interesting and gave a lot of detailed information about Android services.

Some other thoughts…

At the organization level, the conference organizers should make it clear in the conference program and flyer the location where the slides will be posted. At almost every talk there is someone that asked if and where the slides will be posted, and the speakers are sometimes a bit uncomfortable because there is no clearly identified place to post the slides. In the past years, it was made clear that the slides would be posted on the elinux.org wiki, but this year, things are very unclear. Moreover, it’s even more surprising since speakers are asked to post their slides into their Linux Foundation website account, but those slides are not being made visible. Maybe a good suggestion for the Linux Foundation would be to improve how slides are handled and posted online.

Another thought about the Android Builders Summit is the surprising absence of Google, the developer and maker of Android. Google sponsors the Embedded Linux Conference which takes place right after the Android Builders Summit, but they do not sponsor the Android Builders Summit. There is also no talk from Google developers, and I haven’t seen any Google person in the attendees. It’s even more surprising when we know that the conference takes place in a location about 18 minutes away by car from Google headquarters in Mountain View. Maybe Google doesn’t want to see Android being used in application areas other than phones and tablets?

Free Electrons: First day at the Android Builders Summit

Tue, 14 Feb 2012 16:59:53 +0000

Yesterday was the first day at the Android Builders Summit 2012, here in Redwood City, near San Francisco, California. My colleagues Grégory Clément and Maxime Ripard as well as myself are fortunate to attend this conference, and the contents of the first day were really interesting.

Amongst others:

A talk from Karim Yaghmour, well-known for having worked on the original version of the Linux Trace Toolkit, on the Adeos patch, as well as for its activity around Android. He delivered a 30 minutes talk about Leveraging Linux’s history in Android, which covered the differences in architecture between a standard embedded Linux system and Android, as well as how to nicely integrate BusyBox or tools like the Linux Trace Toolkit into Android. The presentation was really impressive: in just 30 minutes, Karim covered a huge number of slides, and made several live demonstrations. It is also worth noting that Karim, following the direction that Free Electrons has drawn 7 years ago, has decided to release his Android training materials under a Creative Commons BY-SA license.
A panel with multiple kernel developers and people involved in Android on how to integrate the specific Android kernel patches into the mainline kernel. Not many new things learned here: the issue with the Android patches is that they add a lot of new userspace-to-kernel APIs, and such code is much much harder to get in mainline than conventional driver or platform code, since such APIs need to be maintained forever. Interestingly, Zach Pfeffer from Linaro pointed out the fact that the major problems with Android integration these days are not due to the kernel patches, but rather to the horrible binary blobs and related drivers that are needed for 3D acceleration ARM SoCs (Systems On a Chip).
Panel « Android and the Linux Kernel Mainline: Where Are We? »
A talk from Marko Gargenta on how to customize Android. He explained how to expose a specific Linux kernel driver functionality to Android applications, through a native C library, the JNI mechanism and an Android service, with complete details in terms of source code and build system integration. This presentation, just like last year’s presentation from Marko, was absolutely excellent. A lot of content, very dynamic presentation, a lot of things learned.
A talk on how ADB (Android Debugger) works. The contents were really good as well here, with lots of details about the ADB architecture, some tips and tricks about its usage, and more. Unfortunately, the speaker was really not familiar with English, and most of its presentation was spent reading the slides. This is a bit unfortunate because the technical contents was really, really excellent. The slides are available at http://www.slideshare.net/tetsu.koba/adbandroid-debug-bridge-how-it-works.
Using Android in safety-critical medical devices. This talk was not about technical issues, but rather about the reason for using Android in medical devices (get those devices connected together and collect some data to learn more about medical practices, their efficiency and cost) and also the legal requirements to get such devices validated by the Food and Drugs Administration in the US. A lot of useful arguments on how to convince managers that Android and Linux in general are usable in safety-critical medical devices.
A talk about Over-The-Air updates in Android, which I didn’t attend, but my colleague Maxime Ripard and other attendees gave an excellent feedback about it. It detailed an advanced system for safely upgrading an Android system, using binary diffs and other techniques.
Customizing Android by Marko Gargenta, Marakana
The talk about Integrating Projects Using Their Own Build System Into the Android Build System had a really promising title and abstract, but unfortunately, the contents were disappointing. The speaker took 25 minutes just to explain how to build BusyBox (outside of any Android context) and then another 20 minutes to explain how to integrate it in the Android build system, on unreadable slides.
The talk about Android Device Porting Walkthrough was really great. Benjamin Zores exhausted its time slot with a 1h15 talk instead of the 50 minutes slot allocated, but fortunately, it was the last talk of the day in this session. During this talk, Benjamin gave a huge amount of information and many details about various issues encountered in the process of adapting Android for an Alcatel business VoIP phone (the ones you see in business desks). Issues like filesystem layout, input subsystem configuration, touchscreen configuration, graphics and much much more were covered. Be sure to check out Benjamin slides at http://www.slideshare.net/gxben/android-device-porting-walkthrough.
Finally, the day ended with a lightning talk session moderated by Karim Yaghmour. Lightning talks are really nice, because in less than 5 minutes, you quickly hear about a project or an idea. When the speaker is not good or the topic uninteresting, you know that after 5 minutes, you’ll hear someone else speaking about a different topic. The lightning talk on the integration of GStreamer in Android was really interesting, as was the lightning talk from Karim about its CyborgStack initiative, which creates an upstream Android source to integrate all the Android modifications that will never be mainlined by Google. See Karim slides at http://www.cyborgstack.org/sites/default/files/cyborgstack-120213.pdf for details.

And now, it’s time for breakfast, before the conferences of the second day of this Android Builders Summit.

Bunnie Studios: Name that Ware, February 2012

Mon, 13 Feb 2012 18:45:29 +0000

The Ware for February 2012 is shown below. Click on the images for a larger version.

Below is the daughtercard that plugs into the above mainboard:

Many thanks to Ben for submitting this rare ware to share.

Have fun!

Bunnie Studios: Winner, Name that Ware January 2012

Mon, 13 Feb 2012 18:45:13 +0000

The Ware for January 2012 is a Polycom Soundpoint IP 501. The winner is Kevin Groce for being the first to name the exact model and make. Congrats, email me for your prize! Next time I’ll blur the MAC address as well. I thought I’d leave it in as a hint, but it turns out in the end that a MAC address can be resolved quite specifically…

Capn's Tech: Playpause 2: Making PCBs at home

noreply@blogger.com (Mitch Davis) — Sun, 12 Feb 2012 17:18:29 +0000

For a long time, I've wanted to make PCBs at home.

In the past, I used to make my own electronics project using stripboard and perfboard. This is reliable, if not slow. But a stripboard design doesn't really lend itself to being constructed by others.

In the past year I've started working with surface mounted devices. SMD doesn't work very well on stripboard, so it becomes not just desirable but necessary to make PCBs. I have put off learning how to do it for a long time, but a month or so ago, I finally got the time to give it a go. This article covers what I currently do, and I'm writing about it here in the hope it will help others.

There are three main ways of making circuit boards at home. The first is via the “toner transfer” method. I have tried that in the past, but never been able to reliably make a circuit board greater than about a square inch: I've always had a lot of trouble getting the toner 100% fused to the PCB without cracking or smudging.

The second is by using a CNC mill to mill away undesired copper, leaving copper tracks. With the imminent completion of the CNC mill at our hackerspace, or if I one day build a CNC mill using components salvaged from old DVD drives, that might be a possibility. However for the moment I don't have access to a CNC mill, so I can't use that method.

The third is the photographic method. With this method, a special copper-clad PCB is covered by a film of UV-sensitive dye. Exposing the dye to ultraviolet light through artwork printed on transparent paper will leave some regions of dye exposed, and some regions unexposed. A developer chemical will remove the exposed areas, leaving the dye in the form of green tracks on the board. Then the board is etched in a chemical etchant, which removes the copper which is not protected by the dye. Finally, the dye is removed, leaving copper tracks.

In this article I'll show how to use the photographic method, although I might try the toner transfer and CNC methods again in the future.

The UV-sensitive PCB stock I'm using is sold by Kinsten, and is available in single- and doubled-sided variants. Here is the Kinsten PCB, plus the developer (Kinsten DP-50), etchant (ammonium persulphate), and a scrubbing pad:

Kinsten, etchant, developer and scrubber

In order to generate the UV light, I made an exposer box using nearly 100 UV LEDs. For an enclosure, I cut up and resized a cardboard box. The box is lined with aluminium foil to reflect light towards the board I'm exposing, and the light has to travel through two diffusers of transparent paper.

Here's a picture of the LED array:

Exposer's UV array, LED side

And here's a picture of how I wired up the LEDs:

Exposer's UV array, wiring side

(The two halves are wired differently because the second board is somewhat smaller than the first board, and wouldn't allow the straight-forward row-and-column arrangement I used on the first board).

The specifications for the LEDs say the forward voltage is about 3V. The wiring of the boards configures the LEDs into many parallel strings of four LEDs. I power the exposer with a 12V power supply. I have adjusted the trimpot on the power supply to get a voltage that gives me a current of 25mA through each LED. The LEDs do get quite warm after running for a while. Here's a picture of the exposer working:

Exposer powered up showing UV

NOTE: The LEDs produce a bluish-purple light, but this is not ultraviolet, it's a consequence of the spectrum from the LEDs being spread out somewhat. Our eyes cannot perceive ultraviolet light, yet it is harmful to our eyes. If you are working with ultraviolet light, try to limit how much UV gets into your eyes, or you may have to bear gritty and sore eyes for a few days. UV filtering sunglasses might be a good idea.

I print the artwork for the board on tracing paper I bought from the newsagent. I print it with a laser printer, and in the printer settings dialog I set the density to be as dark as possible. I usually print right-way-around on normal paper to verify that all the parts fit the board, then I print on the transparency in reverse. If I used a normal printout, there'd be a layer of transparency between the toner and the dye. This can cause blurring, as the UV light can diffuse to under the artwork. Mirroring the image means the toner can be right up against the dye.

Tracing paper with artwork

A few weeks ago when I first started this exercise, I didn't know how long to do the UV exposure for. I made some board artwork of ten TQFP-32 footprints in a row, with some lines of different thicknesses. I put the artwork and the PCB on the exposer with a piece of cardboard. Every fifteen seconds I slid the cardboard across by one TQFP, so that by the time two minutes and thirty seconds had elapsed, I had a row of footprints that had been exposed for various times, from 0:15 to 2:30. When I later developed the exposed PCB, what I found was that for my exposer, no pattern emerged until an exposure time of 2:00, and by 2:30 the pattern had developed very nicely. I have since made PCBs with exposure times of 3:00 to 3:30, and they have turned out very nicely.

Some people I've spoken to said I wouldn't be able to reliably make the 0.016” tracks I was hoping for. The good news is that tracks down to 0.010” come out just perfectly, and tracks down to 0.008” (0.2mm) appear very achievable. I think the biggest limiting factor is the quality of the artwork: I can trace small irregularities in the finished PCB to slight imperfections in the artwork, either because of dust or because there is a small hole in the toner. It seems that the toner binds to some places on the transparency better than others.

When doing the exposure, you need some way to keep the artwork flat against the PCB. I use a glass-topped coffee table. I tape the exposer to the bottom side of the coffee table, and put the artwork and PCB on top, held down by a heavy book. I always clean the glass with glass cleaner before doing the exposure.

The dye on the Kinsten PCB is protected by a white plastic film. Just before exposing, I peel off the film, revealing the blue-green dye. I do the exposing well away from the window, as otherwise ultraviolet from the sun may spoil the exposure.

I don't have a picture of a PCB being exposed, because when I'm doing the exposure, I have my hands full with holding the exposer and watching the exposure time.

At the end of the exposure time, I cover the PCB to prevent stray UV light from damaging the exposure. If you look carefully, you should be able to see the pattern of tracks as a very faint yellow hue on the blue-green dye. If you can't see it, it might indicate an exposure problem.

Here I'm developing the board in developer solution:

Developing Playpause boards in developer solution

This is 15g of Kinsten DP-50 developer, in 250ml of water. The developer doesn't have to be hot or warm, but having it warm speeds things up a little. While exposing the boards, I rock the container from side to side. As the exposed dye comes off, it makes patterns in the water like smoke.

Here are the boards after they have been developed. I wash them in water, then dry them, being careful not to scratch the ink.

Developed boards

Now it's time to etch the boards. There are three main chemicals hobbyists use to etch boards. In order of how often they're used, they are ferric chloride, ammonium persulphate, and a mixture of hydrochloric acid and peroxide bleach. Each method has advantages and disadvantages:

Method	Advantages	Disadvantages
Ferric chloride	Etches at room temperature.	Horrid yellowy-brown colour stains everything it comes in contact with. Best done outside using things you'll never use again.
Ammonium persulphate	Does not stain. Easy to tell how much copper the solution contains, and therefore whether the solution is still ok.	Only etches at 60-70ºC and above. Can be a bit fiddly to get the right concentration.
HCl/H₂O₂	Can be recharged by bubbling air through it with an aquarium pump, which means less chemicals to buy, and less to dispose of.	Two rather nasty corrosive chemicals, so care must be taken.

There is a lot of information about making circuit boards on the Internet. For example, here's an interesting article about using just a tablespoon of ferric chloride per board, which I think I will do next time. There is also lots of information on the various techniques here.

I have been using ammonium persulphate, which needs to be kept hot in order for it to work. I put the etchant in a foam ice-cream container, and heat it in the microwave until I can just see vapour. (You don't want to do this too long, as you probably don't want a film of ammonium persulphate eating away the metal parts of your microwave). The foam of the container helps keep the etchant hotter for longer, although it will probably not stay hot enough for the 5-10 minutes needed to etch the board. So, bad boy that I am, I admit to re-heating the etchant in the microwave, even with the PCB in the etchant. I haven't heard any of the arcing that usually happens if you microwave a dish that accidentally has a bit of aluminium foil in it.

Anyway, here's a pic of the etch in progress:

Etching boards. Blue is copper ions

I etch the boards for long enough that large blank areas of the board have completely lost their copper, but not so long that the etchant has had time to start undercutting the tracks of my circuit. After etching, I wash the boards in cold water.

When you are finished, you will have a container of etchant. If you are a cheapskate hobbyist like me, you can save the etchant in a bottle for next time. The etchant is generally good for a couple of boards, depending on how much etchant there is, and the size of the boards you've etched. But there will come a time (for ammonium sulphate, this is when the solution has become such a dark blue that you don't think it could become any bluer) when you have to dispose of the etchant. The problem is that copper ions are an environmental toxin. Apart from taking the etchant to your local waste disposal centre, one idea is to use a paintbrush to paint the etchant onto newspaper, and let the newspaper dry. Then you can dispose of this newspaper in your garbage.

Obviously, the purpose of the etchant is to eat away metals. The problem is that any etchant that gets splashed onto metal (for example, if you're working near a sink, or if you are foolish enough to tip the etchant down the drain) will keep etching. I'm told a drop of etchant will create pinholes in your sink faster than you'd think. So it's probably best to keep the etchant well away from sinks and drains. I do my etching outside, and have a plastic bucket of cold water to do my rinsing in.

After the board is etched, the areas where you want copper are still covered in the dye. This dye can be removed with acetone, or scrubbed off with a scouring pad (don't use steel wool, as the iron may react with the copper over time). The problem is that this leaves the copper exposed to the air, which will then quickly tarnish. There are several ways to treat this. One way is to spray the board with special solder-through lacquer. Another way is to use a special compound to “tin” the board with a metal that doesn't corrode as quickly as copper. I use Cool-amp silver plating powder from ultrakeet.com.au. I haven't yet worked out how to get a great, easy result with this product, but it's better than nothing. An alternative to Cool-amp is Liquid Tin, (and in .au, here), which I haven't used. Expensive, but I know folks who swear by it, and say it lasts years. Sounds worth it to me.

Here are the etched and tinned boards:

Etched and tinned playpause boards

After tinning the boards, I cut them up using an abrasive wheel in my Dremel tool:

Etched, tinned and cut playpause boards, with artwork

Then I file the edges of the boards, and give them a bevel. The boards are then ready for use.

So there you have it: PCBs from artwork to finished. I hope this is interesting and useful. Special thanks to Ross McK, who showed me how to do it. Ross is a great guy and a fine engineer, and he has taught me a lot.

Coming next: Playpause assembly and programming

Update: Here's another very interesting page where the author also adds a solder-stop mask. His German heritage really shows, as his boards are wonderful!

Video Circuits: 3d image manipulator // vector monitor

noreply@blogger.com (Chris) — Fri, 10 Feb 2012 10:59:32 +0000

synchrot/synchroton

Harald Welte: Some comments on the heated debate on SFC / Busybox / Linux GPL enforcement

Thu, 09 Feb 2012 01:00:00 +0000

During the past week[s], there has been a heated debate on the alleged methods of GPL enforcement as it is performed by the Software Freedom Conservancy on behalf of the Busybox copyright holders.

The extent of license enforcement on Busybox has apparently triggered the proposal to create a non-GPL replacement for it, which in turn has received quite harsh responses e.g. from Matthew Garrett.

It's been relatively difficult for me to figure out what is really going on here. It is well-known that the Free Software Conservancy has been actively enforcing the GPL on Busybox. But then, at the same time gpl-violations.org has been (and still is!) similarly active in enforcing the GPL on the Linux kernel. Still, I haven't yet seen calls to write a non-GPL Linux kernel replacement. Of course, the complexity is on an entirely different scale, so this point is moot.

However, for quite some time there have been rumors about the intensity (some would say aggressiveness) of the enforcement. I don't want to accuse anybody of anything, so I'm going to write speculatively about it.

This post is to summarize my thoughts on all of this:

It is well within the right of each author / copyright holder to decide on the enforcement strategy and license interpretation. As such, I respect the decision of the authors. It is their work, they should decide what to do.
In any kind of GPL enforcement, you of course not only want the complete corresponding source code to one program, but to all of the GPL/LGPL/AGPL or otherwise copyleft licensed programs contained in the product. We at gpl-violations.org have always been requesting the complete corresponding source code to all GPL licensed software during our communication with the infringing companies. This request was typically honored by everyone, without the need to apply any pressure onto it. After all, releasing only one bit of code causes the risk to get sued by somebody else who owns the other not-yet-compliant part of the code.
Now there have been rumors that SFC was not only requesting non-Busybox source code, but also making it a condition for the explicit re-instatement of the license on Busybox. Whether or not there was such a hard condition is subject to debate and there are different opinions on it. For those in the field of FOSS licensing, it has always known that there are different lines of thought with regard to the requirement to explicit reinstatement. We in Germany generally think that it is not required at all, and the existing preliminary injunctions at least implicitly acknowledge that as they enjoin companies from distributing a product as long as it is not in compliance with the license. In other (particularly the U.S.), it is generally assumed that explicit reinstatement is required. In such a case, it may very well be legally possible to use it as a lever to obtain source code for other programs like the Linux kernel. However, I am personally not sure if that really is the right strategy. Not everything that is possible legally is ethically the right thing to do. But then, ethics and legal customs differ widely in the FOSS communities, as they do in society in general. Some countries and communities believe in the death penalty, others don't. Some countries allow abortion, others don't. Some allow prostitution, others don't. So when judging about whether that "reinstatement lever" is acceptable or not, we have to accept that there may be different lines of thought. I for my part definitely think that the far superior method is, beyond doubt, to have a rights holder on those other program in order to make any demand for source code (as opposed to a mere request without implicit or explicit legal threat).
There also have been rumors about a requirement on submitting future source code releases to a compliance audit by the Conservancy. According to SFC sources, there never was any such demand, and the rumors are likely spawned by some incorrect claims of a defendant in a court case, which ended up in the public record. If there was such a requirement, I wouldn't think it is just - at least not for a first-time non-intentional infringement case. If there was repeated infringement and a clear sign that it would happen again and again, such a requirement for future audits may be justified, depending on the case.
People who claim that GPL enforcement is scaring away companies from using Linux and/or other Free Software also have to be careful in what they say. If a commercial entity enters a new market (let's say Android Tablets), then there is a certain due diligence required before entering that market. So if you don't understand Free Software and particularly GPL licensing, then you shouldn't place a Linux-based device on the market. Just think about an analogy: If you have a recycling company and enter a new market (disposal of hazardous chemicals), then you cannot simply treat those chemicals as regular waste, wait until you run into legal trouble and expect to get away with it.
I think there are still far too many GPL violations out there, and we need to see more enforcement in order to get all the major players in their respective lines of business into compliance. But come on, dealing with embedded devices in 2012 and still getting compliance outright wrong really means that there has not been the least bit of attention on this subject. And without enforcement, it is never going to change. People who want no enforcement should simply use MIT-style licenses.
Last, but not least, I also think GPL compliance is a matter of fair competition. There are some companies who really do a good job in ensuring compliance with the various Free Software licenses. If their competition doesn't invest the funds into the respective skills, procedures and business processes, they are getting an unfair competitive advantage against those who are doing it right. If there was no enforcement, the motivation would be to reduce efforts in compliance, not increase it.

Let me conclude with a clear statement to anyone who thinks that by replacing Busybox with a non-GPL licensed project they can evade GPL enforcement: It will not work. There are others out there enforcing the GPL. Last but not least gpl-violations.org. Despite the notoriously outdated webpage, we are still alive and kicking, churning down on the violation reports that we receive. Armijn Hemel, Joachim Steiger, Tim Engelhardt, Julia Gebert and Till Jaeger deserve much of the credit for all that work, while I'm mostly spending each awake minute hacking Free Software for mobile communications. Yes, we should publish more about our activities, and I hope to find the time to do so. There should at least be an annual report with the number of cases...

Tuxbrain: FOSDEM 2012 - Open Source bajo 0 ;)

Wed, 08 Feb 2012 17:18:05 +0000

Un año más, como no podía ser de otra manera, nos hemos echado el petate a la espalda para visitar la ya conocida entre las conocidas y cita ineludible FOSDEM.

Nada más llegar ya nos imaginábamos que esto se iba a acabar pareciendo a un episodio de “Superviviente”,por que había caído una nevada considerable, pero nuestro espíritu “frikoso” nos ha mantenido constantes en nuestro empeño... de llegar a la Fiesta de la Cerveza !!!

Village Telco: SPUD Simple Unified Dashboard for mesh networks

Wed, 08 Feb 2012 06:49:28 +0000

IT46 have been hard at work and have just made the first public release of SPUD (Simple Unified Dashboard), a wireless mesh network visualisation tool for BATMAN mesh networks and its users.

SPUD is a PHP based dashboard that communicates with the BATMAN visualization server and displays real time wireless link status. The software is written in CakePHP (a PHP-based MVC framework) and uses Google Maps API 1.3 for visualization.

SPUD is designed to be as simple as possible to use, and to enable teams, that have installed large amount of mesh nodes, to visualize their networks quickly.

Some of the core features of SPUD are:

Client management: Bulk import of clients from CSV file, Edit client position with Google Maps, Tracking of new clients
Link monitoring: Easy overview of active wireless links, Mesh quality in each direction of a wireless link
Customization: Colours and threshold values for link quality

See above and below for screenshots that shows some of the functionality of SPUD. The source code is available via SVN at

svn co http://dev.villagetelco.org/svn/villagetelco/spud/trunk/

and the default configuration will monitor our demo site in Bo Kaap (Cape Town)

Detailed installation instructions are available at

http://spud.villagetelco.org/install (user: vt-admin pass: ouagadougou) or http://dev.villagetelco.org/trac/wiki/spud_install

We have set up a demo site of SPUD that visualizes the Bo Kaap network. The demo is available at: http://spud.villagatelco.org. Please feel free to play with it, and provide us your feedback!

GNSS-SDR: GLONASS L2: NEW RESULTS

Tue, 07 Feb 2012 15:45:09 +0000

After a pause in developing GLONASS L2 software receiver for SciLab I found some time to work with it. The error that didn't allow to calculate correct PVT is fixed now. So GLONASS L2 scilab receiver is fully working now. PVT solution for L2 signals recorded in the may 2011 is shown on the figure 1.

Figure 1 PVT solution for L2.

On the figure 2 PVT solution for L1 is presented for comparision.

Figure 2 PVT solution for L1.

The source code is available through google code.

Open Hardware Repository: FMC Projects - FMC projects & co. presented in FOSDEM 2012

Tue, 07 Feb 2012 13:35:35 +0000

Freetronics: Yard light controller replaced with an Eleven

Tue, 07 Feb 2012 05:11:04 +0000

The winner of the Tronixstuff January competition, Mike Rossetti, received a Freetronics Eleven as a prize, and today he wrote to the Tronixstuff Google Group with details of the project he used it for. From his post:

The synchro-motor-driven timer in my yard light controller burned out. So instead of spending $15US replacing the clock I decided to implement my own controller using the Freetronics Eleven! (With an ultimate cost well over $100US. But then a lot of that was acquiring some new tools and stocking my 'kit'. ;^) The cost for the parts actually used was right around $20US—not too bad!)

Since I was using an Arduino I was determined to make two critical improvements in my yard light controller that the old synchro-clock could not accommodate:

- No need to reset the clock after a power-fail (courtesy of an RTC)
- No need to get down in the mud twice a year to adjust the clock for that blasted daylight savings time.

Ultimately, I was able to add one other major feature:

- Controllable using an old Sharp remote control.

Here's what I can do with the remote control:

- Display/adjust the current time
- Display/adjust the sun sensor level for turning on/off the lights
- Display/adjust what time the lights are turned off at night and on in the morning (as long as the sun isn't up)
- Display/adjust when daylight savings starts and ends (which Sunday of which month, i.e. DST starts 2nd Sunday of March)
- Manually turn the light on or off, overriding the sun and timer

In the picture here can see the original light control box on the left (with the cover removed). That circular opening with the clear tape on it is where the old synchro-clock was mounted. Beneath the black and yellow wires is a 20A solid-state relay I got for about $5 on eBay. I'd originally wanted (and tried like the dickens) to get everything into the original box but there just wasn't quite enough room, hence the add-on box on the right (that's the smallest Radio Shack had that would fit the Eleven). Below the 7-segment LED display can be seen the photocell and the I/R receiver. Back over in the old box is an unused Nexus S power wart. (I really wanted a smaller power supply! Doesn't anyone have such a thing? Something without a built-in plug?)

That's the project for which I put the Freetronics Eleven to good use. Thanks John and thanks Freetronics for all the fun!

Thanks for sharing the project with us, Mike! We're glad you found a good use for the Eleven.

Liu Xiangfu, openmobilefree.net: 每天都要带着相机

Mon, 06 Feb 2012 23:58:26 +0000

(用电脑上的摄像头拍的，还在激动中…)

Free Electrons: HOWTO Mailing lists with Mailman on Ubuntu 10.04

Mon, 06 Feb 2012 16:55:00 +0000

Free Electrons is not in the system administration business (we offer free and open-source solutions for embedded systems), but we do our best to share whatever experience we acquire, and whatever code we produce.

We configured a KVM virtual machine to run our mailing lists, and we used Ubuntu 10.04, the long term support (LTS) version. Here are instructions based on this experience. You could also use the same instructions to install Ubuntu 10.04 on a tiny, low power ARM board. And if you wish to use a more recent version of Ubuntu, I expect the steps to be very similar.

Here we assume that your domain is example.com and that you install your mailing list software on lists.example.com. It is indeed a good idea to install your mailing list software on a different server. This way, you won’t mess up with your main web and mail servers. Not having CGI scripts running on it will also keep your main mail server more secure.

Install packages

Install the Apache web server. It will allow administrators to configure and manage the lists, and users to subscribe, unsubscribe and tune their subscription settings.

sudo apt-get install apache2

For e-mail delivery, I chose the Postfix MTA (Mail Transport Agent). Exim would have been a good solution too, but I am more familiar with Postfix, which is already in use on our main mail server.

sudo apt-get install postfix

Choose the Internet site option.

Now install the mailman package:

sudo apt-get install mailman

Select the languages that you want your mailing list interfaces to support. I chose English and French for the moment. To add more languages later, run:

sudo dpkg-reconfigure mailman

Configure the Apache web server

First copy the sample Apache configuration file provided by the mailman package:

cp /etc/mailman/apache.conf /etc/apache2/sites-available/mailman

Now, in /etc/apache2/sites-available/mailman, enable short URLs by enabling:

ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/

Also modify /etc/mailman/mm_cfg.py:

DEFAULT_URL_PATTERN = 'http://%s/mailman/'

The last step is to enable your mailman site in Apache:

sudo a2ensite mailman
sudo /etc/init.d/apache2 restart

You should now have a new symbolic link in /etc/apache2/sites-enabled/.

Check that the Mailman website works by opening your mailing lists home page: http://lists.example.com/mailman/listinfo. It should look like http://lists.free-electrons.com/mailman/listinfo.

Configure postfix

Enable the following line in /etc/mailman/mm_cfg.py:

MTA='Postfix'

Once the MTA is configured, generate Mailman specific aliases for Postfix:

sudo /usr/lib/mailman/bin/genaliases

Now, you need to configure Postfix through its main.cf file. A convenient way to do this is to run the below commands:

sudo postconf -e 'relay_domains = lists.example.com'
sudo postconf -e 'transport_maps = hash:/etc/postfix/transport'
sudo postconf -e 'mailman_destination_recipient_limit = 1'
sudo postconf -e 'alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases'

Also add the following line to /etc/postfix/transport:

lists.free-electrons.com      mailman:

and run:

sudo postmap -v /etc/postfix/transport

You won’t have any mail delivery if you forget. I struggled for a few hours before I realized I forgot this setting.

Now, set correct file ownership:

sudo chown root:list /var/lib/mailman/data/aliases
sudo chown root:list /etc/aliases

For logging and debugging e-mail delivery, I recommend to install the sysklogd package. Without it, you won’t have any mail.info, mail.warn and mail.err files in /var/mail/.

To install this package, enable the universe repository if needed (uncomment the lines with universe in the /etc/apt/sources.list file), and run:

sudo apt-get update
sudo apt-get install sysklogd

To avoid having two mail.info and mail.log files with identical contents, edit /etc/syslog.conf and remove the below line:

mail.*                          -/var/log/mail.log

Also create a /etc/logrotate.d/mail file to rotate logs, as in the below example:

/var/log/mail.* {
        daily
        size 10M
        rotate 4
        compress
        missingok
        notifempty
        create 640 root adm
}

Last but not least, restart Postfix:

/etc/init.d/postfix restart

At this point, a good idea is to check that mail delivery works:

sudo apt-get install bsd-mailx
mailx alice@example.com
Subject: test
test
.
Cc:

Note: that’s the line containing only a dot character that allows to terminate the message.

If the receipient doesn’t receive this message, there is an issue in the way your mail server is configured. This could be because the firewall doesn’t allow connections to outside machines through tcp port 25. Anyway, look at the logs in /var/log/mail.* to get a clue. There is no point going on in this howto until you get this fixed.

Creating the mailman site list

Mailman needs a so-called “site list”, which is the list from which password reminders and such are sent out from. The default name for this list list mailman, though you can change this through the MAILMAN_SITE_LIST setting in /etc/mailman/mm_cfg.py.

To create this list, run:

sudo newlist mailman

You will have to answer a few questions like:

Enter the email of the person running the list: postmaster@example.com
Initial newsletter password: xxx
Hit enter to notify newsletter owner...

Choose the password carefully, as crackers will be able to highjack your mailing list if it is too easy to guess.

The next required step is to add the list aliases to /etc/aliases:

# mailman mailing list
mailman:              "|/var/lib/mailman/mail/mailman post mailman"
mailman-admin:        "|/var/lib/mailman/mail/mailman admin mailman"
mailman-bounces:      "|/var/lib/mailman/mail/mailman bounces mailman"
mailman-confirm:      "|/var/lib/mailman/mail/mailman confirm mailman"
mailman-join:         "|/var/lib/mailman/mail/mailman join mailman"
mailman-leave:        "|/var/lib/mailman/mail/mailman leave mailman"
mailman-owner:        "|/var/lib/mailman/mail/mailman owner mailman"
mailman-request:      "|/var/lib/mailman/mail/mailman request mailman"
mailman-subscribe:    "|/var/lib/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe mailman"

In addition to delivering e-mail to the mailing lists, these aliases also allow to subscribe and unsubscribe by writing to special e-mail addresses.

You also need to run the newaliases command, without which there is no e-mail delivery:

sudo newaliases
sudo /etc/init.d/postfix restart
sudo /etc/init.d/mailman restart

Look at the /var/log/mailman/error file for potential issues.

Create regular mailing lists

Regular mailing lists are created in the same way as above: Assuming you want to create a newsletter mailing list. You will need run:

sudo newlist newsletter

Add your new mailing list to /etc/aliases:

# newletter mailing list
newsletter:              "|/var/lib/mailman/mail/mailman post newsletter"
newsletter-admin:        "|/var/lib/mailman/mail/mailman admin newsletter"
newsletter-bounces:      "|/var/lib/mailman/mail/mailman bounces newsletter"
newsletter-confirm:      "|/var/lib/mailman/mail/mailman confirm newsletter"
newsletter-join:         "|/var/lib/mailman/mail/mailman join newsletter"
newsletter-leave:        "|/var/lib/mailman/mail/mailman leave newsletter"
newsletter-owner:        "|/var/lib/mailman/mail/mailman owner newsletter"
newsletter-request:      "|/var/lib/mailman/mail/mailman request newsletter"
newsletter-subscribe:    "|/var/lib/mailman/mail/mailman subscribe newsletter"
newsletter-unsubscribe:  "|/var/lib/mailman/mail/mailman unsubscribe newsletter"

Then, run the usual commands:

sudo newaliases
sudo /etc/init.d/postfix restart
sudo /etc/init.d/mailman restart

Configuring your lists

The easiest way to configure your lists and add members is to open the http://lists.example.com.com/mailman/listinfo URL with a browser.

A few things are also possible from the command line. For example, you can add a member as follows:

echo "alice@example.com" > /tmp/foo
sudo add_members -r /tmp/foo newsletter

Enabling archives

Default file permissions are not completely ready to support mailing list archives:

sudo chown -R root:list /var/lib/mailman/archives
sudo chmod o+rX /var/lib/mailman/archives/private

The second line allows the webserver to access the archives. Note that these settings were forgotten in the official Ubuntu documentation.

Settings for newsletter mailing lists

At Free Electrons, we also use Mailman to deliver our newsletters. Mailman provides recipients with an easy mechanism to subscribe by themselves and unsubscribe whenever they want.

To make it even easier to unsubscribe from a newsletter, Mailman can add a special footer to each recipient, with a custom URL that allows to unsubscribe without having to remember one’s password.

To enable this feature, you have to enable the following line in /etc/mailman/mm_cfg.py:

# Extra options
# Allow to personalize each message
# (useful to provide a password-less unsubscribe link)
OWNERS_CAN_ENABLE_PERSONALIZATION = 1

Restart Mailman (/etc/init.d/mailman restart) and go to the administrative interface for your list. Under Non digest options, you will then be able to set the Should Mailman personalize each non-digest delivery? option to Full Personalization.

Then, you can set a custom footer for each recipient in the Footer added to mail sent to regular list members option. Here is an example:

_______________________________________________
Free Electrons quarterly newsletter
Unsubscribe: %(user_optionsurl)s?password=%(user_password)s
Archives: http://lists.free-electrons.com/pipermail/newsletter/

Beware that sending custom e-mails to each recipient will increase the load on your server. You may not want to do this on mailing lists with great numbers of subscribers.

Useful resources

The below ressources were useful to prepare this HOWTO document:

Don’t hesitate to ask questions and give feedback by leaving a reply below.

FreakLabs: chibiArduino v0.55 Release

Mon, 06 Feb 2012 05:34:43 +0000

I just released the latest version of the chibiArduino code. There are two main changes:1) The code was modified and tested to be compatible with the Arduino v1.0 IDE as well as previous versions.2) The code has been moved to github.I think that's about it. Sorry I didn't make the changes for the Arduino 1.0 compatibility sooner. It was actually pretty painless. The move to github is nice too. Its much nicer to have the repo online rather than having...

osPID: Production Update

Sun, 05 Feb 2012 14:19:54 +0000

Things are finally rolling at osPID HQ. All of our parts are either on site or in transit, and production will being as soon as everything arrives.

That’s the good news. The less-good news is that we’ve had to push back our planned ship date. Originally we were planning on shipping this week. Unfortunately we’ve had to push that back to the week of 2/19.

The Story

With every delay it’s good to have a scapegoat, and we’ve got one! Maxim Electronics. On the prototype temperature card, we used their MAX6675 thermocouple chip. For the production model, we decided to use their newer (and less expensive) MAX31855 chip.

When we went to order the MAX31855 however, instead of the initially advertised January delivery date, the date had been revised to July. JULY! We checked various suppliers, but this seems to be an issue with Maxim itself.

So, faced with a choice between a 6 month delay and a more expensive chip, we decided to eat the cost and revert the board back to the MAX6675 configuration we had used in the prototype.

During this whole debacle we lost our place in line with the PCB manufacturer and had to re-submit our order. Unfortunately this put us on the other side of Chinese New Year.

And that brings us to today. We want to apologize for both the delay and the chip swap. If you had your heart set on the MAX31855, know that from a financial perspective so did we. We have a board designed and ready for that chip. Once supplies of the are more reliable we will transition to it.

Video Circuits: Keaton Smith

noreply@blogger.com (Chris) — Sun, 05 Feb 2012 05:54:56 +0000

Keaton Smith

Video Circuits: Snow Canon (1981)

noreply@blogger.com (Chris) — Sun, 05 Feb 2012 01:45:11 +0000

As it snowed today I was reminded of this

Video by Synopsis
Music by Steve Roach
Graphics by Denise Gallant/Brian Samuels
from California Images:HiFi For The Eyes

FreakLabs: Technique vs Feel

Sat, 04 Feb 2012 22:55:43 +0000

I recently got into an interesting discussion on Twitter with some other engineers regarding the parallels between dancing and engineering. I often get a surprised look from people when I tell them I used to be a professional dancer. Perhaps its because I look like a nerd, or perhaps its because I am one. In any case, its true and its something that I spent many years and countless hours doing. The strange thing is really that it's nothing different...

Free Electrons: Free Electrons at the Android Builders Summit and the Embedded Linux Conference: one talk and video recording

Sat, 04 Feb 2012 05:23:45 +0000

A good part of the Free Electrons team will be in San Francisco (actually, not in San Francisco, but in the Bay Area) from February, 13th to 17th for the Android Builders Summit and the Embedded Linux Conference.

Android Builders Summit 2012

The Android Builders Summit is the second edition of this conference dedicated to Android system development (and not application development). Compared to last year, the conference has been extended to three parallel tracks during two days, as can be seen in the schedule. There are many talks about Android customization, Android internals, Android porting, usage of Android in specific markets (medical devices, vehicle infotainment), etc. A lot of useful talks for developers working at the Android system level.

Embedded Linux Conference 2012

The Embedded Linux Conference is now a well-established conference. Again for this 2012 edition, there will be three parallel tracks during three days. As the schedule shows, there will be talks about many, many topics: performance and optimization, power management, build systems, drivers for various types of devices, multimedia, ARM kernel support and much more.

I will be giving a talk about Buildroot: A Nice, Simple and Efficient Embedded Linux Build System on the second day of the conference. The aim of the talk is to give a status on where Buildroot is, three years after a maintainer was choosen and a big clean up work was started. The project has changed a lot compared to its state three years ago, so I thought it would be nice to make a status on where Buildroot and where it is going.

With my colleagues Grégory Clément and Maxime Ripard, we will also record all the talks from the Embedded Linux Conference in order to put the videos online, freely available, after the conference, as we have done for many past conferences.

We hope to meet you in San Francisco for the Android Builders Summit and the Embedded Linux Conference!

Open Hardware Repository: FMC TDC 1ns 5cha - 02-02-2012: V2 design ready

Erik.van.der.Bij@cern.ch (Erik van der Bij) — Thu, 02 Feb 2012 15:23:55 +0000

Open Hardware Repository: Simple VME FMC Carrier (SVEC) - Schematics review held

Erik.van.der.Bij@cern.ch (Erik van der Bij) — Thu, 02 Feb 2012 13:52:22 +0000

Dieter Spaar: Running your own Node-B

Thu, 02 Feb 2012 01:00:00 +0000

Its now nearly 3 and a half year ago that I wrote the first "Proof-of-Concept" code to get the Siemens BS-11 GSM Basestation up and running. So I think it was time to start with 3G, now that LTE is being actively deployed. You also can sometimes find reasonable priced, used Node-Bs which makes getting access to the equipment possible. A Node-B is the 3G equivalent of a GSM BTS.

So I spent quite a lot of time spread of several months to get a Node-B up and running. Compared with the BS-11 this was a lot more difficult and required much more time. Of course the Air Interface is completely different, in my case I looked at WCDMA FDD so far, there a few more standards used in other parts of the world. Then you have to deal with a huge, different specification, the most important when dealing with a Node-B are NBAP (TS 25.433) and RRC (TS 25.331), around 3000 pages in total. NBAP, the Node-B Application Part, is used to configure the Node-B and do things like creating Radio Links (communication channels) to the phone. RRC, the Radio Resource Control, is the Layer-3 protocol for the control plane between the phone and the access network. It is responsible for accessing the network, setting up and releasing connections or paging a phone. Both NBAP and RRC make use of ASN.1 which makes things not necessarily easier ;-) There are a few more protocols on the lower layers involved like MAC (TS 25.321), RLC (TS 25.322) and FP (TS 25.435 and TS 25.427).

The Node-Bs I used can run "Iub over IP" (Iub is the interface between the Node-B and the RNC, similar to Abis in GSM between the BTS and BSC). Originally Iub is based on ATM which runs over E1/T1 or similar lines with higher data rates. However "Iub over ATM" adds a few more protocol layers for dealing with ATM and I really wanted to avoid this additional complexity. Not all Node-Bs can automatically do "Iub over IP", usually it requires an additional hardware option (interface card). When using "Iub over IP" you have to deal with protocols like UDP and SCTP which are much more convenient.

The current status is a very minimal implementation of something like an RNC to run the Node-B so that a phone can register on the network and do simple things like SMS on the control plane. No user plane like speech or data yet, but this is the next steps I plan to do. The code is not yet public but it will be when it gets more evolved.

There is still a lot left to research and experiment with. For example I haven't looked at things like HSPA yet, I completely ignore handover to other cells as there is only one cell in my experimental setup. So I am sure 3G will give a few more years of a very interesting field to play with before looking at LTE ;-)

Free Electrons: Announcing our Android System Development training

Wed, 01 Feb 2012 06:22:27 +0000

For multiple years, Free Electrons has provided two typical training courses for embedded Linux developers: an Embedded Linux system development course that focuses on the basics for embedded Linux development (bootloader and kernel configuration, compiling and usage, system integration and build systems, cross-compiling, filesystems, application development and debugging, etc.) and an embedded Linux kernel and driver development course that focuses on kernel and driver development (kernel APIs for drivers, character drivers, device model, power management, kernel porting, etc.). In total, we have given dozens of editions of these sessions in multiple locations all around the world. We have kept our commitment to release all the training materials under a free license (the Creative Commons CC-BY-SA license), and they are therefore freely accessible for anyone at http://free-electrons.com/docs/.

We are now announcing a new course, called Android System Development. It is a four day training session that targets engineers who need to develop embedded systems with Google Android.

Through theory and practical labs, the course makes you familiar with compiling and booting Android, with adapting Android to support a new embedded board (assuming that it is already supported by the Linux kernel), and with building a real system through accessing specific hardware, customizing the filesystem and using debugging techniques. See the complete agenda. The training materials for this session will also be made available under the same Creative Commons CC-BY-SA license.

If you are interested in this training session, you can:

Join the public session organized in Toulouse, France, on June 11-14, 2012. See registration and organization details.
Order an on-site training session to be held at your location. See registration details.

This training course will be given by our engineer Maxime Ripard who has gained Android experience by working at Archos on Android tablets, by making Android work on multiple TI OMAP3 based platforms and also by participating to the Android Builders Summit conference.

Do not hesitate to contact us for further details about this new training course.

Sebastien Bourdeauducq, lekernel.net: The OV-D20 radio-club in Berlin-Hohenschönhausen

Tue, 31 Jan 2012 22:02:18 +0000

Located close to the north-west border of the city, far from the popular districts, the D20 “Ortsverbände” of the national amateur radio club is certainly one of the most active grassroots tech clubs in Berlin.

As with many amateur radio clubs, the first thing you notice is that the average age is high. And they know how to appreciate vintage equipment. We can find, for example, a neat exhibition of electronic glassware.

And how about this “Made in DDR” transceiver?

The electronics lab comes with a mix of old (but does such stuff really get old?) and more modern equipment. Do not miss the SMD tools at the right – which were refreshing to see after I have been called “totally crazy” for hand-soldering a 0402 component on top of another in a well-known Berlin hackerspace. Phew, some people really need to catch up with technology.

There can be very interesting things being built there, such as this modified TV antenna that can now be used to… talk to AMSAT satellites and the ISS (yes, the space station) on the VHF band, using for example the APRS digital protocol. So… if you’re growing sick of being told about mediocre computer-controlled plastic extruders and microcontroller+LED kits, pay them a visit. It’s probably going to be worth the rather long travel time.

Open Hardware Repository: CERN Open Hardware Licence - 31-01-2012: OHL being discussed on LWN.net

Erik.van.der.Bij@cern.ch (Erik van der Bij) — Tue, 31 Jan 2012 16:56:49 +0000

LWN.net is a reader-supported news site dedicated to producing the best coverage from within the Linux and free software development communities.
In response to CERN's Call for Comments LWN.net currently discusses improvements to the CERN OHL licence.

Note that cernohl@ohwr.org is the official mailing list where the CERN Open Hardware Licence is discussed and that is guaranteed to be followed by the relevant people. Fortunately the most interesting messages from LWN.net are transmitted to this official mailing list.

Free Electrons: Free Electrons at FOSDEM: two talks and video recording

Tue, 31 Jan 2012 09:12:16 +0000

As usual, Free Electrons will again be present at the FOSDEM conference in Brussels, on February, 4th and February 5th. We will of course mostly be attending the Embedded DevRoom, with multiple talks around development in the embedded space.

We will also be giving two talks this year:

My colleague Maxime Ripard will be giving a talk about IIO, a new subsystem for I/O devices. In short, IIO is a new subsystem in the kernel to write drivers for devices like Analog-to-Digital converters. Maxime has worked on a driver inside the IIO subsystem for the internal ADCs of the AT91 processors from Atmel, and will base his talk mostly on the experience developing this driver. This talk will take place on Saturday, 12:00 AM to 1:00 PM in the Lameere room.
I will be giving a talk on Using Qt for non-graphical applications. It is a talk that has already been given at the Embedded Linux Conference Europe, but the audience of FOSDEM and ELCE being quite different, we have chosen to propose it for FOSDEM as well, and it got accepted. This talk will take place on Sunday, 1:00 PM to 2:00 PM in the Lameere room.

There are also other talks that are worth noting: a SoC power management talk from Jean Pihet who works on OMAP power management support in the Linux kernel, a talk about OpenCores and OpenRISC, a talk about Safe Upgrade of Embedded Systems by Arnout Vandecappelle, who contributes a lot to Buildroot, and also other talks about OpenWRT, Yocto, licensing issues in Android, the EFL libraries, and more.

We will also be carrying our camcorder to video record those talks. We are trying to see with the FOSDEM organization team if it possible to record the audio directly from the room sound systems in order to provide better audio quality in our videos.

If you happen to be at FOSDEM, we’d be very happy to meet you!

Video Circuits: Jeffrey Siedler

noreply@blogger.com (Chris) — Tue, 31 Jan 2012 03:09:19 +0000

http://www.plaide.com/

Free Electrons: Buildroot Developer Day, Brussels edition

Mon, 30 Jan 2012 21:03:55 +0000

Around each FOSDEM conference and Embedded Linux Conference Europe event, we have been organizing a Buildroot Developer Day for a few years, in order to gather some developers and users of the Buildroot build system, in order to discuss the development of Buildroot, its features, development process, design, and more.

In Prague at the last Embedded Linux Conference Europe in October 2011, we had a very interesting meeting that gathered developers from other build systems (OE-lite, OpenBricks and PXTdist), and we published a report of this meeting.

The next Buildroot Developer Day will take place on Friday, 3rd February, just before the FOSDEM conference, in Brussels. This is the first meeting that will gather such a number of Buildroot developers: Peter Korsgaard (Buildroot maintainer), Arnout Vandecapelle (developer from Essensium/Mind, who has been contributing a lot to Buildroot lately), Thomas De Schampheleire (also a big contributor in the last year or so), Luca Ceresoli, Yann E. Morin (developer of Crosstool-NG), my colleague Maxime Ripard (who contributed package enhancements and improvements of the package infrastructure) and myself.

This meeting is open to all Buildroot developers and users, and will take place in a location easily accessible in the center of Brussels. Do not hesitate to contact me at if you want to take part to this meeting.

Open Hardware Repository: FMC ADC 200k 16b 11cha - 200 ksps ADC documented

Erik.van.der.Bij@cern.ch (Erik van der Bij) — Mon, 30 Jan 2012 08:45:47 +0000

Ross Millar, student at the University of Glasgow, has worked for six months at CERN to debug the 200 ksps ADC, write firmware for it and develop a new version of the circuit board. He wrote an extensive report about his work.
Before this ADC can be produced in quantity, the final design has to be verified and the firmware needs to be re-aligned with the firmware of the 100 MSPS ADC so it can more easily be maintained and driver code can be more easily shared.
We needed to put the project on hold because of lack of manpower and the availability of a commercial and proprietary alternative for CERN's applications.

Freetronics: Arduino for amateur radio

Sun, 29 Jan 2012 12:50:59 +0000

Peter Parker VK3YE came along to the Mini Maker Faire in Melbourne a couple of weeks ago, and picked up a KitTen (an Arduino-compatible board in kit form) while he was there. He's already used it for a bunch of interesting experiments, including attaching a radio transmitter to turn it into a Morse-code CQ caller and as a fox-hunt beacon!

Check out his cool video:

http://www.youtube.com/watch?v=kTN-68VhF

Harald Welte: New OsmocomBB RSSI monitor firmware

Sat, 28 Jan 2012 01:00:00 +0000

Jolly has been hacking up a nice new RSSI monitoring firmware application for OsmocomBB.

I let the pictures speak for themselves:

I really hope this trend continues and we'll get some actual user interface in OsmocomBB at some point this year..

Open Hardware Repository: OHR Support - OHWR MAINTENANCE ON 2011-01-30 (MONDAY) 08:30 CEST

egarcia@splendeo.es (Enrique García) — Fri, 27 Jan 2012 10:15:32 +0000

Hello everyone,

Next morning we'll be doing some server updates on the OHWR main server.

As usual, the maintenance job will happen next monday at 08:30 CEST. Our estimation is that it will take about 30 minutes to complete.

All of the ohwr.org subdomains & services (including svn.ohwr.org, lists.ohwr.org, and the git repositories) will be interrupted for a short while during that interval.

We apologize for any inconvenience this could cause.

Best regards,

The OHR-support Team

Freetronics: Review of the DMD Dot Matrix Display by John Boxall

Tue, 24 Jan 2012 10:58:32 +0000

Definitely the most eye-catching device we have in our range is the huge new Dot Matrix Display panel, which comes bundled with a ribbon cable and an adaptor designed to fit standard Arduino headers to make it really easy to get started. It's attracted a lot of interest over on the Freetronics Forum, with new features being added to Marc's driver library very rapidly.

John Boxall (of Tronixstuff fame) has just posted a review of the DMD along with videos showing it in action. Check this out:

You can read his full review on the Tronixstuff site:

Arduino meets Las Vegas with the Freetronics DMD

Geoffrey L. Barrows - DIY Drones: Detecting and locating lights using an Arduino and an image sensor

Mon, 23 Jan 2012 06:00:00 +0000

I've been experimenting with using an Arduino-powered vision system to detect and locate point light sources in an environment. The hardware setup is an Arduino Duemilanove, a Centeye Stonyman image sensor chip, and a printed pinhole. The Arduino acquires a 16x16 window of pixels centered underneath the pinhole, which covers a good part of the hemisphere field of view in front of the sensor. (This setup is part of a new ArduEye system that will be released soon...)

The algorithm determines that a pixel is a point light source if the four following conditions are met: First, the pixel must be brighter than it's eight neighbors. Second, the pixel's intensity must be greater than an "intensity threshold". Third, the pixel must be brighter, by a "convexity threshold", than the average of it's upper and lower neighbors. Fourth, the pixel must similarly be brighter, by the same threshold, than the average of it's left and right neighbors. The algorithm detects up to ten points of light. The Arduino script then dumps the detected light locations to the Arduino serial monitor.

A 16x16 resolution may not seem like much when spread out over a wide field of view. So to boost accuracy we use a well-known "hyperacuity" technique to refine the pixel position estimate to a precision of about a tenth of a pixel. The picture below shows the technique: If a point of light exists at a pixel, the algorithm constructs a curve using that pixel's intensity and the left and right intensities, then interpolates using a second order Lagrange polynomial, and computes the maxima of that polynomial. This gives us "h", a subpixel refinement value that we then add to the pixel's whole-valued horizontal position. The algorithm then does something similar to refine the vertical position using the intensities above and below the pixel in question. (Those of you who have studied SIFT feature descriptors should recognize this technique.) The nice thing about this technique is that you can get the precision of a 140x140 image for "light tracking" without exceeding the Arduino's 2kB memory limit.

The algorithm takes about 30 milliseconds to acquire a 16x16 image and another 2 or 3 milliseconds to locate the lights.

The first video shows detection of a single point light source, both with and without hyperacuity position refinement. When I add a flashlight, a second point is detected. The second video shows detection of three lights (dining room pendant lamps) including when they are dimmed way down.

It would be interesting to hack such a sensor with a quadrotor or another robotic platform- Bright lights could serve as markers, or even targets, for navigation. Perhaps each quad rotor could have an LED attached to it, and then the quad rotors could be programmed to fly in formation or (if you are brave) pursue each other.

With additional programming, that sensor could also implement optical flow computations much like I had done in a previous post.

SOURCE CODE AND PCB FILES:

The main Arduino sketch file can be found here: LightTracker_v1.zip

You will still need library files to run it. I've put these, as well as support documentation and Eagle files for the PCBs, in the downloads section of a Google Code project file, located here: http://code.google.com/p/ardueye-rocket-libraries/downloads/list

Video Circuits: HEX at Space Studios

noreply@blogger.com (Chris) — Sat, 21 Jan 2012 15:31:37 +0000

I went to see the HEX exhibition as Space Studios the other day tis on till Jan the 4th
If you don't know about Hex/Hexstatic and you like video feedback or even just audio visual creativity in general then this is a good introduction.

here are some bad phone snaps

Mark Adrian Bell: pyturtle

Sat, 21 Jan 2012 06:59:30 +0000

Python is a free open source programming language. At an advanced level, it’s a powerful and flexible language, but it’s clear and straight forward syntax, and it’s forgiving nature, make it a great way to introduce people to programming
and computer science.

Younger learners can start by writing programs to draw shapes and
patterns in the PythonTurtle learning environment. They can also learn to write simplified functions to help Guido Van Robot to explore his abstract world. Both these programs provide learners with an interactive environment to learn basic concepts like sequencing, conditional branching, looping and procedural abstraction through problem solving with instant visual feedback.

PythonTurtle

When learners are ready, they can use the Python programming language to explore a free online course book like How to Think Like a Computer Scientist. Advanced learners can graduate to graphics and game programming with a free online course like Invent Your Own Computer Games with Python.

Python is such a flexible language that learners have the opportunity
to exlore procedural, functional and object oriented styles of programming that they can use later if go on to study languages like
C, C++, Java, and Haskell.

Mark Adrian Bell: edubuntu

Sat, 21 Jan 2012 05:36:05 +0000

The Edubuntu live CD is suite of free and open source education and general software that you can run from the CD without having to install anything. It’s based on Ubuntu Linux. It gives you a great range of software to play with for learners of all ages.

If you like some of the stuff on the CD, these days most open source software has Windows or MacOS versions available from the project website for you to download and install. Or if you really dig it, and you’re adventurous, you can install the whole lot to your hard drive and run Linux as an alternative operating system.

Follow the links to find out more about Linux, more about open source software, a place in Australia to buy Linux live CDs in case you don’t feel like downloading and burning your own, other education focused live CDs.

FabFi Wireless: Wifi and the Internet of Things

noreply@blogger.com (Keith Berkoben) — Wed, 18 Jan 2012 17:24:00 +0000

Today is a day for thinking about the future of the web. By virtue of being the author of this blog, that gets back to the future of communications infrastructure, and especially wifi. Apologies in advance if I wax poetic, Wikipedia, Craigslist, and Reddit are all down today in protest of SOPA/PIPA.

In recent years there's been a lot of chatter about the nature of technological convergence and the future of global telecommunications infrastructure. Technological optimists, particularly those interested in the developing world trumpet, "mobile, mobile, mobile" and, on many levels, they're right... While we won't be ditching big screens and real keyboards any time soon, all statistics point to the fact that mobile devices account for an increasing number of transactions, tasks, and amount of user online time. Without doubt, mobile has been disruptive in the west, speeding the transition to cloud computing; a game-changer for Africa, bringing millions online; and largely responsible for an global wave of grassroots protest movements. The thing that people tend to miss, however, when talking about the future dominance of mobile is that the device and the communications infrastructure are not one in the same.

Our lust for data is killing mobile providers (you need only look as far as the near-extinction of the unlimited data plan), and it's technologically challenging to shrink mobile cell sizes enough to [economically] support traffic loads on limited spectrum licenses. Mobile carriers depend on the extremely efficient use of spectrum that comes with careful site planning and modeling. This gets exceedingly hard to do as cell sites become more numerous and demand cheaper installations.

The licensed nature of mobile spectrum/devices also makes the sort of grassroots innovation and entrepreneurship that typifies the online world very difficult. If we were only talking about making smartphones maybe we wouldn't care, but the smartphone is only the tip of the iceberg for the growing world of ubiquitous, cloud-enabled computing.

The ability to be "connected" at all times is clearly desirable (even if we choose to unplug sometimes for our own sanity). Smartphones have achieved a permanent position in our pants pockets formerly afforded only to wallets and house keys; but connectedness is only useful to the degree that we can interact with our world through being connected. Social was easy: "I'm connected. You're connected, let's share some photos and poke each other", but what about STUFF?

The natural next step for a connected person is to have a connected world to interact with. We've already started with the big ones: Thermostats, security systems, home theater. But the possibilities are endless, and it seems that the consumers are hungry. If you think I'm kidding, check out this Kickstarter project from some of my former Media Lab colleagues that garnered a half a million bucks to create a wifi-enabled rubber(?) brick, with a temperature sensor and accelerometer, that can be used for useful stuff like telling you when your laundry is done. Innovation to fill this new space of connected "stuff" will only thrive with the low entry barriers of an open internet, unlicensed spectrum and cheap hardware.

In any case, the monolithic model of wireless communication is just not going to work. A natural consequence of having EVERYTHING connected is a whole lot of unplanned and uncoordinated wireless communications generated by cheap, duty-cycled devices, flying around all over the place. This is the sort of thing that breaks traditional mobile communications.

Wifi, especially with 802.11n and soon 802.11ac boasts so much capacity that even in an environment where 40 or more uncoordinated access points are all visible to each other (such as my bedroom), you can still expect to share 15Mbps or more with all the devices in your home, while your neighbor can do the same, simultaneously. The limitations of wifi, in terms of range and penetration of obstacles, are strengths in the world where everything is a transmitter. You won't send 15Mbps simultaneously to every home in my neighborhood with 4G...

As opposed to falling off in popularity as mobile improves, wifi has continued to strengthen. Wifi will ultimately bridge the gap between wireline and mobile providers. Cable companies have already embraced wifi as a way to increase the value of their services. In Europe, mobile providers like T-Mobile have embraced wifi for years, and US mobile providers are now being forced to add wifi to offload traffic. Ubiquitous, cheap, unlicensed. It's a recipe for innovation, and a guarantee that wifi will only increase in importance as we become increasingly connected. Keep hacking...

FabFi Wireless: Development Kits Live!

noreply@blogger.com (Keith Berkoben) — Wed, 18 Jan 2012 04:31:00 +0000

Thanks to Nathan from California, the first Fabfi development kit went out the door today. With the Monday holiday, I had the chance to do a little fit testing of the hardware on a spare pole I had lying around. The itelite enclosure with integrated 18dBi dual-polarization patch took some modifications to mount the RouterStation, but was very robust and had a solid rubber gasket and grooved interface around the edges to keep water out. The built-in ethernet extension plug was also a nice touch. 19" pigtails for the external antennas exit through an optional port on the itelite enclosure and screw directly into the 2.4Ghz antennas.

Below is a sample look at the current kit spec all mounted up. Mounting with the top of the pole above the tops of the antennas is a common trick to protect against lightning strikes (20cm is usually enough):

I'd prefer to see the stock antenna mounts getting the antennas farther from the pole for decreased RF shadow and better spatial diversity, but this could be easily remedied with a crossbar. For applications requiring less 5Ghz gain, a clean option might be to offer a 6-way radome. I might get a chance to test this out in the near future.

Liu Xiangfu, openmobilefree.net: Icarus mining report

Wed, 18 Jan 2012 03:12:00 +0000

15 days mining about Total: 4.04000000 BTC， the mining software restart about 850 times.

Video Circuits: Michael Matos CUSP

noreply@blogger.com (Chris) — Tue, 17 Jan 2012 01:41:20 +0000

"A short film of a worm like creature, who emerges from the earth, experiences joy and loss, only to return from whence he came. Created with the help of some lzx visionary modules, my dearest eurorack pals, and my lovely oscilloscope."

http://Www.Skull-fuckers.com/

http://soundcloud.com/ultra-gash-inferno

Video Circuits: Old shots of Lucky PDF karaoke with Taki and Lucy

noreply@blogger.com (Chris) — Mon, 16 Jan 2012 10:57:50 +0000

I helped out my friends Taki and Lucy in creating a live video effects karaoke piece as a small part of Lucky PDF Live at Frieze art fair. I just provided the live equipment set up and they did all the hard work as I was out of the country during most of the show, but I did get a chance to snap a few shots of the set up before I went.

also Lucky PDF have been nominated for this art prize so if you are in the mood please vote for them as they are hard working and all round nice guys

Video Circuits: Sync Generator + Encoder + Modular Synth = Video!

noreply@blogger.com (Chris) — Mon, 16 Jan 2012 10:38:57 +0000

So I recently got a Sync generator that has all sorts of signals available on mini jack! I had a video encoder stashed away so I decided to see if I could use my euro rack audio modular to generate video signals, safe to say it worked like a charm! now I just need to build some video oscillators and a small mixer and my system will work pretty well.

Andrew Zonenberg, Silicon Exposed: First BGA board

noreply@blogger.com (Andrew Zonenberg) — Sun, 15 Jan 2012 19:42:21 +0000

(NOTE: This was originally scheduled to happen a lot earlier but the fab screwed up shipping on the boards. I only got them today.)

A while ago I decided to get serious about doing a design based on the Spartan-6 FPGA. Unfortunately all but the smallest part in the family are BGA only. They're somewhat pricey ($40ish for the XC6SLX25) so I figured it'd be a good idea to practice on something less expensive!

Quick calculations given the DorkbotPDX batch order's design rules showed that anything under 1mm pitch was not possible in a full array since a via could not fit between adjacent balls. This rules out the CPG196, CSG225, CSG324, and CSG484 packages. The remaining options are FTG256, FGG484, FGG676, and FGG900. FTG256 looked like the easiest as it had the least pins.

I did a bit of catalog browsing and determined that the cheapest FTG256 part available from Xilinx was the XC3S50A, which at $10 a pop was still a bit expensive for testing BGA soldering processes.

Eventually I settled on CPG56 packaged CoolRunner-II CPLDs as my first victim (Digikey page). CPG56 is 0.5mm pitch but is only two concentric rings, not full array.

CPG56 packaged CPLD

The next step was to design a board. I went with a simple 2-layer design that did not break out all of the balls, but seemed to offer enough IOs to be useful for casual testing.

Once the boards arrived I quickly inspected them under my microscope. They were the typical DorkbotPDX batch boards - purple LPI soldermask and ENIG finish on the pads. Some of the unbonded pads (A7-A9) appeared to have lifted off the board or underetched during manufacture. Since the pads weren't being used in the board layout this was not a problem, though it did mean the chip would be attached a bit less securely. I forgot to take a photo of this but will try to upload one soon.

I have a Proctor-Silex toaster oven I had used for reflow several times in the past but never on a BGA. There is no thermocouple or automatic temperature profile control on the oven yet (a Type-K thermocouple is inbound from Sparkfun as I write this) so I used my standard manual profile for lead-free solder, adjusting the thermostat by hand for each step:

Heat quickly from room temperature to just below 100C
Soak at 100C for 30-60 seconds
Ramp up to 180C, hold for 15-30 seconds
Ramp up to 220C, hold for 15 seconds
Open door, wait 30 seconds, remove board

The first two attempts at soldering failed as the chip was not even close to correctly aligned. The first (pic coming soon) was so far off (about 250 μm) that none of the balls even touched the pads. Visible holes in the flux residue showed just how far off center it had been. The second was slightly better but still not usable.

One of the first two reflow attempts

On the third attempt I paid extra attention to centering the chip and it seemed to turn out well. I then hand-soldered the clock oscillator, voltage regulator, JTAG header, and the 0402 sized decoupling capacitors on the back.

When I attempted to solder the breadboard headers I realized I had used the wrong drill size and the pins didn't fit. Since the only ones I really cared about were power and ground I just soldered two wires into the holes.

Finished board, top view

Finished board, bottom view

Electrical test showed no shorts anywhere between adjacent balls. Optical inspection looked good too.

Side view of CSBGA

After hooking it up to a 3.3V power rail and a JTAG programmer, I was able to successfully program it with a simple design (divide-by-2 counter). Oscilloscope confirmed a nice 10 MHz squarewave on the output when driven by 20.

Freetronics: Arduino-driven Christmas light display

Fri, 13 Jan 2012 03:10:46 +0000

I don't know anything about this project other than what you can see in the YouTube description, but it looks like quite an effort. 7500 LEDs controlled using a custom 50-channel output board, synchronised to music using an Arduino. It's not clear whether it's done with an Arduino Mega (which is what the description says) or one of our EtherMega boards (which it would be if all the parts came from Jaycar, as the description also says).

Either way, it's an impressive bit of work! Enjoy:

LZX Industries: LZX Industries at NAMM 2012

Thu, 12 Jan 2012 15:33:24 +0000

We’re very excited about NAMM 2012 coming up next week in Anaheim, CA. We’ll be exhibiting a large LZX Visionary modular video synthesis system at the Analogue Haven booth (Booth #1270, Hall E). If you’ll be there, we hope to see you!

Freetronics: The Maker Faire is coming to Melbourne!

Wed, 11 Jan 2012 13:28:46 +0000

For those of us isolated from the rest of the world by shark-infested oceans and 10-hour plane trips, seeing all the Open Hardware action in the US and Europe has left us feeling just a little bit jealous. Over the last few years I've looked enviously at pictures of the huge O'Reilly Maker Faire, wishing there was such a thing in Australia.

Now, thanks to the hard work of Paul Szymkowiak (@paulzee to his friends!) and his army of helpers, my dream is coming true!

Within a few hours the venue will be announced (it's all settled, pending some official paperwork) and the call for Makers to exhibit has already gone out.

The Mini Maker Faire Melbourne will take place on Saturday January 14th, 2012 to coincide with the start of linux.conf.au in Ballarat, so if you're coming into town for LCA you can drop in at Mini Maker Faire Melbourne first and then head on to the conference.

More details can be found at www.makerfairemelbourne.com.

Video Circuits: A/V Geeks and LoVid Present “The Tricks That TV Plays” and “A Tone”

noreply@blogger.com (Chris) — Wed, 04 Jan 2012 17:03:32 +0000

"A/V Geeks share an interesting evening with homebrew video and audio synthesizer masters LoVid. A/V Geeks will be presenting a couple of similar themed films with “The Tricks That TV Plays” – films that highlight the visual tricks that television can play on its viewers – films include Seeing Through Commercials, Vidtronics Demo Tape and more!"

Date 26.01.11 Place Kings Barcade 14 West Martin Street, Raleigh, NC 27601

http://www.avgeeks.com

http://www.lovid.org/

HUGE thanks to youtuber toner for the tip off

Zedstar: TCR update

Wed, 04 Jan 2012 14:23:38 +0000

Building The Clashing Rocks prototype was fun. It really identified some brick wall challenges surrounding the quantity of data we had to process in real-time. Even encoding to bit-level was not going to cut it. As a result a new direction for the project will be to focus solely on recording the seismic events. This will provide more opportunity to implement techniques to work with the bandwidth constraints in place and will eliminate the hard real-time processing constraints. There will still be the challenge of synchronising, logging and presenting the data but we will focus more on providing high-level APIs and/or a DSL to help realise this. The project will still be OpenWrt based and run on different architectures.

Chitlesh Goorah: [FEL]: fritzing as new year gift

Tue, 03 Jan 2012 21:01:26 +0000

On the 1st january 2012, fritzing was pushed into fedora stable repositories, by Ed Marshall.

Fritzing is an open-source initiative to support designers, artists, researchers and hobbyists to work creatively with interactive electronics. We are creating a software and website in the spirit of Processing and Arduino, developing a tool that allows users to document their prototypes, share them with others, teach electronics in a classroom, and to create a pcb layout for professional manufacturing.

Fritzing is a nice project from our german friends, which I feel is a nice place to share their openhardware. They even provide Fab service. For those of you who uses the Italian project Arduino, you will enjoy fritzing along with arduino IDE. Happy prototyping !

Chitlesh Goorah: [FEL]: Fix for strange characters on Arduino Ethernet

Mon, 02 Jan 2012 13:05:28 +0000

Thibault North has released an update of avr-gcc-4.6.2 which fixes the presence of strange characters when using the Arduino Ethernet due to a corrupted transmission.

Michele's GNSS blog: Processing Galileo

noreply@blogger.com (Michele Bavaro) — Sun, 01 Jan 2012 13:25:00 +0000

The first prototype of SdrNav20 is working these days to receive the Galileo signal in space.

Figure 1: First SdrNav20 assembled prototype.

Using a simple patch antenna, the first acquisition done using a 8MHz bandwidth reports the expected spectrum purity and signal properties.

Figure 2: Power spectrum of signal acquired on SdrNav20 channel 1. A bandwidth of 8MHz is wide enough for BOC(1,1), but not CBOC(6,1,1/11). A bandwidth limitation is anyway introduced by the antenna SAW filter as well.

Figure 3: Time series and histogram of the acquired signal. The gain of the satellite tuner was set to 60dB (RF) and 8dB (IF), which could not excite the second MSB of the MAX19505 ADC.

The acquisition of Galileo PFM shows the typical BOC(1,1) correlation shape.:


Figure 4: BOC(1,1) correlation shape, averaged on 100 codes (400ms).

A short file (for anybody to try his/her own acquisition) can be found here.

EDIT 27/12/2012: Acquiring with SdrNav20 Galileo-FM2 (Galileo-PFM seemed momentarily disabled)

Figure 5: Galileo-FM2 E1 correlation shape, averaged on 100 codes (400ms).

The messages on E1B looked good, but still dummy:

a98e40000000002aaaaa4f4f2ffb8000
00955555555555555555555544790000
a98ec0000000002aaaaa5063173b8000
3f4a63d11ea372ec4d3b4f84dcbb0000
934ed3e1372ec4d3b4f83b4db6d54000
3f4a63f11ea372ec4d3b4f84dcbb0000
934ed3e1372ec4d3b4f803cb10954000
3f4a64111ea372ec4d3b4f84dcbb0000
934ed3e1372ec4d3b4f8225d9ad54000
00955555555555555555555544790000
a990c0000000002aaaaa4823ab3b8000
00955555555555555555555544790000
a99140000000002aaaaa6957e27b8000
3f4a64711ea372ec4d3b4f84dcbb0000
934ed3e1372ec4d3b4f80a454ed54000
3f4a64911ea372ec4d3b4f84dcbb0000
934ed3e1372ec4d3b4f803617e554000
3f4a64b11ea372ec4d3b4f84dcbb0000
934ed3e1372ec4d3b4f83be7d8154000
3f4a64d11ea372ec4d3b4f84dcbb0000
934ed3e1372ec4d3b4f813ff0c154000
3f4a64f11ea372ec4d3b4f84dcbb0000
934ed3e1372ec4d3b4f82b79aa554000
00955555555555555555555544790000
a99440000000002aaaaa6d48287b8000
00955555555555555555555544790000
a994c0000000002aaaaa726410bb8000
00955555555555555555555544790000
a99540000000002aaaaa531059fb8000
d3978d7c6c2e85281e379780ce9f8000

A sample file is here.

Adding to the above, SdrNav20 demonstrates acquisition of L2C and L5 (or Galileo E5a):

Figure 6: Power spectrum of L2C signal captured with SdrNav20

Figure 7: Signal acquisition of GPS L2C signal (only of enabled PRNs)


Figure 8: Power spectrum of L5 signal captured with SdrNav20

Figure 9: Signal acquisition of GPS L5 signal (only of enabled PRNs)

Figure 10: Signal acquisition of Galileo-PFM on E5a

A couple of files for L2C and L5 are stored respectively here and here. Please mind that L2C acquisition (without assistance) can be a long process given the length of the codes :)

Cheers!

Michele

P.S.: The file name is self-explicative: fs is sampling frequency, fif is intermediate frequency, bw is bandwidth, interleaved I&Q has 'int8_t' type samples (pretty much as the GN3Sv2 used to output).

Andrew Zonenberg, Silicon Exposed: SITREP - December 2011

noreply@blogger.com (Andrew Zonenberg) — Sat, 31 Dec 2011 23:10:33 +0000

Figured it's about time I posted an update since I haven't had time to write for a while, I just started the PhD program and my work has been keeping me busy.

I'm going to be broadening the focus of this blog a bit to cover topics besides reverse engineering: general electronics, FPGA design, semiconductor fabrication, infosec, and various other related stuff.

My focus will be on things generally considered too difficult for hobbyists, like BGA soldering and MEMS/CMOS fabrication.

Expect a series of posts over the next few days on my newly upgraded lab!

Andrew Zonenberg, Silicon Exposed: Multiple Lithography in Homemade PCBs

noreply@blogger.com (Andrew Zonenberg) — Sat, 31 Dec 2011 23:09:27 +0000

Earlier this week I decided it was about time to try making a board for some of the 24AA16 EEPROMs I had sampled from Microchip a year ago. It's a 16kbit I2C EEPROM with five pins: power, ground, I2C data and clock, and write protect.

Five pin package - piece of cake, right? But, just to add to the fun, the package I picked was CSBGA with balls about 250μm apart!

From the packaging specification, it can be seen that the balls are 150 μm diameter and spaced in a 2x2 grid 570μm x 520μm with one more in the center. This is a little smaller than my laser-printer contact lithography process can comfortably resolve. What to do?

Conveniently I have a metallurgical microscope that I've managed to coax into service as a projection lithography system. The field of view is, however, far too small to do an entire PCB.

After a little thinking I decided to try a multiple-exposure technique. The first step was to design a board layout in ExpressPCB (my preferred CAD tool is kicad but Express is a little easier for super simple layouts) with a 4-pin SIL header going to a rectangle of copper a little bigger than the CSP footprint. I also made a second mask containing the BGA footprint and tracks going out to four large pads, and printed it at 4x actual size. The center ball is WP# so I tied it to Vdd rather than breaking out to a separate pin.

Mask design

I then printed a mask on my printer, exposed onto precoated PCB, developed (1% w/v NaOH in distilled water), and etched (6 parts 3% H2O2 : 1 part 32% HCl at low heat) as with my standard PCB process.

The next step was to strip the existing photoresist since it had been exposed to light during the etch process. A few drops of acetone did the trick nicely.

I then spin-coated the board with fresh photoresist, using my standard mixture (Shipley SP24 photoresist diluted 50% v/v with acetone for a thinner layer), soft baked on a hot plate, and exposed the BGA mask onto the copper rectangle. After developing, this was the result:


Second photomask on top of etched metal1

Closer view showing edge quality

Not surprisingly, the resolution and edge roughness were vastly better than the contact lithography process. (I've scaled the same technique to 20 μm half-pitch on silicon and there's room to go a lot further.) In retrospect the traces were a little too small considering that the copper layer they're sitting on is 35 μm thick, but this was a mask design error and not a process issue.

Since the thin photoresist I use is harder to see on copper than the thick stuff the board came coated with, I tossed it in the etchant for a couple of seconds to make it more obvious what was being masked.

After a couple seconds in the etch bath

The copper pad was also a bit larger than it needed to be and exceeded the FOV of the lithography system (note the unwanted photoresist shorting the pads together). I gently scraped this away with a #11 scalpel blade under 30x magnification and briefly etched to confirm good separation.

Surgery time!

After etching, no shorts

I then etched for a couple of minutes and removed the board to see how it was doing.

Almost done etching

Things still looked very good, all traces were intact. For traces with such a high aspect ratio (about 40 μm wide in 35 μm thick copper) things looked surprisingly good, but it needed a little more time.

Overetched. (photoresist stripped before taking this pic)

Unfortunately I overetched, one of the traces was gone entirely and another was seriously damaged. Some residue was still in place between two of the pads. Perhaps better agitation would help?

In either case, had the traces been a little larger (perhaps 75 μm) or the copper a little thinner it would have worked beautifully. The lithography itself was flawless and even though the board was not usable it appears the technique is feasible. Given a mask respin this same board could be fabricated with little difficulty.

OsmoSDR: OsmoSDR hardware verification at 28C3

Sat, 31 Dec 2011 14:51:55 +0000

At 28c3, the OsmoSDR team was busy verifying the hardware design on the first prototypes.

The result can be summarized as:

SAM3U is working, enumerates on USB and can be programmed via SAM-BA
E4K tuner driver is working
Si570 driver is working
FPGA can be flashed via JTAG bit-banging from SAM3U
FPGA and SAM3U can speak via SPI

However, there are at least two bugs:

USB socket footprint pin-out was mirrored
clock output level of Si570 doesn't match FPGA clock input specs (amplitude too low)

The issues have been worked around, and firmware + FPGA development has made progress.

OsmoSDR: About OsmocomSDR

Sat, 31 Dec 2011 14:44:42 +0000

This is the blog of the OsmoSDR project, a small-size, low-cost Software Defined Radio hardware/firmware project.

Video Circuits: Peter Donebauer "Entering" (1974)

noreply@blogger.com (Chris) — Sat, 31 Dec 2011 04:26:37 +0000

"The imagery and sound in Entering were performed 'live' by Donebauer and composer Simon Desorgher, and recorded in real time, using a colour TV studio at the Royal College of Art. Later Donebauer and Richard Monkhouse developed the Videokalos synthesiser, as an image-sound performance instrument. Entering was transmitted by the BBC in 1974."

Uploaded by Visual Remix Workshop rmx-visual.tumblr.com/ "Visual remix" is a project consisting of workshop series aiming to explore ideas of remix in visual arts and design. It invites students to re-interpret or hybridize classic design/art piece and produce unique result independent of the intentions and vision of the original designer/artist.
Project by Rafaela Drazic (rafaeladrazic.net)

Video Circuits: Sabrina Ratté at Bubble Byte

noreply@blogger.com (Chris) — Fri, 30 Dec 2011 12:13:48 +0000

Sabrina Ratté
Activated Memory
31/12/11 - 29/01/12
30/12/2011 (7-11pm GMT)

"bubblebyte.org is pleased to present Activated Memory, a solo exhibition by Canadian artist Sabrina Ratté.

Activated Memory is a two video project based on animated photographs of different parks and buildings of Montreal. Through the use of video feedback, 3D animation and color manipulations, the pictures render a new kind of space, a virtual world where only fragments of "reality" subsist. The music accompaniment is composed by Roger Tellier-Craig.

In Activated Memory I, a video created for The Download section of rhizome.org, parks appear through a very minimalist form composed by trees and grass. It is a journey through the parks disposal and their interaction with light, almost creating a surreal experience while studying symmetric relationships between various elements like dunes, bridges, lost routes and nature. The park and its imaginary recall childhood visits and the way of looking at things, almost like a hologram of an idealised memory.

Activated Memory II, created exclusively for bubblebyte.org, uses buildings as the main subject of observation. As a counterpoint to parks, buildings are characterised by angular forms and opaque surfaces. Architecture is used as a point of departure to create instability. Buildings discompose their limits into the frame while the geometric original shapes and dimensions of the image loose control to create an entrance to a chaotic space where forms become liquid."

Fabricatorz: Open Hardware Manufacturing (from China)

Wed, 28 Dec 2011 00:00:00 +0000

I recently spoke at TTI Vanguard's NEXTGEN conference in Miami. Totally great experience to talk to some very high level folks about the work we are doing as Fabricatorz on the Qi Hardware and Milkymist Video Synthesizer project. Here are my slides. The first set I did on my laptop, and the second set I *performed* using the Milkymist! In 2012, I will try to use the Milkymist for any performances (no more presentations!).

I should note that the presentation title reflects popular interest in some of my topics, and not the specific words I would choose to represent what we are working on. In particular, we are staying away from using the words FREE, OPEN, COPYLEFT now in favor of Sharing, hence Sharism. Also, the word Hardware is a bit problematic because of what it conjures up for computer nerds as this an already manufactured piece of hardware, like the 400K iphones foxconn is churning out a day. We take it to mean more like the glass or metal that is part of a final product. To consider the Milkymist or our projects FROM CHINA is not completely accurate. While I spend a lot of time in China, the Milkymist in particular is manufactured mostly in Taiwan.

Oh well, words are words are words! Check out the slides below and please share. They are ✳ (shared by) me, aka: ✳ Fabricatorz.

(Click here for the SVG presentation or the SVG with outlines)

(Click here for the SVG presentation or the SVG with outlines)

Ask me about the event the next time you see me; I have some great stories to tell since this event was supposed to be mostly private during the conference.

In a more public showing, Yi from Qi Hardware is presenting about the Milkymist tonite (中文 at Xinchejian, the Shanghai-based hackerspace we held the first Sharism Presents Shanghai.

Don't forget to Buy a Milkymist One for yourself or your friendz :)

Video Circuits: Russ Cogdell Apeirogon

noreply@blogger.com (Chris) — Mon, 26 Dec 2011 02:43:01 +0000

russcogdell

Liu Xiangfu, openmobilefree.net: Linux version usbboot for Ingenic xburst 4770

Sat, 24 Dec 2011 08:23:48 +0000

‘Yuenshu Fong’ create a Linux version usbboot for xburst 4770 cpu. you can find the source tar ball here

Uwe Hermann: HOWTO: Using OpenVPN on Debian GNU/Linux

Sat, 24 Dec 2011 00:02:25 +0000

Here's a quick HOWTO for setting up an OpenVPN server and client on any (Debian, in this case) Linux machine of your choice. I'm running an OpenVPN server on a box at home, and a client on my laptop, so I can securely route all my laptop traffic through my OpenVPN server, no matter where I am.

I highly recommend reading the official OpenVPN HOWTO from top to bottom, at least once. But here's a short, condensed HOWTO (specifically geared towards my needs, yours might be different):

On the server:

Install OpenVPN (apt-get install openvpn), then copy the "easy-rsa" files to /etc/openvpn/easy-rsa from where we'll use them to create our keys and certificates:

  $ cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa
  $ cd /etc/openvpn/easy-rsa

In the vars file change the KEY_SIZE variable from 1024 to 4096 for good measure:

  export KEY_SIZE=4096

Then, read in the vars file, clean old keys and certificates (if any) and create new ones:

  $ . ./vars
  $ ./clean-all
  $ ./build-ca

You'll now have the chance to enter some data such as country code (e.g. "DE"), state/province, locality, organization name, organizational unit name, common name, name, and email address. The values you choose don't really matter much (except for commonName, maybe, which could be your hostname or domain or such). Finally, the ca.key (root CA key) and ca.crt (root CA certificate) files will be created.

Next, we'll create the server key:

  $ ./build-key-server server

You'll have to enter lots of info again (see above), commonName could be "server" or such this time. Upon "Sign the certificate? [y/n]" say y, as well as upon "1 out of 1 certificate requests certified, commit? [y/n]". Finally, the server.key and server.crt files will be created.

Same procedure for creating a client key (I used "client1" as filename and commonName here):

  $ ./build-key client1

Next up we'll generate Diffie Hellman parameters (this will take a shitload of time due to keysize=4096, go drink some coffee):

  $ ./build-dh

When this step is done, you'll have a dh4096.pem file.

As we want to use OpenVPN's "tls-auth" feature for perfect forward secrecy (it "adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification"), we'll have to generate a shared secret:

  $ openvpn --genkey --secret ta.key
  $ mv ta.key keys

So much for creating keys. Now, we'll have to configure OpenVPN. Copy the default server config file and edit it:

  $ cd /etc/openvpn
  $ cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz .
  $ gunzip server.conf.gz

The most important change in my setup is that I use port 443/TCP instead of the usual OpenVPN default of 1194/UDP. This increases the chances that you'll be able to use OpenVPN in almost all places, even in environments which firewall/block lots of stuff. Port 443/TCP (for https) will almost always be usable. I also uncommented the following line, which tells the client to use the VPN interface (usually tun0) per default, so that all the client's traffic (web browsing, DNS, and so on) goes over the VPN:

  push "redirect-gateway def1 bypass-dhcp"

Here's my server config file (comments and commented out lines stripped):

  port 443
  proto tcp
  dev tun
  ca /etc/openvpn/easy-rsa/keys/ca.crt
  cert /etc/openvpn/easy-rsa/keys/server.crt
  key /etc/openvpn/easy-rsa/keys/server.key  # This file should be kept secret
  dh /etc/openvpn/easy-rsa/keys/dh4096.pem
  server 10.8.0.0 255.255.255.0
  ifconfig-pool-persist ipp.txt
  push "redirect-gateway def1 bypass-dhcp"
  keepalive 10 120
  tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0 # This file is secret
  comp-lzo
  user nobody
  group nogroup
  persist-key
  persist-tun
  status openvpn-status.log
  log-append openvpn.log
  verb 3

You can now start the OpenVPN server, e.g. via

  $ /etc/init.d/openvpn restart

Server firewall setup/changes:

I'm running a custom iptables script on pretty much all of my boxes. Here's the relevant changes needed to allow the OpenVPN server to work properly. Basically, you need to enable IP forwarding, accept/forward tun0 traffic and setup masquerading (change "eth0" below, if needed):

  echo 1 > /proc/sys/net/ipv4/ip_forward
  iptables -A INPUT -i tun+ -j ACCEPT
  iptables -A FORWARD -i tun+ -j ACCEPT
  iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
  iptables -t nat -F POSTROUTING
  iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

My firewall script gets run upon every reboot. If you don't use such a script, you could add the above stuff to your /etc/rc.local file.

On the client:

Install OpenVPN (apt-get install openvpn), then copy the default client config file and edit it:

  $ cd /etc/openvpn
  $ cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf .

Change the parameters to match the server config (port 443/TCP, and so on) and use "tls-auth /etc/openvpn/ta.key 1" (note the "1" on the client, and the "0" on the server!). Replace xxx.xxx.xxx.xxx with the public IP address of your OpenVPN server. If it doesn't have a public, static IP address already, you can use services such as DynDNS, or (my preferred method), my ssh-based DIY poor man's dynamic DNS setup.

Here's my full client config:

  client
  dev tun
  proto tcp
  remote xxx.xxx.xxx.xxx 443
  resolv-retry infinite
  nobind
  user nobody
  group nogroup
  persist-key
  ca /etc/openvpn/ca.crt
  cert /etc/openvpn/client1.crt
  key /etc/openvpn/client1.key
  ns-cert-type server
  tls-auth /etc/openvpn/ta.key 1
  comp-lzo
  verb 3

Now you only need to copy the required certificates and keys to the client (into /etc/openvpn): client1.crt, client1.key, ca.crt, and ta.key. Do not copy the other, server-specific private keys and such to the client(s)! Also, the root CA key (ca.key) should not even be left on the server, but rather moved to some offline storage/box, so that it cannot fall into the wrong hands, e.g. in the case of a server compromise.

I prefer to manually start the client on my laptop when needed, so I use AUTOSTART="none" in /etc/default/openvpn and then start the client via:

  $ openvpn /etc/openvpn/client.conf

That's it. Comments and suggestions for improving the setup and/or the security aspects of it are highly welcome!

Video Circuits: Neil Gravander

noreply@blogger.com (Chris) — Fri, 23 Dec 2011 09:40:14 +0000

Neil Gravander
http://www.myspace.com/luckyb0ne
scroll down for article

Video Circuits: Valmet Children Glitch Workshop

noreply@blogger.com (Chris) — Wed, 21 Dec 2011 10:07:42 +0000

http://matiaswilkman.blogspot.com/

Peter Zotov, whitequark: Statically compiled Ruby

Wed, 21 Dec 2011 05:48:00 +0000

Ruby is a very dynamic language by its nature, and it has quite a generalized interface. Everything is an object, objects communicate only by sending messages to each other, variables are untyped and everything can be modified at runtime, even (almost) any of the builtins.

This has a serious drawback, through: evaluating Ruby code is a slow process. Even when you have an expression like 5 + 2 (which is syntactic sugar for 5.+(2)), one cannot safely assume that + method has not been redefined as something completely different. Thus, one is required to follow the generic method lookup procedure, which isn’t trivial at all and therefore isn’t fast either.

I have found a way, through, to significantly improve Ruby code performance by restricting just a few of its metaprogramming capabilities.

Strictly speaking, I am placing just a single restriction: no method evaluation at runtime. This implies inability to call load or require after the initial loading process, using Class.new or define_method, absence of eval family functions, certain operations with singleton classes, nested method definitions (def a; def b; end; end) and maybe a few other, even lesser used features.

While all of the above may seem like a severe restriction, actually none of those features are commonly used at runtime, and, in fact, if they are actually used, that’s a sign of bad code. Even on commonly used interpreters this will lead to a huge performance drops because of VM cache invalidation.

Due to the fact that all Ruby definitions are just Ruby code, any compiler is thus required to include a fully capable interpreter. It can be observed that in any typical setting the Ruby application is executed in two stages: at the first one it just loads all the required libraries and defines classes and methods, and at the second stage it simply executes the code while abstaining from defining any methods. The first stage is more complex, as it is a superset of the second.

I propose to execute the definition stage on a full-fledged Ruby interpreter like Rubinius, and to generate efficient machine code with LLVM after it is completed. As the method definition (and redefinition) is forbidden now, it is possbile to perform a lot of optimizations, including constant propagation, type inference and method inlining, and compile a fully statical executable. Unfortunately this approach does not allow for Ruby MRI C extension usage, but FFI can compensate for that.

Let’s dig deeper into the compilation process.

Compilation process

First of all, to be able to operate on the AST of entire application we will need a Ruby runtime library which is written only in Ruby (obviously using primitives for basic operations). Currently, there is only one such implementation–Rubinius–so it is natural to implement the compiler on top of it.

Rubinius provides a lot of methods to inspect its internal state, which will prove to be useful for our purpose. Particularly, it allows one to retrieve bytecode for any executable object.

I should make a small digression here. While I have mentioned operations on AST, in fact these have a little to do with an actual abstract syntactic tree of a Ruby source file. The syntax of Ruby is notoriously complex–it’s enough to say that none of alternative implementations have their own parser–and the AST, while being a bit simpler, is still too complex to allow for convenient transformations. On the other hand, while bytecode only consists of unique opcodes, it is an internal interface prone to unexpected changes, and in case of Rubinius’ bytecode, it is a bytecode for stack VM, which isn’t easily transformed either. The latter can be trivially solved.

AST transformations

The bytecode for stack-based VM is isomorphic to a bytecode for a register-based VM, and the most useful form of latter is a SSA, or Static Single Assignment form. A transformation from stack-based form to SSA is a linear process which practically consists of assigning a new name for each stack cell when something is pushed into it and using that name later when the value is popped and used.

It can be seen that the SSA form is isomorphic to the AST, too, and can be easily folded back to it if necessary. In fact, this will be implicitly done in the process described later.

At this point, a value for each of the arguments of a particular function call is either a literal, a result of a prior function call or application of a primitive. Being constant, literals and results of invocation of pure functions can be propagated through the AST. A lot of literals also behave like a pure function in some or all cases.

Consider this snippet of code:

sym = :test
puts "the symbol is #{sym}"

It may be expanded into the following pseudobytecode:

pushsymbol :test
setlocal 0                  # pop a value and save it as local variable 0
pushstring "the symbol is "
getlocal 0                  # push a value of local variable 0
tostring                    # convert the uppermost value to string
stringconcat 2              # concatenate two uppermost values on the stack
getspecial self             # push the value of self on the stack
send :puts, 1               # send a message :puts to the uppermost value
                            # with 1 next uppermost stack value as an argument
leave                       # return the uppermost value as expression result

The directly transformed SSA representation is as follows:

a = :test
setlocal(0, a)
b = "the symbol is "
c = getlocal(0)
d = tostring(c)
e = stringconcat(b, d)
f = self
g = send(f, :puts, [e])
leave(g)

After folding all local variable accesses and propagating constants, it looks like this:

leave(
  send(self, :puts, [
    stringconcat(
      "the symbol is ",
      tostring(:test))]))

Note the resemblance of resulting structure to an AST.

At this point one can notice that tostring and stringconcat, apart from being primitives, are pure functions and their arguments are constant, too. So, we can expand them at compile time.

leave(
  send(self, :puts, [
    "the symbol is test"]))

The transformation is finished.

In this short example, only one function call (puts) is present. Ruby, where everything is an object, has a lot of examples where simple operations (like adding integers) are actually implemented through function calls with all the associated complexity. In this stage, if we see that a function only consists of a single primitive (like Fixnum#+), we can just replace it with that primitive, which may very well translate to a single machine instruction or even be expanded at compile time. A common Ruby interpreter cannot do that so easily becasue even Fixnum#+ may be redefined at any point at the runtime.

Type inference

If one could infer method return types from their arguments, then in a lot of cases method lookup can be performed at compile-time, which not only avoids running the slowest part at runtime, but also allows to inline methods.

To prepare for this step, we need to compute a call graph–a directed and possibly cycled graph with methods as vertexes and method calls as edges. This graph will be later used to propagate the computed type information from primitive methods to complex ones. Let’s look into this process.

Suppose we have this block of code:

def add(a, b)
  a + b
end

def addi(world)
  add(5, world.to_i)
end

def adds(whimper)
  add("bang! ", whimper.to_s)
end

Without taking any of the cross-references into account, not a lot of information could be confidently inferred from the code. Let’s draw a graph for those few bits which could.

The variables in square brackets represent type specialization for the functions–think of C++ templates–and literals are marked with blue background. Note that while, by a common convention, methods named to_s return String, this convention is not enforced, and hence the compiler cannot rely on it. A value *, when used as a type, means that there is not enough information to do any conclusions on the type of the operand.

A directly derived callgraph for the code above is quite simple:

Green arrows in the leftwards direction represent function return value types.

One can note that function addi always calls add with an Integer as a first argument, and adds similarly always passes String. Looking even further, it becomes clear that for both of the argument types the + operation is a primitive which always returns the same type. So, in our particular case the add function has its return type always the same as that of its first argument. Similarly, the addi and adds functions just return whatever add has returned.

Up to this point, the algorithm was actually implementation- and language-independent. (It is actually a greatly simplified description of Damas-Hindley-Milner type inference on untyped lambda calculus.) Now, with this additional knowledge, one can map the now-typed methods to an optimized implementation. In this case, we will get the biggest benefit from specializing the add method and thus avoiding the + method lookup on each invocation.

Now, both of these specializations can actually be inlined to avoid method call overhead. As each of them is only called from one location, this is safe, straightforward and will actually reduce code size.

Also, this process will optimize out most, if not all of argument verification code–bound checking (if a constant is passed), respond_to? and similar operations.

Advanced type inference

Hindley-Milner type inference only operates on functions, and thus it does not cover some of the problems arising from the use of objects. For example, an array, being strictly heterogenous, is a “typing black hole”: it can accept objects of any type, and it always emits unqualified objects.

A solution to this problem will be presented in a future article.

Space optimizations

As it has been mentioned already, Ruby has a lot of metaprogramming methods, most of which, especially the introspecting ones, require to keep a lot of data at runtime and sometimes have an impact of performance.

For example, if something is calling methods method of an instance of Float, the compiler is required to include method lists for the entire ancestor chain for Float, which isn’t very large, as symbols are used, and to add all of the method names to the symbol table. The latter would consume 905 bytes (as of MRI 1.9.3), which isn’t a big amount for a desktop system with gigabytes of RAM, but may eat up a significant part of ROM of a microcontroller.

All of the instance variable accesses (including those through attr function family) can be compiled to fast indexed access–that is, unless there is a instance_variable_set call somewhere. If there is, a compiler is required to include a hashtable for looking up instance variables by name, and use a less efficient structure for storage to allow expanding the table at runtime.

By correctly inferring the possible types for metaprogramming method applications, the compiler can significantly reduce the space requirements for compiled code. On the other hand, if such a method is applied to unqualified type (represented by * in the graphs), the compiler will then be forced to include metadata for each and every type used.

A way to identify the location of such deoptimizing statements will be provided in the form of detailed optimization log.

Code generation

At last, the machine code is generated. This topic will also be discussed in following articles.

Chitlesh Goorah: [FEL]: gplcver crash fix and openocd update

Mon, 19 Dec 2011 21:31:58 +0000

Shakthi updated gplcver to fix a crash upon launch.

Dean Glazeski updated openocd to 0.5.0.

Chitlesh Goorah: [FEL]: Some minor updates

Sun, 18 Dec 2011 15:04:56 +0000

Here are some minor updates on the FEL:

dinotrace – new update was pushed on testing repositories
fped – new update was pushed to stable repositories
geda-gaf (Fixes broken dependency libgmp.so.3 on rawhide and FTBFS with glib headers, Fixes RHBZ#604288, RHBZ#710281, L#704829 – Refresh on in-use tab causes crashes)
vhd2vl 2.4 – new update was pushed on testing repositories
Fritzing will soon be part of Fedora repositories
Toped will have a technology editor which will reduce days of porting foundry’s tech files.

Geoffrey L. Barrows - DIY Drones: Wide field 4D optical flow odometry using Arduino and Stonyman image sensor

Fri, 16 Dec 2011 16:39:09 +0000

I've been working on a new version of our ArduEye using one of our "Stonyman" image sensor chips and decided to see if I can grab four dimensions of optical flow (X shift, Y shift, curl, and divergence) from a wide field of view. I wirebonded a Stonyman chip to a 1" square breakout board, and attached it to an Arduino Mega256 using a simple connecting shield board. I then glued a simple flat printed pinhole onto the chip using (yay!) 5-minute model airplane epoxy. With a little black paint around the edges, the result is a simple low resolution very wide field of view camera that can operated using the Arduino.

I programmed the Arduino to grab five 8x8 pixel regions- region 0 is forward while the other four regions are about 50 degrees diagonally off forward as shown. In each region the Arduino computed X and Y optical flow and odometry (essentially an accumulation of optical flow over time).

To compute X and Y shift, the algorithm summed respectively the X and Y odometry measurements from the five pixel regions. These are the first two dimensions of optical flow that most people are familiar with. To compute curl and divergence, the algorithm added the appropriate X or Y odometries from the corresponding pixel regions. For curl this results in a measurement of how the sensor rotates around it's forward axis. For divergence this results in a measurement of motion parallel to the forward axis.

In the current configuration the system operates at about 5 to 6 Hz, though when the serial dump is on that slows to about 2 Hz. Most of the delay is in the acquisition and involves wasteful array lookups to select which pixels to read out. Using an external ADC (which the middle board supports) and better code there is room for probably an order of magnitude speed increase.

The video shows a few test runs where I exposed the sensor to three of the four fundamental motions. Y shift was implemented using an air track (like some of you used in physics class). Curl motion was implemented with the aid of a well-loved turntable. Divergence was implemented by hand by moving the sensor to and from clutter. The corresponding plots show the response of all four motions, with the "correct" one emphasized.

You can see that the four components are largely independent. There is some crosstalk- curl and divergence tend to be the biggest recipients of crosstalk since they are effectively a difference between signals (and getting an accurate number by subtracting two noisy numbers is not easy). Factors such as varying distances around the camera can cause uneven stimulation of the different pixel fields, resulting in phantom curl and div. There is also a little bit of drift. There is a lot of room for optimizing the system for sure.

One immediate improvement would be to use two of these Stonyman cameras back-to-back so that near omnidirectional sensing could be performed. This would give us more information to separate the different components (X,Y,curl,div) as well as allow us to separate out the other two axes of rotation from X and Y.

A setup similar to this formed the basis for our recent single sensor yaw and heave (height) stability sensor demonstration.

What could something like this be used for? You could put it on a ground vehicle and do some odometry with it, either looking down or even looking up, though for looking up the odometry measurements would depend on distance to other objects in the environment. You could also mount this on a quad looking down- X and Y would give your basic optical flow for sideways drift regulation. Curl give you yaw rotation (though you already have that with a gyro). Divergence is most interesting- it would tell you about change in height.

You could also implement something similar with five of Randy's optical flow sensors aimed to look in the same five directions. (You could probably dispense with sensor 0 to save weight/cost in this case.)

Sebastien Bourdeauducq, lekernel.net: TDC core test results

Fri, 16 Dec 2011 13:03:44 +0000

The test results for the FPGA time to digital converter (TDC) core are available from OHWR. Except from one problem which I believe is due to external signal integrity problems, the core worked well on the SPEC. From these tests, the 2-sigma precision is +/- 52 ps.

Liu Xiangfu, openmobilefree.net: Copyleft FPGA board: Icarus

Thu, 08 Dec 2011 19:44:46 +0000

We bought a copyleft FPGA Develop/Bitcoin Mining board: Icarus made by Ngzhang, the PCB, FPGA code, Mining software is all open. for more information please check bitcointalk.org.

I setup the Icarus with my server.here is the script file to keep it minng all the time. you can find more logs here.

Freetronics: New device: Hall Effect and Proximity Sensor Module

Thu, 08 Dec 2011 07:01:33 +0000

The Hall Effect and Proximity Sensor Module is a versatile and tiny device, great for sensing magnets or other physical objects nearby:

Applications include detecting shaft rotation: put a magnet on a rotating shaft and then use the Hall Effect Sensor to count / measure the frequency of rotation, giving you RPM. The module also includes a very handy "triggered" LED, so all you need to do to test it is apply power and watch the LED! Great for debugging your project while getting it sorted.

There's example code and a wiring diagram on the Hall Effect Magnetic and Proximity Sensor Module Quickstart Guide.

Freetronics: TronixStuff review of our modules

Thu, 08 Dec 2011 05:37:14 +0000

John Boxall of TronixStuff fame (one of the best sources of Arduino tutorials anywhere!) has just posted a quick review of a whole bunch of our new modules. Included in the review are even a couple of videos, including this one showing our RGB LED Module displaying different colours:

He also combined a couple of modules, like in this video where he used the Light Sensor Module to control the frequency of a tone being driven to the Sound & Buzzer Module:

Check out John's review here:

http://tronixstuff.wordpress.com/2011/12/06/review-freetronics-module-family/

Video Circuits: Warner Jepson

noreply@blogger.com (Chris) — Tue, 06 Dec 2011 17:19:05 +0000

Not sure how much Jepson was involved with the video or if he always had collaborators, never the less some beautiful images and sounds.

"Orange Wind" via shinkoyo

Ice Box Nice Box via gryflett

Music Jepson with Video from Stephen Beck via zackdagoba

With Bob Pacelli on video via clemgal007

Mirko Vogt, nanl.de: SwitchSmart!

Tue, 06 Dec 2011 09:55:08 +0000

The “radio controlled power sockets”-project finally got its very own name and project site:

SwitchSmart!

Several improvements happened since my last post about this project:

there’s finally an Android app now!
shared-memory is now used for sharing the states of devices between several instances
there’s now one more tested and working platform: the La Fonera router by Fon
and – as usual at the end of changelogs: several bugs and timing issues got fixed

Liu Xiangfu, openmobilefree.net: Naihanlis crates and milkymist one

Tue, 06 Dec 2011 04:21:31 +0000

4PM DEC 2 2011. Upon invitation from Terrence Curry, Associate Professor at Tsinghua University’s School of Architecture, Naihan Li gave a talk about her crates in front of about 50 students. this event is about the story of her and her mobile furniture crates. you can find more info about her work at google . but here is a small picture can give you a brief idea. she will using her Media Wall while the speech. this Meida Wall is most interesting things for us. since it have DMX-Light, DMX-Laser, Speakers, Big Screen, Projector. since I have no idea about architecture or design stuff, I will just put the entire event video record somewhere later. then people who have interesting can download this video. there about ~50 students in this event, total time is ~1 hour, Milkymist One is keep rendering about ~20 minutes at the Answer Section, students like it since they think it part of the arcwork I will just put some pictures:

Events Presentation
Professor_Curry_Form_follows_function_or_does_it.pdf
Naihanli_Crates_设计的故事.pdf

Events video
Naihanli_Tsinghua_Event_Crates_1
Naihanli_Tsinghua_Event_Crates_2
Naihanli_Tsinghua_Event_Crates_3
Naihanli_Tsinghua_Event_Crates_4

About Naihanli:
http://naihanli.com/
http://en.wikipedia.org/wiki/Naihan_Li
http://www.core77.com/blog/design_festivals/beijing_design_week_2011_crates_by_naihan_li_20686.asp

About Milkymist One:
http://en.qi-hardware.com/wiki/Milkymist_One
https://sharism.cc/shop/product_info.php?products_id=13

Geoffrey L. Barrows - DIY Drones: Make an optical flow sensor using an Arduino, CdS cells, and a shoebox!

Mon, 05 Dec 2011 23:25:12 +0000

This device is no match for an Randy's sensor, but it does (minimally) work. Think of this little project as a fun hack more than anything else. But with some tweaking and size reduction someone could probably implement an occasionally working altitude hold sensor for a fixed-wing RC aircraft.

This optical flow sensor uses CdS cells as light sensing elements. Recall that a CdS cell is basically a resistor whose value changes with illumination- more light results in less resistance. The fundamental sensing structure here is a pair of CdS cells connected in series to form a voltage divider. The middle node between the CdS cells forms the output. When both cells are equally illuminated, the output voltage is midway between Power and Ground (assuming the CdS cells are matched). If one cell is illuminated more than the other, the output voltage varies accordingly. An interesting quality of this CdS cell pair is that if you, say, double the amount of light striking both cells, the output changes very little.

Nine of these CdS cell pairs are laid out in a row, as shown in the video. Pay attention to the photo below to see how the CdS cells are placed and how they overlap within the array. The nine resulting outputs go to ports A0 through A8 (analog inputs 0 through 8) of an Arduino Mega. This project required a 'Mega because of the number of analog input signals.

For those of you with an image processing background, you can say that a CdS cell pair forms a simple analog edge detector, and that adjacent edge detectors are 120 degrees out of phase.

As light patterns travel across the CdS array, the nine analog signals will vary accordingly and can be interpreted by a basic one dimensional optical flow algorithm. For example, if a shadow moves left to right across the array, a pulse or step function will appear in sequence across ports A0 through A8 in sequence (or the other direction) which indicates visual motion.

To obtain an image, I just used a slit opening, which is a variation of a pinhole camera. This slit opening was oriented perpendicular to the CdS array, which preserves visual information parallel to the CdS array and smooths out information perpendicular to it. This helps make the array more sensitive to 1D visual motion in the desired direction. (For a rough metaphor, think of a bar code.)

I mounted all the electronics into a shoebox using masking tape. (For a more professional and durable version, use duct tape!) I also placed dark construction paper on the inside of the box to prevent light from bouncing around. I cut a slit opening in the box top as shown to be positioned over the CdS array.

The output can be read in two ways- The Arduino port D3 generates a PWM signal that, when connected to the RC network shown, can generate an analog output representing the optical flow (5V = max positive, 0V = max negative, 2.5V = zero). Alternatively you can read it out using the Arduino environment's Serial display.

The sensor is crude but does work. It needs a lot of light to function- it should work in a bright indoor environment but works better with natural outdoor lighting, say several hundred lux and up.

The Arduino sketch is attached here: CdS_OF_Sensor_r1.pde

Have fun!

Freetronics: New device: Microphone Sound Input Module

Mon, 05 Dec 2011 03:08:52 +0000

Detecting sound opens up a whole range of possibilities for your Arduino, so Marc designed our new Microphone Sound Input Module to provide two outputs: one providing the raw audio waveform, and one providing the sound pressure level (SPL).

The two outputs provide independent access to either the raw signal waveform (the MIC output) or the sound pressure level (the SPL output) to provide maximum flexibility in your projects. If you want to process the audio waveform directly you can use the MIC output, or if you just want to detect sound level (for example, to detect noise above a certain threshold) you can use the SPL output.

You'll notice that near the top right corner is an LED labeled "DETECT", which is linked to the SPL output and illuminates proportionally to detected sound pressure. Perfect for quick visual feedback that it's picking something up. To verify that the module is working you can just supply power and make a noise - you'll immediately see the response on the LED!

See how to hook it up in our Microphone Sound Input Module Quickstart Guide.

Chitlesh Goorah: [FEL]: archimedes 2.0.0 stable release

Sun, 04 Dec 2011 13:31:58 +0000

Archimedes, the 2D Quantum Monte Carlo simulator for semiconductor devices, has been updated on both Fedora and EPEL testing repositories.

Since last FEL release, archimedes entails the following changes:

The material parameters have been checked and modified
Benchmark tests were carried out to check the validity of the framework
Scattering phonons can be set to ON or OFF
Support for Full band approach was implemented
Parabolic, Kane and Full bank verified
Full band parameters supports for all materials
Initial implementation of FEM for Poisson
Quantum Effective Potential modified
Bohm Potential Model was implemented
Calibrated Bohm Potential Model was implemented
Density Gradient corrected and tested
Full effective potential model was implemented

Chitlesh Goorah: [FEL]: Bug fix release pcb-0.20110918-3

Sat, 03 Dec 2011 19:36:05 +0000

A bugfix release of PCB layout tool editor has been pushed to Fedora testing repositories to resolve the following:

Bug fix L#882712 Route styles are not properly loaded after nm conversion
Bug fix L#699307 Panning problem when mouse button is released on scrollbar (sf-2923335)
Bug fix L#891041 png export broken for tilted, square pads

Chitlesh Goorah: [FEL]: ngspice-23 stable release

Sat, 03 Dec 2011 19:35:00 +0000

ngspice-23 was released into Fedora and EPEL testing repositories with the following enhancements:

New devices: HiSIM2 and HiSIM_HV models from Hiroshima University have been added.
New features: transient noise simulation, a random voltage generator option trrandom and random telegraph noise added to independent voltage and current sources; command wrs2p to write a s-parameter file using Touchstone vers. 1 format.

Liu Xiangfu, openmobilefree.net: Prepare Milkymist One for Nanhailis event

Sat, 03 Dec 2011 11:09:01 +0000

Nanhanli a independent architect and designer for architectural and graphic design, she will give a speech at TQinghua university at DEC 2 2011, she will use her new Media Wall as the screen talk about her Crates story. there is a chance for Milkymist One that can connect to the artwork or part of artwork. since she bought a Milkymist One and we have a big update at NOV 30 2011, so we update her Milkymist One for her event.

she is live at 红 a great place at Caochangdi Beijing. oh when I saw this building the first thing come from my mind is change them to HEX. , will update Milkymist one is not hard, just boot it and click the ‘Webupdate’, on thing is the ‘Webupdate’ will not update the standby.fpg, which will not give you the AUTO-ON feature. so I have to use reflash_m1.sh –release for update the standby.fpg, after update just re-plug the power cable. the middle led will immediate on. no needs press middle button any more. here is a picture after new images boot.

for prepare the event I created 7 patches for that. here is two screenthos: at the end of the day we project the milkymist one performance to the wall just for fun

Freetronics: EtherTen / Siri hack by Marcus Schappi featured in the Sydney Morning Herald

Fri, 02 Dec 2011 02:25:18 +0000

Marcus Schappi (from Freetronics reseller Little Bird Electronics) recently demonstrated a neat little hack where he intercepted DNS requests from an Apple iPhone 4S to send Siri queries to a proxy server, allowing it to hand off the event to a Freetronics EtherTen and control house lighting. This morning it was picked up by journalist Ben Grubb and featured in the Sydney Morning Herald!

Check out the story on the SMH site:

Aussie hacks Siri to automate home

Great work Marcus!

Geoffrey L. Barrows - DIY Drones: RC micro helicopter hover (yaw and height) using millimeter thick vision camera

Fri, 02 Dec 2011 00:24:55 +0000

As part of Centeye's participation in the Harvard University Robobee project, we are trying to see just how small we can make a vision system that can control a small flying vehicle. For the Robobee project our weight budget will be on the order of 25 milligrams. The vision system for our previous helicopter hovering system weighed about 3 to 5 grams (two orders of magnitude more!) so we have a ways to go!

We recently showed that we can control the yaw and height (heave) of a helicopter using just a single sensor. This is an improvement over the eight-sensor version used previously. The above video gives an overview of the helicopter (a hacked eFlite Blade mCX2) and the vision system, along with two sample flights in my living room. Basically a human pilot (Travis Young in this video) is able to fly the helicopter around with standard control sticks (left stick = yaw and heave, right stick = swash plate servos) and, upon letting go of the sticks, the helicopter with the vision system holds yaw and heave. Note that there was no sensing in this helicopter other than vision- there was no IMU or gyro, and all sensing/image processing was performed on board the helicopter. (The laptop is for setup and diagnostics only.)

The picture below shows the vision sensor itself- the image sensor and the optics weigh about 0.2g total. Image processing was performed on another board with an Atmel AVR32 processor- that was overkill and an 8-bit device could have been used.

A bit more about optics: In 2009 we developed a technique for "printing" optics on a thin plastic sheet, using the same photoplot process used to make masks for, say, making printed circuit boards. We can print up thousands of optics on a standard letter size sheet of plastic for about $50. The simplest version is a simple pinhole, which can be cut out of the plastic and glued directly onto an image sensor chip- pretty much any clear adhesive should work.The picture below shows a close-up of a piece of printed optics next to an image sensor (the one below is a different sensor, the 125 milligram TinyTam we demonstrated last year).

The principle of the optics is quite understandable- a cross section is below. The plastic sheet has a higher index of refraction than air, thus a near hemisphere field of view of light may be focused onto a confined region of the image sensor chip. You won't grab megapixel images in this manner, but it works well for the hundreds of pixels needed for hovering systems like this.

We are actually working on a new ArduEye system, using our newer Stonyman vision chips, to allow others to hack together sensors using this type of optics. A number of variations are possible, including using slits to sense 1D motion or pinhole arrays to make a compound eye sensor. If you want more details on this optics technique, you can visit this post, or you can pull up US patent application 12/710,073 on Google Patents. (Note: We are planning to give a blanket license of the patent for use in open hardware systems.)

(Sponsor Credit: "This work was partially supported by the National Science Foundation (award # CCF-0926148). Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.")

Freetronics: New device: Addressable RGB LED Module

Thu, 01 Dec 2011 23:21:32 +0000

At first glance the RGB LED Module looks trivial: it's an LED on a PCB, right? Look closer though and you'll see that it's far more than that.

It uses a high-brightness RGB (Red/Green/Blue) LED, which means that you can generate all the colours of the rainbow. On the back of the board it includes a WS2801 constant-current multi-channel LED driver with built-in PWM (Pulse-Width Modulation) outputs, allowing you to set different brightness levels on each output independently and have them hold that illumination level without requiring any PWM outputs from your microcontroller.

Cooler still, the WS2801 can be daisy-chained so that you can serially address a whole row of RGB LED modules off just two digital I/O lines from your Arduino.

Check out the details including example source code to drive it from an Arduino in the RGB LED Quickstart Guide.

Freetronics: Impromptu in-store Arduino display at Jaycar Newcastle

Thu, 01 Dec 2011 03:26:34 +0000

This is one of those things that fall into the "pure awesome" category. We just received photos of an in-store display created by staff at Jaycar's Newcastle store, combining a Freetronics Eleven with a temperature sensor, an LCD module, a solderless breadboard, and a couple of other miscellaneous parts:

How cool is that? Actually, the display can give you the technically correct answer to that question:

It even offers words of inspiration to customers:

Whoever it was that set up the display: if our paths ever cross in the future, remind me that I owe you a $FAV_BEVERAGE.

Freetronics: New device: Sound and Buzzer Module

Thu, 01 Dec 2011 01:35:12 +0000

The new Sound and Buzzer Module is quite versatile, and can be used for either input or output.

Piezo elements have an obvious application as sound-generating devices, and by connecting the module to a PWM output on your Arduino you can generate tones. However, with the inclusion of a 1M resistor across the terminals (pre-fitted on the module for convenience) it can also be used as a knock sensor. Just connect the module between GND and an analog input and you can detect sharp bumps, taps, or knocks!

Examples are provided in the Sound and Buzzer Module Quickstart Guide.

Freetronics: New device: Humidity and Temperature Sensor

Tue, 29 Nov 2011 11:25:51 +0000

The new Freetronics Humidity and Temperature Sensor Module is very handy for environmental monitoring, combining both temperature and humidity readings in a single unit.

Readings update every two seconds, with +/-0.5C and 2-5% accuracy. Perfect for logging data in your house, office, or server room, or even for building your own thermostat to control a heating or cooling system.

Connecting the sensor takes just one data pin on your Arduino, and we've provided a handy tutorial to get you started: see our Humidity and Temperature Sensor Module Quickstart Guide for details.

Freetronics: New device: Shift Register / Expansion Module

Tue, 29 Nov 2011 10:59:44 +0000

Another new device that's just hit the shelves is the Shift Register / Expansion Module, which gives you a convenient way to drive additional output lines if you start running out of I/O on your Arduino.

Using just three I/O lines on your Arduino you can control eight outputs, and you can even daisy-chain multiple modules together to drive even more: with two modules you can drive 16 outputs with those same three I/O lines!

To see an example of how to hook it up and sample code to drive it, check out the Shift Register / Expansion Module Quickstart Guide.

Freetronics: New device: Logic Level Converter Module

Mon, 28 Nov 2011 23:52:25 +0000

Another brand new device is the Logic Level Converter Module. Many of the most interesting sensors and devices are only available in 3.3V or even lower voltage versions these days, which can be a problem if you want to connect them to a 5V microcontroller such as an Arduino. This module easily connects different logic voltage levels together for bi-directional communication on up to 4 channels, allowing you to use low-voltage sensors with a 5V microcontroller.

The module acts as a "bridge", linking high-voltage and low-voltage parts of your project together so they can happily talk to each other. See how it can be used in the Logic Level Converter Module Quickstart Guide. Best of all they're dirt-cheap at only $6.95, so it's worth having a spare around in your parts drawer just for those frustrating times when you have an Arduino in one hand and a 3.3V device such as a GPS module in the other, and want to convince them to be friends and play nicely together.

Freetronics: New device: Light Sensor Module

Mon, 28 Nov 2011 23:40:15 +0000

We've just rolled out a whole new range of tiny functional modules to make it really easy to expand your projects. First came the AM3X 3-Axis Accelerometer Module, and now the LIGHT Light Sensor Module has also landed. This module is amazingly small:

Well, it may not look small when it's blown up so large, but keep in mind that the connection headers are on 0.1" centers! The whole board is about the size of a fingernail. The TEMT6000 sensor is a very reliable and consistent device, unlike a typical light-dependent resistor (LDR) that can vary with temperature and between different units. The TEMT6000 comes pre-calibrated so if you put a bunch of them in the same lighting conditions, you'll get the same value coming out of all of them. Brilliant.

To see how easy it is to use with an Arduino, check out the Light Sensor Module Quickstart Guide.

LZX Industries: New York Video Synthesis Workshop & Showcase

Mon, 28 Nov 2011 17:02:49 +0000

LZX Industries will be in Brooklyn, New York this December to present a demonstration of the LZX Visionary modular video synthesizer. Following the demonstration will be a discussion on video art history and techniques, as well as performances and screenings of works by video artists using the system such as Tommy DOG (The Brain People) and Johnny Woods. Expect a casual atmosphere with plenty of time for open discussion and hands on exploration of the modular system — as well as the opportunity to discuss more advanced techniques for those of you using the systems already. Everyone is welcome!

Glasslands Gallery, 289 Kent Ave, Brooklyn NY 11211
December 18th, 1PM – 6PM
$15 Admission

Freetronics: Open 7400 Logic Competition prize pack winner

Mon, 28 Nov 2011 03:22:05 +0000

Freetronics founder Marc Alexander was one of the judges on the Open 7400 Logic Competition recently, and we also provided a prize pack to go out to one of the winners.

The recipient of our prize pack was Luc Small, for his "(Wheely) Bin Night Reminder" project. Nice one, Luc!

Luc blogged about his win, and we're very interested to see what things he comes up with using the EtherTen, LCD & Keypad Shield, and Terminal Shield he received in his prize pack.

Kristian Paul: GPS-SDR on the Milkymist (Update 2)

Sat, 26 Nov 2011 21:50:23 +0000

~/blog/Untitled.html Has been a while since the last update in January, starting because for now
this implementation will no run in the nanonote :-) Not because it cant be do it,
just because i get more close to Milkymist platform so i feel more confident with it
(libre knowledge is my power) :-)

After read/skim some books/links [1][2] about GNSS/GPS and check Namuru proyect (thanks to Fabrizio)
i decided to port this namuru core to milkymist soc [3], this in beta stage and the current
effort is around making and tunning the correlators to get a proper signal acquisition and tracking [4],
this is a software asisted task that will be acomplished by osgps, and thanks to Artyom from gnss-sdr [5] wich
ported this project to a simplified version [6], getting started will not be hard.

Still more code in osgps that could be ported to get a fix, but for now having and stable method to get
navigation data from the GPS satellites is the priority.

Thanks for reading !
And all qi-hardware/milkymist comunity for supporting me :-)

[1] http://en.qi-hardware.com/wiki/GPS_Free_Stack/Books
[2] http://en.qi-hardware.com/wiki/GPS_Free_Stack/Web_Links
[3] https://github.com/kristianpaul/milkymist/tree/gps-sdr-testing
[4] http://en.qi-hardware.com/wiki/GPS_Free_Stack/Notes_About_Namuru
[5] http://gnss-sdr.ru
[6] http://code.google.com/p/gnsssdr/source/browse/#svn/trunk/OSGPS_MOD

Village Telco: Guest Post: Adapting Mesh Potatoes for Emergency Work

Thu, 24 Nov 2011 15:43:03 +0000

This is a guest post from Keith Williamson who has been exploring the potential of Mesh Potatoes in disaster relief scenarios.

My interest started with the use of amateur radio for emergency services and disaster relief where I saw the potential benefit of having portable Mesh Potato (MP) systems to augment emergency services team communications. The more I thought about it, it occurred to me that there are many other usage scenarios for such portable telephony networks. Some of those are amateur radio field-day operations, jeep jamborees, motorcycle touring groups… essentially any large groups of people who temporarily camp out together in remote locations. This would also be of interest to what are called “preppers” here in the U.S..people who believe in being prepared for any sort of disaster (whether natural, economic, political, etc). With the advent of the SECN approach, it was apparent that any of the WiFi-enabled smartphones (which are becoming quite ubiquitous) could be quickly configured to be able to call into and take calls from such a network of MPs. The advantage of this approach is that such a network could be built with as little as a single portable MP. Without the inclusion of smartphones, netbooks, or WiFi SIP phones, the Mesh Potato isn’t very useful unless everyone in a group has one.

In amateur radio, many of us put together “go boxes” which are composed of portable transceivers, battery power systems, portable quick-setup antennas, etc. So I started looking at how the MPs could be packaged as “go boxes” and how other people who have a smartphone but don’t have such a “go box”, could participate in the network. The “administrator” for the MP (or network of MPs) could secure the network but provide the WiFi security credentials/passwords to any person with a smartphone, etc they deem as a valid member of the group. Such a usage scenario as described above yields useability requirements that have been somewhat implicit in my emails over the past weeks (months?). A core requirement is at least one MP with DHCP services for the non-MP devices. Generally, an Internet uplink won’t be available but I’d like to allow for a somewhat painless addtition of one (e.g satellite uplink provided by emergency services team). I’ve tried cellular routers but in the US, at least, the cellular providers don’t forward SIP requests (party poopers) so I really don’t see many remote area opportunities for Internet access. That said, I don’t see Internet connectivity as a core requirement anyway. The network’s main function is to provide local telephony with a secondary, optional function of providing access to a portable information server (something else I’m working on).

For the “go box”, I’ve built two prototypes of what I’ll call the Mesh Potato “take-out” (not really). It’s based on a waterproof Pelican 1200 case, includes a quick-release bracket to hold the MP, a rechargeable Li-Ion or Li-Poly battery, a telephone handset, and a junction box to tie everything together and provide an on/off switch and convenient access to the charging ports, telephone jack, and a USB convenience port for charging a smartphone. Between the first proto and second proto, I changed the battery from a Lenmar external laptop battery to a Tekkeon MP3450i instrument battery. I also made a bunch of changes to enhance manufacturability and lower component costs (with the exception of the battery). The third proto I’m about to build (when I’m not busy with my pesky day job) will incorporate a few more tweaks to manufacturability. The unit can be operated with the MP docked in it’s bracket for short-range environment or unlatched and extended into a tree or antenna tower for longer range. The battery can be charged using a solar panel with as little as 10W (using a “solar booster adaper”) but really needs a 20 to 30W panel to be charged effectively and in a timely manner. It can also be charged from a car battery via alligator clips or cigarette lighter jack. It can also be charged from an a AC power brick connected to a generator. I need to do quite a bit of study on the solar charging aspects and also need to look into whether I need to incorporate a low-voltage cutoff to prevent over discharge of the battery.

Keith is a Systems Engineer in Arizona

Freetronics: Using Handbag with the USBDroid and Android

Fri, 18 Nov 2011 02:41:22 +0000

Simon Monk has posted a great little introductory guide to using our USBDroid with Philip Lindsay's "Handbag" software development toolkit to create your own Android accessories with just a few lines of code. In this video he shows an interface running on an Android mobile phone communicating with a USBDroid to drive servos when buttons are pressed on the touchscreen:

Brilliant! Check out his guide here:

Handbag - Android and Arduino without the Java

FreakLabs: chibiArduino v0.54 Release - Fixed Previous Broken Release

Wed, 16 Nov 2011 22:32:18 +0000

I just released chibiArduino v0.54 which fixed the broken release known as v0.52. I had thought I tested v0.52 before releasing it into the wild, however an experimental configuration header file got into the release and was wreaking major havoc with the stack. I recommend anyone that downloaded v0.52 to not use it and switch over to v0.54 immediately. It is tested and working with Arduino v021 and v022 IDEs. If there are any questions, please feel free to email...

Video Circuits: Video Transmitter Experiments

noreply@blogger.com (Chris) — Tue, 15 Nov 2011 11:08:41 +0000

So I found this old transistor set on the way home from a friends house a while ago and I had already got a few transmitters in my piles of junk, so I thought I would test them out and try some feedback. To my amazement the transmitter would invert the image on some settings. I also played around with my Audio to video circuit in to the transmitter at one point and made this "cool" montage poster

Video Circuits: Johnny Woods and Dpony VHS Movie/Album

noreply@blogger.com (Chris) — Tue, 15 Nov 2011 01:41:18 +0000

Dpony Movie is available on VHS tape in a limited edition of 100 copies.
Orders are available now for the price of $19.99 (including shipping and handling, USA only)

http://www.dponymovie.com/

Video Circuits: zenit

noreply@blogger.com (Chris) — Mon, 14 Nov 2011 09:29:44 +0000

Not a video synth related post however I helped out with some of the sound on this for my good friend Max. It's for an energy drink animation competition. Him and Dave really knocked it out of the park on this one I am in awe !!! also for those who are interested all of the sounds were generated with analogue synthesisers they felt this went well with the visual style inspired by Russian matchbook Labels from this excellent post on sci-fi-o-rama.

also I find it quite amusing to appropriate soviet imagery for a very capitalistic reason but then I think back to animators of the soviet block subtly working in the stories they wanted to tell regardless of the state line and maybe this is the capitalist version ?

http://www.slowgolde.com/
http://www.maxtaylordesign.com/

Altus Metrum: bdale's rocket blog: RF Immunity

Mon, 14 Nov 2011 08:39:45 +0000

We've had sporadic Altus Metrum customer reports about RF susceptibility issues with their TeleMetrum installations. In almost every case, these problems have been completely resolved by either making sure the system battery has sufficient charge before launch, or through the application of standard engineering techniques such as twisting wire pairs to reduce differential coupling. However, even when every technique we could think of had been applied, once in a while someone still had issues.

Around the time of LDRS this year, the incidence of such reports seemed to increase. One customer, in particular, had an installation in which he virtually always saw continuous resets of the board once his 54mm airframe was put on a launch rail, and several customers reported seeing board resets during ejection charge firing. Keith and I saw a board reset during main charge firing happen in person at NCR's Oktoberfest, and with a couple days available to work together after that launch, we decided it was time to figure out what was really going on.

Here's what we've learned.

In bench testing, it quickly became clear that the problem was the 3.3 volt power supply rail getting pulled down far enough to reset the CPU. This most frequently happened during ejection charge firing, when the input of the LDO regulator is pulled down by the near-short presented by the e-match when a pyro FET is turned on. To keep the 3.3 volt rail voltage up during firing, we include a 100uF bulk capacitor on the regulator's output. In all of our prior bench testing, we never saw the 3.3 volt rail droop significantly. Clearly something had changed... or maybe several things had changed?

The first thing I wondered about was whether the new Kalman filtering code, which requires more compute cycles from the processor, might be consuming enough more power to pull the rail down faster during charge firing. After poking around at it, though, we have no data to suggest the new code makes a measurable difference in power consumption.

The next thing we pondered was that at least some of the e-matches we and others are using in the hobby now come from the fireworks industry, where it is apparently considered a feature for the match to retain continuity after firing. This means the input of the LDO gets held down for longer than with the e-matches we used to use and Quest Q2G2 igniters that open when fired. But that still didn't make sense as the root cause, as we chose the FET firing time such that even with a dead short across the igniter terminals, the 3.3 volt rail wouldn't be pulled down far enough to cause trouble during firing.

One of the big changes between v1.0 and v1.1 on TeleMetrum was that the newer boards incorporate a better reset circuit. This helps ensure the GPS chip always comes up running at power on, which was a problem at temperature extremes with older boards. However, a side-effect of this change is that a v1.1 board will reset any time the 3.3 volt rail drops below 3.15 volts, whereas older boards didn't trip until a much lower voltage. So the recent increase in reports might just be related to more v1.1 boards being placed in service?

While experimenting on the bench, we observed that injecting RF energy into the input of the LDO regulator had the effect of pulling down the output voltage, presumably because the internal reference source accumulates charge and is fooled into thinking the output is too high. Since our designs all have the power switch contacts ahead of the LDO, the wires going out to the switch and back are effectively an antenna... as are, to a lesser extent, the wires going to the e-matches. There is some variability from part to part in just how badly the LDO reacts. But by attaching a tuned length of wire as an antenna to the LDO input and playing around, we were finally able to reproduce the problem reliably on a test board at my bench!

On further analysis, we realized that the output of the USB battery charger chip and the input of the LDO both expect a 1uF bypass cap to ground. At some point, those looked redundant and we eliminated one of the two. Unfortunately, we weren't internalizing the fact that the switch leads were between the two caps, and the one we left was on the output of the charger and not at the input of the LDO. Placing a suitable bypass cap right at the input of the LDO turns out to have a truly dramatic effect on RF immunity!

Once we realized that RF getting into the LDO input was the problem, Keith pointed out that we used to see "noise" in the accelerometer data on earlier boards that was caused by the 3.3 volt rail moving slightly during radio transmit, which we fixed with a hardware change on v1.1. We are now convinced that this was at least partly related to RF coupling to the LDO input, not just the change in power consumption on the LDO output. We didn't realize what was going on in earlier testing because we often didn't have ematches wired up, so RF coupling was minimal. But going back to flights logged with v1.0 boards that included deployment, and studying the magnitude of the "steps" in acceleration data observed when the transmitter was on, Keith was able to compute the amount the 3.3 volt rail must have sagged if the real acceleration wasn't changing... which in some cases was as much as 180mV! We think this proves that RFI could cause the LDO to drop its output voltage below the reset controller set point on v1.1 boards.

Based on these observations, I'm making two hardware changes for the next version of TeleMetrum (version 1.2), and Keith is also making a software change. We have tested all of these changes on real boards both on the bench and in test flights, and the net effect is a major improvement in the RF immunity of TeleMetrum.

The first hardware change is moving to a slightly lower trip voltage on the reset controller. Instead of 3.15, the new part trips at 3.00 volts nominal. This gives us more "headroom" to tolerate 3.3 volt rail droop during charge firing, and will allow the board to operate longer on a given battery charge. This change is not relevant for v1.0 and prior.

The second hardware change is adding an appropriate bypass capacitor right at the LDO input. This requires a PCB update, but it's possible for me to update existing production boards by adding an 0402 cap right across the appropriate pins on the regulator chip.

The software change prevents our altimeters from turning on the radio transmitter while an ejection charge is firing. Since the RF transmitter draws substantial additional power, this should help keep the 3.3 volt rail from drooping. This may not really matter, but it feels like the right thing to do. This change will be part of our next stable firmware release.

We think most TeleMetrum customers need not worry about these updates. But if you have seen odd resets on the rail or during ejection charge firing in flight with a TeleMetrum v1.1, feel free to contact me about updating your existing board to include these improvements.

Tuxbrain: BCNDEVCON... Open Source, Al ataqueeeerrrrr !!!

Sun, 13 Nov 2011 18:25:14 +0000

De manera excepcional y tirando por los suelos nuestra estrategia de "No avisar de lo que vamos a hacer para parecer 'misteriooosos' y vender menos" (que por lo visto no funciona ;) ) , aquí estamos para informaros que el próximo fin de semana tendrá lugar en Barcelona un nuevo evento para Developers, la BCNDEVCON.

FreakLabs: 'Hacker' Group Safecast Crowdsources Radiation Data in Japan

Thu, 10 Nov 2011 19:48:05 +0000

FreakLabs is a proud member of Safecast and Tokyo Hackerspace and is an ardent believer in open, transparent data via open source sensor networks...and the safecast devices are using the Freakduino. yay! :) Link (http://www.pbs.org/newshour/rundown/2011/11/online-hacker-group-crowdsources-radiation-data-for-japanese-public.html) Link (http://www.pbs.org/newshour/bb/science/july-dec11/japanradiation_11-10.html)

Video Circuits: Television Magazine April 1976

noreply@blogger.com (Chris) — Tue, 08 Nov 2011 09:34:12 +0000

from this auction

Freetronics: The Project Showcase competition: tell us about your project to win a prize!

Wed, 02 Nov 2011 23:44:24 +0000

The recently launched Freetronics Forum has a category specifically to give people a chance to showcase their projects, either complete or in progress. Marc and I love seeing the things people build so we're partly doing this for selfish reasons: we ship a lot of devices out but don't often see the end result of the projects they go into, so this is a way for us to get a warm fuzzy feeling knowing they're being put to good use.

So for the month of November we're inviting anyone who has built an Arduino-based project to do a quick post in the Project Showcase section of the forum, and at the end of the month we'll pick one as the winner of a Freetronics Inventors Kit containing an Eleven, some Prototyping Shields, a Terminal Shield, an LCD & Keypad Shield, and a selection from our range of new add-on modules that are about to be released.

Judging will be by Marc and myself and is completely arbitrary - it doesn't need to be the most complex project, or the cleverest, or the most well presented. It'll just be the one that we like the best! So if you've built something you're proud of, don't be shy. Let us know about it.

And no, we can't be bribed with beer. Neither of us like it that much. Chocolate, on the other hand...

So get to it!

Project Showcase

Freetronics: The Freetronics forum goes live

Wed, 02 Nov 2011 09:19:37 +0000

Eagle-eyed readers may have noticed a new menu item appear near the top right of our site this morning when the Freetronics forum went live. Those with particularly sharp eyes may even notice that the first posts appeared in the forum yesterday - before we'd even linked to it! Last night while Marc and I were at the Melbourne Hackerspace we gave a couple of people a sneak peek, and once word got out the forum came to life before our eyes.

Our plan is for the forum to fulfill three main purposes.

First, we want it to be a convenient place to get support for Freetronics devices, both from Freetronics and also from the many talented members of the Arduino / Open Hardware community. We often find that we answer the same questions over and over again via email - which of course we don't mind doing, but unfortunately it means the answers we give to one person don't benefit anyone else. Covering support questions in a more public way will help all our customers by providing ready-made answers right where Google can find them.

Second, we hope that the forum is a place where Makers everywhere (but particularly Aussies and our cousins from over the Tasman Sea) can chat about whatever they happen to be working on. We've put in categories for 3D printing, random chit-chat, and a project showcase, but that's just to get the ball rolling. If there are other areas of interest that you think deserve their own dedicated category just let us know.

Finally, it's an opportunity for us to get to know you, and vice versa. We've met so many cool people through the Melbourne Hackerspace and events such as linux.conf.au and OSDC, and we love to hear about what people are working on. Freetronics isn't just a faceless company providing products for the market to consume: we're hackers / Makers ourselves, and we started doing this because it's what we love. Having an opportunity to meet people and be inspired by what their imaginations give birth to is what makes this all worthwhile.

So, come along to the Freetronics forum and say hi!

FreakLabs: Light Sequencing and Decoding DMX with an Arduino

Mon, 31 Oct 2011 05:13:03 +0000

It's been a while since I posted anything and that deserves another post just to talk about everything that happened in the last 8 months since the March earthquake and tsunami here in Japan. I'm a little bit tired of heavy topics and serious projects so I thought I'd put together a little something that's kind of fun and also timely. Now that we're moving into the holiday season, we're about to start seeing the hard core Christmas people setting...

Freetronics: Welcome to our new Californian reseller, EpicTinker

Sun, 30 Oct 2011 22:04:32 +0000

Last week another reseller joined Freetronics, carrying local stock in California for the benefit of our US customers who need their fix of Arduino-compatible goodness without waiting for international shipping.

I'm sure that being able to order in US$ is much easier for our American customers, too, so make sure you check out EpicTinker. They even offer live chat and a US-based customer service phone number.

Moxie Processor: Using the Altera USB-Blaster on Fedora

Fri, 28 Oct 2011 21:14:16 +0000

Altera’s Quartus tools include some special software to download bitstreams to their devices over USB (a DE-2 eval board, in my case). They require some tricky work to set up properly on Fedora – my dev host of choice. But you’re in luck! I’ve packaged up an RPM that takes care of this extra work for you. It creates a udev rule to set up the USB-Blaster properly when you plug in your USB JTAG connection. It also provides a service wrapper for Altera’s jtagd daemon and moves some of Altera’s data files around so things just work. The sources are in moxiedev, but I’ve posted the binary and source RPMs here for convenience: http://moxielogic.org/tools/. Be sure to read the docs in /usr/share/doc/moxie-quartus-altera-1 once installed. It assumes that you’ve already installed Quartus II on your box (they don’t package in RPM format, unfortunately).

I’m told that the open source alternative UrJTAG may work for this device as well, but I haven’t had a chance to look into it. Any experience worth sharing out there?

Freetronics: Combining the LCD & Keypad Shield and the USBDroid

Fri, 21 Oct 2011 11:34:49 +0000

There are only a finite number of I/O pins available on Arduino boards, and sometimes the pins used on a shield conflict with other shields or even the Arduino board itself. In the case of the USBDroid, digital pins D9 through D13 are used for the onboard USB-host functionality that allows it to operate as a peripheral for an Android device such as a tablet or phone. However, the LCD & Keypad Shield also wants to use D9 so if you plug them together you need to reassign one of the pins to avoid a conflict.

It's really not hard once you know what needs to be done, and we've explained the options in a new tutorial:

Combining the LCD & Keypad Shield and the USBDroid

Freetronics: Bruce Perens to keynote LCA2012

Wed, 19 Oct 2011 23:48:00 +0000

Just announced this morning was the news that Bruce Perens, author of the Open Source Definition, will be a keynote speaker at linux.conf.au in January 2012. Bruce has been one of the driving forces behind the uptake of Open Source software in major corporations over the last decade, and his focus in this keynote will be Open Hardware!

From the announcement on the LCA site:

"Genetic engineering at home? Teaching science on a low budget? Fully open mobile and wireless devices? The design and manufacture of development tools? Is it possible?

Yes.

Join open source luminary Bruce Perens as he explores the Second Revolution of Open Source - Open Hardware.

Open Hardware is a movement dedicated to creating physical objects under the same terms and principles as Open Source Software. That is, their design and manufacture yields freedoms such as the ability to run the hardware for any purpose, study it, change it and share it with others."

LCA2012 will have a big Open Hardware focus, starting with the Arduino Miniconf (organised by Andy Gelme and myself) on the very first day. There are also a number of Open Hardware talks in the main conference, and having Bruce deliver a keynote on the subject just goes to show that it's arrived in a big way. So if you can make it along to LCA, make sure you register soon to take advantage of the Early Bird discount:

http://www.linux.conf.au/

Village Telco: Mesh Potatoes now FCC and CE Approved

Tue, 18 Oct 2011 12:35:34 +0000

The process of developing Village Telco and in particular the Mesh Potato has been a huge learning curve and indeed this is what makes it so worthwhile (dare I say fun) is the variety of skills and knowledge that one has to acquire to become a small scale manufacturer. However, the very nature of learning implies sometimes making mistakes and the occasionally painful experience of acquiring knowledge after you needed it as opposed to before.

One of the early mistakes we made with the Mesh Potato was not placing sufficient emphasis early on, on getting type approval for the Mesh Potato and indeed focusing on both European and U.S. type approval. What is type approval you ask? Type approval is the magic glue that makes unlicensed spectrum work. Many people take the term unlicensed to mean unregulated but nothing could be further from the the truth. Unlicensed spectrum succeeds because the devices that are permitted to use unlicensed spectrum are carefully regulated to ensure that they conform to strict standards in terms of power output and many other technical specifications that ensure that unlicensed devices “play nicely” with each other.

I am happy to say that this issued has finally been addressed in full and Mesh Potatoes now enjoy full compliance with both the standards of the Federal Communications Commission (FCC) of the United States and the European Union’s CE standard. These are the two most common international standards for compliance and should ensure that the Mesh Potato can conform to almost any regulatory regime.

If you would like to get copies of the certification in order to apply for local type approval in your country, please get in contact with us via this website.

Freetronics: First look: EtherMega production samples

Tue, 18 Oct 2011 11:15:33 +0000

It's taken longer than we would have liked, but the EtherMega has finally made the leap from bits to atoms!

It's got "the lot": everything we could cram into the most versatile board possible. It has the Mega 2560 microcontroller with lots of code space, ram and I/O; on board Ethernet; micro SD card slot; USB; and a switchmode power supply.

Some things of note:

PCB Colour. The picture above shows a design-validation sample so the PCB colours aren't correct: the production units will be in the usual Freetronics colours with yellow markings.

Power supply. The reason for the big delay in getting to this point has been swapping out the linear reg for a switchmode supply. You'd think it would be simple, but no, it turned out to have all sorts of side-effects! The supply we've used is rated up to 28V input, which means you can connect it to any handy power supply in the 7-28Vdc range and it'll just work without causing overheating problems. Current model boards with a linear regulator and an Ethernet shield run a tight-rope between getting enough power to run the Ethernet chip (which requires a good, solid 5V) and overheating the reg. Because I tend to mount Arduinos in odd places (inside walls, etc) it's important to me to have a board that runs cold, so I was determined to go with the switchmode supply even though it caused delays.

Power source selection. Near the upper left of the board you'll see a 3-way male header with a jumper fitted. That's to select the power source between USB and DC IN. Yes, we dropped the power auto-select for this one, in favour of a reliable high current power selection jumper. One of the big complications with the switchmode supply is that the chip can't handle a back-voltage being applied to its output, so with the traditional supply auto-switching circuit the chip gets fried the moment you plug in USB power. Oops. In the end a simple jumper was the most robust solution. We looked at switches to use instead, and found that tiny switches able to fit on the board just aren't rated to the 300mA+ that would be required. In fact most of the tiny surface-mount switches you see are only rated to about 200-300mA maximum! So, a jumper it is.

Soooo close. The first batch of production units will begin any day now.

Kristian Paul: First atempt to listen weather satellites

Mon, 17 Oct 2011 21:50:23 +0000

~/blog/log33.html Today i tried to listen a NOAA-19 weather satellite, i got a few seconds for
what sounds like its telemetry [1].

I used a uv-200 transceiver and a home made yagi-like antenna wich seems to work
if i inverted it (?) so, as no proper design was tought for it, i bet i
can be improved as soon i read more about this topic.

[1] http://kristianpaul.org/~paul/tmp/noaa19.wav

Freetronics: "State of Electronics" documentary preview

Sun, 16 Oct 2011 10:37:41 +0000

Director / cinematographer Karl von Moller has been working on a little pet project for a while: a documentary on the evolution of the electronics industry in Australia. It's titled "State of Electronics", and he's spent the last 12 months travelling around Australia interviewing some of the most influential people in the industry. A couple of weeks ago he mentioned that he now has 120 hours of footage! The big job now is trimming it down to just a couple of hours.

To give a bit of insight into the project, Karl has released a sneak peek called "Roll Call". It's not part of the actual doco, more of a "behind the scenes" extra feature to highlight some of the people interviewed so far. It has some amazing names on there, and I even managed to sneak in among all the big wigs: you'll see me briefly in the video below, although Karl decided to give me a promotion and call me the Freetronics CEO! Marc and I don't have titles yet.

In my section of the video you'll see me working at my kitchen table assembling something under the microscope. I can't really tell from the video, but I think it was a ProtoShield or maybe an early-model 433MHz Receiver Shield. No, we don't assemble stuff by hand that way anymore, all our products are put together by high-speed pick-and-place machines, but we still do some prototyping and personal projects by hand. I assembled the first few hundred ProtoShields and Receiver Shields in that oven over the space of a couple of months, but now they come off the production line by the thousand within a matter of hours.

So, to whet your appetite for the full doco:

Roll Call - State of Electronics from karl von moller on Vimeo.

Freetronics: "State of Electronics" documentary preview

Sun, 16 Oct 2011 10:37:41 +0000

So, to whet your appetite for the full doco:

Roll Call - State of Electronics from karl von moller on Vimeo.

Mirko Vogt, nanl.de: PostgreSQL – altering table name does not update references to its primary key and sequence automatically

Thu, 13 Oct 2011 10:27:42 +0000

During a setup of multiple PostgreSQL instances, replicating content via the replication framework Slony-I, I had to manually create the very same SQL schema to every Postgres node – as Slony just replicates the payload data and not the actual SQL schemas.

I was creating tables like this on every node:

CREATE TABLE x (
id SERIAL PRIMARY KEY,
content VARCHAR(255) DEFAULT NULL
);

but decided after half of having those nodes I already configured to rename the table from ‘x‘ to ‘y‘ using the ‘ALTER TABLE‘ command

ALTER TABLE x RENAME TO y;

and continued creating the schemas on the remaining nodes with the following command:

CREATE TABLE y (
id SERIAL PRIMARY KEY,
content VARCHAR(255) DEFAULT NULL
);

After finally having provided the schema to all nodes I started the replication daemons and got thrown errors from half of the nodes that replication doesn’t work properly since the schema doesn’t match the one on the master replication server:

CESTERROR remoteWorkerThread_1: “select “_db”.setAddTable_int(1, 3, ‘”public”.”y”‘, ‘x_pkey’, ‘Table public.y with primary key’); ” PGRES_FATAL_ERROR ERROR: Slony-I: setAddTable_int(): table “public”.”y” has no index x_pkey

All of the non-working nodes were those, I first created the table x on and later renamed it to y, instead of just directly creating table y like I did on the others.

Looking at the global table definitions – including the automatically co-created sequence – you can see that the table did get renamed, but the sequence didn’t:

Table y directly created:

postgres=# \d
List of relations
Schema |      Name      |   Type   | Owner
——–+—————-+———-+———-
public | y              | table    | postgres
public | y_id_seq       | sequence | postgres
(4 rows)

Table x created and altered to be named y:

postgres=# \d
List of relations
Schema |      Name      |   Type   | Owner
——–+—————-+———-+———-
public | y              | table    | postgres
public | x_id_seq       | sequence | postgres
(4 rows)

That normally doesn’t cause any trouble, since the reference of table y (formerly x) to the sequence x_id_seq is still valid. However since replication requires the very exact same schema on every node this actually is causing trouble. However that’s not the error mentioned in the error message above, which is referring to the primary key.

Diff’ing the actual schemas shows up more differences:

                                  Table “public.y”
Column |          Type          |                   Modifiers
———+————————+————————————————
- id      | integer                | not null default nextval(‘x_id_seq‘::regclass)
+ id      | integer                | not null default nextval(‘y_id_seq‘::regclass)
content | character varying(255) | default NULL::character varying
Indexes:
-    “x_pkey” PRIMARY KEY, btree (id)
+    “y_pkey” PRIMARY KEY, btree (id)

The reference to the sequence and and name of the reference to the value of the primary key were NOT updated by altering the table name to match again. This separation of table-name and references might be a feature, however I find it hard to imagine a use-case where it makes sense using the sequence and/or primary key of another table. UPDATE: I just got told that it indeed might make sense sharing one sequence among several tables.

Also sequence and primary key were created inside / co-created by the ‘CREATE TABLE‘ statement, so at least I’d find it more consistent if both would be always reference by this table, by means of the table they got originally created with.

Looking for information, hints or documentation about this behaviour wasn’t fruitful as well.

So personally I’d really like to really see those reference updated – by changing the tables name - automatically. I’d like to see at least a NOTICE that primary key and sequence are still haveing the name of / are referring to it’s old values and need to be updated / re-created to match again.

Conclusion: Make sure – when altering table names in Postgres – references to primary key and sequence are getting updated as well – manually! Primary key and sequence are NOT tied together with the table they got created with!

Moxie Processor: Fake RAM, load/store and push

Wed, 12 Oct 2011 03:00:59 +0000

Progress report time….

I need RAM in order to implement/test most instructions. To that end, I’ve implemented a fake data cache that is always accessed within a single cycle during the WRITE pipeline stage. Eventually this will have to be replaced with a real data cache that reads/writes to real memory over the wishbone bus while the processor pipeline stalls.

The push instruction was easy enough to implement. It’s the first one that writes to both memory and a register (to update the stack pointer). This meant reworking the interface between the EXECUTE and WRITE stages. Pop is a little more tricky because we need to update two registers: the stack pointer and the register we’re loading memory into. I’m going to work this out tomorrow night, but I can see now how making it work in a single cycle will require a little more logic than splitting it up into two cycles. It will be interesting to experiment with changes like that once everything is working.

Also, I reorganized the HDL source to cleanly separate the moxie core from the muskoka SoC and related firmwares and cores. As usual, everything is in github.

GNSS-SDR: Source code for acquisition and tracking algorithms of GLONASS L3 signals

Sun, 09 Oct 2011 18:05:50 +0000

Acquisition and tracking source code is available for download now. It's a reworked version of GLONASS L1 software receiver for scilab.Details about new GLONASS L3 signals can be found here. The main differences of the new signals are:
1) Ranging code - trancated Kasami sequence (in L1 and L2 bands - М-sequence);
2) Ranging code bit rate: 10.23 MHz (in L1 and L2 bands - 0,511 MHz);
3) Ranging coded is repeated every 1 ms as it was previously, but ranging code is additionaly modulated with 10-digits Hamming code ("0000110101"). Each digit of Hamming code lasts for 1 ms;
4) New signals are CDMA (in L1 and L2 bands FDMA is used);
5) Digital data is coded with convolutional coder;
6) Superframes, frames and strings length is changed.

Acquisition and tracking algorithms are made for now. The next step is to make viterbi decoder.

File with the new signal record from L3 band can be downloaded.

Peter Zotov, whitequark: My first factory-made PCBs

Fri, 07 Oct 2011 17:31:00 +0000

Today, my first batch of PCBs made on a real factory has arrived.

I’ll describe the purpose, functionality and process of making the boards after components will arrive; that will probably happen in roughly two weeks.

The sources are released under WTFPL: tft-lvds.tbz2.

The Eagle library for National DS90C363 chip and Hirose DF20G-40DP connector is released to the public domain.

27 Jan 2012 update: the boards have arrived and I’ve assembled them, but they have some nasty crosstalk bugs and are unfortunately unusable. DO NOT USE THIS DESIGN. I’ll try fixing them once I’ll get access to a >100MHz scope.

The footprints in library are verified and correct, through.

Peter Zotov, whitequark: strace and V4L2

Tue, 04 Oct 2011 23:50:00 +0000

Let’s suppose you have a webcam which works with Skype, but does not with your V4L2 code. You start Skype under strace… and suddenly discover that it does not know any of the V4L2 ioctl’s and shows them like this:

ioctl(117, VIDIOC_S_PARM or VIDIOC_S_PARM_OLD, 0xb1025024) = 0

That’s not very useful. If only you could get something like this…

ioctl(117, VIDIOC_S_PARM or VIDIOC_S_PARM_OLD, {type=V4L2_BUF_TYPE_VIDEO_CAPTURE, capability=V4L2_CAP_TIMEPERFRAME, capturemode=0, timeperframe={numerator=1, denominator=30}, extendedmode=0, readbuffers=0}) = 0

Sure you can. Just grab the patch against strace 4.6 source, apply it, compile (don’t forget autoreconf -i) and rejoice.

Dan Reetz: DOES IT TURN PAGES?

Thu, 29 Sep 2011 16:49:06 +0000

One of the best things about my community is that it is just chock full of awesome people.

One of the bad things about being the “DIY BOOK SCANNER guy” is that people always ask “DOES IT TURN PAGES?”.

Well, my friends, it turns pages.

jck57/Monson’s Servo Auto Scanner.

DIY Page Turner from Berlin Hackerspace C-Base:

dtic was among the page-turning pioneers of our forum:
Revision 1:

Revision 2:

jck57/Monson is actually building a full-auto scanner, check out his other impressive engineering:

Altus Metrum: bdale's rocket blog: AltOS 1.0.2 Released

Thu, 29 Sep 2011 16:29:12 +0000

Keith and I released version 1.0.2 of AltOS, the open source firmware and software system associated with our Altus Metrum hobby rocket avionics systems.

This release includes a fix for the defect in version 1.0.1 that prevented rebooting an altimeter from idle to pad mode over the radio link. This affects both TeleMetrum and TeleMini boards, and re-flashing the altimeter firmware is required to pick up this fix.

We also restored the pre-1.0 mode selection behavior for TeleMetrum at power on. This is also an altimeter firmware change, but does not affect TeleMini.

Qi Hardware: News Release: VJing Made So Simple Anyone Can Do It

Wed, 28 Sep 2011 15:00:00 +0000

September 28, 2011 15:00 PM Central European Time
BERLIN, Germany

The Qi Hardware project is proud to announce the Milkymist One video synthesizer.

A total power consumption of only 5 watts and latency of only 60 milliseconds are the highlights of the new high-performance video synthesizer. Without additional computer, Milkymist One takes line-in audio to create real-time music visualizations. Ideal for musicians and DJs, restaurant and bar owners, people organizing parties or interested in visual art. The included camera feeds live video into the synthesis.

Milkymist One is the second product launched by Qi Hardware after the Ben NanoNote in March 2010. While the NanoNote was built around a MIPS-architecture SoC, Milkymist One takes copyleft freedoms one step further by being the first free computing architecture built around the GPL licensed 32-bit Milkymist SoC.

Visual artists benefit by being able to program their patches, including connectivity and control of DMX lights, lasers and MIDI instruments, all directly and in real-time from the Milkymist One synthesizer. Network connectivity allows the inclusion of live Twitter feeds. Free software programmers benefit by having the first fully programmable graphics accelerator at their disposal, opening the world of reusable and portable Verilog to free software developers.

Milkymist SoC is a new generation of collaboratively developed IC designs, founded in 2007 by Sebastien Bourdeauducq. It aims to be an ARM competitor with new sharism business model, allowing for greater development speed and better customization and optimization in embedded products.

Milkymist One is available from Sharism Ltd. now, and sells for 499 USD plus shipping from Taipei.

[1] Milkymist One shop: https://sharism.cc/milkymist/

[2] Media Gallery: https://sharism.cc/media/

EDITORS PLEASE NOTE: To request more information or find out about obtaining Milkymist One for review, please contact info@sharism.cc

--Qi team 15:00, 28 September 2011 (CET)

Crypto Stick: Introduction

Tue, 13 Sep 2011 14:11:23 +0000

The Crypto Stick is an USB key with integrated (proprietary) smart card to enable highly secure encryption of e-mails and data, for authentication in networks and for access control. Other than ordinary software solutions, the secret keys are always stored securely inside the Crypto Stick. Their extraction is impossible which makes the Crypto Stick immune to computer viruses and Trojan horses. The user-chosen PIN and the tamper-proof design protect in case of loss and theft. The hardware and software are both available as Open Source to allow verifying the security and integrating with own applications.

Use cases

E-mail encryption based on X.509/SMIME and OpenPGP (e.g. Outlook, Thunderbird, Evolution)
Encryption of data stored on separate storage (e.g. TrueCrypt).
User authentication on local computers (e.g. Windows, Linux).
User authentication for network services (e.g. Firefox, OpenSSH, OpenVPN, IPSec, OpenID).

Advantages to ordinary software solutions

Secret keys are always stored securely inside the Crypto Stick. Their extraction is impossible. All sensitive cryptographic operations are computed in the Crypto Stick.
User-chosen PIN protects in case of loss and theft against brute force attacks.
Immune to computer viruses, Trojan horses, phishing attacks and other malicious software.
Tamper-proof design prevents sophisticated physical attacks with laboratory equipment.
Secret keys are generated securely on the Crypto Stick to prevent their extraction by attackers.

Advantages to proprietary security devices

Secure implementation can be verified by client and independent third parties to ensure the absence of back doors and security flaws.
Compatible to a large variety of software applications such as Outlook, GnuPG, Enigmail, Mozilla Thunderbird, OpenSSH for instance.
Own custom applications can be integrated easily due to open interfaces and open drivers
Lack of vendor lock-in increases security of investment
Security does not depend on secrets stored centrally at the vendor
Growing acceptance and user base supports continuously improvement and ensures high security due to peer reviews.
Transparent and open development process as an open source project

Further advantages

Windows, Linux, and MacOS X are supported.
Additional administrator PIN enables hierarchical use cases.
Three independent RSA keys, max. length 4096 bit each.
Import of existing keys and backup of keys possible.
High security due to embedded smart card which is based on Common Criteria 5-high certification.

Many ordinary security and encryption devices were broken

In 2011 RSA Inc was hacked and secret information about RSA’s securID token was stolen which allows to crack them.
In 2010 it was revealed that AES-256 encrypted and FIPS 140-2 Level 2 certified USB storage devices of the following vendors could be easily accessed by using a default password: Kingston, SanDisk, Verbatim, MXI, PICO

Serious security flaws were also found in the following products:

Corsair's Padlock (2010)
Raidon‘s Staray-S-Serie (2009)
All USB storage devices from 9Pay, A-Data and Transcend which use fingerprint readers based on the USBest UT176 and UT169 from Afa Technology (2008)
Excelstor’s GStor Plus (2005)
Lexar JumpDrive (2004).

Download this text as PDF

Peter Zotov, whitequark: Tweaking Linux TCP stack for lossy wireless networks

Mon, 12 Sep 2011 18:44:00 +0000

Public wireless networks are often congested and located in a noisy RF environment. Standard TCP congestion control algorithms work inefficiently in these conditions, leading to frequent timeouts, large RTTs and poor overall performance. There are some tricks, however, which can be enabled to improve it a lot.

First, there is one simple option which can be changed to get an impressive performance increase. It is the network interface retry limit. By default, it is set to a relatively high value of 7:

# iwconfig wlan0 | grep Retry
          Retry  long limit:7   RTS thr:off   Fragment thr:off

Somehow, in a lossy environment this value results in a constantly overflowing packet queue, skyrocketing latency and, at some point, a disconnect. After setting it to 0 (iwconfig wlan0 retry limit 0), packet queue will tend to overflow for a much lesser amount of time, and while latency will still probably be high and unstable, it will not grow infinitely anymore.

Per my experience, this change has resulted in latency drop from 10-160s (yes, seconds) to 0-12s (3-5s average), which is indeed a lot, but is manageable.

Linux TCP stack may be configured via sysctl utility. The TCP options are listed in man 7 tcp, and they are located in net.ipv4 namespace. (Well, technically there is one for IPv6, too, but I haven’t seen a single IPv6-enabled public network, ever). So, the option tcp_foo may be set to 1 by invoking sysctl net.ipv4.tcp_foo=1.

Interestingly, changing the TCP congestion control algorithms did not yield any visible result. On the other hand, changing several other options did.

There are three options worth mentioning. First two are related to F-RTO, a recovery algorithm designed specially for wireless networks.

Excerpt from `man 7 tcp’

tcp_frto (integer; default: 0; since Linux 2.4.21/2.6)
              Enable  F-RTO,  an enhanced recovery algorithm for TCP retrans‐
              mission timeouts (RTOs).   It  is  particularly  beneficial  in
              wireless  environments  where  packet  loss is typically due to
              random radio interference rather than intermediate router  con‐
              gestion.  See RFC 4138 for more details.

              This file can have one of the following values:

              0  Disabled.

              1  The basic version F-RTO algorithm is enabled.

              2  Enable  SACK-enhanced  F-RTO  if  flow uses SACK.  The basic
                 version can be used also when SACK is in use though in  that
                 case scenario(s) exists where F-RTO interacts badly with the
                 packet counting of the SACK-enabled TCP flow.

The tcp_frto option is set to 2 by default on Debian, which is the recommended setting, but changing it to 1 sometimes improves the performance.

Excerpt from `man 7 tcp’

tcp_frto_response (integer; default: 0; since Linux 2.6.22)
              When  F-RTO  has detected that a TCP retransmission timeout was
              spurious (i.e, the timeout would have been avoided had TCP  set
              a  longer retransmission timeout), TCP has several options con‐
              cerning what to do next.  Possible values are:

              0  Rate halving based;  a  smooth  and  conservative  response,
                 results  in  halved  congestion window (cwnd) and slow-start
                 threshold (ssthresh) after one RTT.

              1  Very conservative response;  not  recommended  because  even
                 though  being  valid,  it  interacts poorly with the rest of
                 Linux TCP; halves cwnd and ssthresh immediately.

              2  Aggressive response; undoes congestion-control measures that
                 are now known to be unnecessary (ignoring the possibility of
                 a lost retransmission that would require TCP to be more cau‐
                 tious);  cwnd  and ssthresh are restored to the values prior
                 to timeout.

This option is set to 0 by default, as the manpage suggests, but changing it to 2 makes retransmission delays much smaller.

Excerpt from `man 7 tcp’

tcp_low_latency (Boolean; default: disabled; since Linux 2.4.21/2.6)
              If  enabled,  the  TCP  stack makes decisions that prefer lower
              latency as opposed to higher throughput.   It  this  option  is
              disabled,  then  higher throughput is preferred.  An example of
              an application where this default should be changed would be  a
              Beowulf compute cluster.

Again, this option is disabled by default, and it seems that after enabling it, TCP stack prefers to retransmit more often.

You could make this settings to be applied on boot by adding them to /etc/sysctl.conf:

/etc/sysctl.conf

# TCP stack tweaking for lossy wireless networks
net.ipv4.tcp_frto = 1
net.ipv4.tcp_frto_response = 2
net.ipv4.tcp_low_latency = 1

Geoffrey L. Barrows - DIY Drones: Chip design, open source, and DIY: Part 3, batch fabrication of chips

Mon, 12 Sep 2011 14:17:18 +0000

This is the third part of a three-part posting on chip design and how to reconcile it with the open source and DIY movements. (Part 1 is here and part 2 is here.) In this part I will discuss economics- How much does it actually cost to fabricate a chip? Can batching be used to make the cost accessible to a group of (hypothetical) casual chip designers?

Masks

Once a chip design is “taped out”, the chip foundry who manufactures them first creates a set of masks- anywhere from around 15 to upwards depending on the design and the manufacturing process. These are for a photolithography process that is vaguely similar to those used in PCB manufacture, however for chips the masks are both more precise and more expensive.

I won’t give exact costs or list specific foundries, but I’ve seen masks cost anywhere from under $10k to over $50k for a complete set. This is for a 0.5um or 0.6um process. Obviously the masks for the latest 32nm process would be much more.

Reticle

Typically in chip design the foundry creates a set of masks for a “reticle”, a box-like region that gets replicated over and over across a whole wafer using a stepping process. A wafer itself is a disc of silicon less than a millimeter thick but generally tens of centimeters in diameter.

The typical reticle size I use is about 21mm x 21mm. (The masks themselves are much larger than this but the image is optically reduced during the manufacturing process.) You can fill up that reticle pretty much any way you want- you can put in a single 21mm x 21mm chip. If your chip size is just 2mm x 2mm you can put in a 100 of these into the reticle, so every reticle gets you 100 chips. You could also put in 100 different designs. This is where batching would come in.

Batching

There are companies that provide batching services. One of the oldest is the MOSIS service, run by ISI of the University of Southern California. MOSIS was set up originally with DARPA and NSF grants as a way to bring chip design to universities, and give students the ability to design and fabricate a chip, either as a classroom exercise or for a research grant. MOSIS also offered their services to industry. To this day they still offer these services and actually serve as a “store front” for several major chip foundries (ON-Semiconductor, TSMC, IBM, and others) for customers who want to prototype chips without paying for a whole set of masks.

The economics are essentially that everyone shares the cost of the tooling. Let’s say a mask set for a reticle has 10 different designs and cost $20k to make (a somewhat made up number)- that comes down to $2k per design- a much more reasonable number!

There are other services similar to MOSIS, and there are also individual companies that offer “multi-project runs” specifically for smaller customers that want to batch-prototype chips. So the batching concept is clearly established. In fact, whenever I do a run of silicon at Centeye I also place multiple designs on one reticle to get the most for my money.

Hypothetical Cost Breakdown

So let’s suppose a company wanted to get into the chip batching business. Let’s say the company decides to accept 2mm x 2mm size chips, and place 100 different designs onto a reticle. (The remaining 1mm slivers could be used for test circuits and quality control…) Looking at pure costs alone (e.g. neglecting stuff like “overhead”, “labor”, and “profit”), the numbers might look like this:

Mask set for a 21mm x 21mm reticle: $20,000

6”/150mm diameter wafers, set of 10 (approx 30+ reticles per wafer): $10,000

Dicing the wafer up into chips: $500 per wafer

First consider prototype quantities- I don’t know of any foundry that will make a single wafer- typically a set of wafers are manufactured in case one or a couple of them fail quality assurance inspections. For initial prototyping you would end up dicing just one wafer. Next comes packaging- most customers are not equipped to work with bare die, so they would probably want the chips in a DIP or similar package that they can then solder to a board or press into a breadboard- this would probably cost at most $20 per chip, at cost. Total cost per customer: ($20k + $10k + $500)/100 = $305 for about 30 chips, plus $20 per chip packaged.

Next let’s consider a slightly higher quantity price break, by dicing up all 10 wafers. The total cost per customer rises to ($20k + $10k + 10 x $500) = $350 for about 300 chips, not including packaging.

These numbers are encouraging. Of course, we have to assume 100 such customers can be found, and we have to consider the other costs to stay in business, but the above numbers should give you a starting point.

So where does that put us?

Once we factor in the cost of doing business, we get upwards to a thousand dollars for a batch-run prototype chip. This is a stiff amount compared to a batch-fabbed PCB. But it is not impossible- This amount is easily within the budget of a Kickstarter project, and there are hobbyists that would be willing to spend this amount on a chip fab. Certainly small companies could spend this amount. Also note that due to the nature of the chip manufacturing process, there could be several hundred individual chips available for use (or sale) if the design works. (There are a number of caveats, of course, which I didn’t mention here, but can discuss below if there is interest.)

I think one of the challenges, though, is overcoming the fear of spending money on a fabrication that doesn’t work. Getting back a PCB that doesn’t work is never fun; the stakes are higher for chips because of both the higher cost and the long lead times (generally six weeks or more). This is where the combination of good design tools and good design practices can help out- I think the “abstract layout” workaround mentioned in my last post, properly executed, could make “probability of success” sufficiently high for the DIY crowd.

Peter Zotov, whitequark: Treetop: typical errors

Wed, 07 Sep 2011 20:41:00 +0000

Treetop is a PEG parser generator for Ruby which is very flexible and allows to create DSL’s in minutes, but it may be hard to understand for a newcomer.

Examples in this article were checked on Treetop v1.4.10.

Grammar tricks

First of all, parser expression grammars are always greedy. This is probably the most frustrating and unintuitive aspect of PEG’s. Consider this grammar:

Incorrect grammar

grammar Example1
  rule string
    '"' .* '"'
  end
end

The string rule is expected to parse double-quoted strings; it is woefully incorrect, through. The .* predicate will match any character, including a double quote, and the parser will never reach the end of the rule.

To fix the error, we can exclude the quote from the possible characters (replacing .* with something like [^"]*), but a cleaner and more flexible approach exists. We can instruct the parser to fetch one more token from the input stream and verify that it does not end the string; this is called negative lookahead. Here is the fixed rule:

Working grammar

grammar Example2
  rule string
    '"' ( !'"' . )* '"'
  end
end

To allow representing double quotes inside our strings, escape characters are required. It may seem obvious to add a second choice to the list of characters like this:

Never matches "

grammar Example3
  rule string
    '"' ( !'"' . / '\"' )* '"'
  end
end

This is incorrect as well. ., being greedy (as any other PEG predicate is), will consume the backslash, and the second choice will never be taken. In order to work as expected, variants must be ordered from the narrowest to broadest one. Compare with the fixed code:

Knows what "a\"b" is

grammar Example4
  rule string
    '"' ( '\"' \ !'"' . )* '"'
  end
end

Note that the negative lookahead predicate has changed its position: it belongs to the broadest . predicate.

AST quirks

Sometimes Treetop embeds some AST nodes into another nodes when you do not expect this. For example, let’s look at this excerpt from one of my grammars:

grammar SimpleExpression
  rule expression
    ( string / number ) {
      def to_code
        elements.first.to_code
      end
    }
  end

  rule string
    '"' ( !'"' . / '\"' )* '"' {
      def to_code; text_value; end
    }
  end

  rule number
    [0-9]+ {
      def to_code; text_value.to_i; end
    }
  end
end

require 'treetop'

Treetop.load 'ast_quirks.treetop'

parser = SimpleExpressionParser.new
ast = parser.parse %q{42}
p ast.to_code

The expression rule may look a bit strange as-is, but it is actually just the last part of more complex code generation rule which included unary and binary operators, and a dozen of simple types in one list at end. If executed, ast_quirks.rb will display a thrown exception: (eval):10:in 'to_code': undefined method 'to_code'. But the method is indeed defined!

Somehow Treetop embeds the string or number subtrees into the expression tree, losing the attached methods in process. To alter this behavior, a 1..1 repeat specifier may be attached: it does not change the meaning of the rule, but prevents AST squashing.

grammar SimpleExpression
  rule expression
    ( string / number ) 1..1 {
      def to_code
        elements.first.to_code
      end
    }
  end

  rule string
    '"' ( !'"' . / '\"' )* '"' {
      def to_code; text_value; end
    }
  end

  rule number
    [0-9]+ {
      def to_code; text_value.to_i; end
    }
  end
end

Useful snippets

Fancy error reporting

This function will show the location of an error in Clang or Java style.

def parse(data)
  if data.respond_to? :read
    data = data.read
  end

  parser = ExampleParser.new
  ast = parser.parse data

  if ast
    ast.do_something_useful
  else
    parser.failure_reason =~ /^(Expected .+) after/m
    puts "#{$1.gsub("\n", '$NEWLINE')}:"
    puts data.lines.to_a[parser.failure_line - 1]
    puts "#{'~' * (parser.failure_column - 1)}^"
  end
end

$ ruby test.rb
Expected one of >=, <=, <, >, ==, !=, *, /, +, -, $NEWLINE, ; at line 2, column 14 (byte 35):
  scope @type, = "nothing"
~~~~~~~~~~~~~^

String unescaping

This is a modification of string parsing rule described above which adds support for arbitrary escaped characters.

escaped_string.treetop

grammar EscapedString
  rule string
    '"' letters:( !'"' string_letter )* '"' {
      def fetch
        letters.elements.map { |el| el.elements.last.fetch }.join
      end
    }
  end

  rule string_letter
    '\\' char:["ntH] {
      def fetch
        case char.text_value
          when '"'; '"'
          when 'n'; "\n"
          when 't'; 9.chr
          when 'H'; "hello world"
        end
      end
    }
    /
    . {
      def fetch
        text_value
      end
    }
  end
end

$ irb
ruby-1.9.2-p290 :001 > require 'treetop'
 => true
ruby-1.9.2-p290 :002 > Treetop.load 'escaped_string.treetop'
 => EscapedStringParser
ruby-1.9.2-p290 :003 > puts EscapedStringParser.new.parse(%q{"see:\t\t\H"}).fetch
see:     hello world
 => nil

Matching whitespace

Here are four whitespace helpers: s in the name means “space”, n means newline, and capitalization means that the capitalized part is required (contrary to being optional).

rule sn
  sN?
end

rule sN
  ( ( S "\n" / s comment_to_eol / s "\n" ) s comment_to_eol? )+
end

rule s
  S?
end

rule S
  [ \t]+
end

rule comment_to_eol
  '#' (!"\n" .)* "\n"
end

Geoffrey L. Barrows - DIY Drones: Chip design, open source, and DIY: Part 2, open source issues

Wed, 07 Sep 2011 20:00:00 +0000

Above: Concept for an "abstract layout" workflow that could reconcile open source circuit designs with "closed" process design rules and libraries. First the designer would generate an abstract layout by instancing cells for various components. The above example shows a 2-input AND gate, with one input pulled to ground with a 10k resistor, and a tri-state buffer as an output. The designer would instance these cells, and then route connections between them. The designer would also place cells corresponding to "pads" at the periphery of the chip. The designer would not need to know the exact layout of the cell interiors- this may be kept "closed" even while the abstract layer itself is "open". This abstract layout may then be converted to a full detailed layout that may be used by a foundry to fabricate the chip.

Introduction

This is the second part of a three-part blog posting on chip design and how to reconcile it with the open source and DIY movements. Previously in Part 1, I gave a top level summary of “indie chip design” as I experience it. In this part I will discuss the real issues I would face if trying to “open” up a chip design. There are three areas to consider: the CAD design tools themselves, the design rules for a particular chip fab process, and design libraries.

First a few definitions: The term “foundry” refers to a company that performs the actual chip fabrication. The term “process” refers to a particular fabrication line of a foundry. A foundry may have several processes including ones optimized for digital circuity and others designed for analog. Typically a foundry will have several grades of processes, with more expensive ones having more capabilities or a smaller feature size. The term “design tools” refers to the CAD tools that one may use to design a chip (analogous to Eagle for PCBs). The term “design rules” refers to specifications such as minimum width, spacing, and other requirements for the different layers.

Chip Design Tools: Open source versions do exist!

First I present some good news- Open source chip design tools do exist. One of the most prominent versions is Magic, which was created in the mid 1980’s and has gone through multiple revisions as late as 2008. I personally used versions 6.4 and 6.5 for all of Centeye’s chip designs from 2001 through 2004, including designs with up to 400,000 transistors. Magic is somewhat derided by many chip designers because it automates the generation of some layers and restricts you to purely Manhattan geometries e.g. no diagonal features. However in practice these restrictions affect only a minority of overall chip designs and do not cost much in terms of layout space. Magic has a real-time design rule verifier- you will know pretty much right away if your layout has violated a design rule. I found this useful when first learning chip design. Magic is also able to create CIF and GDSII files, the chip design equivalent of Gerbers used for PCBs.

Magic was originally designed to run on Unix and Linux operating systems, but it has more recently been ported to Windows (using Cygwin) and is maintained here at Open Circuit Design. Unfortunately it appears that recent development efforts have slowed, so I am not sure if Magic is as actively used as in the past.

Other open source layout tools exist as well, for example Electric. There is also a free, but not open source, tool called Lasi (pronounced “lazy”).

For circuit verification there are also free circuit simulators, most notably the venerable SPICE.

Commercial chip design tools exist as well (if you have the money...)

There are a number of commercial design tools available as well. I now use Tanner Tools, while others (with more resources) may use Cadence or Synopsys. The cost of Tanner Tools is within reach for a small company (on the order of the price of a new car- depreciation is my friend!) but is out of reach for most hobbyists. The other latter tools can cost, as far as I know, a upwards to a million dollars per seat, but allow wide-scale cooperation between large teams of designers.

As for why I switched from Magic to Tanner- Around 2005 we were migrating to a new foundry and process and were anticipating designing more complicated chips, so I felt the need for something “professional”. Tanner Tools has worked very well for us. However- and this would be a good story for another post- we succumbed to “complexity creep”, thus producing complicated (and headache inducing) designs, but later reversed course, so that now are designs are more minimalist again. I could go back to Magic, however since I now have the Tanner and have built up my own libraries within it, it is easier stay with Tanner. There are also other issues, which will be discussed next.

The bad news: Design rules, setup files, and design kits are generally not open.

As I see it, the biggest issue preventing bringing open source to the chip design rule is not the design tools themselves, but the design rules! The design rules on a PCB are relatively easy to set up and for programs like Eagle are freely available. They are also easy to understand. For chips, however, the design rules are generally treated as proprietary by the foundry. This is because the design rules contain information that describes the capabilities of a process, and the foundries don’t want that information freely disclosed without restrictions. Yes- I had to sign NDAs to get the design rules for all of the processes we use now! Similarly, the “setup files” that design tools use to configure a design program for designing chips for a particular process are also generally treated as proprietary by the company that sells the tools.

The same applies to the “design kits” themselves- these are basically library files that contain cells for different subcircuits you may want to use in a chip design. This includes cells such as gates, flip flops, or basic analog components. This also includes essential cells such as the “pads” that allow a chip to be interfaced with the outside world.

And this, folks, is why we cannot open source our chip designs- I would be violating all the NDAs I had signed with these companies! The most I could do (which I have already done in one case) is to release a schematic of the chip, in PDF form, that contains details on the circuits I had designed, and then “black boxes” for anything that came from a design kit.

Overall the trend seems to be for new advances to be made in the “closed” world, with open design tools and design kits being increasingly obscure and obsolete.

Is there a workaround?

I can see two possible workarounds. One method is, in fact, a workaround that has been used in the past and (I believe) is still available to an extent. The other is one that comes to my mind. Both would require some level of cooperation from the chip foundry.

Workaround #1: Use simplified, genericized design rules

During 2000 through 2004 when I was using Magic, I also used the MOSIS service for chip fabrications. MOSIS is effectively a brokerage service that places different designs from different people onto the same wafer, thus allowing everyone to share the tooling costs. (I’ll talk more about that in Part 3 of these posts.) When using MOSIS, you had the option of using either the design rules from the foundry (requiring an NDA), or you could use more generic design rules that MOSIS set up and made freely available.

The MOSIS rules had the advantage of being a bit more transparent and easy to understand. Also a design made for one process could be fabricated on any process that supports the same design rules. However they had several weaknesses- First, designs made using these rules are not a compact as they would be using the native foundry rules. In practice this penalty would be small, on the order of a few percent at most. Second, the MOSIS rules may not allow you to use all the features that a particular foundry or process supports. Third, the MOSIS rules are compatible with only a few processes- A look at the MOSIS website reveals that these rules are usable with two foundries. If you are willing to be constrained to just these two foundries (and both are good!), and if you don’t need some exotic unsupported feature, for most designs this approach will work.

The same concept used to make these MOSIS design rules can be applied to other foundries. The only barrier is obtaining the cooperation of the foundry, who may not want details of their process revealed openly or simply may not want to spend resources supporting an additional set of design rules.

Workaround #2: Use an intermediate abstract layout

The second workaround would be to set up an abstract design layer that is more detailed than “schematic” but less than that of “layout”. I envision something like what is depicted on the top of this post- A designer would create an abstract “layout” that instances cells such as gates, pads, or individual discrete components. Each of these cells would have a number of known “ports”, including power/ground lines, inputs, and outputs. For example an “AND2” gate may have two power ports (ground and power), two digital inputs, and one digital output, while a capacitor or resistor may have just two ports. Some cells, of course, would be the pads that allow the chip to be connected to the rest of the world.

The designer would not need to know the specific layout of these cells or even their exact circuit diagram, but would need to know enough to use them in a design. The designer would instead have several page (or more) datasheet describing everything needed to use that cell. For example, it might be known that the AND2 gate requires 5ns to settle and can source up to 10uA of current, or that a specific capacitor cell holds 1pF but has 0.1pF of parasitic capacitance at one node. The designer could then create an abstract layout by dropping these cells at various locations on the chip, much like a PCB designer places “parts” on a circuit board layout. The designer could then draw the wires to connect the components together. Such a design tool could have autorouting features. The design tool would then perform basic design rule checks.

Once the design is complete, this abstract level design file would be exported and sent to either the foundry or a “middle man”. The foundry or middle man would then be responsible for generating the final layout files from the abstract layout. Finally, the foundry could fabricate the chip.

The disadvantage of this approach is that the design is still only “partially open”. However at least the abstract layout could be made “open” and freely shared or released with appropriate open source licenses as desired.

There would be another benefit to this approach- The workflow would be more similar to that of making a PCB, in both the steps taken and the complexity. This approach would make chip design more accessible to a “casual” chip designer.

In my next post, I will discuss economic issues associated with chip fabrication.

Peter Zotov, whitequark: Fixing ACPI on Samsung N250

Sun, 04 Sep 2011 03:42:00 +0000

In this article I’d like to describe some of the typical BIOS design flaws of a modern netbook, and methods which can be used to locate, dissect and heal the bugs.

Introduction

First of all, ACPI is a generic management interface which controls a lot of hardware functions on modern computers ranging from power and battery control to detecting external displays. It consists of a several configuration tables, one of which contains code for a virtual machine to be executed by an operating system kernel. The latter was added to make the system as flexible as possible.

Theoretically, this system should have been made hardware-specific chipset drivers unneccessary. It is quite potent (not to say overblown) and is definitely able to accomplish the task; Macs are a good example, as they use ACPI extensively and correctly.

In reality, however, PC-based hardware vendors would supply buggy and incomplete ACPI tables for their systems, and vendor lock-in appears not as the least reason to me. Therefore, such systems require numerous nontrivial workarounds, often flawed and undocumented. I’ve attempted to fix the ACPI itself for a particular computer instead.

The system I have is a Samsung N250+ netbook. It has quite good hardware (except for battery-hungry and quirky Broadcom WLAN card which I have replaced with a better one by Atheros), but the ROM BIOS quality is really poor. At the moment of release there even was no way of enabling the wireless card on a Linux system; its state could be changed via CMOS Setup, through. Now there is a kernel driver, but it uses a fundamentally flawed approach, too (and it has some usability problems).

Examining the current state

Support for features of the laptop which ACPI has lacked was initially provided by an easy slow down manager kernel module, which was eventually merged to the kernel under the name samsung-laptop.c.

As can be seen on line 725 of the source, this driver uses SMI calls (via an interface called SABI) to set the backlight level, change performance mode (this actually changes just the fan speed) and control the wireless card power. An SMI call is a command which leads CPU into so-called System Management Mode: a special processor and chipset feature which is equally similar to a hypervisor and a rootkit.

BIOS can set up the chipset to intercept certain operations (like accessing memory or I/O ports) and launch SMM, which cannot be detected nor interrupted by OS. It then may execute arbitrary code: for example, SMM is used to trick old OSes (think of DOS) to believe that a USB mouse is actually a PS/2 one without any changes to the OS itself. Moreover, a memory area which belongs to SMM under no circumstances can be accessed by the OS, making it impossible to study its behavior directly.

Hopefully, in this case SMI calls probably just change a byte or two, and it may be possible to determine their locations without examining SMM code itself.

Next, let’s take a look at the ACPI tables. There are plenty of them, but we need one called DSDT

—the biggest and most important one which contains handlers for a huge number of possible hardware events.

To dump the tables and rework the code two utilites are required: acpidump and iasl. On a Debian-based system they can be found in packages with same names.

$ sudo acpidump -o dsdt.aml -b
$ iasl -d dsdt.aml # generates dsdt.dsl

To ease the demonstration, I’ve uploaded the table on github; initial state can be checked out here. As you can see, the table is quite big at more than 5000 lines; tables more than 25000 lines long are not uncommon.

At an attempt to compile the table back to bytecode (try make) without any changes, the compiler will spit out a few warnings and errors. They are quite trivial to fix just by looking at error messages and ACPI specification; this Gentoo forum thread has some pointers as well. Note that while the manual is 7 years older than my notebook, the latter has roughly same quirks as described (and fixes do work, too). Fixed version can be found at this commit.

Repairing backlight

My netbook has LED backlight, which means that its brightness could be controlled simply by keeping it on for a known part of time, e.g. to dim it by 30% one could keep it on just for 70% of time. To make the flickering invisible, this switching (called PWM) is done on a frequency far above the sensitivity level of a human eye—200 kHz is good enough.

In this case, PWM duty cycle is probably controlled by an integrated graphics controller. We can see it on a PCI bus:

$ lspci
00:00.0 Host bridge: Intel Corporation N10 Family DMI Bridge
00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller
00:02.1 Display controller: Intel Corporation N10 Family Integrated Graphics Controller
<...>

The numbers 00:02.0 are an address of the device on the bus. With this address, we can inspect and modify the properties of the device, as Linux provides numerous sysfs hooks for that purpose. One of them is an ability to read and write PCI configuration space: a memory block of 256 bytes used to configure a PCI device. First 64 of them have predefined meaning; other ones can be freely used by device vendor.

Let’s check what changes in the device configuration when we alter backlight level with an SMM-based driver (note that it would be perfectly possible with a closed-source driver or even on Windows: all you need is a tool to scrap the configuration space):

# echo 7 >/sys/class/backlight/samsung/brightness
# hexdump -C /sys/bus/pci/devices/0000\:00\:02.0/config >config-1
# echo 5 >/sys/class/backlight/samsung/brightness
# hexdump -C /sys/bus/pci/devices/0000\:00\:02.0/config >config-2
# diff -u config-1 config-2
--- config-1 2011-09-05 01:06:13.326930250 +0400
+++ config-2 2011-09-05 01:06:21.503828025 +0400
@@ -13,5 +13,5 @@
000000c0  00 00 00 00 01 00 00 00  00 00 00 00 a7 00 00 00  |................|
 000000d0  01 00 22 00 00 00 00 00  00 00 00 00 00 00 00 00  |..".............|
 000000e0  00 00 00 00 00 00 00 00  00 80 00 00 00 00 00 00  |................|
-000000f0  79 00 00 00 ff 00 00 00  ad 0f 00 00 7c 0e 5c 7f  |y...........|.\.|
+000000f0  79 00 00 00 73 00 00 00  ad 0f 00 00 7c 0e 5c 7f  |y...s.......|.\.|
 00000100

So, the byte at index 0xf4 controls the brightness level. This can be verified by running sudo setpci -s 00:02.0 f4.b=80 (replacing the 80 with a brightness value).

Now, let’s set up DSDT code to update this value (and possibly determine the cause for it to not work in first place).

According to ACPI specification (section B.6.2, page 704), a compliant graphic adapter description should implement methods _BCL, _BCM and _BQC. Our DSDT has these methods defined at line 1767. Here is the annotated source code:

/*  = Query List of Brightness Control Levels Supported =
 * Returns an array (Package in ACPI terms) which contains
 * supported and preferred backlight levels.
 */
Method (_BCL, 0, NotSerialized)
{
    /* Flip a bit in GVNS system memory region (line 132).
       I don't know what it does. */
    Or (VDRV, 0x01, VDRV)

    Return (Package (0x08)
    {
        0x64, /* Preferred level for AC power */
        0x05, /* Preferred level for battery power */
        0x0F, /* A list of valid brightness levels */
        0x18, /* 24 */
        0x1E, /* 30 */
        0x2D, /* 45 */
        0x3C, /* 60 */
        0x50  /* 80 */
    })
}

/*  = Set the Brightness Level =
 * Receives the target brightness in Arg0.
 * OS guarantees that it will be included in list
 * returned by _BCL method.
 */
Method (_BCM, 1, NotSerialized)
{
    /* Divide Arg0 by 10. Remainder goes to Local0, result
     * is placed in Local1. */
    Divide (Arg0, 0x0A, Local0, Local1)

    /* Predicate names are beginned with L (from "Logic") in
     * ACPI. Here, LEqual(Local0, 0x00) may be written as
     * (Local0 == 0x00) in C.
     *
     * As you can see, for half of valid brightness levels this
     * will silently do nothing.
     */
    If (LEqual (Local0, 0x00))
    {
        /* Pass the target level to BRTW function (line 5324).
         * It does not work. */
        BRTW (Arg0)
    }
}

/*  = Brightness Query Current level =
 * Return current level. The value should be contained in
 * list returned by _BCL method.
 */
Method (_BQC, 0, NotSerialized)
{
    /* See above. */
    Divide (BRTL, 0x0A, Local0, Local1)
    If (LEqual (Local0, 0x00))
    {
        /* Return BRTL value, which should have been updated
         * by BRTW function (at line 5341). */
        Return (BRTL)
    }
}

To make this work via PCI configuration space writing, a new field first should be defined in an ACPI structure describing that space. The adapter has an address of 00:02.0; this corresponds to a value of 0x00020000 ACPI can understand as an address of a PCI device (section 6.1.1 on page 200). A device with such an address is defined at line 1325; the PCI configuration space description follows.

As was said, first 64 (0x40) bytes in this space are reserved for internal purposes. Because of that, ACPI does not even include them to the region: it is defined as OperationRegion (IGDP, PCI_Config, 0x40, 0xC0), where third argument means a count of bytes skipped from the beginning. Our brightness byte with a whole-space address of 0xf4 is located at position 0xb4 in this region.

Below that, field definitions are located. The whole Field construct represents a stream of bit fields (the field length is defined in bits, not bytes), where one can be placed after another, or at a particular Offset (contrary to fields, offsets are given in bytes). Let’s call our brightness level field BLVL and incorporate it to the structure:

@@ -1347,7 +1347,8 @@ Device (IGD0)
                             Offset (0xB0),
                             Offset (0xB1),
                     CDVL,   5,
-                            Offset (0xB2),
+                            Offset (0xB4),
+                    BLVL,   8,
                             Offset (0xBC),
                     ASLS,   32
                 }

As ACPI has hierarchical naming system, our field is now globally accessible as \_SB.PCI0.IGD0.BLVL (the name is defined by the nesting of Device and Scope clauses). We can now rewrite three backlight control methods to access BLVL field directly:

Method (_BCL, 0, NotSerialized)
{
    /* It's a good idea to keep things you don't know
     * what they do. */
    Or (VDRV, 0x01, VDRV)

    /* Levels at PCI control point range from
     * 0x00 to 0xff. Let there be 16 points. */
    Return (Package (0x12)
    {
        0xEE, /* proposed on AC adapter on */
        0x22, /* proposed on AC adapter off */
        0x01, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66,
        0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD,
        0xEE, 0xFF
    })
}

Method (_BCM, 1, NotSerialized)
{
    Store (Arg0, \_SB.PCI0.IGD0.BLVL)
}

Method (_BQC, 0, NotSerialized)
{
    Return (\_SB.PCI0.IGD0.BLVL)
}

Updated DSDT can be found in the repository.

While testing the changes, I’ve encountered a need for debugging the code. This can be done with a Store (something, Debug) command. Don’t forget to enable ACPI debug output by adding acpi.debug_level=0x1f parameter to kernel command line.

The changed and compiled (iasl -tc dsdt.dsl) DSDT should now replace vendor-provided one. To achieve the goal, we could reflash the BIOS—but it is not even known where DSDT is located in it. So, a simpler approach can be used: Linux can be instructed to ignore the DSDT found in system RAM and load a provided one instead. To do that, you should place compiled file dsdt.hex (verify that it contains a C array definition; the -tc option instructs iasl to emit one) in include/ directory of Linux source tree and set option CONFIG_ACPI_CUSTOM_DSDT_FILE to dsdt.hex. (To be able to access the latter, you should turn off CONFIG_STANDALONE; it is named “Select only drivers that do not need compile-time external firmware” and located in “Generic driver options”.)

Compile the modified kernel and reboot. Voilá: ACPI driver can now set backlight level. (Try echo 7 >/sys/class/backlight/acpi_video0/brightness).

Other features

To locate other fields in the PCI configuration space which might be changed by SMM-based driver, I wrote a simple script. Note that some devices, namely PCI-Express bridges and network adapters, have a lot of spurious changes which happen in background on their own.

Sadly, not the fan speed nor wireless rfkill switch state were not linked to any changes within the configuration space. I guess that they may be done through Embedded Controller and via SMBus interface, which means that no permanent changes are accumulated in the system RAM itself, and all of the processing is buried deep inside the SMM BIOS.

Moreover, even if I could find the rfkill interface, there is no standard way to describe it in ACPI. On laptops where it actually is exported via ACPI, there is a platform-specific driver handling that (contrary to the backlight, which can be controlled in a generic way).

GNU Radio Blog: Howto receive and decode NOAA APT images with the Funcube Dongle and Gqrx

oz9aec@gmail.com (Alexandru Csete) — Wed, 31 Aug 2011 19:17:25 +0000

One of the great advantages of software defined radio receivers is that tuning receiver settings is a matter of adjusting software parameters. Gqrx is no different here and has optimal settings built in for weather satellite reception. This tutorial describes how to receive automatic picture transmissions (APT) from NOAA weather satellites using Gqrx SDR, record them to a WAV file, and finally decode the images using the free and open source Atpdec decoder. If you follow this guide you can end up with very nice results such as the one shown at the end.

I have used the Funcube Dongle with an Arrow antenna for this example but any receiver hardware supported by Gqrx can be used, provided that it can receive the required bandwidth, which is around 40 kHz.

Step 1: Reception and recording

NOAA APT transmissions are analog transmissions. The data coming from the imaging sensors is used to amplitude modulate a 2.4 kHz sub-carrier, which is then used to FM modulate the VHF carrier at 137.x MHz. The FM deviation is 17 kHz and using the Carson bandwidth rule we get a channel bandwidth of

BW = 2 × (17 + 2.4) kHz = 38.8 kHz

Hence the requirement for 40 kHz bandwidth. In fact, a few kHz more will not hurt but allow to track the signal during the whole pass without any active Doppler tuning.

The Funcube Dongle uses 96 ksps sample rate and has an effective bandwidth of 80 kHz. Thus there is just about enough bandwidth to have the APT signal on one side and avoid interference from the DC spike, which can not be completely eliminated at these frequencies.

Start by tuning the FCD PLL to 23 kHz above or below the satellite frequency. For example, NOAA-18 transmits on 137.9125 MHz and I tuned the FCD to 137.935 MHz. Then tune the channel filter so that the RX frequency will correspond to the satellite frequency (see the Gqrx screenshot above).

In the demodulator options select FM with 17k deviation and disable de-emphasis by setting the filter time constant tau to 0.

When the satellite comes in range, start the audio recorder by pressing the red dot in the Audio settings. Note that the red dot in the toolbar is the I/Q data recorder – we don't need that here.

Watch video on YouTube.

As you can see I have very good signal above; about 20 dB C/N when the satellite is close to the horizon and almost 40 dB C/N at the time of closest approach. The recording was made in a relatively quiet area and I had LNA gain reduced to 10 dB.

Don't forget to stop the audio recorder when the pass finishes, otherwise the WAV file will have corrupt header.

Note that Doppler tuning is not necessary as long as the channel filter is wide enough. This is an advantage (maybe the only advantage?) of FM modulation: The Doppler shift will be seen as a moving DC offset in the audio but the audio amplitude, which is the important parameter for APT, will not be influenced. This assumes that the audio level is sufficiently below the maximum level, otherwise a DC shift will saturate and clip the samples. You may have to experiment with the settings before you find the optimal volume; however, the -15 dB audio gain I am using will probably also work for you.

Step 2: Convert the recorded audio

Gqrx records audio WAV files at 48 kHz. We need to convert it to 11.025 kHz WAV. If you have a favorite conversion program just do it your way. I often import the WAV file into Audacity where I can also cut any noise from the beginning and the end. In audacity you need to use Track → Resample, then also change the project rate from 48 to 11.025 kHz (maybe it is sufficient to change the project rate?). When finished export the audio to a new WAV file.

In case you end up with a corrupt WAV file (gqrx is in testing phase ;-) you can still use VLC or Sox to resample it.

Step 3: Decode image from audio recording

Now that we have an 11.025 kHz WAV file we can use Atpdec to decode the APT image from it. The latest stable version is 1.7 from 2005, but it appears to be sufficient and is easy to build compared to the latest code in the CVS repository. If you read the README file you'll see that it requires libsndfile and libpng to compile. All of these are pretty standard and available for all Linux. Remember that we need the -dev or -devel packages when compiling against libraries, i.e. libsndfile-dev or libsndfile-devel.

The README file also contains necessary information about the usage of atpdec. I have used

  atpdec -s 18 -i ab recording.wav

but you can of course use whatever you wish. Note that NOAA-19 is not included in Atpdec version 1.7, for that you will need the latest version from CVS. At the time of writing, the code in CVS does not compile for me.

Step 4: Enjoy and experiment

Below you can see an image I received from NOAA-18 on August 28, 2011. As mentioned above, I used the Funcube Dongle and a simple Arrow antenna.

Once you have mastered basic reception, you should start experimenting with the receiver settings. I would also be interested to see scripts / hacks that perform automatic recording and decoding. I guess that will be easier once I implement the scheduler in gqrx.

In any case, I hope you'll have fun with this area of space communications!

Geoffrey L. Barrows - DIY Drones: Chip design, open source, and DIY: Part 1, Indie chip design

Thu, 25 Aug 2011 00:39:39 +0000

Above: Simple circuit using a transistor (an N-channel MOSFET), a resistor, and a capacitor. Left shows the schematic, right shows the layout.

Following discussions from a previous post here, I’m writing a three-part blog post on chip design, as I experience it professionally, and how I see it relating to both the open source community and the DIY crowd. This first post will discuss the chip design process itself. I am going to focus on what could be called “indie chip design” as it may be executed by a small company or even a single person. Obviously I can’t explain how to design the next hot microcontroller in a single blog post, but you should get a flavor for how this process is similar to and different from, say, designing a printed circuit board (PCB).

First a little background- I work in a small company Centeye that makes image sensor chips for various embedded vision and robotic applications. These designs incorporate both digital and analog circuitry, including pixel circuits, on the same chip. Due to our size (and budget!) we favor a minimalist approach to these image sensors. The chips themselves typically have anywhere from a thousand to at most several million transistors and are simple enough in architecture that one person (e.g. me) can handle the whole design. Our chips are three to six orders of magnitude simpler (by transistor count) than a contemporary processor or GPU chip, which currently contain up to several billion transistors.

The “complexity” of any design is an important consideration. Consider how much the complexity of a PCB can vary. At one end you have a 10-plus layer state-of-the-art computer motherboard. At the other end you can have a single layer PCB that uses a basic Atmel and a few discrete parts to blink an LED. Both of these are “circuit boards”, but one can be designed by a single person in a fraction of an hour while the other requires specialized (e.g. expensive) software and a team of engineers putting in person-years of effort. The design methodologies are certainly different for each board- You can take a cowboy approach and “wing it” when designing the blinking LED board. But the computer motherboard requires careful and rigorous preliminary research, planning, and coordination between the designers. Now I don’t want to imply that I design chips with a cowboy approach (well not usually) but the simplicity of our designs allows for different methodologies than what are needed for, say, designing a new GPU.

The PCB design process

As a starting point, that more people here would be familiar with, let’s first consider the PCB design process that one might follow if using a set of tools like Eagle. You might follow these steps:

Specification: Decide what you want to make. Decide some basic components to include (e.g. what processor to use or other desired components). Decide the interface, for example how you power and “talk to” the board if there is an I/O aspect.

Sketching and Research: Sketch out different sections of the board schematic (on paper or with Eagle), read datasheets, and determine what exact components you need. (For example- what voltage regulators do you need, what caps / resistors do those regulators need, and so on.)

Schematic Entry: Enter the schematic diagram.

Board Layout: Place components in desired locations, and then route, route, route to make all the desired electrical connections between them.

Verification: Run design rule checks. You need to verify, for example, that routed wires are thick enough, that unconnected wires are not too close together, and that no routing is too close to the board's edge or to holes. Run electrical rule checks to make sure that you didn’t accidentally connect two nodes that should be separate.

Fabricate: Generate the Gerbers and get the board made.

Populate: Solder components to the board. When done, power it up and test it.

Depending on the board, you may do some of the above steps in parallel and/or repeat earlier steps if you find some problem with the design, for example if the components don’t fit in a desired space.

Chip layout vs. PCB layout

The most fundamental way that chip design is different from PCB design is in the purpose of the layout. For PCBs, the "layers" of the layout define the electrical connections between the different components that will be soldered to the board. Some layers define etched copper patterns to form "wires", while other layers define “vias” for electrical contact between layers.

For an example of chip layout, look at the photo on the top of this post for details. On a chip layout, some layers are similarly used to form such electrical connections. Generally these are the “metal” layers with a low resistance, and are often made on the actual chip with aluminum or copper. This appears as "blue" in the above layout. There are also “via” and “contact” layers defining similar connections between layers, visible above as black squares.

However there are other layers that are used to actually form devices when geometric objects are drawn according to well-defined rules. When designing a chip, you not only draw the wiring between transistors, capacitors, and resistors, but you also draw those transistors, capacitors, and resistors themselves.

For example, there is one red layer called “polysilicon” which is a conductor but generally has a higher resistance. If you draw a long, thin wire of polysilicon, you get a resistor. (A long thin wire of metal also gives you a resistor but of much less resistance.) To form a capacitor, you can draw two plates of polysilicon on top of each other, with one plate located on “polysilicon 1” (light red) which is deeper in the chip and the other plate located higher up on “polysilicon 2 (dark red)”. They will be separated by a thin insulator, so that the two plates and insulator form a capacitor. A transistor (such as a MOSFET) can be formed by crossing a polysilicon wire over a box of “active” layer (green). I won’t describe all the possibilities- that could fill a textbooks- but hopefully you get the basic idea.

In other words, the fundamental difference is that on a PCB, the geometric figures you draw define the electrical connections between components, while on a chip, the geometric figures also create the components themselves.

As you can imagine, the “design rule checks” for chips are much more complicated. Fortunately all that is now automated.

Cells

A chip design generally uses a hierarchical structure based on what we call “cells”. A basic cell may be an OR gate, a single capacitor, or a single pixel circuit. Then we can create higher level cells by “instancing” and connecting together existing lower level cells, and optionally adding new layout. For example, a pixel cell may contain a couple transistors and a photodiode, and routing for power line and output. Then a pixel array cell can be constructed from a large 2D array of individual pixel cells. Similarly a flip flop cell can be constructed from a few gates, and a register cell can be constructed from an array of flip flop cells. The “top level cell” would be the whole chip.

This hierarchical structure is analogous to the hierarchical structure of a computer program. You have variables and individual instructions at the bottom level, then lower level functions that use these variables and instructions, higher level functions that call these lower level functions, and finally the “main” function at the top.

In a chip design, the cell structure is present in both the schematic level and the layout. Consider a pixel cell: In the schematic entry software I use, elementary cells like “capacitor”, “resistor”, and “N-type transistor” are already defined. The pictures below show examples. To make a pixel cell I would instance the appropriate components (generally some transistors and a photodiode), draw wires to connect them, and create a “symbol” that represents the pixel cell. Then I would create an associated layout for the cell. This would be a drawing of the different layers (metal, polysilicon, active layer, etc.) that together create the electronic circuitry depicted in the schematic.

Once I have created a cell, I would next “verify” it. This includes running design rule checks such as making sure wires are thick enough and that unconnected wires are not too close (sound familiar?). This also includes other more esoteric design rule checks such as making sure the different layers are properly drawn to form devices like transistors and capacitors. I also run a “layout vs schematic” test to make sure that both the schematic and layout versions of the cell show the same circuit. If needed, I may also perform a circuit simulation (using SPICE) to verify that the circuit should function as I intend. In the SPICE simulation I would present different inputs to the circuit and verify that the simulated output is as expected. For example for a NOT gate I would apply a digital 0 and then 1 and verify that the output was the opposite. I would also verify that the threshold voltage (the crossover from 0 to 1) is appropriate.

Once a cell has been completed, I can then construct and verify higher level cells in the same manner. For example I could create a pixel array by instancing individual pixel cells. I would verify the pixel array cell and move on to the next cells until the chip is finished.

One nice thing about the cell architecture is that once a cell is made, you can reuse it in other chip designs, either verbatim or with some changes. This is much like how you can re-use existing source code to write a new program. Also it is possible to acquire libraries of cells for many common circuits- I never design my own flip flop cells- I used existing flip flop cells that either the CAD tool company or the chip foundry has provided- I not only save time but have the peace of mind of using a cell that I know works.

This ability to reuse cell designs is crucial for reducing design time. My record for designing a chip, start to finish, is three hours sitting in a Dupont Circle coffee house in DC back in 2001. All of the cells were reused, with one or two modified, except for the top level cell which was constructed from scratch. (Yes, that chip did work!)

The three pictures below show sample layout and schematic of pixel cells.

Above: Layout of a single pixel cell. "blue" is the lowest metal layer e.g. metal1, "grey" is the second metal layer e.g. metal2, tan is the third metal layer e.g. metal3. White squares are "vias" between metal layers. The big area with right-hand cross hatches is the "N" side of the photodiode. The "P" side is the chip substrate itself.

Above: Schematic diagram of a single pixel circuit. Node "rowsel" is used to select a row of pixels. Node "out" is the column output. Nodes "prsupply" and "swvdd" are effectively power supplies for the pixel.

Above: 16x16 array of single pixel circuits used to form a 16x16 focal plane array section.

The Indie chip design process:

Now I can summarize the process I use to design a new image sensor chip:

Specification: Typically I would hand draw a few critical items in my notebook. This may be the schematic diagram for individual pixel circuits or related subcircuits. This would also include a specification of the interface, such as how I want the digital signals provided to the chip to control the chip, and the nature of the output (analog, digital, etc.)

Sketching and Research: Next I would sketch out a cell hierarchy for the chip, including initial hand-drawn schematic sketches for the most critical cells and how they interact. I would also look through existing designs and libraries for cells that I can reuse and/or modify.

Design the chip, cell by cell: Next I would go through the process of designing the cells that will make up the chip design. I would start out with the basic cells, construct both layout and corresponding schematic and symbols, and do any verification. Generally I would both create and verify a given cell before moving up the hierarchy.

Redesign: Sometimes it just happens that through the process of designing it you realize that something may not work or fit. In this case you just have to go back and change some aspect of the design.

Padframe: The padframe is a cell that contains all the “pads” which are the electrical contacts between the chip and the outside world.

Top level cell: I would then assemble and verify the top level cell of the chip.

Tape-out and Fab: The term “tape-out” is the chip design equivalent to making Gerber files for a PCB. I think this is an archaic term that comes from a time when the layout files were literally written to magnetic tape that was then mailed out to the fab company. Nowadays of course you just create the layout file and email it in.

Dicing and Packaging: The chips come back in wafers (see this previous post). We send them out to a company to dice them e.g. cut them up into individual dies. Packaging refers to the process of connecting the individual dies to some sort of package that allows you to solder them to a board. You can’t solder directly to the chip (the pads are between 60 and 100 microns wide!) so typically one uses a wire bonding machine to connect the chip to a package with 1-mil thick gold wire. We own a wire bonding machine so we just wire bond the chips directly to a test PC board, in a process described here. Once this is done we can then test the chip to verify it works.

Cost? For a single chip design I’ve spent anywhere from $980 to $58k to get multiple (between 4 and 40) copies of a single chip design made. For wafers I’ve spent anywhere from about $18k to just under $100k to get multiple wafers containing multiple chip designs made, generally yielding four to eight thousand chips. (Note that for a fine-scale digital process used to make current GPUs or CPUs, you can probably spend millions.) As you make more the price drops further. The economies of scale are drastic. I will comment on that in another post.

Time? You can get PCBs made the same day if you really need it. For chips I wait anywhere from 6 weeks to 4 months. Yes, the long wait can make one nervous…

Simplicity and avoiding feature creep

A final thought on the chip design process as I experience it- Simplicity rules! The final part of verifying a chip design is stressful since you really can’t fully verify the chip design, including how the individual cells interact, until you actually fabricate the chip. (Actually for digital circuits the behavior is generally predictable if you use the right practices, but analog circuits are more complicated.) The best I can do until then is to rely on circuit simulations of a limited set of scenarios, along with double, triple, and quadruple checking, and hope that the resulting design works.

So as a result of this, I’ve found that the best habit to have is to be very choosy about what features to include and keep all aspects of the chip (interface, layout, topology, etc.) as simple as possible. The simpler the chip, the easier the layout and the verification, and the less opportunity you have to screw things up! The 80/20 principle is key here- Only include what is necessary. This can be a challenge because we engineers are notorious for saying “hey we can add this feature, and while we’re at it add that one and this other one too”.

In my next post, I'll discuss issues the real issues I face when trying to "open" up chip designs, and how these may be addressed.

Zedstar: The Clashing Rocks

Fri, 19 Aug 2011 23:22:38 +0000

This project is about using embedded Linux devices to detect, record and react to seismic events. The idea is to use accelerometers to detect shaking and then communicate this event to all other devices connected to the same broadcast group. We are developing the technology using OpenWrt which allows us to use a range of hardware including routers and pocket computing devices. We really like the idea of exploring emerging low-powered, low-bandwidth mesh networks in developing countries. In this video you can see some early work using a network of Ben NanoNote computers fitted with WPAN hardware. Three devices are connected to a Spread daemon running on a co-ordinating device. Because our current hardware lacks accelerometers we run a program on one device to send fake accelerometer data onto the network. Each device should then pick up this data across our wireless network. We are currently able to get some basic support for IP networking using a hack by Werner Almesberger who also developed the WPAN hardware. In the video you can see the devices display a bar graph indicating it received data. Only one bar is registered as only one device is transmitting. This bar graph could act as a finger print for deciding the scale of seismic activity in a larger network. We intend to add some more intelligence to this part by building a some kind of knowledge system. Currently the project is at a very early stage with some basic infrastructure developed in C. The aim is to extend this infrastructure by embedding GNU Guile. This will allow us to dynamically control how we communicate, store and process the structured data shared amongst devices. Part of this system will involve trying to minimise the quantity of structured data exchanged on the network by serialising to bit-level using Packedobjects.

Further details of the project can be found at The Clashing Rocks wiki.

Geoffrey L. Barrows - DIY Drones: New Image Sensor Chips for Robotics and Embedded Vision

Wed, 10 Aug 2011 01:56:37 +0000

I just got back some new silicon! These are the latest image sensor chips I designed specifically for robotics and embedded vision applications. The pictures above show a full wafer followed by a close-up of the wafer from an angle. There are four chips in each reticle- if you look closely you can see them packed into a rectangle (about 8.8mm by 7.0mm). Shortly after that picture was taken, we had the wafer diced up into individual chips and started playing with them!

One of the chips is named “Stonyman” and is a 112 x 112 image sensor with logarithmic-response pixels and in-pixel binning. You can short together MxN blocks (M and N independently selected from 1, 2, 4, or 8) of pixels to implement bigger pixels and quickly read out the image at a lower resolution if desired. The interface is extremely simple- there are five digital lines that you pulse in the proper sequence to configure and operate the chip, and a single analog output holding the pixel value. With two power lines (GND and VDD) only eight connections are necessary to use this chip.

Another chip is named “Hawksbill” and is a 136 x 136 image sensor, also with logarithmic response pixels (but no binning) and the same interface as Stonyman. What is different about Hawksbill is that the pixels are arranged in a hexagonal format, rather than a square format like Stonyman and 99% of other image sensors out there. Hexagonal sampling is not conventional, but it is actually mathematically superior to square sampling, and with recent advances in signal processing one can perform many image processing operations more efficiently in a hexagonal array than a square one.

(Above: 8x8 hex pixel layout from CAD tools, Stonyman chip wire bonded to test board- pardon the dust!)

We plan to release the chips in the near future, with a datasheet, sample Arduino script, and (yes!) a schematic diagram of the chip innards. (If anyone *really* wants one now, I can make an arrangement…)

We are also working on a new generation ArduEye sensor shield with these chips. The shield will be matched to an Arduino Mini for small size, and use a 120MIPS ARM for intermediary processing. The design will be “open”, of course. (Note- anyone who purchased an original ArduEye will get a credit towards the purchase of the new version when it comes out.)

(The thrill of getting new chips back is much like that for circuit boards. You designed it, so in theory you know how it works. But you are never 100% sure and there is no datasheet for you to consult other than your own notes or CAD drawings. You are always slightly afraid of getting a puff of smoke when you first power it. No smoke… the circuit breaker didn’t trigger… so all is good. Then you probe it, verify that different portions work as expected, tweak various settings, and finally get it working. The experience is just like that for a PCB except the stakes are higher.)

Qi Hardware: Copyleft Hardware News 2011-08-08

Mon, 08 Aug 2011 08:00:00 +0000

Language:

English ‪中文(台灣)‬

Qi News
RSS Twitter

Copying is an act of love. Please copy & share.
Mimi and Eunice by Nina Paley

Buy

Join the new era of computing, slow fidelity on the freedom channel, and buy the world's best copyleft hardware

Product	Starting At	Shipping
Ben NanoNote	99 USD/EUR	Tuxbrain for Europe Sharism for US/Japan/others
atben-atusb Combo	59 EUR	Tuxbrain
Elphel 353	880 USD	Elphel
Elphel Eyesis	24,000 USD	Elphel

Projects

Homebrew CMOS and MEMS foundry

Andrew Zonenberg sighted The Nyan Cat on silicon!
This Nyanotechnology comes as part of Andrew's homebrew MEMS project by lithographic projection, the world's smallest nyan cat. His next goal is a comb drive. Lab Notes Pictures

The Nyan Cat head at 100x zoom. The entire cat is around 600 microns long and 360 microns high.

The Nyan Cat head at 400x zoom. Pixels are 20 microns square.

The Nyan Cat in the Toped IC layout editor.

Milkymist

Xiangfu Liu made recordings of four Milkymist One patches.

Starfield [57 s, 6.5 MB, download]	The Piper [1:10 min, 12.42 MB, download]
Slow Shift Matrix [1:8 min, 15.28 MB, download]	A Matter of Taste [1:10 min, 22.53 MB, download]

Lars-Peter Clausen and Michael Walle improved Linux 3.0 on Milkymist One. [1]
Lars-Peter Clausen ported an OpenWrt userland to Milkymist One, with static linking and uClibc. [2]
Xiangfu Liu setup daily builds of OpenWrt for Milkymist One. [3]
Lattice Semiconductor released version 3.8 of the Mico32 core, which among small fixes comes with a major cleanup of the licensing header at the top of every source file.
Earlier licensing headers were hard to understand and got some people to doubt the openess of the core. The new headers make the Mico32 core indisputably open source and GPL compatible. Lattice Download Comparison of old and new licensing header
Christopher Adams designed a new Milkymist logo and selected the free Orbitron font for logo and branding.
roh from Raumfahrtagentur engraved a mirror version of the new logo on the inside of the top acrylic for the upcoming RC3 run.

svg pdf

Milkymist One logo on acrylic.

Yi Zhang finished the Milkymist One box design and sent it off to the box makers.

PDF file sent to the printshop, prepared from a Scribus original.

Printed and die-cut box.

Adam Wang continued with Milkymist One RC3 production testing.
All production testing software is free software, results are tracked online.

Thirteen wires in and out of Milkymist One during production testing.

Wolfson Microelectronics' WM9707 audio codec helped reduce audio noise on the Milkymist One RC3 video synthesizer by 90%, from about 500 mV to about 50 mV.
Earlier runs used a National Semiconductor LM4550B codec. [4]
Cristian Paul ported the Namuru GPS correlator to the Milkymist SoC (thanks to Fabrizio Tapper and Peter Mumford for their support).
This core will allow speedup of the correlation process for getting a fix and tracking GPS satellites. Work continues on the OpenSourceGPS receiver which will provide the high level software interface to process the navigation data tracked by Namuru. Namuru port to Milkymist, Namuru datasheet, OpenSourceGPS code repository, OpenSourceGPS documentation
David Kühling helped port the SoftGNSS matlab code to GNU Octave.
This will allow offline analysis of raw data for a variety of GPS front-ends. SoftGNSS repo
Jon Phillips gave a talk about Milkymist One at FISL 12 in Porto Alegre, Brazil (slides of talk below). [5] [6]

Jon Phillips at FISL 12 (July 2, 2011, Porto Alegre, Brazil).
[46:17 min, 78 MB, download]

atben/atusb

Werner finished designing the ben-wpan boards, a set of IEEE 802.15.4 wireless dongles. [7]

Range of ben-wpan boards measured at Werner's apartment in Buenos Aires (dimensions in cm).

Werner wrote documentation and tools for the production and testing process of ben-wpan 802.15.4 boards.
A total of five pages, overview page and four detail pages. Announcement Overview

Production and testing process flowchart.

Tuxbrain produced 135 atben and 117 atusb boards and started selling on June 13.
One month later, David reported sales of 44 atben and 42 atusb boards.

David depanelizing PCBs

atben

atusb

Copyleft Hardware Explained

Werner Almesberger published a two part comparison of Free scripted CAD tools - Part 1, Part2.

Cadmium	CGAL	OpenCSG, showing artefacts
OpenSCAD	OpenSCAD, modeling artefact (internal structure)	OpenSCAD, modeling artefact (reversed face)

The names of component packages are often confusing and vary among manufacturers. This is Werner's first step (for small logic gates) towards a packageology.
Some data sheets don't contain all the information necessary to make Copyleft Hardware. Here is Werner's anatomy of a datasheet.

NanoNote

Jadon Dutra made two nice Ben NanoNote tutorial videos. [8]

Tutorial: Hello World program on Ben NanoNote.
[5:43 min, download 11 MB/52 MB]

Tutorial: How to boot Ben NanoNote into USB mode.
[2:23 min, download 5 MB/38 MB]

Werner published a test point map for the Ben NanoNote. [9]

Ben NanoNote test point map, SoC mappings here

sujan and zedstar took some NanoNotes on a trip to Nepal. We don't really know what happened, but got this nice picture back...

Ben NanoNote in Nepal

OpenLase

David from Tuxbrain found out about OpenLase, an open laser projector started by Hector Martin "marcan".
We are learning about lasers, galvanometers, dichroic mirrors and more now and are evaluating how to make good copyleft hardware out of this one day. Thanks David for bringing this up! OpenLase blog OpenLase sources

OpenLase laser projector.
[2:17 min, 20 MB, download]

OpenLase prototype used in making the video.

Detail of galvo (Galvanometer).

Presentations, Slides, Brochures

Jon,Werner and Sebastien talked about our projects, here's an opportunity to catch up and browse through slide decks, presentations, and a brochure.

Jon's slide deck on Milkymist One

(announcement, video)

Jon's slide deck on Copyleft Hardware

(announcement)

Werner's talk at FISL 12 in Porto Alegre about Copyleft Hardware

(source FISL 12 in Porto Alegre, Brazil)

Sebastien's talk at THSF 2011 in Toulouse about Milkymist One

(source THSF 2011 Toulouse Hacker Space Factory, May 28, 2011)

Sebastien's Milkymist One brochure

(source [10])

A happy continued summer everyone (winter for Werner). Cheers.

--Qi team 08:00, 8 August 2011 (CET)

GNU Radio Blog: Gqrx on Mac OS X (almost)

oz9aec@gmail.com (Alexandru Csete) — Tue, 02 Aug 2011 21:35:44 +0000

Few weeks ago, or maybe a month or two – I don't remember, I spent an afternoon trying to build gnuradio-core and gr-audio on Mac OS X without using any macports. It was a casual an undocumented attempt that resulted in a compilation failure. I wasn't surprised because I made several mistakes along the way, so I just left it an moved on.

Now with the alpha release of gqrx it was time to make another attempt, and this time I tried to do it right I have also documented the whole process. It took me few hours to get through the whole process of compiling the dependencies then GNU Radio, but to my great surprise I actually ended up with a working GNU Radio installation!

I even managed to build and run gqrx as you can see on this twitpic. Since that tweet I even found out that I can simply use the descriptive names as device names, i.e. "FUNcube Dongle V1.0" for the Funcube Dongle. Unfortunately, the OS X audio source seems to have issues with sample rates above 44.1 kHz which makes the gqrx/fcd combination useless for now. The issue is known and has actually been known since 2009.

I hope somebody will be able to fix it because I really don't know anything about OS X audio programming and looking at the source code for the OS X audio source doesn't make me want to learn it either.

Chitlesh Goorah: Swiss wine tasting

Sun, 10 Jul 2011 19:06:30 +0000

Got the opportunity to taste the following Swiss wines :

Aigle, Vieux coucou, Grand Cru, 2010
Aigle, Peau Rouge, Grand Cru, 2010
Aigle, Gamaret, Evionnaz,2010
Aigle, Pinor noir de Chamoson, 2008
Yvorne, Le Florin, sélection Terravin
Chablais, Malvoisie
Chablais, Oeil-de-Perdrix
Ollon, Pinot Noir
Ollon, Rosé de Pinot Noir

Chitlesh Goorah: the missing -ldl

Sun, 03 Jul 2011 13:09:40 +0000

export CFLAGS="%{optflags} -ldl -lpthread"

to fix

/usr/bin/ld: dynload.o: undefined reference to symbol  'dlsym@@GLIBC_2.2.5'
/usr/bin/ld: note: 'dlsym@@GLIBC_2.2.5' is defined in DSO
/lib64/libdl.so.2 so try adding it to the linker command line
/lib64/libdl.so.2: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

FreakLabs: Bob's Energy Vulture

Fri, 01 Jul 2011 18:16:16 +0000

I recently got a very nice surprise in the mail. @wa7iut, aka Bob, from Ambient Sensors (http://www.ambientsensors.com/) sent me one of his latest breakout boards. I've been itching to try out the LTC3108 for a while because it can boost input voltages as low as 20 mV up to a very usable 3.3V. People have been sticking probes into plants to power their sensor nodes using these chips. Bob is well known in the open hardware scene...

Chitlesh Goorah: Restoring Electronics-menu in Gnome3

Sun, 19 Jun 2011 11:01:54 +0000

With Gnome 3 shipped with Fedora 15, the menu “electronics” is no longer available on Fedora 15′s gnome-menu.

It was rather annoying for me, as this custom “Electronics” menu remained the first thing that non-linux users would look at if they want to embrace Free(Fedora) Electronic Lab.

Finally, I found how to fix it. It seems that the directory /etc/xdg/menus/application-merged became /etc/xdg/menus/application-gnome-merged.

$ mkdir  /etc/xdg/menus/applications-gnome-merged
$ ln -s /etc/xdg/menus/applications-merged/electronics.menu /etc/xdg/menus/applications-gnome-merged/electronics.menu

The “electronics-menu” package will soon be updated to reflect this fix on Fedora 15.

Dan Strother: Complete "Cones" disparity map generated by dlsc_stereobm reference algorithm

Sat, 11 Jun 2011 06:26:29 +0000

The first version of my open-source OpenCV-compatible FPGA Stereo Correspondence Core is now available! (have a look at my previous FPGA Stereo Vision Project post for some more context) It’s written purely in synthesizable Verilog, and uses device-agnostic inference for … Continue reading →

Capn's Tech: Playpause 3: Assembly and programming

noreply@blogger.com (Mitch Davis) — Thu, 09 Jun 2011 12:16:06 +0000

So far in this series we have discussed the Playpause concept and design, and how to make PCBs, using Playpause as an example. Now I want to show how to assemble a Playpause, and how to load the software using a bed-of-nails jig.

Surface mount technology is within reach of everyone. There's no special technology being used here. The iron is a normal 25W soldering iron, it's just normal electronics solder, and the soldering in the photos is being done by my 11-yo son, who has barely soldered before. Thanks Tim!

The first thing to start with is the ATtiny85 microcontroller. When I was a lad, we were told to add the semiconductors to our project last, because of the danger of damage from static. The reason I'm putting the microcontroller on first is because we need to program the chip, and the other components can interfere with programming.

Here's a pic of the chip perched on the board. I've lined up the pins with the PCB pads. Since we will first solder just one pad, it's not critical that all pads are lined up, just the corner pad that gets soldered first:

Chip perched on board

Unless the chip is held in position, it is likely to be moved out of place when touched by the soldering iron. A totally excellent way of holding the chip in place during soldering is to use one tine of a small gardening fork, as described by Jonathan Oxer:

Pressure applied with mini garden fork

Next up, soldering the first pin:

Soldering the first pin

The aim is for the soldering iron to touch both the pad and the pin, so both get heated, for about a second. Then lightly feed a little solder onto the joint (not onto the iron) until the solder flows between the pad and pin. Then remove the iron, and allow the molten solder to solidfy. Make sure the joint is not moved until the solder is set. Surface mount components are very small, and don't take well to being heated for long periods, so try to minimise the amount of time they are in contact with the iron.
After the first pin is soldered, you can gently rotate the chip to get all the pins aligned.

One pin soldered, the chip can be aligned

After the pins are aligned, the rest of the pins can be soldered:

Soldering the rest of the pins

Don't worry if you bridge pins with too much solder. In fact, one good way of soldering fine pitch chips is to deliberately use too much solder, then remove the excess with desoldering braid:

Fixing solder bridges with soldering braid

Now that the microcontroller is soldered on, we can program in the firmware. I am using Tom Long's fantastic USBTiny mkII programmer. Also in this picture is a SparkFun AVRStick, which was my original inspiration for both the USB Doodad and Playpause projects. Thanks SparkFun for the AVRStick, and thanks Objective Development for V-USB!

AVRStick and programmer

To program the Playpause, I'm using a “bed-of-nails” made of “pogo pins” to connect the 6 wires of the ISP header to the micro. You can find out more about pogo pins and making bed-of-nails jigs at this SparkFun tutorial.

To line up the pins with the pads on the circuit board, I made a sleeve out of three pieces of cardboard, glued together as a sandwich. Holes drilled in the top piece of cardboard line up with the pads on the PCB. I slide the PCB into the sleeve, then using one hand, I can hold the bed of nails and the sleeve together. With the other hand, I can press Enter on my computer to run the command to copy the firmware to the micro, and set the right fuses (for example, the fuse which turns on the clock PLL that I mentioned earlier).

Playpause with bed of nails. The PCB in this pic doesn't have a chip, but of course for programming it would need to have one.

Programming:

FIXME

The PCB traces at one end of the board are just the right shape to work as a USB connector. But the copper isn't very thin, and if used often, the other part of the connector (the part in your PC) will wear away the copper. To avoid this, you can tin the USB tracks with solder:

Tinning USB connector traces

After the controller is programmed, and the USB traces are tinned, we can add the other components as per this chart:

You can use the gardening fork on all the components except for the diodes, if the diodes are cylindrical. For the diodes, you can ask a friend to hold the diode in position with a small screwdriver.

And now a small admission: When I was copying and pasting the layout to make ten boards, I accidentally deleted a track. That track was omitted on all ten boards I made. So here a small wire is being soldered on to act as the missing track. All the other components have already been soldered.

All passives soldered, doing the switch (extra wire)

When I was developing Playpause, I made a few mistakes in the firmware, which meant I needed to correct and update the firmware. But because I'd already loaded all the components onto the PCB, I couldn't put the PCB back into the programming sleeve. So as an alternative, I direct-wired a 6-pin ISP header to the PCB.

Note that having additional components can interfere with the programmer, but in this case, it seems to work:

Playpause hot-wired to programmer

I made ten of these Playpause boards and took five of them to a friend's place for a craft-and-chat day. Most of the soldering on these boards was done by people who had never done any kind of soldering before, thus proving that surface mount soldering doesn't require any particular skill or dexterity, but just some instruction and guidance.

Five completed playpauses

So, I now have a Playpause to use at work when I'm listening to music, and I can now apply my knowledge of making PCBs and doing bed-of-nails programming to the USB Doodad. Maybe you can too. If you have any questions, or want help making a Playpause or PCBs, ask me.

Capn's Tech: Playpause 1: Design

noreply@blogger.com (Mitch Davis) — Thu, 09 Jun 2011 00:43:58 +0000

Ever needed to quickly pause the music or movie that's playing on your computer? Maybe someone is calling you, or you're trying to listen to something else. Hunting around for the pause button with a mouse takes several seconds. What if you could instantly pause with a single button press?
When a USB Doodad gets shipped to someone, it will have a presoldered AVR chip. Somehow I need to get the bootloader into the AVR chip without soldering anything else to the board. The natural way of doing this is via a bed of nails, as I mentioned in Doodad 4.

I have been messing around with bed-of-nails recently, via a little subproject I've been working on called "Playpause":

On top is the Playpause board.
Below is the board for doing bed-of-nails testing.

While the USB Doodad is designed to be a general purpose reprogrammable device, Playpause just does one job: It is a tiny USB device which pretends to be a HID keyboard. But unlike most keyboards, playpause only knows how to send one keycode: The play/pause keycode you'll get from pressing the play/pause button on a multimedia keyboard. Thus with one of these plugged in, you can play and pause your music or movie player without having to get busy with the mouse. It's small, inexpensive, and easy to build.

(You can find the source code and the KiCad design files here. TODO: I'm currently working out how to do git submodules so I can park the V-USB code inside playpause, because that's how V-USB likes to be used).

Because it sends a standard USB HID Keyboard keycode, PlayPause will work with any operating system, and doesn't need to have drivers installed. (Although at present it doesn't work with the Mac. I wish I knew why).

Playpause uses the V-USB software USB stack. This is a good choice for AVR projects that you want to be USB-capable, even if the AVR micro you're using doesn't have support for USB in hardware. But there's a catch: V-USB implements USB by using software, which means that when processing USB traffic, the micro can't do anything else. In practice, this is fine if the task you want your micro to do isn't timing or latency critical, and for this V-USB works very nicely.

Playpause uses surface mount soldering, and the micro I'm using is the 8-pin ATtiny85 in a SOIC-8 package . The pitch on these pins is less than half of an ATtiny85 in PDIP format, which is why Playpause can be made so conveniently small.

While the USB port provides 5V for your device to run on, the USB signalling is done at 3.3V. This means that every USB project needs to handle this difference somehow. There are two basic ways of doing this. The first is to regulate the 5V down to 3.3V, then feed your micro on 3.3V. This can be done with a linear regulator, or by using the voltage drop across two ordinary diodes. The second is to run your micro at 5V, but clamp the USB signals to 3.3V. This can be done with two 3.6V zener diodes, or I've seen some designs (for example the SparkFun AVRStick) that use the forward voltage drop of blue LEDs. The reason why 3.6V zener diodes are used instead of 3.3V, is that at the frequencies USB runs at, and given the capacitance of a zener diode, the 3.6V zener effectively clamps at 3.3V. For Playpause, I'm taking the second approach, as shown in “solution B” on the V-USB hardware design page.

Playpause has no external crystal or resonator. Instead, the clock for the AVR chip is generated onboard using the ATtiny85's RC oscillator. This presents two problems. The first is that the RC oscillator is uncalibrated, and may not produce the accurate or stable frequency needed to bit-bang USB packets. The second problem is that the minimum frequency at which the controller can run V-USB is 12MHz, which is above the nominal 8MHz of the RC oscillator. How is this situation resolved?

The first problem can be solved by noting that certain parts of the USB protocol take a precise amount of time. The V-USB software in Playpause can count how many CPU cycles this known time period takes, then from this calculate a calibration value for the RC oscillator. That calibration value then makes sure the RC oscillator produces an exact frequency.

The solution to the second problem lies in the ATtiny85's built-in digital PLL. This circuit has a multiply-by-8 function, so that an input of 8.25MHz from the RC oscillator (8MHz but tweaked up a bit via calibration) gets boosted by the PLL to 66MHz. This frequency is then fed through the clock prescaler, which divides it by 4, to give 16.5MHz, which a frequency supported by V-USB. Curiously, only certain Atmel chips have a PLL, including the ATtinyx5, but excluding the ATmegax8 range. Very useful indeed!

Things to do

Macs

For some reason, Playpause currently doesn't work with Mac computers. My Mac-using friends tell me that the Playpause is able to identify itself correctly, but for some reason MacOS doesn't believe it has a driver to handle the multimedia keypresses Playpause is sending. To try to solve this problem, my plan is to plug in a commercial multimedia keyboard, and sniff the codes it sends when the pause button is sent. That's what I originally did when developing the software, but perhaps there's something I missed, particularly in how multimedia keyboards identify themselves. Either way, it seems that only a software change would be needed to fix the problem.

Suspend

The USB standard says that when the computer suspends, USB devices should put themselves into a low power mode. I'm not currently doing that, so my board is using more power than is strictly necessary. To fix this, I'd set up the processor to sleep until a USB interrupt is received, and if it's not the wakeup condition, go back to sleep.

Code cleanup

The code that's in Git is a direct offshoot of my work on the USB Doodad. As such, it's cluttered with a bunch of things which are not relevant to Playpause. Some janitorial work here would be good.

Coming next: Making PCBs at home

Qi Hardware: Copyleft Hardware News 2011-06-01

Wed, 01 Jun 2011 03:00:00 +0000

Copying is an act of love. Please copy & share.
Mimi and Eunice by Nina Paley

Milkymist

We decided to market Milkymist One as a video synthesizer, not interactive VJ station as planned before. Almost everybody on the project felt that video synthesizer would get more people to understand quicker what the product does, and lead them in the right direction with their second question, whereas interactive VJ station would send them in all sorts of different directions.
Yi Zhang took a series of Milkymist One product shots at the Mayray photo studio in Shanghai.

Sebastien and Xiangfu released several Milkymist One software updates. (Sebastien April 6 - v0.3, Xiangfu May 9 - snapshot, Sebastien May 23 - v0.4)

One of many new features and improvements in Milkymist One.

Milkymist One was demoed and used in many places around the world, by Kristian Paul at labSurlab in Medellín/Colombia, Jon Phillips at the 6th Libre Graphics Meeting in Montreal/Canada, guyzmo at a Lua workshop in Paris, Sebastien at PiXXXeL in Amsterdam, Vision-R festival in Paris and the Toulouse Hacker Space Factory.

Milkymist One at labSurlab in Medellín, Colombia, April 7, 2011

Xiangfu Liu added a screenshot feature to Milkymist One, here's a collection of screenshots.

Real-time video synthesis is an exciting feature of Milkymist One. There are still few recordings of performances, because nobody has a VGA grabber, and real-time encoding and streaming into formats such as Ogg Theora or WebM is possible but will require substantial work. Kristian Paul has recorded a small segment with a second video camera... (another one from Sebastien)

Video-in with Milkymist One. [0:27 min, 19.6 MB]

Xiangfu Liu demonstrated Open Sound Control ("OSC") with his Milkymist One. OSC is another promising way to control Milkymist One, with nice clients on popular smartphones and tablets.

Controlling Milkymist One from an Android phone over OSC (Note: video without sound). [0:57 min, 6.5 MB]

Andrew Zonenberg, a PhD student from Rensselaer Polytechnic Institute in New York is embarking on a series of semiconductor DIY experiments and projects. If you are interested in following his work, start with the 5-page long DIY fabrication of microstructures by projection photolitography. Andrew reports about progress in #milkymist on Freenode (webchat, backlog).
Next up on his agenda is the manufacture of a ring oscillator (pictured below) onto a 35 USD 4' ' wafer. If things go well after that maybe a replica of Intel's venerable 4004 CPU.
Andrew will document his entire process publicly, and release all tools under free licenses.

Ring Oscillator

Slashdot carried a post about our soon-to-be launched open CPU - Milkymist. [11]
Sebastien started writing a nice Wikipedia article about the Milkymist project. [12]
Sebastien managed to get a clarification from Google that they are not planning to release open and free sources for their WebM hardware codec. [13]
Two threads on the mailing list discussed plans about adding a MMU to the Milkymist SoC. [14], [15]
Hong Kong based Sharism Ltd, manufacturer of the Milkymist One, sold out its batch of Milkymist One RC2 units. A big THANKS! to all supportive buyers who believed in this product at such an early stage. RC3 will be available soon...
Adam Wang reported on the latest Milkymist One RC3 production status. [16]

NanoNote

Werner Almesberger implemented an external VGA display using the 8:10 memory card slot of his Ben NanoNote. Ben + UBB + a few components = VGA. homepage, mailing list posts: [17] [18], going high-res, DMA and 1024x768, dual-screen, 640x480 without FIFO jitter, productization, dithering

Ben NanoNote and external VGA display. [0:27 min, 4.8 MB]

Slashdot covered Werner's VGA hardware hack (and hackaday, and Dangerous Prototypes).
Werner Almesberger wrote dirtpan, a quick and dirty tool to demonstrate IPv4 over 802.15.4 ben-wpan boards. details

Ben and Ben talking. [3:30 min, 14.9 MB]
(background info: the video was cut using the command-line melt utility from the MTL framework, sound track P97 made with Korg Kaossilator, scripts)

Tuxbrain continued with ben-wpan production, PCBs have been made (see picture), component mounting date (SMT) is scheduled for next week.

Tuxbrain's ben-wpan PCBs.

kyak proposed a Russian keyboard layout for the NanoNote, Jane took it one step further and hacked her keyboard into a Colemak layout! [19]

Russian keyboard layout proposed by kyak.

Fabric paint as adhesive.

Jane's finished Colemak keyboard layout.

viric has been (for a while already) maintaining nanonixos, a Nix package manager based distribution for the Ben NanoNote. [20]
Mark Tuson reported running Debian Wheezy on his NanoNote. [21]
David Kuehling added hardware acceleration to the MPlayer video player, which can now play most files in Ogg Theora and WebM formats up to 320x240 and 30fps, and most audio except for surround-sound. Smaller video files are automatically played back full-screen by using the CPU's hardware-scaler. [22]

Big Buck Bunny from the Blender Foundation running on Ben NanoNote.

Hans Bezemer released 4tH v3.61.1 for the Ben Nanonote. Changelog

4tH on Ben, thanks to Hans Bezemer

Xiangfu Liu released a new OpenWrt 2011-05-28 image for Ben NanoNote. Announcement Changelog

Ben NanoNote OpenWrt 2011-05-28 image after bootup.

--Qi team 03:00, 1 June 2011 (CET)

Ignacio Garcia, dingux.com: New Gemei X760+

noreply@blogger.com (booboo) — Wed, 25 May 2011 16:15:20 +0000

In the comments of the previous post Neno provided the following link:

http://www.it.com.cn/audio/mp4/news/2010/03/10/09/757299_1.html

So I asked ChinaChip. That is the upcoming Gemei X760+ (yes, same name than the old x760+, fun!), and the specs in the linked page are wrong. It's due out by the end of May according to ChinaChip.

It's CC1800 based, same SoC than in the Gemei A330. LCD is 4.3" 480x272. I like the wealth of controls in the lower side.

Unfortunately work on the CC1800 has been slow. It's no fun to write code based on other code with no comments and no programmer's manual, plus I recently got sponsoring for porting dingux to a JZ4755 based device (can't say much about that at the moment), which will be eating up absolutely all of my spare time for the next couple of months. As I already said, I'm not happy being the bottleneck here, so I asked ChinaChip to let me disclose the information they provided on the CC1800 but got no reply, so for now I must honor my promise of keeping the information closed.

Capn's Tech: Rumours of this blog's death are premature

noreply@blogger.com (Mitch Davis) — Thu, 19 May 2011 10:08:58 +0000

Wow, has it really been three months since I last blogged? Hard to believe. I have been so busy hacking on cool stuff. Previously my blog posts have been to demonstrate something, which is all well and good when one has something to demonstrate. I think I might do more blog posts which are stream-of-consciousness.

In particular, the USB Doodad project is not dead. I have been working on it constantly, just not writing about it.

Anyway, expect to see a rash of new articles soon.

Village Telco: AfrikaBurns Again for a Village Telco

Tue, 17 May 2011 16:15:12 +0000

The following is a guest post from Scarborough Mesh pioneer David Carman who set up a Mesh Potato telephone network for the second year at AfrikaBurn.

We headed for Tankwa Town with a full load and empty wallet and flashed & configured the Mesh Potatoes (MPs) in the desert using the good ol’ 192.168 range. The booths were different to last year: they had production MPs, new sleeves and no lighting. I set each node with a different Virtual Access Point (VAP) SSID based on the phone number because I found that using an identical VAP SSID caused SSH to die. This will be ideal in the future, when each MP owner has a WPA key on their router and both cabled and VAP connections are linked to the same account. So any device that wants to roam must either switch between VAPs or run batman itself.

Steve came up for 2 days to help set up and bring some much-needed supplies. I discovered that an Olmeca tequila bottle is not as sturdy as it looks. It broke in the trailer and softened up the Tetrapak milk until most of the cartons ruptured too. So a Nano, a few phones and other gear were swamped. Thanks for the rescue, Steve.

We set up the booths easily this year – far less wiring and better ground pegs. We put phones in the organiser’s caravan, medics and the gate, with a Nano to cover the 5km distance to the gate. However this year they had moved the gate to the end of the airstrip, so it was only 1km away.

I had brought a netbook with broken screen to act as gateway, redirecting all port 80 traffic to a phpbb3 bulletin board with the appropriate DirtyBoard2.0 skin – see http://swug.za.net/phpbb/. I also redirected port 53 to dnsmasq that spoofed the DNS of Top Level Domains (TLDs) to the gateway IP too. These are the kinds of things that naughty people do, but I think it works well for our application. I set each router’s dns as 8.8.8.8 and SIP registration to villagetelco.org. When a mesh is connected to the Internet, DNS & SIP will work fine (once VT has a SIP server). If there is no Internet access, DNS/SIP/HTTP can be fielded by an offline gateway server. It does look a bit odd, but it works.

The spoof gateway was running fine for devices connected to the LAN but was not accessible from the WAN. In fact, no other device connected to a different MP could be seen except for the MP’s LAN address itself. This suggested that there was an issue with the dummy gateway setting on the LAN, required to allow Asterisk to run as per David & Elektra’s discussion

I was 4 days into the trip by then and it was time to party, so I left the gateway for another day – and Internet access. It was most helpful though in checking the booths. Instead of plugging in a netbook, one could just pick a nearby cosy camp, settle down and connect wirelessly. DHCP, LAN bridging, batman routing, Asterisk were all working fine.

Solar operation

This year I invested in a 90W monocrystalline solar panel and regulator for the camp – 90 watts when the sun is shining for the next 25-50 years. It will be part of my home solar office in a few weeks. I had 4 105AH tractor batteries from last year and connected the gateway netbook and the fixed one (20-40W each), plus about 20W of lighting and didn’t have a power problem for the whole week.

We used the 10W flexible solar panels and 12AH batteries on the booths as with last year, but this time there was no lighting in the booths. 10W kept the booth MPs up throughout the week, but the batteries drained progressively. I put this down to the number of phone calls being made – nearly all the time, day & night. One booth’s phone was left off-hook providing dialtone for a few hours. I disconnected it for a charge back at camp and it was sorted. Perhaps a dialtone hangup can be written into Asterisk for such events on battery-powered phones.

I also installed a phone in a friend’s art car, connected to the cigarette lighter adapter. It was great to be able to phone the art car from anywhere and ask for a pick-up. However next year, I’ll bring along some battery clips so that the phone stays on when the car is off – see whether the MP can “survive the crank”.

Conclusion

This year was tougher with just Steve and I setting up, but easier because of the work we could build on from last year. The most promising result from this year were that the phones worked and worked hard. It gave me some time to work towards the 4093-node, no-NAT VAP firmware I long for. Although the VAP was not feeding into the gateway, every person with a wifi-enabled laptop or phone saw hotspots – so hopefully they’ll be better prepared next time too. Comments from participants were different this year too. Last year the phones were a novelty; this year people were more interested in and supportive of the technology behind the phones.

This year I met some important people for next year. Adriaan Wessels is the technical chap on the organising committee. For next year, we’ll be able to plan carefully regarding gate link and possibly organiser car links. Organiser confidence in the network will mean that they will be able to pre-announce a “Tankwanet” and its services so that participants can be better prepared to take advantage. There are a lot of IT geeks at Afrikaburn. Perhaps some of them could be persuaded to offer services on the network.

Rod Bracher runs the Tankwa Town post office, Burning Mail. They have some old rotary-dialling phones that they connect with carrier but without dialling. I tried to coordinate with him to hook his phones up to the network, but ran out of time. We had a chat about doing so at this burn, so pulse-dialling is definitely on for next year.

The streaming services company antfarm.co.za were at AfrikaBurn this year. I couldn’t spot their VSAT dish, but made brief contact. They were streaming the burns live, which led me to figure a rule at AfrikaBurn: the isolation is an important part of the event, but the isolation need only exist one way – incoming. So theoretically, participants should be able to send SMSs, update their twitter accounts and post on a forum on the Internet – as long as they don’t see any response from outside the burn. Antfarm’s ISP only allows Internet connection on port 80, so a little port jiggling and a helpful Internet server should squeeze whatever we need through, except for multiport SIP.

Lastly and simply, Isigidimi was at AB2011. The continuity will help us attract more participants next year, and perhaps more of the VT-dev community. You can set up an Asterisk service, website, jabberd, tinker with pulse-dialling, or just sip on the Kool Aid and be inspired ;^)

Here are some more images from Afrikaburn 2011

Ignacio Garcia, dingux.com: A320 back to production

noreply@blogger.com (booboo) — Wed, 27 Apr 2011 12:32:58 +0000

It could be infered from the fact that support for a new LCD type was implemented, but I just got confirmation from ChinaChip.

Village Telco: Small Enterprise Campus Network (SECN)

Mon, 25 Apr 2011 11:10:01 +0000

Meet Terry Gillett. Terry joined the Village Telco community early this year and purchased a couple of Mesh Potatoes. He immediately saw the opportunity that Mesh Potatoes might have for smaller networks such as a campus or small firm. However, the existing firmware for Mesh Potato was very focused on voice communication in a structured Village Telco environment. Of course it is possible to configure Mesh Potatoes in a 100 different ways but those alternative configurations can be somewhat arcane and a real barrier to alternative uses of the Mesh Potato.

Setting “smart defaults” is a key to masking complexity and lowering the barrier to uptake. Think of Google’s search minimalism after Altavista et al or Apple’s simplification of so many applications that were filled with twiddly knobs, checkboxes, and radio buttons in other operating systems that shall remain nameless. Wordpress is another great example of an application that is capable of impressive sophistication for “blogging software” yet pretty much “just works” after completely a bare minimum of setup information. Terry has taken us one giant step closer towards WordPress-like usability with his Small Enterprise – Campus Network (SECN) setup for Mesh Potatoes.

His goal to be able to serve a local network of modest size offering seamless voice and data. He wanted any Mesh Potato to pick up Internet connectivity via the ethernet port, if it could find it, and for each Mesh Potato to offer a local WiFi access point. After experimenting a little bit, he chose to install the BATMAN-ADV mesh protocol instead of BATMAN protocol we currently use. The big difference between the two protocols is that BATMAN-ADV runs at Layer 2 and BATMAN at Layer 3 of the OSI layer model. What does that mean? Well the simplest explanation is that BATMAN-ADV makes Mesh Potatoes behave as if they were all part of one big network switch which means that IP addressing and routing for the network is dramatically simplified as each Mesh Potato is effectively transparent to the IP network. This effectively removes the hassle of figuring out network addressing and Network Address Translation for Mesh Potatoes. Everything is just one flat network which means that devices can easily communicate with each other on the network. The flip side of this is that you have to be careful about what you put on the network because a poorly configured or worse infected computer can generate a lot of local network traffic. This is something we’re exploring but for a small network, BATMAN-ADV seems to work exceedingly well.

With Terry’s modifications, an SECN configured Mesh Potato network will now:

offer an encrypted, WPA-enabled, wireless access point as well as a peer-to-peer wireless connection on each mesh Potato. This is done by creating a Virtual Access Point (VAP) on the same radio interface as the mesh. Initially we chose not to enable this by default on the core Mesh Potato distribution because we were concerned about network data load have an impact on voice quality but Terry’s work makes me think that this was a mistake. Much better to encourage use and solve the problem of over-use rather than ensure a functional but underused network;
pick up a network connection from any DHCP-enabled Internet-connected device it is connected to the ethernet port on the Mesh Potato;
transparently carry DHCP requests over the network to devices connected to Mesh Potatoes whether by ethernet or WiFi; and,
offer simple on-network and also VoIP service provider configurable phone calling. Local phones can be dialed simply by entering the last 3 digits of the IP address of the Mesh Potato you want to call or the Mesh Potatoes can be registered with any VoIP service provider.

The long and short of this is that if you plug in a bunch of SECN-configured Mesh Potatoes and make sure at least one is connected to something simple like a DHCP-enabled ADSL router, then you have a transparent, highly-adaptable technology for creating a robust local telephone and data network with no wires.

So, did Terry do this all by himself? Without Terry’s interest and hard work at testing, reconfiguring, debugging the SECN version might never have happened but one of the great things about Open Source is that one is rarely starting from scratch. He was able to build on the configuration that Elektra built for the Mesh Potato which in turn built on great Open Source initiatives like OpenWRT, Asterisk, and others. And at least a dozen people in the Village Telco community were there to help him solve problems and answer questions. Better still his work inspired others to try out new configurations with the Mesh Potato and Elektra was inspired to take the set of instructions that he had developed and embed them in a new Mesh Potato firmware distribution that people can use to set up smaller Village Telco networks to serve both voice and data.

If you’re interested in trying this out yourself, you’ll need a few Mesh Potatoes to start and then you’ll want to download the latest SECN firmware and flash the Mesh Potatoes with this new firmware. Terry has been developing the documentation for the SECN, the latest version of which is here. Because this is still at an early stage, that URL may change. Best to check in with the Village Telco google group to find the latest version.

Gerard Braad: Simple Bugzilla client

noreply@blogger.com (gbraad) — Sat, 23 Apr 2011 14:12:47 +0000

At the moment I work as an IT Consultant on a QA-related project in Beijing at an outsourced partner. As you might know, the Internet connectivity in China is not optimal and this caused some issues on our end. Since we have to do a lot of cross-checking, we needed a way to keep track of remotely reported bugs and store these in a local instance of a previously in-house developed cross-check tracker. I started to develop a simple client to pull information from the remote Bugzilla instance which is then stored locally. This solved most of the issues we encountered with the latency and improved the productivity of our team.

XML-RPC client
The local tracker is built in PHP, so at first a small prototype was built to see if it was possible to call Bugzilla's XML-RPC interface. To ease the development I chose to use the standard ZendFramework library and the XML-RPC client they offer, Zend_XmlRpc_Client. The biggest issue I encountered was the way authentication was implemented on the remote side, but the actual client was simple and very easy to implement. The prototype was first done in a very sequential way... and eventually after a little bit of refactoring this is what remained:

// Add the AutoLoader
require_once('Zend/Loader/Autoloader.php');
Zend_Loader_Autoloader::getInstance();

class BugzillaClient
{
  // Initialize the client
  protected $rpcClient = null;
  protected $basUrl = null;

  public function __construct($baseUrl, $username, $password)
  {
       $this->baseUrl = $baseUrl;    // Store internal for later use
       $this->rpcClient = new Zend_XmlRpc_Client($baseUrl . "/xmlrpc.cgi");

       $httpClient = $this->rpcClient->getHttpClient();
       $httpClient->setCookieJar();  // Needed to retain user cookie
       $httpClient->setAuth($username, $password, Zend_Http_Client::AUTH_BASIC);

       // Login request (XMLRPC)
       $response = $this->rpcClient->call('User.login', array(array(
           'login'    => $username,
           'password' => $password,
           'remember' => 1
       )));
  }

  public function __destruct()
  {
       // Logout request (XMLRPC)
       $response = $this->rpcClient->call('User.logout', array());
  }

  public function Get($id)
  {
       $returnValue = array();

       // Get request (XMLRPC)
       $response = $this->rpcClient->call('Bug.get', array(array('ids' => $id)));
       $index = 0; // Only retrieving one bug, so don't bother with index now

       $returnValue['id'] = $id;
       // Construct a remote URL
       $returnValue['url'] = $this->baseUrl . "/show_bug.cgi?id=" . $id;
       // Collect some basic information about the bug
       $returnValue['summary'] = $response['bugs'][$index]['summary'];
       $returnValue['status'] = $response['bugs'][$index]['status'];
       $returnValue['resolution'] = $response['bugs'][$index]['resolution'];

       // Comments request (XMLRPC)
       $response = $this->rpcClient->call('Bug.comments', array(array('ids' => $id)));
       // Extract the first comment from the bug and store as description
       $returnValue['description'] = $response['bugs'][$id]['comments'][0]['text'];

       return $returnValue;
   }
}

This code provides a constructor which does the login and a 'Get' function to query the remote instance.

Example
To use this client you just need to include this module and create a new BugzillaClient instance.

require_once('config.php');          // Contains the baseUrl and credentials
require_once('BugzillaClient.php');  // This is the client code

$bzClient = new BugzillaClient($bzBaseUrl, $bzUsername, $bzPassword);
$bug = $bzClient->Get($id);

echo $bug['summary']);

After this the summary will be printed.

Future work
The last time I did some actual development with PHP was during PHP 3 and the move to PHP 4. At that moment I was not so happy with the Object Orientation model that the language offered. Luckily this improved a lot and hope this code testifies of that... as I have seen some horrific spaghetti code during these several days.

Using this solution does not provide a complete up-to-date picture of the bug, but this is not a problem to us. Besides, triggering a script which iterates over all local bugs and queries the remote state solved this issue. Some more features will be implemented, like searching for bugs and pushing comments back. This basic implementation code has been posted to public git repositories, so fork it and start pushing your improvements.

Repositories

Ignacio Garcia, dingux.com: Support added for new LCD type (ILI9338)

noreply@blogger.com (booboo) — Thu, 21 Apr 2011 20:38:21 +0000

A couple of maintenance releases, which basically boild down to the addition of support for a new LCD type, ILI9338. The support was implemented and tested by ChinaChip, I just prepared the dual boot installer and added the new zImage to the old system package.

Check out the google code downloads page here.

Capn's Tech: USB Doodad 6: Bootloader

noreply@blogger.com (mjd) — Thu, 14 Apr 2011 16:22:56 +0000

Now that we know USB is working, it's time to get the bootloader working. The bootloader is called "bootloadHID", and can be found here:

http://www.obdev.at/products/vusb/bootloadhid.html

I downloaded bootloadHID and extracted it:

[mjd@onza src]$ wget -q http://www.obdev.at/downloads/vusb/bootloadHID.2010-07-29.tar.gz
[mjd@onza src]$ tar -xzf bootloadHID.2010-07-29.tar.gz
[mjd@onza src]$

I have made some changes to the bootloader source and config:

We're using different pins for the USB.
I want the LEDs to blink to show something's happening. The blinking is different depending on whether the bootloader is in program mode, or has handed control to the application.
Our bootloader program mode switch is connected to an analog input rather than a digital input. Therefore I had to add code to read an analog value.
Once the bootloader is in program mode, I want it to stay in program mode after the button is released. (In the stock code, you have to hold down the button constantly in order to program the MCU).
I've changed the MCU type, the fuses, the execution start address and the right command to run avrdude for my USB programmer:

--- bootloadHID.2010-07-29.orig/firmware/bootloaderconfig.h
+++ bootloadHID.2010-07-29/firmware/bootloaderconfig.h
@@ -43,7 +43,7 @@
/* This is the port where the USB bus is connected. When you configure it to
* "B", the registers PORTB, PINB and DDRB will be used.
*/
-#define USB_CFG_DMINUS_BIT      0
+#define USB_CFG_DMINUS_BIT      3
/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
* This may be any bit in the port.
*/
@@ -106,6 +106,7 @@
#ifndef __ASSEMBLER__   /* assembler cannot parse function definitions */
#include <util/delay.h>

+#if 0
static inline void bootLoaderInit(void)
{
     PORTD = 1 << 3; /* activate pull-up for key */
@@ -113,6 +114,7 @@
}

#define bootLoaderCondition()   ((PIND & (1 << 3)) == 0)   /* True if jumper is set */
+#endif

#endif

--- bootloadHID.2010-07-29.orig/firmware/main.c
+++ bootloadHID.2010-07-29/firmware/main.c
@@ -81,8 +81,15 @@

static void (*nullVector)(void) __attribute__((__noreturn__));

+static inline void setLed(const int i)
+{
+    PORTC &= ~(_BV(PC0) | _BV(PC1) | _BV(PC2) | _BV(PC3));
+    PORTC |= i & (_BV(PC0) | _BV(PC1) | _BV(PC2) | _BV(PC3));
+}
+
static void leaveBootloader()
{
+    setLed(15);
     DBG1(0x01, 0, 0);
     cli();
     boot_rww_enable();
@@ -215,9 +222,68 @@
     sei();
}

+#define ADC_CHANNEL                    6
+#define ADC_ENABLED                     (1 << ADEN)
+#define ADC_SINGLE_CONVERSION           (0 << ADATE)
+#define ADC_CONV_COMPLETE_INTR_OFF      (0 << ADIE)
+#define ADC_PRESCALE_128                ((1 << ADPS2) | (1 << ADPS1) | (1 << ADPS0))
+#define ADC_REFERENCE_AVCC              (0 << REFS1 | 1 << REFS0)
+#define ADC_RIGHT_ADJUSTED              (0 << ADLAR)
+#define ADC_START_CONV                  (1 << ADSC)
+#define ADC_CONV_IN_PROGRESS            (1 << ADSC)
+#define ADC_CONV_INTFLAG                (1 << ADIF)
+
+static inline void ADC_Init()
+{
+    // Write 0 to power up ADC, 1 to power down
+    PRR &= ~PRADC;
+
+    ADCSRA = ADC_ENABLED | ADC_SINGLE_CONVERSION | ADC_CONV_COMPLETE_INTR_OFF | ADC_PRESCALE_128;
+
+    ADMUX = ADC_REFERENCE_AVCC | ADC_RIGHT_ADJUSTED | ADC_CHANNEL;
+
+    _delay_us(10); /* wait for levels to stabilize */
+}
+
+static inline uint16_t ADC_Read()
+{
+    // TODO: Start conversion with ADSC=1
+    ADCSRA |= ADC_START_CONV;
+
+    // Wait for the conversion to complete
+    while (ADCSRA & ADC_CONV_IN_PROGRESS)
+        ;
+
+    ADCSRA |= ADC_CONV_INTFLAG;
+
+    return ADC;
+}
+
+static inline void ADC_StopReading()
+{
+    // ADEN in ADSRA enables ADC
+    ADCSRA &= ~ADEN;
+}
+
+static inline void bootLoaderInit(void)
+{
+    ADC_Init();
+}
+
+static inline char bootLoaderCondition()
+{
+    uint16_t v = ADC_Read();
+
+    ADC_StopReading();
+
+    return v < 512;
+}
+
int __attribute__((noreturn)) main(void)
{
     /* initialize hardware */
+    DDRC |= _BV(PC0) | _BV(PC1) | _BV(PC2) | _BV(PC3) | _BV(PC4) | _BV(PC5);
+    PORTC = _BV(5);
     bootLoaderInit();
     odDebugInit();
     DBG1(0x00, 0, 0);
@@ -229,7 +295,14 @@
         GICR = (1 << IVSEL); /* move interrupts to boot flash section */
#endif
         initForUsbConnectivity();
+        unsigned int a = 0;
+        unsigned int b = 0;
         do{ /* main event loop */
+            if (++a == 32)
+            {
+                a = 0;
+                setLed(++b >> 11);
+            }
             wdt_reset();
             usbPoll();
#if BOOTLOADER_CAN_EXIT
@@ -243,7 +316,7 @@
                 }
             }
#endif
-        }while(bootLoaderCondition());
+        } while(1);
     }
     leaveBootloader();
}
--- bootloadHID.2010-07-29.orig/firmware/Makefile
+++ bootloadHID.2010-07-29/firmware/Makefile
@@ -14,11 +14,11 @@
#     make flash   # to load the boot loader into flash
#     make lock    # to protect the boot loader from overwriting

-DEVICE = atmega8
-BOOTLOADER_ADDRESS = 1800
-F_CPU = 12000000
-FUSEH = 0xc0
-FUSEL = 0x9f
+DEVICE = atmega328p
+BOOTLOADER_ADDRESS = 7800
+F_CPU = 16000000
+FUSEH = 0xda
+FUSEL = 0xff
# Fuse high byte:
# 0xc0 = 1 1 0 0   0 0 0 0 <-- BOOTRST (boot reset vector at 0x1800)
#        ^ ^ ^ ^   ^ ^ ^------ BOOTSZ0
@@ -38,7 +38,7 @@

###############################################################################

-AVRDUDE = avrdude -c stk500v2 -P avrdoper -p $(DEVICE)
+AVRDUDE = avrdude -c avrisp2 -P usb -p $(DEVICE)

LDFLAGS += -Wl,--relax,--gc-sections -Wl,--section-start=.text=$(BOOTLOADER_ADDRESS)

A note about the changes to the Makefile:

"BOOTLOADER_ADDRESS = 7800": This is the start address of the bootloader. There's 2k (0x800) bytes of program space allocated for the bootloader and the '328 has 32k (0x8000) bytes of program flash. So the start of the bootloader is at 0x8000 - 0x800 = 0x7800.

"FUSEH = 0xda": For the blinkenled and the mouse demo, the high fuse was set to the '328's default of 0xd9. With this fuse setting, execution will start at address 0. In order to jump to the bootloader, we want to enable (=0) the BOOTRST fuse, and set the size of the bootloader to be 2048 bytes = 1024 words, and the start address to be 0x3C00 words = 0x7800 bytes. (This use of words and bytes is quite confusing. In the AVR and gcc world, some values are given in bytes and some are given in words. I've had several puzzling moments getting all this straightened out...)

Once again I looked up the fuse calculator:

http://frank.circleofcurrent.com/fusecalc/

Making these changes gives a high fuse value of 0xda.

Ok, back to the patch:

[mjd@onza src]$ cd bootloadHID.2010-07-29
[mjd@onza bootloadHID.2010-07-29]$ patch -p1 < ../bootloadHID.2010-07-29.diff
patching file firmware/bootloaderconfig.h
patching file firmware/main.c
patching file firmware/Makefile
[mjd@onza bootloadHID.2010-07-29]$

Then I compiled the software:

[mjd@onza bootloadHID.2010-07-29]$ cd firmware
[mjd@onza firmware]$ make
avr-gcc -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -Iusbdrv -I. -mmcu=atmega328p -DF_CPU=16000000 -DDEBUG_LEVEL=0 -x assembler-with-cpp -c usbdrv/usbdrvasm.S -o usbdrv/usbdrvasm.o
avr-gcc -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -Iusbdrv -I. -mmcu=atmega328p -DF_CPU=16000000 -DDEBUG_LEVEL=0 -c usbdrv/oddebug.c -o usbdrv/oddebug.o
avr-gcc -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -Iusbdrv -I. -mmcu=atmega328p -DF_CPU=16000000 -DDEBUG_LEVEL=0 -c main.c -o main.o
usbdrv/usbdrv.h:213: warning: 'usbFunctionDescriptor' used but never defined
usbdrv/usbdrv.h:220: warning: 'usbSetInterrupt' declared 'static' but never defined
avr-gcc -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -Iusbdrv -I. -mmcu=atmega328p -DF_CPU=16000000 -DDEBUG_LEVEL=0 -o main.bin usbdrv/usbdrvasm.o usbdrv/oddebug.o main.o -Wl,--relax,--gc-sections -Wl,--section-start=.text=7800
rm -f main.hex main.eep.hex
avr-objcopy -j .text -j .data -O ihex main.bin main.hex
avr-size main.hex
text data bss dec hex filename
0 1926 0 1926 786 main.hex
[mjd@onza firmware]$

The warnings don't seem to matter, and I have ignored them.

Now I can program the Doodad:

[mjd@onza firmware]$ su
Password:
[root@onza firmware]# make flash
avrdude -c avrisp2 -P usb -p atmega328p -U flash:w:main.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "main.hex"
avrdude: writing flash (32646 bytes):

Writing | ################################################## | 100% 0.60s

avrdude: 32646 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex contains 32646 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 8.67s

avrdude: verifying ...
avrdude: 32646 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

[root@onza firmware]# make fuse
avrdude -c avrisp2 -P usb -p atmega328p -U hfuse:w:0xda:m -U lfuse:w:0xff:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: reading input file "0xda"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xda:
avrdude: load data hfuse data from input file 0xda:
avrdude: input file 0xda contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xff"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xff:
avrdude: load data lfuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

[root@onza firmware]#

Let me explain my strategy regarding the LEDs. My changes mean that the bootloader lights up the last LED, and the mouse demo lights up the second last LED. Both programs also run a binary counter on the next four LEDs.
If the last LED is on, it means that the bootloader has run. If the second last LED is on, it means the mouse demo has run. After programming the Doodad as above, the bootloader LED is on, but the mouse demo LED isn't. That makes sense because programming the bootloader erases all memory. Note also the four LEDs before the mouse demo LED are all on. That tells me the bootloader tried to jump to the mouse demo.

Also, when I run the lsusb command, I can't see any USB devices corresponding to the Doodad.

Next, pull out the Doodad and insert it with the button held down. The bootloader LED is on, the mouse demo LED is on, and the next four LEDs are running a binary counter. That tells me the bootloader is in program mode. lsusb also shows this:

⋮
Bus 003 Device 010: ID 16c0:05df VOTI
⋮

Later on I'll show how to program an application such as the mouse demo over USB, but for the moment I want to prove that I can load the mouse demo and the bootloader into memory at the same time, and that the bootloader will fall through to the mouse demo if the bootloader button isn't pressed when the Doodad first starts.

So far, whenever avrdude has programmed the '328 program flash, that memory has first been erased. The problem with this is that it erases any existing program.

In order to get both the bootloader and the mouse demo in flash at the same time, we need to program the bootloader with a flash erase, then program the mouse demo without erasing the flash. (Note, the only time you can load a program with the programmer without doing an erase is if you're loading into memory which has already been erased).

Erase the flash

--- vusb-20100715-orig/examples/hid-mouse/firmware/Makefile
+++ vusb-20100715/examples/hid-mouse/firmware/Makefile
@@ -11,7 +11,7 @@
F_CPU = 16000000 # in Hz
FUSE_L = 0xff# see below for fuse values for particular devices
FUSE_H = 0xda
-AVRDUDE = avrdude -c avrisp2 -P usb -p $(DEVICE) # edit this line for your programmer
+AVRDUDE = avrdude -c avrisp2 -P usb -p $(DEVICE) -D # edit this line for your programmer

CFLAGS = -Iusbdrv -I. -DDEBUG_LEVEL=0
OBJECTS = usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o main.o

And if that wasn't impressive enough, After I plugged it into my computer's USB port, the mouse cursor started moving around in a large circle, and the LEDs are counting!
Here's what lsusb shows:

[root@onza mjd]# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 1a40:0101 TERMINUS TECHNOLOGY INC.
Bus 001 Device 003: ID 0951:1607 Kingston Technology Data Traveler 2.0
Bus 001 Device 004: ID 0951:1607 Kingston Technology Data Traveler 2.0
Bus 001 Device 005: ID 0951:1607 Kingston Technology Data Traveler 2.0
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 16c0:03e8 VOTI free for internal lab use 1000

The mouse is the "VOTI" entry. The USB vendor ID and product ID can be set in the software.

Now to see the details:

[root@onza mjd]# lsusb -v

Bus 003 Device 002: ID 16c0:03e8 VOTI free for internal lab use 1000
Device Descriptor:
bLength                18
bDescriptorType         1
bcdUSB               1.10
bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass         0
bDeviceProtocol         0
bMaxPacketSize0         8
idVendor           0x16c0 VOTI
idProduct          0x03e8 free for internal lab use 1000
bcdDevice            1.00
iManufacturer           1 obdev.at
iProduct                2 Mouse
iSerial                 0
bNumConfigurations      1
Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              400mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.01
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      52
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81 EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008 1x 8 bytes
        bInterval             100
Device Status:     0x0000
(Bus Powered)
⋮
[root@onza mjd]#

I'm not sure why it says the report descriptors are unavailable. But at least it works.

Now I'll start working on the bootloader. If I can get the bootloader working, I can take the three pins we're currently using for ISP, and make them LED outputs.

To be covered in the next article:

How to use the bootloader to program new apps to the Doodad without using an ISP.
How to use fuses to protect the bootloader.

Capn's Tech: USB Doodad 4: Blinkenleds

noreply@blogger.com (mjd) — Tue, 12 Apr 2011 21:31:03 +0000

Progress on the USB Doodad has been going well with several successes.
After soldering on the processor, I added the reset pullup resistor, and rigged up a 6-pin programming header on the end of the board.

(Note this is a prototype at a later stage)

There's no permanent position for a programming header on the board. This is because once the board has a bootloader, loading software on the Doodad will be done over USB. Our plan is to use pogo pins to make a "bed of nails" that we can temporarily sit the Doodad board on to get the bootloader into it.

I plugged the Doodad into my programmer, and plugged the programmer into my PC. There was no smoke (!), and the avrdude program could recognise the '328! That's always a good sign.

[root@onza mjd]# /usr/bin/avrdude -c avrisp2 -P usb -p m328p -q

avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x1e950f

avrdude: safemode: Fuses OK

avrdude done. Thank you.

[root@onza mjd]#

I then soldered a LED and a dropper resistor onto the pin for bit 5 of port C, searched for a simple "blinkenled" program on the 'net, and compiled it for the '328:

[mjd@onza 328hello]$ cat hello.c
#include <avr/io.h>
#include <util/delay.h>

int main()
{
    // Set bit 5 of port C to be an output
    DDRC |= _BV(PC5);

    while (1)
    {
        // Invert the value of pin 5 on port C
        PORTC ^= _BV(PC5);
        _delay_ms(500);
    }
}

[mjd@onza 328hello]$ avr-gcc -Os -DF_CPU=8000000 -mmcu=atmega328p -o hello.o -c hello.c
[mjd@onza 328hello]$ avr-gcc -Os -DF_CPU=8000000 -mmcu=atmega328p -o hello.elf hello.o
[mjd@onza 328hello]$ avr-objcopy -O ihex hello.elf hello.hex
[mjd@onza 328hello]$ ls -l hello.hex
-rw-rw-r--. 1 mjd mjd 582 2010-11-21 14:52 hello.hex
[mjd@onza 328hello]$

I then programmed it into the '328:

[root@onza 328hello]# /usr/bin/avrdude -c avrisp2 -P usb -p m328p -U flash:w:hello.hex
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "hello.hex"
avrdude: input file hello.hex auto detected as Intel Hex
avrdude: writing flash (200 bytes):

Writing | ################################################## | 100% 0.08s

avrdude: 200 bytes of flash written
avrdude: verifying flash memory against hello.hex:
avrdude: load data flash data from input file hello.hex:
avrdude: input file hello.hex auto detected as Intel Hex
avrdude: input file hello.hex contains 200 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.06s

avrdude: verifying ...
avrdude: 200 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

[root@onza 328hello]#

Yay, the LED blinks! But there's a slight problem: The LED should blink once a second, but I found it was actually blinking once every eight seconds. This is because by default, there's a fuse in the '328 which divides the clock by 8.

AVR chips have a few bytes of persistent memory called "fuses". The bits in these fuses control things such as what source the chip uses for clock, and what areas of memory are protected. The name for the fuse that's dividing the clock by 8 is called CKDIV8.

Here's how I retrieved the fuse values:

[root@onza 328hello]# /usr/bin/avrdude -c avrisp2 -P usb -p m328p -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude> dump lfuse
0000 62                                               |.               |

avrdude> dump hfuse
0000 d9                                                |.               |

avrdude> dump efuse
0000 07                                                |.               |

avrdude> quit

avrdude: safemode: Fuses OK

avrdude done. Thank you.

[root@onza 328hello]#

I then looked up an AVR fuse calculator:

http://frank.circleofcurrent.com/fusecalc/

Turning off the CKDIV8 fuse means the "low fuse" value changes from 0x62 to 0xE2. The fuse calculator also helpfully shows the avrdude parameters to make this change:

[root@onza 328hello]# /usr/bin/avrdude -c avrisp2 -P usb -p m328p -U lfuse:w:0xE2:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: reading input file "0xE2"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xE2:
avrdude: load data lfuse data from input file 0xE2:
avrdude: input file 0xE2 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

I can then check that the fuse programming has worked:

After doing this, the LED flashes once per second.

At this point, the '328's clock is being provided from an internal oscillator. The internals oscillator is convenient if you want to keep the number of parts on the board to a minimum, but the frequency can drift with temperature, so it's not a great choice for a USB device. So my next step was to solder on a quartz crystal and the two associated capacitors.

Back in the fuse calculator, I used the pull-down menu in the "low fuse presets" to choose "Ext. Crystal Osc.; Frequency 8.0- MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms; [CKSEL=1111 SUT=11]". That makes the low fuse value 0xFF. So I programmed that in using avrdude as above:

[root@onza 328hello]# /usr/bin/avrdude -c avrisp2 -P usb -p m328p -U lfuse:w:0xff:m

⋮
⋮
⋮

avrdude done. Thank you.

The LED is now flashing, but it's twice as fast as it should be. This is because when I compiled the code, I said the clock frequency was 8MHz, to match the internal oscillator. That's not going to work very well with a 16MHz external crystal. So I recompiled the code:

[mjd@onza 328hello]$ avr-gcc -Os -DF_CPU=16000000 -mmcu=atmega328p -o hello.o -c hello.c

I won't show the linking and .hex file creation steps as they're the same as above, but after reprogramming the '328, the LED now blinks at 1Hz.

So, I have a board on which I can run software, and the means to program it. Winnage!

Andrew Zonenberg, Silicon Exposed: Wet etching process

noreply@blogger.com (Andrew Zonenberg) — Fri, 18 Mar 2011 20:08:34 +0000

My preferred method for delayering chips is wet etching in dilute hydrofluoric acid (HF), commonly available in grocery stores as Whink brand rust remover:

~2% technical grade HF from Price Chopper

As the MSDS makes quite clear, this stuff is not something you want to splash on your hands (or skin in general). While it's extremely dilute compared to the 45% concentrated solution used in some laboratories, I've been through the HF safety talk at my school's cleanroom enough times that I'd rather not take chances.

I have a pair of Norfoil (Silver Shield) gloves around that I use for this kind of work. They're rather stiff so a common practice to improve dexterity is to double-glove with an XL nitrile glove over the Norfoil. When combined with a lab coat, splash goggles, and a face shield there's little chance of anything getting through.


Nitrile outer glove (blue) over Norfoil glove (silver), tucked into sleeve of Tyvek lab coat (white)

My standard lab PPE

Before getting dressed I placed a 10 ml beaker of distilled water on my hot plate and preheated it to a warm but not boiling temperature (exact temp isn't critical).

The next step is to pour a bit under 1 ml of the HF solution into a plastic test tube. HF will eat glass so using glass labware with it isn't a good idea!

HF solution in the test tube

Drop the die into the tube, cap it, and place it in the water bath. Etch rate depends on temperature, strength of the acid (Whink's strength isn't precisely controlled and I often will re-use the acid several times) and a few other factors so it's difficult to accurately predict. I usually will etch for 30 seconds at a time on modern planarized processes and 60-90 seconds on a large non-planarized chip.

Sample etching in the water bath

When the time is up, remove the tube from the heat and suction the HF with a pipette. The acid can usually be re-used for many etches, though it does get weaker over time. Drop the die into a beaker of acetone to remove any acid residue.

Remove the sample from the acetone using solvent-resistant plastic tweezers. (Many common plastics, such as polycarbonate, will dissolve into the acetone and contaminate your sample. Metal tweezers have a nasty habit of chipping edges of dies.)

Rapidly blow-dry the sample, holding it down with tweezers so it doesn't go flying. I used a can of R-134 duster spray. (If you let the solvent evaporate slowly large crystals can form from dissolved materials.)

Drying the sample

Image the die under a microscope to see if you've etched far enough. (The die I used in this demonstration was actually a bit over-etched as I paid more attention to camera angles than etch timing!)

The other main delayering method I plan to explore is CMP with colloidal silica. At the moment MTI is sold out, but when a new shipment arrives expect a post on CMP!

Ignacio Garcia, dingux.com: Running code on the GA330

noreply@blogger.com (booboo) — Sat, 12 Mar 2011 23:07:08 +0000

Check out usbtool here:

http://github.com/iggarpe/cc1800

The CC1800 has 16KB of SRAM located at 0x0010000, and also mapped at 0x00000000 if certain bit of a special register is set. At boot time this bit is clear and ROM is mapped at 0x00000000.

The A330 can be made to boot from SD card by pressing DOWN during power up. In this mode the ROM code will load sectors 2-17 into SRAM at address 0x00100000 and execute. The code in rom.bin will then in turn execute the USB boot code, and from then on you can use the usbtool above to upload and execute your code through USB. Much more convenient that moving an SD card around.

Note however that since the USB boot code is not executed from ROM but from SRAM, the same SRAM you will be uploading to (at least until the SDRAM controller has been initialized), some restrictions apply: the USB boot code code in rom.bin is loaded at 0x00100000, and first thing it seems to do is move itself to 0x00102000, that is, to the second half of the 16KB of available SRAM. This means you can use only the first 8KB for your code AND the stack.

Ignacio Garcia, dingux.com: GA330 unbricking tool

noreply@blogger.com (booboo) — Sat, 12 Mar 2011 20:35:04 +0000

http://www.mediafire.com/?ed998x4zj86c1a2

Mind you, I haven't been able to make it work. I managed to brick one of the two GA330 that ChinaChip kindly provided, but haven't been able to restore the firmware. Not that I care much anyway since I don't really need the native firmware running for porting the linux kernel.

Note that the USB boot mode is not used in any of the CC1800 based machines that I know of, due to a ROM problem, so actually you will be using SD card boot to run a fixed USB boot code.

To prepare the boot SD card in windows use the ChinaChipSDBurnTools.exe utility. First argument is the drive letter, second argument is rom.bin file. Example:

ChinaChipSDBurnTools.exe I: rom.bin

This will just write the rom.bin file to sectors 2-17 in the SD card, so it will probably destroy the contents of the card. From linux you can use the dd command. Assuming the SD card drive is /dev/sdi, then:

dd if=rom.bin of=/dev/sdi bs=512 seek=2

You can actually make a boot SD card which is also usable for storage: just make it so that the first (and possibly only) partition starts somewhere beyond sector 17. How to do that is beyond the scope of this post.

Insert the card and plug the USB cable while you press DOWN. The GA330 should be now in USB boot mode.

From there on you need to use the Burning_tool(CC1800 V1.14)_W35.exe tool. The first big button will install the USB driver (at least it will copy the files in C:\Windows\System32\ChinaChipUSB, you might need to point windows to that directory when new hardware is found). The second big button starts the burn process, which you can only do after selecting the IPL, DL and HXF firmware files.

If you succeed unbricking your GA330 with this tool, please report in the comments.

EDIT: if you happen do have your serial console connected, please log and send me the output during the unbricking (57600 8N1, the code in the SD card that implements the USB boot mode will output a few lines 115200 8N1, so you'll see some garbage).

Andrew Zonenberg, Silicon Exposed: Microchip PIC12F683 teardown

noreply@blogger.com (Andrew Zonenberg) — Thu, 03 Mar 2011 10:46:14 +0000

I'm going to kick off the meat of this blog with a teardown of a chip that has a special place in my memories - the first microcontroller I ever worked with, the Microchip PIC12F683. It's an 8-bit RISC microcontroller made on what looks like a 350nm 3-metal process, with 14 bit wide instructions and a fairly nice set of peripherals:

2K words program Flash
128 bytes SRAM
256 bytes data EEPROM
Two 8-bit and one 16-bit timer
Four-channel multiplexed 10 bit A/D converter
Comparator

I decapped one of these a few months ago and imaged it at 400x magnification. Pin 1 is at the top left. (At the time I was still experimenting with panorama stitching techniques so there are a few alignment glitches.)

PIC12F683 metal 3 with passivation, magnified 400x

The glass layer (reddish) was quite annoying and made it hard to resolve traces so I decided to remove it using my standard wet-etch procedure (heating in 3% HF). I'll be writing about this process in more detail over the weekend.

PIC12F683 metal 3 after wet etching, magnified 400x

We now have enough information to create a floor plan of the chip:

The large block at bottom center (surrounded by power rails with 14 white capacitors at the bottom) is the program flash. Each capacitor is part of a charge pump used to generate high voltage for erasing one bit of flash.
Immediately to the left is the RAM.
Above the RAM is the EEPROM. As with the flash, there is one capacitor per bit of memory for high voltage generation.
Above the flash, and slightly to the right, are the configuration fuses. Each of the small red plates is part of a single configuration bit.
Analog peripherals are in an L-shape along the top and right sides

Top portion of PIC12F683 configuration fuse array (metal 3 after etching off glass)

The configuration fuses are single cells of EEPROM-style memory storing data such as the clock oscillator source and code / data protection bits. As with most other PICs, when the protection bit is in the "1" state the chip operates as normal; in the "0" state attempts to read firmware or EEPROM respectively via ICSP return all zeros. Configuration fuses can always be read.

EEPROM is typically susceptible to erasure (all bits set to 1) by strong UV light and the configuration fuses are no exception. If we can expose just the fuses (and not the flash or EEPROM, whose data we presumably want intact) to UV, the code protection can be removed and the firmware reverse-engineered using standard software RE tools. Note that PICs are thus a slightly easier target than Atmel chips. Atmel fuses in the "1" state indicates the chip is in the locked state (i.e. UV will set rather than clear the fuse).

Enough talking, time to try pwning the chip! As of this writing my decapping lab is offline, but Brooke Hill from Jimnson Research was kind enough to decap a few samples I sent him.

Decapped PIC12F683, magnified 10x. Rotated 90 degrees counterclockwise from other photos.

The first step was to plug the chip into a breadboard and verify it still worked. (Although decapping is normally a fairly low-risk procedure, bond wires do occasionally work loose during the rinse or cleaning steps.) The test firmware I used was a short piece of assembly that blinked an LED on GP2, and had the code-protection bit set.

I then laid down a mask over the memory areas I wanted to protect. I used the old classic, black nail polish applied with a lint-free swab under a stereo microscope. The brand of polish I purchased turned out to be very thick and gooey; in the future I intend to thin it with acetone for a more even coating.

Halfway through applying the mask

At this point the difficult work was over. I placed the chip inside my homemade UV erasure box, powered by two germicidal fluorescent bulbs.

UV exposure system

Two hours later the PIC was removed from UV and put back in the breadboard. I attempted to verify memory integrity with my PICKit 2.

Success! Program memory and EEPROM are undamaged (and unprotected) while configuration fuses read as all 1s.

Although the code protection on the PIC12F683 is clearly broken I am not finished with it; as an educational subject has not outlived its usefulness. Stay tuned for a future post with gate- and transistor-level analysis of interesting areas!

Andrew Zonenberg, Silicon Exposed: Welcome

noreply@blogger.com (Andrew Zonenberg) — Thu, 03 Mar 2011 05:06:42 +0000

Hello readers, and welcome to my virtual laboratory!

I am an undergraduate computer science student at Rensselaer Polytechnic Institute (beginning my PhD this the fall) with a wide variety of technical interests. The focus of this blog is my research into integrated circuit reverse engineering.

While many hardware reverse engineering blogs (such as that of Tarnovsky) are primarily focused with defeating configuration fuses and anti-tamper circuitry, I hope to cover a wide range of topics including these as well as general CMOS logic and sample preparation techniques.

For the skeptics among you, the right to reverse engineer ICs is protected by United States copyright law (17 USC 906), which states that it is not an infringement of a mask right for "a person to reproduce the mask work solely for the purpose of teaching, analyzing, or evaluating the concepts or techniques embodied in the mask work or the circuitry, logic flow, or organization of components used in the mask work".

Geoffrey L. Barrows - DIY Drones: ArduEye: Brutally minimalist (but quite fast) vision sensor using an Arduino

Tue, 01 Mar 2011 05:13:12 +0000

We are finally having manufactured a "shield" board for the Arduino platform that interfaces a Centeye image sensor with an Arduino to form a true (if simple) "smart sensor". This particular version is about a simple as you can make it:

Shield Board: The board itself is a simple 2-layer board, and can be connected to either a full-size Arduino board (we've so far tried the Duemilanove and the Pro), or a mini-sized version (we've tried Sparkfun's Pro Mini). You need a 5V board to power the image sensor.

If one doesn't want to use the board with an Arduino, it is of course possible to just use it as a breakout board for the image sensor chip. The board design is open source.

Image Sensor: The shield board is compatible with any of Centeye's current image sensor chips, but for the above version we are using the Tam series- These are very simple image sensor chips requiring only five lines- Ground, Power, Clock, Reset, and AnalogOut. When you pulse Reset, a counter on the chip points to the first row, first column pixel, which is output as an analog value. Pulsing the Clock line advances the counter to the next pixel row-wise. That is it. The chips are available in two resolutions- Tam2 at 16x16 and Tam4 at 4x32, the latter with rectangular shaped pixels. I've also taken a leap of faith and decided to publish the schematic of the chip! We've released the analog portion down to the transistor level, and the digital portion down to the gate level.

Right now we have about 200-250 each of the Tam2 and Tam4 chips in stock, in bare die form.

Optics: The sensor will be shipped with a micro lens (about 1.6mm)- we can ship the board with the lens mounted or unmounted. In the latter case the Tam4 chip will be open and exposed, which is appropriate for people who want to use their own lens.

Sample code: I've also written a sample Arduino sketch that illustrates acquiring an image, obtaining a fixed pattern noise mask, and computing one dimensional optical flow from the 4x32 Tam4 chip. By cutting out the serial monitor and acquiring/computing optical flow on just one 32-element row, we obtained more than 200 frames per second- I think more is possible with further optimization. The source code is "open" and is intended to be a starting point for developing your own application.

Uses: I didn't design this board for any specific application, but it should be able to do some things of interest to robotics. I've come to appreciate that it can be difficult if not impossible to make a "one size fits all" sensor, even if supporting just one mode (like optical flow). This is because there are many parameters that must be adjusted for each application. Thus for this board we are taking a different approach- rather than try to hide the optical flow computation from the user, we want the user to be fully aware of what is going on. In order to really use this sensor, you'll have to do some hacking of the code to tailor it to your application. I'll be honest- this is not for those who are afraid to hack a bit. But I think the Arduino environment makes it very easy to hack, play around, and try different things. I'd appreciate your feedback on this approach.

As for what I think the board will ultimately support (with some hacking)- in the context of robotics and drones I think that things like wall following or basic terrain following should be doable (if on a forward moving platform). Several sensors should support some basic obstacle avoidance against large obstacles. Fulfilling the role of an downward optical flow sensor for a quad might be doable, but would require some careful optimization and algorithm tuning. I don't think impossible though- If the classic 1980's video game Defender could run, with rendering, on a 2MHz processor, then I would imagine adequate optical flow for a quad could be done with 16MHz. Please note though that I haven't tried any of these things yet with this board.

Just so that you know megapixels aren't needed- here are a few facts to consider:

1) Most flying insects have from several hundred to several thousand pixels. They have at most "kilopixels"! 2) We demonstrated altitude hold in 2001-2002 with 16 to 88 pixels, and obstacle avoidance in 2003 with 264 pixels total. 3) We also controlled the yaw angle of a helicopter with 8 (eight) pixels.

For the released files (including the Tam chip schematic), please visit this posting at Embedded Eye. For other details including purchasing, please visit this page at Centeye. Current asking price is $100 per board plus $9 shipping/handling for US customers. We hope we can lower this price in the future as we learn to automate working with bare die and the lenses in the current manner we use.

Please feel free to ask questions.

Ignacio Garcia, dingux.com: GA330 native firmware SDK

noreply@blogger.com (booboo) — Sat, 19 Feb 2011 02:10:36 +0000

This might very well be old news, but just in case.

You can find the native firmware SDK for the A330 here:

http://code.google.com/p/mp4sdk/downloads/detail?name=A330-SDK-Setup-20101106.exe&can=2&q=

It's an "unofficial" release.

Village Telco: In a Village Telco Minute

Thu, 17 Feb 2011 11:12:08 +0000

Over the last couple of years we have struggled to communicate the message of the Village Telco simply and succinctly. Thanks to the creative folk at BlinkTower, we think we’ve finally succeeded.

Comments welcome.

Ignacio Garcia, dingux.com: Booting the GA330

noreply@blogger.com (booboo) — Tue, 15 Feb 2011 11:49:11 +0000

Just a few tech comments I left out in the previous post due to lack of time... but after a quick clarification about ChinaChip:

They have a lot of open fronts in a very competitive market and a limited set of resources, I assume that if the project has been put on hold is because they had no choice. Note however that they're still providing information and support, but with some limitations.

As I said, I have schematics, docs (which suck but are just what they have) and BSP code. I'm now working on the tools to boot code on the GA330 through the USB port, and as soon as I get it working and a kernel booting with a serial console, I'll publish it all (but I still believe it will be of little use to other developers without the docs and BSP). I don't like to be the bottleneck, but that's how things are now.

Now for the tech details:

The CC1800, like the JZ4732 and other SoCs alike, has several boot modes implemented in the internal ROM. The code checks the state a of a few pins and then proceeds to boot from NAND, NOR, SD or USB. Actually, USB boot means the ROM code sets up the USB port in device mode and waits for instructions. You can get CPU info, upload code to SRAM, and execute it, that's pretty much all.

Note that I wrote SRAM, not SDRAM. That's why you usually need a two stage process to boot code via USB: upload and execute a tiny piece of code to SRAM which configures and initializes the SDRAM controller (and some other peripherals) so that memory is accessible, and then upload and execute the large piece of code, the kernel, to SDRAM.

Surprisingly, in the two CC1800 based machines I have, the GA330 and an HD8900, the bootsel[2] pin is tied to 3.3V. This means you can't enter USB boot mode. The bootsel[1] pin is connected to the down input of the d-pad, which means that switching the GA330 on while keeping down pressed you enter SD boot mode. In this mode the CC1800 loads the content of sectors 2-17 (a total of 16 sectors, 8KB) from the SD card to SRAM and executes it.

It turns out that due to some errors in the CC1800 design (not sure if it's the silicon or the ROM code) the USB0 port being used wasn't stable. Since the ROM code can't be changed, the hardware designers were forced to use some other alternate boot mode, and went with SD. Now, if you put in the SD a modified version of the USB boot code in ROM which uses USB1 instead of USB0, you're back on track and can complete the flash burn process through the USB1 port.

(note that in SoC of this complexity it is very usual to have tens or even hundreds of errors which are generally described by the manufacturer together with workarounds in the corresponding errata sheets, see the LM3S9B96 from Texas Instruments for instance)

Needing to have an SD card inserted to enter USB boot mode is a small inconvenience for the manufacturer, but can be a blessing for final users, because:

It makes a dual boot unnecessary. You will be able to boot dingux from the SD card without any modifications to the GA330.
Even if a dual boot is necessary, the install method would require only an SD card (no more USB driver madness).

For us developers it's an insignificant inconvenience. We need USB boot because it makes compiling and testing code very easy, and we just happen to need an SD card inserted all the time. Note that the partition table in sector 0 of the SD card is not affected, so you can set the first partition to start anywhere beyond sector 17 and have an usable data partition while still keeping the boot code in sectors 2-17.

Ignacio Garcia, dingux.com: Update on dingux for the GA330

noreply@blogger.com (booboo) — Sat, 12 Feb 2011 12:30:58 +0000

It's been way too long since the last entry. First I delayed it a bit just to have something actually substantial to write, and then then stretched it a bit longer, and well, here we are.

After coming back from China I had a list of tasks I had agreed with the ChinaChip management and engineers to get dingux up and running on the A330 in the near term. There was also the possibility of they sponsoring the development. To make a long story short, I was willing to anything between working on my spare time for free and being hired full time, and I was expecting something in between: I'm way too expensive for full time dedication (plus it's probably too soon for that) and while I'd be happy to work in my spare time, that would of course come with no commitment to any schedule or even to completion.

Since then, there's been some kind of priority rearrangement in ChinaChip and the "dingux on the A330" project as been put on hold. That means that the engineers that would do their part (mostly adapting their firmware to allow comfortable dingux installation in the internal flash) aren't available at the moment to work on it. And delivery of the required information to get a kernel port to the CC1800 running has been... well... slow. I got the most important part a couple of weeks ago. And no sponsoring. So I'll do my best but again, don't hold your breath, since as of now my job and my family allow only for a very limited amount of spare time.

The partial CC1800 programmer's manual I've got is 38 pages long. And consists of a couple of paragraphs describing each peripheral and tables of registers. Only the names of the registers and the bit fields. All in Chinese. The Texas Instruments OMAP3503 programmer's manual is +3000 pages. Go figure.

Not that I'm really complaining, since I truly believe that's what they have from the people that actually designed the CC1800. The cheese is in the BSP, which is code, which means if something is not properly done or downright broken you can't fix it, since you don't have a reference programmer's manual.

I wanted to end this post with some tech details about the A330 boot process and memory map, but I have to leave now, so it'll go in the next post.

Village Telco: Bo-kaap Village Telco Part 1

Tue, 01 Feb 2011 19:59:16 +0000

While David Rowe and Lemi Soares have been busy building a Village Telco in Dili, the capitol of East Timor, we’ve also been hard at work in Cape Town building a Village Telco within the Bo-kaap community. The Bo-kaap is a largely muslim community in the heart of Cape Town. Many of the residents go back several generations and have fascinating stories to tell. It is a mix of wealthy and poor and also has a sprinkling of “immigrants” mostly white, artistic types (film-makers, photographers, architects) who have been attracted by the Bo-kaap’s unique character.

In terms of a place to pilot a Village Telco, it sits above the demographic we intended the Village Telco for but it seemed a good choice for a number of reasons:

There is a really strong community. There are strong social bonds linking everyone in the Bo-kaap and strong social bonds means a strong desire to communicate locally. This was the strongest motivator for choosing the Bo-kaap
We’re still learning and don’t want to create a dependency on something that is still evolving. The fact that Bo-kaap community is a little wealthier on average than our target community means that although they may value the Village Telco, they won’t be completely stuffed up if something goes wrong as we perfect the network.
It’s convenient. Tempting as it is to set up a rural Village Telco right away, the Bo-kaap is not many minutes away for me so easy to get to and work on.

At the right you can see a screenshot from the Afrimesh software that we use to monitor the mesh. Right now we’re up to about 50 nodes in the mesh and the increasing density continues to make things easier and easier. In the beginning we had to be very careful about long links and used some Ubiquity Nanostation IIs to make some of the long shots. We also had to be very careful about getting the Mesh Potatoes into a strategic position to pick-up other Mesh Potatoes. Now, once I get up on someone’s roof, I can usually see a Mesh Potato in some direction so installation is as simple as finding something to attach the Mesh Potato to. TV antenna’s have proven to be very convenient in this regard.

The installation process for the Bo-kaap has been slow, partly because it took a long time to get production Mesh Potatoes into our hand but also because the Bo-kaap is an old community and the houses in it have evolved more than they have been planned. Each house is a little exercise in complexity in terms of getting to the roof, finding a cable path down from the roof, finding power near the desire location of the phone, etc. I’ve got it down to a routine now though. Having the right tools like a long concrete drill bit for going through walls are simple things that make life a lot easier.

We’re learning a lot as we install the Bo-kaap Village Telco. We decided to offer 100 Mesh Potatoes to the community in exchange for user feedback on the Village Telco. In order to build the most useful network possible, we built connections by following social ties, a bit like snowball sampling in research. We started with a family that ran a cafe and followed their social ties, brothers, sisters, friends, neighbours. Each new person is at liberty to suggest others. By following existing strong social ties, the Village Telco immediately begins to delivery high-value connections. An older mother-in-law that wants to stay in touch with her family who are only a few doors away but it is hard for her to get around. A mother who recently became a grandmother wants to stay in touch with her daughter. In each of these cases, they could use a mobile phone to call but like the majority of people in South Africa they are conscious of what time spent on the phone costs them. A local Village Telco call is free.

Mesh Potatoes can be gateway-ed to other telecom networks and can also offer Internet services but for the time being we are just offering local voice because the devices do that on their own at no additional cost. Once the community is ready to take over the network themselves and manage external voice and Internet charges, we’ll enable those other features. Stand by for more from the Bo-kaap Village Telco.

Marcan's Abort, Retry, Hack?: OpenLase hardware and simulator

Mon, 31 Jan 2011 19:48:00 +0000

I apologize for taking this long to post this! I’ve been busy non-stop since 27c3 and never got a chance to get around to it. Finally, though, here it is: the description of the Mark 1 laser projector that I use with OpenLase.

But wait, there’s more! If you don’t have the hardware and don’t want to build it, or you want to try out OpenLase, or you want to be able to mess around with it on the go, you can now do that. There’s a new OpenGL-based simulator in the OpenLase tree. It works off of the JACK data (so you still need JACK) and it tries to simulate the dynamics of my laser scanner, including brightness effects and some of the physical limitations of the galvos. Here’s a comparison of the simulator vs. the real thing:

I’m aware that documentation on the software is still sorely lacking. Please bear with me while I get my act together and write that up

Hawkboard: Hawkboard Update

Mon, 31 Jan 2011 18:30:57 +0000

Dieter Spaar: GPRS Air Interface

Sun, 30 Jan 2011 01:00:00 +0000

To get a better understanding of how GPRS looks like at the air interface, I implemented some first experimental code in Airprobe (this is not yet ready to be released). The output of this code are the RLC/MAC blocks on the downlink (no uplink yet). As far as I am aware, WireShark cannot decode RLC/MAC yet.

The GPRS air interface is not that different than "standard" GSM (signalling or voice). The PDCH (Packet Data Channel) uses its own multiframe structure with a length of 52 frames, the biggest difference are four coding schemes (CS-1 to CS-4, CS-1 and CS-2 use puncturing) which are chosen depending on the quality of the radio link. If the link quality is good, a coding scheme with less forward error correction and more information bits is used which results in a higher data rate. As a side note, you can test how good your receiver really is if CS-4 is used (very good radio link quality, no forward error correction at all), you should have nearly no bit errors in the decoded data (the phone also receives error free data, otherwise CS-4 would not be used).

I have not yet implemented decoding EDGE, besides other coding schemes EDGE can also use a different modulation (8-PSK instead of GMSK).

Please note that being able to decrypt the A5 encryption does not help with GPRS, it does not use A5 encryption at all, it uses its own encryption algorithm (GEA) at a higher level. If you want to experiment with GPRS encryption, the easiest to start with is probably using a GPRS setup with OpenBSC plus the nanoBTS and look at the traces to the SGSN with WireShark (you have to implement a GPRS encryption algorithm in osmo-SGSN first, the specification of GEA3 is publicly available).

Dan Strother: System modeling/verification diagram

Tue, 25 Jan 2011 05:28:10 +0000

As alluded to in a few of my other posts, I’m working on developing an open-source FPGA-accelerated vision platform. This post is a detailed overview of the project’s architecture and general development methodology. Future (and past) posts will elaborate on … Continue reading →

Geoffrey L. Barrows - DIY Drones: Kicking off two open source optical flow / vision sensor projects (Finally!)

Thu, 20 Jan 2011 01:00:00 +0000

I would like to "formally" announce two open source projects related to optical flow / programmable vision sensors. These are based on some of the optical flow techniques developed at Centeye, but in the spirit of "open source" are meant to be hacked/modified/copied any way a user deems fit. In both cases, the source code has been opened up under a modified FreeBSD license, while the board design has been released under a Creative Commons Attribution-ShareAlike license, the same license that applies to the Arduino boards.

The first project is the CYE8 sensor, an optical flow sensor based on an Atmel ATmega644 (possibly to be replaced by an ATmega1284) 8-bit processor, and using a Faraya64plus sensor head. (A "sensor head" is a vision chip wire bonded to a 9mm x 9mm PCB with a board to board connector on the other side.) We fabricated our first two iterations last year (the first one described here), and are now readying the third iteration this month.

The hardware of the second project was introduced in a recent blog post and is based on the Sparkfun Arduino Pro Mini platform (which uses a similar but smaller Atmel microcontroller) and comprises a simple shield board that interfaces the Arduino with a sensor head. Currently we have used only a FarayaSmall sensor head, but this board will support other chips as well.

At the current time, these projects are hosted on another open Ning network Embedded Eye, since we are trying to capture a broad set of applications beyond drones. If these projects take off, we can set up Huddle spaces accessible across both Ning networks, or move the project elsewhere. (I'll take suggestions- I'm still learning about how to do projects like this.) The CYE8 project is located here and the Arduino-based project is located here. These forum pages include initial board designs and source codes.

Based on interest, we will likely also launch projects built around an Atmel AVR32 processor (faster than the AVR8's) and/or an XMOS quad-core processor (if you have real need for speed).

One common theme of these two projects (which has strengths and weaknesses) is that they utilize vision / image sensor chips designed by Centeye. (This is not a requirement of the license- it is just how they were designed.) The strengths are that since we designed the vision chips, we can probably reveal as many details of the inner workings of these chips as we want. We all have heard complaints of chip manufacturers being too vague about what is inside, so I hope that this is a welcome change. The weakness is that we basically have to burn new wafers every time we want more sensors, so they are not as available as, say, a part from Digikey.

We are actually going to start a new run of silicon soon with the intent of increasing manufacturing quantity. It is tempting to use this as an opportunity to explore semi-open chips designs. I'd be happy to share a (virtual/real) beer with anyone interested in discussing (whether here, at EE, or directly) the various issues associated with the design and manufacture of chips of this type.

I look forward to speaking with everyone soon!

Geof

Geoffrey L. Barrows - DIY Drones: Make your own plastic mini lens, part 2

Wed, 12 Jan 2011 01:45:45 +0000

In a recent post I described some simple acrylic lenses I made using a simple press-molding technique. The methods were crude, but the results weren't too bad. Also, I had designed an assembly containing four minor variations of these lenses and submitted that for fabrication over the holidays. The injection molding step was a bit of an experiment- rather than using a full optic-grade firm, which would have cost us well into the five figures to try, we used U.S. based Protomold, who was able to create this mold in two weeks and make 100 assemblies (400 lenses) for a bit more than $2k. I again selected acrylic as the resin material for these lenses.

The picture above shows the parts as they came back (top and bottom side). Below shows a close-up of two lenses cut out from the above assembly.

The real test, of course, is that image quality. I mounted these lenses onto some of our image sensor chips using the same methods as that discussed in the above-quoted recent post, painted on an iris, and sealed the chip up. Below is a picture of me waving at the camera in 32x32 resolution.

I also took another picture of my backyard with a different chip and a different setup at 90x90 resolution. The field of view was roughly between 70 and 80 degrees, thus the pixel pitch was less than one degree. The image quality in this latter picture was not as good. Two factors probably contributed to this- First the finer pixel pitch could have exceeded the limits of the optics, second my method for removing fixed pattern noise was less accurate in this setup. Right now I do not know which of these two factors dominate.

One comment- There was in fact some shrinkage in the lens, on the flat bottom part that gets placed onto the chip. However this was small and easily filled in with the optical adhesive, which has almost the same index of refraction as acrylic.

One lesson learned regarding the injection mold design: There are four slightly different lenses in the above assembly. The difference is in the total thickness, with sequential lenses different by 25 microns. (It turned out this difference was moot compared to the varying thickness due to the amount of adhesive used.) This was to allow me to experiment with variations to compensate factors such as shrinkage and enlarging of the mold through polishing. However I made the mold family perfectly symmetrical (other than the small variations in lens thickness)! When I got the parts back, it was hard to find out which lens was which! Fortunately I found the sprue (where the plastic charge gets injected into the mold) and with careful eyeballing under a microscope, identified the lenses. But the lesson learned is that I should have added a slight marking or asymmetry to help me identify right from left.

Overall I am pleased with the results. For pixel pitches of about two degrees per pixel and up, this technique is adequate. Two degrees per pixel may not sound like much, but many flying insects have this type of resolution and do quite well. It may be that with the right iris and better fixed pattern noise cancellation, I could get the sharpness down to one degree or pixel, but this will have to wait.

Here again is the link to a zip folder containing the Alibre files for the mold: CYE_LensMold_Untested.zip

Geoffrey L. Barrows - DIY Drones: Arduino Pro Mini optical flow sensor

Mon, 10 Jan 2011 14:32:17 +0000

This is a follow-on to an earlier post about an Arduino-based optical flow sensor prototype. Here I actually constructed a complete sensor that could actually be integrated into a robotic platform. To achieve a smaller size, I used an Arduino Pro Mini board from Sparkfun, and added a "shield" to interface that with a Centeye image sensor and optics. The breakout of parts is shown above- The complete sensor is shown next to a US Quarter. You can also see the individual blue Arduino board and the green "shield" board. On the right are individual "sensor heads" which are basically small PCBs holding the image sensor chip (here the "FireflySmall"), optional optics, and two capacitors. The sensor head plugs into the green shield board via a Hirose DF30 board to board connector. Three sensor heads are shown- on top is a sensor head with optics, in the middle the board-to-board connector side, and on the bottom the image sensor chip side.

I wrote a simple Arduino script to grab pixels from the vision chip (configuring it to grab rectangular pixels), compute 1D optical flow using a variation of Srinivasan's "image interpolation algorithm", and dump a display of the optical flow to the serial monitor. (Some of you may know Professor Mandyam Srinivasan as the Australian biologist who has studied honey bee navigation, in particular how honey bees use optical flow to close control loops using simple but elegant heuristics.) A simple video of the sensor is shown below. I've also attached the Arduino script code, in case anyone is interested.

PIO12Firefly_ProMini_LinearOF.pde

Methril: Sumarizing 2010

noreply@blogger.com (Methril) — Sun, 09 Jan 2011 14:53:54 +0000

After being so "silent" in my Open Source world, i need to sumarize the last year.

It could look that i leave the FOSS world, but nothing further from the truth. I've been FOSS advocate at my actual company, improving our FOSS ecosystem.
I had to fight in some fronts of the Computer Science that i never had contact with before:

I had a combat with binutils/gcc/newlib for ColdFire v1 devices, and i win (we get a multi platform toolchain ready to work), both Windows and Linux builds are working fine.

I also deal with other compiler: SDCC. It was hard, but it's our official PIC compiler :D

Configure and make an application with RTAI and comedi to measure quality and some important parameters of our physical final products (it was a working proof of concept, we need to improve it a little bit, but it's working). In the while i have to evaluate the use of Scicoslab, RTAI-Lab, Scicos-Hil, Scilab, Xenomai, RT-PREEMPT patch and robotics frameworks like Orocos.

I get hands dirty with LTSP, as sys-admin, and i configured some servers and services.

And some other propietary stuff or internal work.

Unfortunately, i didn't found time to work with Efika-MX, Ben-NanoNote and carry on hacking my Neo Freerunner (between all my hw toys), neither post some words about my advances. But, at the end of the day i did nice FOSS development, and i also touch the Linux kernel, in a personal way.
So... 2010 was not a bad year :)

Zedstar: Searchable USB flash drives

Thu, 06 Jan 2011 21:35:45 +0000

Recently I was revisiting a powerful open source search engine technology on a Ben NanoNote to see how well it performed. Bearing in mind the NanoNote is only equipped with 32MB of RAM and a 336MHz MIPS processor it performed admirably. As a proof of concept I took the PDF lecture slides from three MIT OpenCoureWare undergraduate modules and indexed them on the device. This part of the process is time consuming but only needs to take place once. As you can see from the following video (OGG format), searching the PDFs is rapid and there should be no problem scaling to thousands of documents.

One nice feature of connecting the NanoNote to your PC is that you are able to access the search engine through your PC’s web browser. This becomes close to something I have thought about for a while – a copyleft designed USB flash drive with embedded web server and search engine. This would allow you to take your documents with you and view them using a familiar g**gle style search on any PC you get access to (in theory) without relying on the host OS to do the work.

Geoffrey L. Barrows - DIY Drones: Make your own plastic mini lens

Wed, 22 Dec 2010 12:09:07 +0000

One of my side projects has been to develop an open-source visual motion / optical flow sensor that may be usable in all sorts of devices, whether robotic related or not. I've found though that one of the most difficult parts of developing tiny vision sensors is finding the right optics. Ideally we want something that is cheap, easy to mount, has a decent field of view, and yet creates a reasonable image. For higher resolution images (hundreds of pixels across or more) and image sensors four or more millimeters wide, there are many excellent lens assemblies available from companies like Sunex. (We've used and still use their products in higher resolution sensor designs, always with success.) However there is really nothing available for image sensors a millimeter wide. Printed pinholes do work, but don't let through as much light. This post highlights a little project to design a decent lens for the Faraya64 image sensor, whose focal plane measures about 1.1mm across.

The basic concept (shown below) is to make a simple "plano convex" lens, with the curved surface (e.g. "bump") facing outward and the flat section resting on an image sensor. I decided on acrylic as an optical material, since it is light, easily formed, and for our purposes is as good as glass. An opaque "stop", perhaps made of paint or a piece of black plastic, would fit over over the lens and allow light to reach the image sensor through only the center of the front bump.

For the front surface I decided to use a spherical shape- this is a pretty traditional shape for 99% of all lenses out there. I used the ray tracing and optimizing capabilities of Zemax, a commercial optics design software package, to find an optimal shape. I found that to provide the 1.1mm image sensor chip with a 60 degree field of view, the dimensions shown above were optimal: The front bump would be a sphere with a radius of 0.61mm, while the total thickness would be 1.6mm. I also allowed the optimizer to try aspherical conic shapes (e.g. parabolas, hyberbolas, ellipses) but found that I did not gain much performance over that of a sphere and so decided to keep it simple.

The two figures below show two plots generated by Zemax. First is the lens layout, showing the 0, 10, 20, and 30 degree off-axis rays. Second is the spot diagram showing how the image would be blurred from ideal, for red, green, and blue rays! The pitch between pixels on the Faraya64 image sensor is about 17.1 microns, so the RMS blurring shown here was not quite optimal but was good enough for me to go on.

I decided next to first try forming a lens by hand by stamping it. This technique won't match the precision from the Zemax simualtion, but I thought it would be fun. Using Alibre, I designed a simple stamp that would produce a lens of the above shape. I had this stamp CNC machined from aluminum by the company FirstCut.

The stamp came back, but it needed more finishing. Basically the part of the mold that forms the spherical lens bump needed to be polished to "optical quality". I didn't really know what I was doing, but I did manage to find a way to polish this area! I used a Dremel tool, a toothpick, and some polish (Simichrome Polish by Gesswein), put a dab of polish in the hold, and used the Dremel tool to spin the toothpick. After about 5-10 minutes of spinning and moving the toothpick around, I managed to get the spherical surface polished to a decent quality, as shown below. I also cut channels to let the plastic escape as the stamp was being pressed down. The result is shown below.

Now comes the fun part- the pressing! I don't have any photos from this step, but I'll try to describe the technique that worked best. I placed a pyrex dish on a hot plate, and set the heat to low-medium. After a few minutes I then placed a piece of aluminum foil on the hot plate, and a tiny piece of acrylic onto the aluminum foil. A few minutes later the acrylic piece got soft, and I pressed down onto it with the stamp. I lifted the stamp out, and the pressed acrylic piece (and the aluminum foil) came up with it. The picture below shows the business end of the stamp, the pressed piece of acrylic, and a U.S. Quarter for size comparison. If you look carefully, you can see the spherical bump in the middle of the piece of acrylic. You can also see extra plastic around the outer side of the lens- I cut that away with a utility knife.

I'd say that about 40% of the lenses I pressed turned out OK. Below and at the very top of this post are front and back pictures of some of the final lenses produced.

The next step is to mount the lens on a chip. Basically I used a UV curable optical adhesive (Norland 63) to glue the lens directly onto the chip. Then I used black modeling paint to form the "opaque enclosure". Finally I added more optical adhesive to encapsulate everything (except for the lens bump). The result is shown below- you'll see the lens mounted onto a Firefly chip (similar to the Faraya) and that mounted on a small 9mm x 9mm PCB. If you look closely you can also see the wire bonds that connect the chip to the PCB.

How was the image quality? Actually much better than I expected, especially since the flat side of the lens was not perfect. The optical adhesive's index of refraction is similar to that of acrylic, so I think together they helped smooth out some of the imperfections. Below is a screen shot- the quality is certainly good enough for 32x32 images, and I think with refining can be further improved.

So now the final step is to automate this process. Rather than press molding by hand, injection molding is the way to go for quantity. Below is a family mold with four slightly different variations of the same lens. This is currently being fabricated by Protomold. I should get parts back in the second week of January. I'll report back on this in a few weeks!

Antitronics: I’ve published my remaining knitting machine files

Sat, 18 Dec 2010 19:57:24 +0000

I had published my floppy drive emulator for the brother knitting machine, and some other information, using the wiki here at antitronics. This was sub-optimal from the beginning, and since Lady Ada published some of that in her git repo here: https://github.com/adafruit/knitting_machine, I’ve been intending to get more of my files out there. Limor’s repo seemed like the best place to put them, and she’s graciously allowed me to add them. What documentation I’ve created about the brother data format is in there, as well as all the hacked-up tools I used to help with the reverse engineering. There’s nothing there for anyone wanting easily usable end-user applications, sorry about that.

As usual, I’d love to hear from anyone who finds these to be useful.

Steve

Zedstar: A dynamic data encoder for embedded systems

Mon, 13 Dec 2010 18:58:28 +0000

I personally view Scheme as a good extension language. Something that can be embedded into C code to ease the pain of doing everything in C. I am interested in exploiting this concept on embedded systems where there is a lot of fooling about to make a binary. I still intend to produce binaries and reuse the large amount of existing C code out there. However, I want to script the network communication and in particular the structure of the network packets. I have periodically been working on a tool that attempts to support this. This summer I intend to get rid of the old C code in this project and rewrite it entirely in Scheme apart from the low-level encoder/decoder which will remain in C. In this white paper I attempt to describe the work.

**update**

This white paper has now be superseded by the paper “Everything counts in small amounts“.

Ignacio Garcia, dingux.com: Clarifications on previous post

noreply@blogger.com (booboo) — Sat, 04 Dec 2010 10:50:18 +0000

I'm not sure I've explained myself properly, since I totally agree with the comment posted by Xeatheran, but he failed to notice.

Using his words, people buying the A320 and similar devices want an emulator priced around $100. Any feature that significantly increases the price would make it have to compete with the other more expensive linux based consoles (Wiz/Caanoo come to mind) or with the godzillas of the market (NDS, PSP).

So, any wished feature must be such that doesn't increase the price significantly:

Better processor: by next year, the CC1800 will be obsolete and underpowered compared to other competitors in the PMP market. The CC2000 will be a bit more expensive, but here they have no choice but to move on or lag behind. Note that the CC2000 has a powerful GPU. More details upon the official anouncement.
256MB: this was already planned before I suggested it. Note that the CC2000 processor uses DDR RAM, whose widespread usage makes it cheaper than the SDRAM used by the JZ4732 and CC1800. This means 256MB in the next generation consoles may probably cost the same or less than 64MB in the current generation consoles.
A 480x272 4.3" LCD screen is not much more expensive than the A320 LCD, and it would make a big difference, at least for me. I find the A320 and GA330 screens too small. Problem here is that if you need a multiple of 320x240, you'd have to go for an 800x480 4.3", which I believe will be not just a little but much more expensive.
It should be obvious: either powered host USB type A or SDIO. Not both. My choice here is host USB, because dongles are way cheaper and more accessible than SDIO cards. But they pointed out that it may be impossible to fit such a bulky connector in the design. Maybe the PCB cutout would solve this. Anyway, it would increase cost just a little bit (mostly due to the USB power DC-DC converter), but you are also saving by removing the 2.4GHz radio from the design, which also as I pointed out, may be a big advantage when (if) time comes to pass CE/UL certification.
Analog nubs: if they are aiming, besides emulation, to get software studios to develop games for this console, it is a must. A GPU capable of, for example, running FPS games, would make no sense without analog nubs.

The rest of features I mentioned are essentially free (except licensing Doom, Duke, etc).

So: a CC2000 SoC (800MHz, GPU), 256MB DDR RAM, 4.3" LCD, analog nubs and powered host USB type A port. This would make a killer emulation console and stay in the same price range where the A320/GA330 are.

Camera, touchscreen, WiFi, etc, are nonsense. If you want too shoot crappy photos (most integrated cameras are crap) or browse the internet, use your phone or buy a tablet.

Capn's Tech: USB Doodad 5: Working USB

noreply@blogger.com (mjd) — Sat, 04 Dec 2010 10:43:47 +0000

Now that I know the processor on the Doodad is working, I want to try out USB. As we'll be using a software USB library, it's important that we test this out as soon as possible, in case we need to make circuit changes, or it's unreliable, or it just doesn't work at all.

The software USB stack we want to use is called V-USB:

http://www.obdev.at/products/vusb

I downloaded V-USB and extracted it:

[mjd@onza src]$ wget http://www.obdev.at/downloads/vusb/vusb-20100715.tar.gz
--2010-11-23 18:17:39-- http://www.obdev.at/downloads/vusb/vusb-20100715.tar.gz
Resolving www.obdev.at... 78.46.114.187
Connecting to www.obdev.at|78.46.114.187|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.obdev.at/ftp/pub/Products/vusb/vusb-20100715.tar.gz [following]
--2010-11-23 18:17:40-- http://www.obdev.at/ftp/pub/Products/vusb/vusb-20100715.tar.gz
Reusing existing connection to www.obdev.at:80.
HTTP request sent, awaiting response... 200 OK
Length: 417848 (408K) [application/x-gzip]
Saving to: “vusb-20100715.tar.gz”

100%[======================================>] 417,848 94.8K/s in 4.3s

2010-11-23 18:17:45 (94.8 KB/s) - “vusb-20100715.tar.gz” saved [417848/417848]
[mjd@onza src]$ tar -xzf vusb-20100715.tar.gz
[mjd@onza src]$

V-USB comes with several demos. I chose the mouse demo because it doesn't require any extra hardware such as switches or chips.

I have made some changes to the mouse demo source to reflect that we're using different pins for the USB, and also to make the LEDs blink. I've also changed the MCU type, the fuses, and the right command to run avrdude for my USB programmer:

--- vusb-20100715-orig/examples/hid-mouse/firmware/main.c
+++ vusb-20100715/examples/hid-mouse/firmware/main.c
@@ -124,9 +124,19 @@

/* ------------------------------------------------------------------------- */

+static const unsigned char portCMask = _BV(PC0) | _BV(PC1) | _BV(PC2) | _BV(PC3);
+
+static void setLED(const unsigned char v)
+{
+    PORTC &= ~portCMask;
+    PORTC |= (v & portCMask);
+}
+
int __attribute__((noreturn)) main(void)
{
-uchar   i;
+    uchar   i;
+    DDRC |= _BV(PC0) | _BV(PC1) | _BV(PC2) | _BV(PC3) | _BV(PC4) | _BV(PC5);
+    PORTC |= _BV(4);

     wdt_enable(WDTO_1S);
     /* Even if you don't use the watchdog, turn it off here. On newer devices,
@@ -148,12 +158,16 @@
     usbDeviceConnect();
     sei();
     DBG1(0x01, 0, 0);       /* debug output: main loop starts */
+    unsigned char a = 0;
     for(;;){                /* main event loop */
         DBG1(0x02, 0, 0);   /* debug output: main loop iterates */
         wdt_reset();
         usbPoll();
         if(usbInterruptIsReady()){
             /* called after every poll of the interrupt endpoint */
+            ++a;
+            a &= 0b111111;
+            setLED(a >> 2);
             advanceCircleByFixedAngle();
             DBG1(0x03, 0, 0);   /* debug output: interrupt report prepared */
             usbSetInterrupt((void *)&reportBuffer, sizeof(reportBuffer));
--- vusb-20100715-orig/examples/hid-mouse/firmware/Makefile+++ vusb-20100715/examples/hid-mouse/firmware/Makefile
@@ -7,11 +7,11 @@
# License: GNU GPL v2 (see License.txt), GNU GPL v3 or proprietary (CommercialLicense.txt)
# This Revision: $Id: Makefile 692 2008-11-07 15:07:40Z cs $

-DEVICE = atmega168
-F_CPU   = 16000000    # in Hz
-FUSE_L = # see below for fuse values for particular devices
-FUSE_H =
-AVRDUDE = avrdude -c usbasp -p $(DEVICE) # edit this line for your programmer
+DEVICE = atmega328p
+F_CPU   = 16000000 # in Hz
+FUSE_L = 0xff# see below for fuse values for particular devices
+FUSE_H = 0xd9
+AVRDUDE = avrdude -c avrisp2 -P usb -p $(DEVICE) # edit this line for your programmer

CFLAGS = -Iusbdrv -I. -DDEBUG_LEVEL=0
OBJECTS = usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o main.o
@@ -125,6 +125,8 @@
clean:
     rm -f main.hex main.lst main.obj main.cof main.list main.map main.eep.hex main.elf *.o usbdrv/*.o main.s usbdrv/oddebug.s usbdrv/usbdrv.s

+main.o: main.c usbconfig.h
+
# Generic rule for compiling C files:
.c.o:
     $(COMPILE) -c $< -o $@
diff -x usbdrv -X lufa-dontdiff.txt -u -r vusb-20100715-orig/examples/hid-mouse/firmware/usbconfig.h vusb-20100715/examples/hid-mouse/firmware/usbconfig.h
--- vusb-20100715-orig/examples/hid-mouse/firmware/usbconfig.h    2010-07-16 02:43:47.000000000 +1000
+++ vusb-20100715/examples/hid-mouse/firmware/usbconfig.h    2010-11-22 09:07:33.000000000 +1100
@@ -27,7 +27,7 @@
/* This is the port where the USB bus is connected. When you configure it to
* "B", the registers PORTB, PINB and DDRB will be used.
*/
-#define USB_CFG_DMINUS_BIT      4
+#define USB_CFG_DMINUS_BIT      3
/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
* This may be any bit in the port.
*/
@@ -116,7 +116,7 @@
/* Define this to 1 if the device has its own power supply. Set it to 0 if the
* device is powered from the USB bus.
*/
-#define USB_CFG_MAX_BUS_POWER           20
+#define USB_CFG_MAX_BUS_POWER           400
/* Set this variable to the maximum USB bus power consumption of your device.
* The value is in milliamperes. [It will be divided by two since USB
* communicates power requirements in units of 2 mA.]

I applied this patch:

[mjd@onza src]$ cd vusb-20100715
[mjd@onza vusb-20100715]$ patch -p1 < ../vusb-20100715-mjd-1.diff
patching file examples/hid-mouse/firmware/main.c
patching file examples/hid-mouse/firmware/Makefile
patching file examples/hid-mouse/firmware/usbconfig.h
[mjd@onza vusb-20100715]$

Then compiled the software:

[mjd@onza vusb-20100715]$ cd examples/hid-mouse/firmware
[mjd@onza firmware]$ make hex
cp -r ../../../usbdrv .
avr-gcc -Wall -Os -DF_CPU=16000000 -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=atmega328p -c usbdrv/usbdrv.c -o usbdrv/usbdrv.o
avr-gcc -Wall -Os -DF_CPU=16000000 -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=atmega328p -x assembler-with-cpp -c usbdrv/usbdrvasm.S -o usbdrv/usbdrvasm.o
avr-gcc -Wall -Os -DF_CPU=16000000 -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=atmega328p -c usbdrv/oddebug.c -o usbdrv/oddebug.o
avr-gcc -Wall -Os -DF_CPU=16000000 -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=atmega328p -c main.c -o main.o
avr-gcc -Wall -Os -DF_CPU=16000000 -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=atmega328p -o main.elf usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o main.o
rm -f main.hex main.eep.hex
avr-objcopy -j .text -j .data -O ihex main.elf main.hex
avr-size main.hex
text data bss dec hex filename
0 1872 0 1872 750 main.hex

And now I can program the Doodad:

[mjd@onza firmware]$ su
Password:
[root@onza firmware]# make flash
avrdude -c avrisp2 -P usb -p atmega328p -U flash:w:main.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "main.hex"
avrdude: writing flash (1872 bytes):

Writing | ################################################## | 100% 0.65s

avrdude: 1872 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex contains 1872 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.52s

avrdude: verifying ...
avrdude: 1872 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

[root@onza firmware]# make fuse
avrdude -c avrisp2 -P usb -p atmega328p -U hfuse:w:0xd9:m -U lfuse:w:0xff:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: reading input file "0xd9"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xd9:
avrdude: load data hfuse data from input file 0xd9:
avrdude: input file 0xd9 contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xff"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xff:
avrdude: load data lfuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

[root@onza firmware]#

As a prelude to trying it I also filed away the end of the board so it can fit into a USB port.

Well after that, I power cycled the Doodad, and the second last LED is lit. And if that wasn't impressive enough, After I plugged it into my computer's USB port, the mouse cursor started moving around in a large circle, and the LEDs are counting!

Here's what lsusb shows:

The mouse is the "VOTI" entry. The USB vendor ID and product ID can be set in the software.

Now to see the details:

Ignacio Garcia, dingux.com: Suggestions for the next generation consoles

noreply@blogger.com (booboo) — Thu, 02 Dec 2010 14:36:10 +0000

While I was with the CC folks I discussed with them a few suggestions I had for what I though would be the killer console, just in case some could be implemented in their next generation. They're eager to listen to users. That's invaluable IMHO.

Mind you, these are my own suggestions and that means some of them may be pointless since as you may already know I'm not a gamer. So, I'll really appreciate all kinds of comments.

I also collected suggestions from the people at #dingoonity IRC channel during one of the sleepless nights.

These are my suggestions:

At least 256MB RAM (this is already confirmed).
4.3" or larger LCD (larger would probably hinder portability).
Powered USB OTG port (GA330 is OTG but not powered).
Host USB type A connector on the top side. Would allow easy use of WiFi or bluetooth dongles to add wireless capabilitites (internet, multiplayer, etc). Proably the only way to place such a connector without making the console too think would be to use a PCB cutout, such that the connector, instead of being on the PCB, is "into" the PCB (i.e. center of connector aligned with PCB).
One microSD slow and one SD/MMC slot with SDIO capability, which would allow use of wireless SDIO cards. Note that the host USB type A connector mentioned above would probably be a much better solution, since there are many more USB dongles to choose from and they're much cheaper than SDIO cards (you can buy a tiny bluetooth dongle for less than $6 shipped).
Allowing external wireless through either host USB type A or SDIO has some nice advantages over the internal 2.4GHz module currently used in the GA330:

You can connect to another GA330, your mobile phone, home network, and whatnot. With the internal 2.4GHz module you can only connect to another GA330.
Brings down the price of the console for users that don't need wireless anyway. For those that want it, it's dead easy to add it (mostly in the case of the hust USB type A connector). They could even sell a "wireless edition" pack including the dongle.
Lack of wireless in the base console eases CE/UL certification (in case they ever want to comply).

Hardware color space conversion and scaling (already in the CC1800 VPU, and of course in the CC2000 which has a GPU).
Good subtitle support. Their high end PMP HD8900 already does support subtitles, buy they lack the black outline which is fundamental to ensure readability independent of image, and fails miserably (and silently) to load some subtitle files (I was able to solve this by rewriting then in strict UTF8 encoding, but this should not be necessary).

These are from #dingoonity:

Include Dingux plus a bundle of GPL games in each A320/GA330, and advertise it on the box as a selling point. Community will be happly to prepare such a bundle. In order to comply with the GPL the source code could be supplied in a separate subdirectory with a README stating that it can be safely deleted to reclaim some disk space.
License the full version of some famous OSS games like Doom, Duke Nukem 3D, etc, and include them in the bundle above.
Use the third connection of the headphone jack as a mic or line input, as it's used in many handsfree headphone kits. Usage of such a feature would be certainly minoritary, but it's essentially free (they're already using a three pin headphone jack in the A320 and I bet the codec they use in the GA330 already has MIC bias and MIC input pins).
Analog joypad. This would be great for games, but notice that this would provide the necessary pointing device for a web browser, for example.
Route all the unused GPIO pins to test pads on one clear area of the most accessible side of the PCB (both in the A320 and GA330 this would be the opposite side to where the LCD is connected, that is, the side you can access right after opening the case). Would be great if among those pins there was a I2C or SPI bus. This would be great for diehard hardware hackers, and is essentially free since doesn't increase manufacturing costs.

Ignacio Garcia, dingux.com: GA330 serial console

noreply@blogger.com (booboo) — Tue, 30 Nov 2010 20:38:40 +0000

I just added a serial console port to one of my GA330. The pictures below detail the TX and RX pins location and the final result.

Green wire is TX, orange is RX, white is GND (you can probably connect to GND more easily anywhere on the other side of the PCB).

For the curious, here's the boot output (57600 8N1):

ChinaChip IPL V1.04
Data : Jun 08 2010 Time : 17:31:33

SDRAM CAPACITY IS: 04000000
89D7943E
000084FF
Total Size = 0x00047D60

!!! Ecc Correct Error !!!
!!! Ecc Correct Error !!!
.!!! Ecc Correct Error !!!
.Loader Size = 0x00037D60

ChinaChip SPL V1.14
Data : Aug 06 2010 Time : 16:02:01

loader is normal mode...
loader_burning = 0
Battery Voltage = 3746.
g_poweron_vol = 3550
ccpmp_config Ver : 1.08 !!!
LCD Set Init !!!!
LCD Set Init Over !!!!
ccpmp_config.firmware_name = A330.HXF ...
ccpmp_config.update_key = 0x81 ...
ccpmp_config.lcm_name = LCM_TB_TD030WHEA1_320_240 ...
LCD Init Begin.

CN2009P_CFG.DL Data : Aug 25 2010 Time : 17:38:37

****** Enter LCD Init ******
wHCLKDIV = 1, wLCLKDIV = 0
num = 0, flag = 0
num = 1, flag = 0
num = 2, flag = 0
num = 3, flag = 0
wHCLKDIV = 1, wLCLKDIV = 0
num = 1, flag = 1
update key bDevMode = 0
ccpmp_config.load_mode = 0
ret = 0x00102878
usb_mode = 1
NAND ID:
89D7943E
00008400
A0FFFFFF
0000FFFF
A0FFFFFF
0000FFFF
80FFFFFF
0000FFFF
A0FFFFFF
0000FFFF
Nand manufacturer 0: inter
Nand type 0: 4GB
Nand manufacturer 1: Unknown
Nand type 1: Unknown
Nand manufacturer 2: Unknown
Nand type 2: Unknown
Nand manufacturer 3: Unknown
Nand type 3: Unknown
Nand manufacturer 4: Unknown
Nand type 4: Unknown
Nand manufacturer 5: Unknown
Nand type 5: Unknown
Nand manufacturer 6: Unknown
Nand type 6: Unknown
Nand manufacturer 7: Unknown
Nand type 7: Unknown
(dev 0)offset = 8192.
(dev 0)size = 131072.
(dev 0)nb_block = 256.
xxx -- nf_bi[0] 8192.
000 -- sta_block = 16, sta_chip = 0, end_chip = 8192.
xxx -- aaa.
001 -- end_block = 272, sta_chip = 0, end_chip = 8192.
xxx -- bbb.
xxx -- 002.
(dev 0)start chip = 0.
(dev 0)start block = 16.
(dev 0)end chip = 0.
(dev 0)end block = 271.
_this->start_chip = 0, _this->end_chip = 0.
nand_scan_blocks -- 000.
nand_scan_blocks -- 001.
block range of partition 16 ~ 272 on chip 0.
Found bbt at block 16, ver:0x0001.
bklight level: 00000004
bk value = 98
update_succ = 0
ccpmp_config.load_mode = 0
hxf_exist = 0
Play Logo on Music !!!
animation total frame = 15.
CC1800 Run OS ....
nandc0 - chip0, ID: 89 d7 94 3e 84 0
nandc1 - chip0, ID: 80 fe ff ff ff ff
nandc1 - chip1, ID: 80 ff ff ff ff ff
nandc1 - chip2, ID: 80 fe ff ff ff ff
nandc1 - chip3, ID: a0 ff ff ff ff ff
gDiskCapacity = 7941120
begin fs_init...
begin cc_ntfs_init ...
cc_ntfs_init ok ...
fs init OK.
s_wLongPressGOHOME -1
SWITCHOFF KEY register -1
RMT 17 )
LCD Set Init !!!!
LCD Set Init Over !!!!
Init UDC
in otg init 3-14
out otg init
OS Heap Information:
Total Size: 0x00e00000
Used Size: 0x00245e24
Free Size: 0x00bba1dc
AP Heap Information:
Total Size: 0x02000000
Used Size: 0x0018ec8c
Free Size: 0x01e71374
OS Heap Information:
Total Size: 0x00e00000
Used Size: 0x00245e90
Free Size: 0x00bba170
AP Heap Information:
Total Size: 0x02000000
Used Size: 0x0018ec8c
Free Size: 0x01e71374
OS Heap Information:
Total Size: 0x00e00000
Used Size: 0x00245e90
Free Size: 0x00bba170
AP Heap Information:
Total Size: 0x02000000
Used Size: 0x001ff61c
Free Size: 0x01e009e4

Ignacio Garcia, dingux.com: Back from China

noreply@blogger.com (booboo) — Tue, 30 Nov 2010 14:29:54 +0000

I'm back in one piece. It's been an exhausting trip and an amazing experience. I'm still in conversations with ChinaChip and will be writing some more updates in the following days. Meanwhile, a quick trip log:

20/11 Sat - Flight from Valencia to Paris, where I have a 6h transfer.

21/11 Sun - Flight from Paris to Hong Kong. The 12h trip is not as bad as expected because I score nothing short of 9h sleeping. They pick me up at the airport and take me to Shenzhen, have dinner, and then go to Dongguan straight to the hotel. I realize I'm gonna have a very hard time getting used to the chinese pronunciation of english.

22/11 Mon - Pick up at the hotel, not too early because I'm seriously jetlagged and wasn't able to sleep much. We go to the ChinaChip main headquarters and factory where I'm introduced to all the department heads and a few engineers. I visit all the facilities including the factory, and later have a meeting to outline the matters we should discuss in the following days. Excellent dinner with ChinaChip's president.

23/11 Tue - I've been able to sleep just a couple of hours from 10:00 to 12:00, and it's now 7:00 and I'm broken. Had arranged pick up at 9:00 but must delay it a few hours in order to try to catch some sleep. End up having lunch before going to ChinaChip's headquarters, where I spend most of the rest of the days in meetings.

24/11 Wed - Was able to sleep a bit more, so we can go early to the headquarters. More meetings in the morning, and then a walk around Dongguan downtown main square, which is amazingly huge. Late in the evening we travel to Shenzhen where we pay a quick visit to the marketing an sales offices and then go to the hotel to leave the baggage. Nice seafood dinner by the hotel and out to a club for a few beers and some fun.

25/11 Thu - Visit to the China Folk Culture Village park in Shenzhen, where you can see scaled down reproductions of the most important chinese landmarks, together with some other cultural information on the many ethnic groups. The park is huge and we spend the whole morning there. Then lunch and visit to Shenzhen's shanzhai market, which is shocking and will require a whole post. I could have very well spent several days in the market, but had to travel to Hong Kong, where we arrive by 21:00 after a tedious trip and several customs inspections. There's not much day left, so I just have a short walk on the Kwoloon shore to admire the island's view.

26/11 Fri - Full day on my own in Hong Kong. So much to see, so many people everywere. This also requires a whole post.

27/11 Sat - Plane takes off at 10:45, 13h flight (I score only 7h sleep in this one), 2.5h transfer in Paris, 1.5h flight and back in Valencia.

I'll also try to quickly summarize, for now, the content of the meetings with the ChinaChip folks:

- They will make changes to their bootloader and internal flash layout so that the dingux kernel and rootfs is installed in the internal flash. Both for the A320 and GA330 consoles. You'll have access to the internal flash from dingux (but the NTFL won't be released). The installation of dingux will be streamlined in the same way native firmware updates are, so no need to fiddle with usb tools any more.

- There will be dingux for the GA330, with full hardware support, and full open source. There's no problem with knockoffs here because it is based in their propietary CC1800 chip not available to third parties (as opposed to the JZ4732 in the A320).

- There is no schedule for the above as of now, since they're yet to decide if and how they'll sponsor it. In other words, one extreme is I work on it on a hobby basis as I've been so far and at zero cost, and the other extreme is they hire me full time. Anything in between is possible.

- The next generation of consoles will be based on the CC2000 and expected to roll out by Q2 next year. The CC2000 will be announced in a month or so, and I've been kindly asked not to reveal the details, but as you can imagine, it's beast compared to the JZ4732 and CC1800.

I'm sure I'm leaving something out, but I'll continue posting as things come up while I review my notes and prepare the reports of the meetings I'll be sending to ChinaChip. I'll also review the huge lot of pictures I took and post some.

Someone at #dingoonity said he needed a replacement speaker for his A320. Got it, but don't remember who he was. Email me, please.

Marcan's Abort, Retry, Hack?: OpenLase: open realtime laser graphics

Wed, 24 Nov 2010 02:25:52 +0000

Update: see this post for hardware info and also a new GL laser simulator for those without hardware.

First of all, as I’m sure everyone knows by now, I’ve been working on hacking the Kinect and writing open drivers for it. There’s a website for the community and a Git repo with the code, and it’s working fairly nicely by now.

With that out of the way, here’s a project that I’ve been working on on-and-off for the past year or so. I’ve been interested in laser scanning and DIY laser projectors, but I couldn’t find any good open source software to drive them. Specifically, I was interested in the realtime aspect: rendering and showing dynamically generated images and responding to events, not just making and preprocessing laser shows. So I set out to write my own set of software to do real-time rendering. This was the result:

DIY laser projectors commonly use sound cards as DACs. This shifts most of the processing over to the PC, but also lets us get very fine control over the realtime aspects of projection, which is what I want. Thus, my laser projector is based on a bog-standard USB soundcard, modified to pass DC. I’ll probably write a detailed article on the hardware later, but suffice it to say that it’s a galvo kit, a hacked chinese laser pointer, my own laser driver and monitoring circuitry, and some other minor parts. Total cost is about €200, if you play your cards right.

Since we’re converting laser images to audio data, why not just treat the laser data as audio in the first place? After all, laser samples are audio-rate data, and 16-bit multichannel 48kHz fits the requirements for laser projection very well. So that is what I did. OpenLase isn’t really a monolithic framework. Instead, it’s a series of stand-alone applications and chunks built on the excellent JACK audio connection kit, which serves to pipe realtime laser data around the different bits.

On a typical setup, you’d have two processes running on top of JACK. On one hand, there’s the output processor, which is responsible for formatting the idealized laser data to suit the peculiarities of the hardware. This includes things like brightness scaling, the obvious X/Y inversion settings, the final output perspective transform (to fit the screen), and minor filters to try to compensate for hardware imperfections. It also generates a 1kHz square wave on one channel – this is a peculiar safety feature of my laser hardware. I have a microcontroller monitoring this signal, such that if the software hangs or crashes for some reason, the laser shuts down immediately (to avoid having a static dot which would be a serious eye hazard). The OpenLase output processor has a simple Qt GUI that lets you tweak these settings on the fly.

On the other hand, you have whatever picture source you want to use. You can have bare JACK applications, such as two examples: ‘circlescope‘, a circular oscilloscope that takes realtime audio data from a media player, and ‘playilda‘, a bare-bones ILDA file player (ILDA / .ild is the standard file format for laser graphics). The circlescope is particularly good for showing off the real-time aspect (note that the input can come from the laser DAC’s line-in with only the small JACK buffering delay):

However, the other big part of OpenLase is libol, a realtime rendering library loosely modeled on OpenGL which lets you produce 2D and 3D graphics on the fly. This is what I used for the LASE demo above. The demo itself isn’t currently open source (and the code is utterly horrid – I wrote half of it at Euskal Encounter and finished it mere minutes before the deadline), but if there’s demand I might open source it too, just please don’t expect pretty code! However, keep in mind that most features used by the demo (text rendering, 3D, “shaders”, ILDA file loading, etc.) were implemented as part of libol, so you aren’t missing out on much. There are two libol-based examples: some rotating cubes, and Pong.

There’s one part of the demo made it into the OpenLase distribution as a separate example: tools/trace.c. This used to be some tracing code that I used for the metaballs and fire effects (I kind of cheated there, as those are rendered as bitmaps and then traced in realtime into laser vectors). It’s a terribly naive algorithm (check the source out for details), but it worked surprisingly well for certain kinds of video, so I hacked it and tacked on more heuristics in order to attempt to make it work better. It now lives next to tools/playvid.c, which is a simple video player using libavcodec. Here’s what it looks like (improved version (mkv), original YouTube video). More complex videos are hit and miss, but some things turn out surprisingly well for such a silly algorithm.

You can also add filters between the output and the image generator. This is what I did for my Kinect + OpenCV + OpenLase demo, which projects anything projectable by OpenLase onto a moving screen, with a dynamic perspective transform (in this case the perspective transform happens in the filter, not in the output processor). That code currently doesn’t even build with current libfreenect, but again, if someone is interested, drop me a line and I’ll make it work again and publish it.

OpenLase doesn’t have any facilities to patch together these JACK apps. Instead, you should just use existing JACK tools, such as QJackCtl, to connect all the input and output ports together. QJackCtl has a patchbay feature that automagically connects the ports when applications start up, so it’s quite seamless.

Right now there is pretty much no documentation, but I’d like to know if people are interested. If you have (or want to build) this kind of DIY hardware, you run Linux or some other UNIX that can run JACK, and you’re interested in hacking on the code or using it for something, please let me know! Here’s the git repo.

Update: Three more videos, musically themed. A laser visualization of MIDI data (MIDI to laser):

And the other way around, a laser harp (laser to MIDI):

Zedstar: A minimal OpenWrt image for the Openmoko Freerunner containing GNU Guile

Tue, 23 Nov 2010 20:24:59 +0000

To experiment some more with OpenWrt I dusted out a Freerunner and built a minimal image containing GNU Guile. The image is built with glibc and an IP 192.168.254.101 to match my Nanonote settings.

** UPDATE: GNU Guile now has readline support and root image now contains GLib **

Flash the following:

http://zedstar.org/freerunner/openwrt-s3c24xx-2.6-uImage

http://zedstar.org/freerunner/openwrt-s3c24xx-root.jffs2-128k

Boot the device then:
john@thinkpad:~$ telnet 192.168.254.101
Trying 192.168.254.101…
Connected to 192.168.254.101.
Escape character is ‘^]’.

=== IMPORTANT ============================
Use ‘passwd’ to set your login password
this will disable telnet and enable SSH
——————————————

BusyBox v1.16.1 (2010-05-02 14:45:14 BST) built-in shell (ash)
Enter ‘help’ for a list of built-in commands.

_______ ________ __
| |.—–.—–.—–.| | | |.—-.| |_
| – || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
KAMIKAZE (bleeding edge, r21293) ——————
* 10 oz Vodka Shake well with ice and strain
* 10 oz Triple sec mixture into 10 shot glasses.
* 10 oz lime juice Salute!
—————————————————
root@OpenWrt:/# uname -a
Linux OpenWrt 2.6.30.10 #1 PREEMPT Sun May 2 14:59:31 BST 2010 armv4tl GNU/Linux
root@OpenWrt:/# guile
guile> (string-tokenize “hello world”)
(“hello” “world”)
guile>

Ignacio Garcia, dingux.com: Traveling to China

noreply@blogger.com (booboo) — Sat, 20 Nov 2010 20:19:32 +0000

I'm leaving tomorrow to HK/China, where I'll be meeting the ChinaChip people. Will be back in a week, but will try to update as time permits on anything relevant to dingux on the GA330.

UPDATE: Paris CDG airport is da bomb. At least in terminal E where I am as I write this, plenty of places to lay and take a nap, massage chairs, PS3 for entertainment (free). The 5 hours I have to wander here suddenly don't feel so uphill.

They even have 10 minute free wifi. Too bad it's only 10 minutes. Unless you disconnect, clear the browser cookies, change the WiFi interface MAC address, and connect again, of course. You didn't read that here.

sudo ifconfig wlan0 hw ether [your previous MAC + 1]

Ignacio Garcia, dingux.com: DA330 ---> GA330

noreply@blogger.com (booboo) — Mon, 08 Nov 2010 00:42:48 +0000

I'm not sure I understand as of know the relationship between ChinaChip, Dingoo, and Dingoo Technology. It appears that there are two Dingoo companies, one that produces 3D games and another that actually produces the A320. Both belong to ChinaChip group. Then there's Dingoo Technology, which have marketed the A330 which is basically an A320 (JZ4732/JZ4740 SoC) with a different case/LCD, 64MB RAM and stolen firmware. In order to avoid confusion with the later, at some point I decided to refer to it as A330 and to refer to the newer, CC1800 based machine as DA330. But I was mistaken since it is Gemei (another company of the ChinaChip group) who will be marketing it (my two sample machines have both the Gemei logo). So, I figured out I'd rather fix this silly mistake soon. So, from now on, I'll refer to the newer CC1800 based A330 as GA330.

Sorry for any caused confusion. I've edited previous blog entries to reflect this change.

Ignacio Garcia, dingux.com: GA330 specs

noreply@blogger.com (booboo) — Mon, 08 Nov 2010 00:39:32 +0000

I believe there's some confusion on the GA330 specs. As I mentioned in the previous post, I have only preliminary, general, info, but this is what I found out so far (don't take it for granted anyway):

CC1800 processor (ARM926 400MHz).
320x240 LCD, slightly larger than the A320 one.
64MB RAM.
2.4 GHz communication module. This is a true radio device and not just a keyboard hack. Enables multiplayer and custom peripherals.
USB OTG port, which allows connecting USB devices, but you'll need external +5V power (i.e. a powered hub).

The CC1800 has some nice features: the OMIP seems to be a video decoding coprocessor, and the VPU seems to be some kind of video post processor which can do quick scaling and color conversion before spitting out the data to the LCD.

I would say that the CC1800 CPU core belongs in the same class than the JZ4732 in the A320, however, being an ARM architecture has the advantage of the existing assembly optimized emulation cores. I bet that the VPU will allow a sizeable boost in performance by offloading the color conversion work from the SDL code.

64MB vs. 32MB in the A320 are a big advantage too.

Ignacio Garcia, dingux.com: GA330 guts

noreply@blogger.com (booboo) — Mon, 08 Nov 2010 00:38:38 +0000

It's been some time now since I received the two Gemei A330 sent by ChinaChip (GA330 from now on, to distinguish it from the other A330 out there which is basically an A320 with 64MB RAM). We're still working out the details (NDA, possible trip to China) to acquire the required info on the CC1800 SoC (system-on-chip) in order to port dingux to it, and it might still take a bit longer. Please excuse me if I don't comment more on the matter until everything is settled.

I'm working on the x760+ dingux port. As I said, I have all the required info, but time is limited and I've invested most of it reviewing all my initial work together with recent developments. Please be patient (yes, even more, sorry).

Meanwhile, here you have some electronics pron:

You'll notice that there is no battery in the pictures. The samples were sent without battery due to customs regulations, and though it's not strictly necessary for development, I'll get hold of substitutes soon.

You know I don't use the A320 and GA330 much for gaming (lack of time, you know, bla bla bla), so I can't give you a thorough review of the new GA330. Here are some first impressions. Please bear in mind that I'm not sure to which point the samples I got are definitve production machines, so take it with a pinch of salt:

The construction build feels good but not as good as the A320.
The LCD is exposed, i.e. there is no plastic protection (which is part of the enclosure) over it, as happens in the A320 and the X760+. This is definitely a no-no.
The LCD is a "delta matrix" type. Don't know much about the technology (I'll appreciate links), but it basically means that the color dots are not aligned in an orthogonal matrix but spread in a zig-zag pattern. This is supposed to be better for displaying pictures and video, but I think it's not good for games.

Please let me stress what I already said: these might not be definitive production units and the final product to market may have many of these thingies fixed. Also, note that ChinaChip actively supporting linux on their machines is a huge advance, and a first in the chinese PMP market as far as I know. And more powerful machines will come in the near future.

One final comment on the CC1800: it as a video processing unit (VPU) capable of doing scaling and all kinds of color conversion. The JZ4732 in the A320 has an image processing unit (IPU) which unfortunately is only good for converting YUV to RGB. This is very useful for video playing but useless for gaming. The CC1800's VPU will allow to provide each game with the framebuffer resolution and color space which is best suited, allowing for a significant increase in performance. Being an ARM processor will allow also to use the already existing assembly optimized emulation cores, for another boost in performance.

Ignacio Garcia, dingux.com: hwinit fixed

noreply@blogger.com (booboo) — Sun, 07 Nov 2010 21:52:17 +0000

I just modified hwinit (in the subversion repository) so it works on all A320 out there. These are the changes:

Added WP bit clean in CP0 CAUSE register (original idea by BouKiCHi).
Added LCD init and logo display as visual feedback of hwinit success (original idea also by BouKiCHi).
Code cleanup and removal of unneeded nand code.

Kudos to BouKiCHi for an awesome work of debugging.

The first fix is just weird. CP0 means "coprocessor 0" in MIPS architechture. It's the part that takes care of memory management, exceptions, privilege levels and such. It turns out that some versions of the IPL (Initial Program Loader) ROM code in the JZ4732 set up the WATCH registers in such a way that a watch exception occurs but it deferred (by setting the bit WP in the abovementiones CAUSE register). Then later, when the linux kernel boots, as soon as it sets up the CP0 STATUS register (another special regitser of the same "coprocessor"), the WATCH exception is immediately serviced, caused an unhandled exception panic (that is: for people suffering this problem, hwinit was actually working, but the kernel was panicking way before the LCD was initialized, so they could see nothing at all).

Why some IPL ROM versions behave this way is a mystery, and would be harmless if the kernel MIPS initialization code was careful enough as to clear the WP bit before setting up the CP0 STATUS register (I bet this is fixed in more recent kernels, but I'm too lazy to verify it).

I'm working to provide a native firmware based dual boot installer, so this hwinit issue wasn't really top priority, but it had bugged me for so long that I just had to sort it out before continuing. I'm just like that, like to walk on solid ground and feel very uncomfortable when I leave loose ties behind me.

I won't make a new dual boot installer release with just the fixed hwinit, since by now I guess all those with trouble have eventually been lead to hwinit2. Next release should, in my opinion, include at least:

A newer kernel with:

Fixed I/O corruption bug(either Ingenic or OpenDingux based).
with support for newer flash chips in recent A320.
Support for x760+.

An updated buildroot and toolchain, with both 32 and 64 bit versions. I had to upgrade my buildroot since the old one didn't compile in my Ubuntu 10.04 x64 box.

Ignacio Garcia, dingux.com: x760+ key mappings

noreply@blogger.com (booboo) — Thu, 04 Nov 2010 19:23:51 +0000

I know I asked this before, but it was loooong ago, and I'd like some more input on the topic. The x760+ has only UP/DOWN/LEFT/RIGHT/A/B/X/Y keys, which means START, SELECT, LSHOUDLER, RSHOULDER and HOLD are missing and they'll have to be emulated or I guess some dingux apps out there will not be usable.

The funny thing is that the schematic shows actual HOLD, START and SELECT keys. Incidentally, it also has LSHOULDER and RSHOULDER, but those are available only as test pads (which means someone with enough time could theoretically add them).

So I've though this simple approach:

POWER + UP = LSHOULDER
POWER + DOWN = SELECT
POWER + Y (triangle) = RSHOULDER
POWER + B = START

None of those combinations will be comfortable to use, but it's better than nothing. I just chose the combinations so they reflect the spatial locations of the corresponding keys in the A320. Will have to increase the reboot/poweroff time when POWER is pressed, otherwise it might be accidentally triggered when using the combos.

Comments welcome.

Gerard Braad: How-to setup dual-booting MeeGo 1.1 on the N900

noreply@blogger.com (gbraad) — Thu, 04 Nov 2010 05:39:00 +0000

The current image of MeeGo is for development purpose. Do NOT try to use it for daily use. You can make a phonecall or send a message, but I already had some issues with not being able to pick up phonecalls which I receive. It should be used as a means for developers to get familiar to the MeeGo environment for use on a handset. Also see the note at the end of this article.

For this how-to I use Fedora 13, but tmost of the steps also apply to any other Linux distribution. Be sure you have downloaded the correct MeeGo images before you begin and that you have a MicroSD card of 2G or more. I used a 4G MicroSD card from SanDisk.

The kernel root filesystem you download have to download from: http://repo.meego.com/MeeGo/releases/1.1/handset/images/meego-handset-armv7l-n900/

You need the following two files:
meego-handset-armv7l-n900-1.1-mmcblk0p.raw.bz2 (521M)
meego-handset-armv7l-n900-1.1-vmlinuz-2.6.35.3-10.3-n900 (1.5M)

N900
Enable the extras-devel repo on your device and install from app-manager: uboot-pr13
or from the terminal with:

 # root
$ apt-get install uboot-pr13

Be sure you have upgraded to PR1.3 before doing this. This is all that's needed on the mobile handset.

Workstation
On Fedora you have to install the uboot-tools to create a bootable kernel image. For writing the disk image I also included pv to have some progress indication. Install these tools with:

$ yum install uboot-tools pv cfdisk

Connect your N900 in Mass Storage mode with the MicroSD card inserted or use a multicard reader. As mentioned before, use a 2G or more MicroSD card to dump the raw image to. You have to find the correct device to use from e.g. the dmesg, replace sdX with the correct device. The command for this is:

$ bzcat meego-handset-armv7l-n900-1.1-mmcblk0p.raw.bz2 | pv | sudo dd bs=4096 of=/dev/sdX

Note: This may take some time, especially on the class of SD card you are using. I used just a class 2 4GB from SanDisk. Also be sure it is not mounted during this action. Some distributions use auto-mounting for Removable Media.

To make the MicroSD card usable for dual-booting you have to add a third partition. This might be a little more tricky if you haven't done this often. That is why you can use cfdisk.

$ cfdisk /dev/sdX

And add a new partition in the last freespace you see. The first is only 1.3MB, which is TOO small to contain the kernel image. Define it as a primary partition of 4MB (or full size). Take note of the device name. It should be sdX3.

Now create a FAT filesystem on the newly created partition. This is where your kernel needs to be placed.

$ mkfs.vfat /dev/sdX3

Now you need to prepare the kernel image for use on the SD card.

$ mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008000 -n meego-handset-armv7l-n900-1.1-vmlinuz-2.6.35.3-10.3-n900 -d meego-handset-armv7l-n900-1.1-vmlinuz-2.6.35.3-10.3-n900 uImage

You would now have a file called uImage which you need to place in the FAT filesystem on /dev/sdX3. If you have difficulty creating the file, you can download it from here. Be sure you rename it to uImage. Temporarily mount it or reinsert the SD card so auto-mount can deal with it. Copy the uImage file to the root and unmount.

Now you could use this MicroSD to boot MeeGo 1.1. Try it out by powering off your N900 phone, remove the backcover and place the SD card. Be sure you have placed the backcover before you power on the device. If you don't do so, the root filesystem can not be mounted and the device will show a kernel panic.

External links

Note
I do not take any responsibility in you damaging your device or loosing data during the process. As I had mentioned, it is intended for development use and therefore I hope you have some basic understanding of what you are doing. If you have any question, please post them in the MeeGo Handset forum.

Capn's Tech: USB Doodad: An SMT exercise project

noreply@blogger.com (mjd) — Thu, 04 Nov 2010 01:21:41 +0000

Surface mount soldering doesn't have to be scary!

Way back in the distant past when I learned electronics, components were "through hole". That means that components such as resistors had a wire out each end, and these wires were bent and passed through holes in a circuit board, then soldered.

An example through-hole board.

These days, through hole technology is on the decline. It's becoming harder to get the newer integrated circuits in through-hole form. In its place, more and more people are using "surface mount" technology to build circuits. With SMT, components are often in the form of a tiny block, which is placed on a circuit board, directly in contact with the circuit board tracks, then soldered into place.

An example SMT board.

Many people I've spoken to think that using SMT is harder than through-hole. Sure, many SMT components are very tiny, but it's quite easy to buy larger sized SMT components.

As a project at our hackerspace, Connected Community Hackerspace, Ross McKenzie and I have been working on a project which shows people that doing SMT assembly is not as hard as people think. We have deliberately used the largest size of SMT components to make assembly as easy as possible.

The board has a USB connector at one end, a small expansion connector at the other, and a row of 16 software controlled LEDs in the middle.

The primary purpose of the board is to act as a practical exercise in surface mount assembly. The secondary purpose is to show how to use the V-USB software USB stack to make a USB device. The third purpose is to give the Doodad some post-tutorial value, in a number of intentionally frivolous ways:

Persistence-of-vision toy. Wave it around or put it on the wheels of your bike. Enjoy making groovy flowing messages in the dark.
Secure password keystore.
Log-data-to-serial-flash data logger, where samples could be retrieved over USB at some later time.
“Messages waiting” / “processor load” / “build progress” indicator.
Multimedia keys (if your keyboard doesn’t have them).
Novelty breathalyser.
Countdown timer for car parking reminder.

Our estimate for the cost of this board is about AUD30, so it's well within hobbyist reach.

We plan to release the design for this project under an open licence, possibly the TAPR OHL, which means that others can copy this design.

The project has been designed to use a single sided PCB. Although this makes the job of designing and routing the board traces much more difficult, being single sided means people can make this board at home.

For applications which require the doodad to operate independently of a PC, we plan to add a small Li-Ion battery and management chip to the reverse of the board.

More information about the project can be found in the USB Doodad Google doc.

Ross and I are making rapid progress, and I'll post more project updates here soon.

Capn's Tech: USB Doodad 3: Hot-air soldering of TQFP-32 chips

noreply@blogger.com (mjd) — Thu, 04 Nov 2010 01:20:02 +0000

The processor we're using in the USB Doodad is an AVR ATmega328P. This very capable processor is at the heart of the popular Arduino educational microcontroller platform.

The two most common packages for the ATmega328P are the PDIP-28 and the TQFP-32.

<Good place to insert picture of PDIP vs TQFP>

Because the whole purpose of the USB Doodad is to use surface mount components, we want to use the TQFP-32 package.

Image courtesy of SparkFun.

Armed with a USB Doodad prototype board that Ross etched, I thought it was time to try soldering this chip.

There are several ways to solder SMT ICs. A good guide is in this SparkFun SMT tutorial. The method I used was using solder paste and hot air.

In order to do hot air soldering, I use a "hot air rework station" which I bought for about $80 in China. I found another one at Ameritronics which looks very nice, nicer than mine.

Ideally, I'd use a syringe of solder paste, but I don't have one. Instead I used the paste I covered previously.

I applied my solder paste with a jeweller's screwdriver. Not a very precise way of doing it, but it did the job. I applied one thin line of solder paste along the line of IC pads, then squished the chip pins into the paste. Then I ran some liquid flux along the pins on all four sides of the chip.

Next, I used the hot air to melt the solder on each corner of the chip. That was to fix the chip into place. Finally, I ran the hot air along each side of the chip in turn. The combination of pins, solder paste and flux means that when the solder paste melted, it blobbed around each pin. I didn't get any bridges between pins, but if I had, I'm confident I could have fixed it with some desoldering braid.

My success makes me think that beginners could solder it too, if they had the right equipment (a hot air rework station). And if we had a board with a solder mask (as we'll surely have for Doodad a little further down the track), I think beginners could do it with a regular iron too, if they had a video to watch showing how it's done.

Well, that's how I soldered a TQFN-32!

Capn's Tech: USB Doodad 2: Board design and layout

noreply@blogger.com (mjd) — Thu, 04 Nov 2010 01:19:27 +0000

Some time ago, Ross and I discussed and agreed on what we'd like this board to do (and perhaps just as importantly, what we don't need it to do). How do we get from this stage to something people can assemble? One way is by making a prototype.

A prototype lets us:

Try out the circuit and different variations,
Try out the PCB layout and variations,
Try out the software and variations, and
Try out different assembly ideas.

Ross started off by finding a project in Elektor, a famous English-language electronics magazine produced in the Netherlands. What it has in common with the Doodad is that it uses an ATmega328P microcontroller, and uses V-USB to do software USB.

Using that project as proof of what is possible, Ross designed the circuit to our requirements, and did a PCB layout. Because we may use the underside of the board for other purposes later, Ross faced the additional constraint of having to make the board single-sided. He and I discussed and improved the circuit and the layout several times, and Ross reworked the circuit and layout to match.

In particular, if we use the same pins as the Elektor project, we'd only have 14 pins free for driving LEDs. Ideally however, we'd like 16 LEDs. We think by reassigning some pins, doing away with some features (for example, a bootloader exit button, and a reset button), and being creative with some circuit ideas (for example, using a resistor network to run a number of switches off some otherwise-unused ADC pins), we believe we can recover enough pins to give us 16 LEDs. We'd also like to be able to use the SDA and SCK pins on the expansion port so we can easily attach I²C devices such as sensors and storage ICs.

In order to do this pin experimentation, the board currently has a number of solder pads we can link to reroute various signals. Here's the current layout:

USB Doodad PCB artwork (v15)

On the left is the expansion port (+, - and two data pins). On the right is the USB finger port. Along the bottom is where the LEDs and dropper resistors will go. In the top right are the USB analog components. In the middle is the microcontroller, and to each side are the power supply and clock components. The switches go in the top left.

While this board may not do everything we want it to, it will let us answer a lot of the questions we need to answer before we can produce a final board ready for sending to a manufacturing house.

I want to say that Ross has done a top job: The single-sided layout constraint is pretty fierce, and the quality of the prototype board is easily as good as a bought one. I am learning a lot working with him.

Capn's Tech: Making PCBs using the toner transfer method

noreply@blogger.com (mjd) — Wed, 03 Nov 2010 15:44:46 +0000

Last year the folk at CCHS, my local hackerspace, did some work on producing PCBs using the photo resist method.

Because I don't have a UV box, and because I'd rather not keep buying UV sensitised PCB, I have been looking at the "toner transfer" method.

http://www.riccibitti.com/pcb/pcb.htm

Most people use glossy magazine paper, or glossy inkjet paper. I have been looking at other transfer materials.

Last year, I was using the slippery backing paper from sheets of labels. This didn't transfer too badly, but I did have somewhat of a problem of small sections of track flaking away from the backing paper before I could do the transfer. Also, I don't have much of the backing paper.

Last night I got to thinking of other transfer materials. Something I can print on, but would be willing to give up the toner when it's heated. I decided to try aluminium foil.

I've done some searching this morning, and it seems I'm not the first to think of using foil:

http://hackaday.com/2006/05/27/pcb-fuser-for-toner-transfer-etching/

Well, I did several experiments last night, what I can report is that the tracks on the aluminium foil transfer very nicely to the copper. If the heat is right, there's absolutely no toner left on the aluminium, and the foil can be quickly and cleanly peeled back to leave the tracks of toner on the PCB.

The artwork I'm using has SMT ICs of 0.6mm pitch, which means the tracks have to be really precise. I haven't yet got one that's of sufficient quality to etch, but I think I'm very close. Some of my attempts have had great tracks in the middle, but lost some tracks at the edge. Some of the attempts have had 100% transfer to the copper, but are a little smudged. I don't think this problem is because I'm using foil as a transfer medium. Rather, I think it's a problem with the way I'm doing the ironing to transfer the image. If I can refine the heating process, I think I can produce very high quality boards. I'd expect to be able to do thinner than the 0.6mm our group can get with the photo resist process.

I think I'll look into getting a laminating machine. More results to follow.

Ignacio Garcia, dingux.com: Electronica 2010

noreply@blogger.com (booboo) — Tue, 02 Nov 2010 16:11:30 +0000

Next week I'm going to electrodisneyla... er... I mean electronica 2010, in Munich. Since there are only direct flights from Valencia on tuesday and saturday, I'll be staying there for more days than I really need to visit the trade fair, so I'll have some spare time. Please let me take the liberty to use this otherwise technical blog to kindly ask for advice on what to do in Munich (besides beers and flash job interviews :-)

Thanks.

Antitronics: Knitting machines – Lady Ada takes the Baton!

Tue, 02 Nov 2010 13:20:01 +0000

There’s a great tutorial up by Lady Ada and Becky Stern which is based on some reverse engineering I did of a Brother Knitting machine. This is great, and makes me want to get that machine off the shelf.

It’s so great to find that something you threw out to the public is useful to someone.

Geoffrey L. Barrows - DIY Drones: Arduino optical flow sensor (fun breadboard prototype)

Tue, 02 Nov 2010 14:05:03 +0000

I'm learning to love things open source! To see what the fuss was about, I obtained an Arudino Duemilanove board from Sparkfun and decided to play around with it. It didn't take very long for me to assemble a (very) simple optical flow sensor using this board and one of my 16x16 Tam vision chips.

The circuit is very simple- the only electronic components were the Arduino board, a 16x16 Tam vision chip I developed at Centeye, and a single bypass capacitor. The vision chip and the bypass capacitor reside on a one inch (25.4mm) square breakout board. This particular Tam chip is pretty simple to operate- aside from the power signals, it requires two digital inputs, clock and reset counter, and generates one analog pixel output. A counter on the chip determines which pixel is to be output (by row/column) at the output analog line. Every time the clock is pulsed, the counter increments and the next pixel is selected. Pixels are read out one row at a time. The pixel circuits themselves operate in continuous time and are always generating a voltage in response to light. The counter merely determines which pixel voltage is sent to a voltage buffer before being sent off-chip.

A simple Arduino program reads out the pixel signals, digitizes them with the Arduino/Atmel's ADC, and computes a simple one-dimensional optical flow measurement. For the optical flow algorithm, I chose a variation of the Hassenstein Reichardt algorithm, an venerable algorithm from the 1950's that was one of the first proposed neural models for visual motion sensing. The Arduino program then dumps the simple running graph of the optical flow onto the serial dump terminal.

The optical flow algorithm is very simple. Let pA and pB be the signals output by pixels A and B respectively. Let lp( ) be a simple low-pass filter function, which can be implemented as a running average. The optical flow estimated from pixels A and B is merely lp(pA*lp(pB)-pB*lp(pA)), with the outer low pass filter having a longer time constant than the inner low pass filters. If we have an array of pixels A, B, C, D, and so on, then we compute this algorithm once for pA and pB, then again for pB and pC, and again for pC and pD, and so on, and average the results. This certainly isn't the best algorithm one could use, but it was very simple to throw together and I was actually curious to see how it would work.

For this implementation, I'm only reading in the middle 8x8 block of pixels and row-averaging them to form an eight-pixel line image. Thus the optical flow output you see is really from eight pixels worth of image data, or seven individual optical flow measurements averaged together as described in the last paragraph.

The first video above shows the response when the 16x16 Tam chip is exposed to light and a moving card casts a moving shadow across the chip. The second video shows the response when a lens is placed over the chip, so that the image of my moving hand is tracked. The pictures below show the two complete sensor setups, with and without lens, and a close-up of the Tam chip on it's breakout board.

The purpose of this experiment was to see how easy it would be to throw together a simple optical flow sensor using an Arduino board and a simple image sensor chip. The results are certainly crude, but the concept works. I think with some more work a decent Arduino-based sensor can be made, and it could be as easy to hack as pretty much any other Arduino project. (Arduino rocks!)

For those that are curious, I have another post on another forum that shows simple ASCII images taken from the image sensor, and discusses the operation of the chip in greater detail.

(Note: The "Tam" chip here is similar to but not the same as the "Tamalpais" chip used in the recent post on the 125mg sensor. Both are 16x16, but the Tam has larger pixels and is simpler to operate while the Tamalpais is smaller and has better on-board amplification. There is a story behind both names...)

Geoffrey L. Barrows - DIY Drones: 125 milligram optical flow sensor "TinyTam"

Mon, 01 Nov 2010 19:30:00 +0000

As an exercise in size reduction, we have prototyped a complete optical flow sensor in a 125 milligram and 7mm x 7mm package. This mass includes optics, image sensing, and all processing. Below is a video and two close-up photographs. In the video, note the green vector indicating measured optical flow as a result of image motion.

Image sensor: Centeye Tamalpais 16x16 pixel image sensor (only an 8x8 block is being used), 1.3mm x 4.1mm, focal plane about 0.3mm x 0.3mm.

Optics: Proprietary printed pinhole, about 25 microns wide

Processor: Atmel ATtiny84

Optical flow algorithm: Modified "Image Interplation" algorithm, originally developed by Prof. Mandyam Srinivasan (well known for his research on honey bee vision and navigation).

Frame rate: About 20Hz.

This work is being performed as part of Centeye's participation in the Harvard University Robobees project, an NSF-funded project to build a robotic bee. The final target mass for the complete vision system (including processing) will be on the order of between 10mg to 25mg, and will include omnidirectional sensing as well as algorithms to detect flowers. Obviously we still have some more work to do!

We documented the construction of this sensor, with lots of photographs, in case anyone is interested.

Zedstar: SlowFi protocols on copyleft hardware

Fri, 29 Oct 2010 20:40:33 +0000

Recently I have been working on Packedobjects which included redesigning the API and replacing a lot of C code in Scheme. I will try and formalize the whole encoding process which I have called Integer Encoding Rules. I also began work on a manual which includes some examples. My aim is to support the tool on OpenWrt which also involves maintaining the GNU Guile build.

I built and tested the software on my Ben Nanonote. The ipk is available: http://zedstar.org/ipk/packedobjects_0.4_xburst.ipk

After improving the documentation I intend to use the tool in a networking course at work. I think it is important for students to gain some experience of designing and structuring binary network protocols. We will be getting a bunch of Nanonotes to compliment the Openmoko Freerunners we have. This will provide some nice hands on experience packing some data and communicating it across different kinds of hardware.

Long term, I am interested in designing some funky SlowFi protocols on copyleft hardware.

Capn's Tech: Open letter to seek.com.au: Suggestions for improvement

noreply@blogger.com (mjd) — Sat, 23 Oct 2010 18:48:26 +0000

From time to time I jump on seek.com.au to see what jobs are out there. They currently have a boring-as-all-getup survey to gauge how Seek users find the website. Buried in the survey is a text field which says "in what ways could the site be improved?".

Since I couldn't fit my suggestions in their text field, I'm posting them here, and I'll send Seek a link to here instead.

Goodness, where do I start???

Suggestion 0: Don't ask people "Please provide as much information as possible" then give them a 6-line text field to write it in.

I can list 20 more ways to improve your website. Please keep in mind that lots of my comments below are about how to make reviewing a large amount of data as simple and as speedy as possible.

I am an experienced Software Engineer in Melbourne. Naturally I look for jobs in the ICT classification, in the Melbourne area.

Job searching

Because I'm experienced, I could do jobs in several of the ICT sub-classifications. Not to mention that many jobs are misclassified. However your website only allows selection of one sub-classification at a time.

Suggestion 1: In the advanced search, allow users to select multiple subclassifications instead of just one.

Since your site doesn't let me do that, I'm forced to use "Any sub-classification". That means I have to trawl through a LOT of jobs, most of which won't be relevant to me. So it's vital that I can do that trawling as efficiently as possible.
While I understand many people just browse on your site, I'm the kind of guy who wants to be sure he's read every ad. So it's important to me to know where I got up to on my last visit. At the moment I start from the top and keep reading until yesterday's or last week's ads start appearing. But this is something the Seek website could do for me.

Suggestion 2: Have something like a bookmark, or a filter that says something like "show me only ads listed since I last visited".

Computers are very good at managing large amounts of data, and finding trends and correlations in that data. For example, one of the little known purposes of your supermarket's loyalty card is so that the supermarket can use "market basket analysis" to identify correlated buying patterns.

If you want an example, head to the Jango music site. Enter an artist. Jango starts playing music, and you can say whether or not you like that song. Your input, plus the listening patterns of Jango's other users, is used to start feeding you music from other artists. Jango very quickly starts playing you only the music you like, and through this I have discovered many really cool music acts. Go try it!

Suggestion 3: Use market basket analysis and other data mining techniques to say to a user "you liked that ad, you'd probably also like this ad". Then show them those ads.

Suggestion 4: Take this idea further, and play "20 questions" with the user. Show them two ads. Ask them which they prefer. Use their selection and some "affinity analysis" to find two more ads. Or show an ad and ask the user to rate it "hot or not". Twenty answers can whittle a million choices down to one. Twenty questions, and Seek can then say "based on that, here are the jobs we think you'll love". Implemented well, Seek could use this in a marketing campaign as "simply the fastest way to find the job that's right for you".

Presentation

Trawling means I scan a whole page of jobs, then go to the next page. I use space or PgDn. But when I get to the end of the page, I need to take my hands off the keyboard, point with the mouse and click Next. That takes time I don't want to spend. (I’ll cover the major reason I use the keyboard later on).

Suggestion 5: Provide keyboard shortcuts so one can go to the next page without using the mouse.

Since I have to look at every single ICT job in Melbourne, there's a lot of noise I have to trawl through. Let's assume the user has a "hot list" and a "not list" of words.

Suggestion 6: Given the "hot list", highlight any of those words that appear in that ad.

Note, these keywords are not definitive enough to warrant me searching on them. Plenty of great jobs in a certain area don't use meaningful keywords. Keywords are hints, not search keys.
Conversely, there are a bunch of technologies out there that I have no experience or interest in. If a term for that technology appears in an ad, it's a pretty fair bet that the job’s not for me. So I really don’t want to put any brain power into that job.

Suggestion 7: Given the "not list", grey out the whole ad if any of these words appear. It still appears in the jobs listing, but greyed out.

Now let’s look at how you’re using screen real-estate. I have an LCD monitor that’s 22” from corner to corner. That’s by no means uncommon; you can buy one from MSY for under $180. 22” corner to corner is 19” side to side. Let’s look at how that space is used, left to right:

2.5” absolutely blank space
2.5” refine your results (only top 5% of column used)
1” job selection checkbox
2.5+” location, and maybe salary
5.5” the text of the ad
2.5” some “helper” icons (only top 10% of column used)
2.5” absolutely blank space

You are spending 5” in absolutely blank space! And you are spending 5” on tools and search refinement that could live at the top/bottom of the page. You’ve reduced my nice 19” monitor to a 9” monitor, smaller than my first 12" monitor in 1989!

You might say “well, ads (and web pages in general) look bad if they’re too wide so we have that space to burn any way". But what happens if I want to use the left half of my screen to look at Seek ads, and the right half to compose a cover letter? Or if I have a smaller screen? Or I’m looking at it on a smart phone?

Fortunately, the whitespace on the sides disappears when I resize the window smaller. But everything else stays the same. But I do end up having to sideways scroll the page to get the ads centred.

Suggestion 8: Put the 2.5” of “refine your results” stuff, and the 2.5” of “helper” icons at the top/bottom of your page, and make sure your page doesn’t need sideways scrolling on smaller screens.

As mentioned, I do a lot of scrolling through ads. I rely on words of interest passing by and catching my eye. You have a pink box that highlights an ad as the mouse goes over it. I’m sure you thought that was a great idea. But the flashing of that pink box as ads go under my mouse is INCREDIBLY distracting when I’m looking for keywords. And it makes your site look like someone’s CSS homework. Just because it’s possible doesn’t mean it’s a good idea.

Suggestion 9: Please, lose the pink highlight. Please?

One thing that really bugs me about Seek’s website is that once an advertiser retires an ad, Seek loses all memory of it. For example, let’s say there’s an ad for a good job. I bookmark the ad, and apply for it online. Then the advertiser gets enough interest that they retire the ad, because they really don’t need any more candidates. Next I get a call for an interview. So I go back to the bookmarked ad to review what the advertiser wanted, and GRRR, it’s not there any more! How can I prepare for the interview?

Suggestion 10: Except in the case of an ad that was offensive or illegal, if someone has the URL, show them the ad, even if it’s been removed from the public listing.

So, in order to cope with the above, I have to print out all the ads I’m interested in. Means I can’t use your tools to manage my applications, but at least I've still got the ad after it's retired. But what about if I want to go back to the online version?

Let’s say I was after job number 18393608. What I have to end up retyping is:

http://www.seek.com.au/job/c-engineer-adelaide-based-satellite-communications-next-g/melbourne/18393608/28/1/

That’s a lot of annoying typing, and if I made a mistake in typing it or copying it down, a great job could get away from me.

Suggestion 11: Rewrite your single job pages as (to use the above as an example): http://www.seek.com.au/job?18393608 or similar. Note, short URLs are no easier for unscrupulous companies scraping your website for jobs, than long ones, so there's no reason to have long ones. Long ones just make life difficult for schmucks like me.

Data quality

Remember I’m in Melbourne? I have a family and I’m not interested in moving or working outside of Melbourne, so in the advanced search, I always choose Melbourne. So I’m baffled that I keep seeing ads that aren’t for Melbourne, like the example ad from above. Please, why does this ad show up if I searched for Melbourne?

This is not a one-off: I’d estimate about 5% of your ads are similarly (and like the Adelaide Next-G ad above, I’d certainly say deliberately) misfiled.

Suggestion 12: Give people a way of reporting such ads (but see below).

Another extremely annoying thing is when recruitment companies put in ads for themselves. In other words, there’s no job, just a company putting in an ad because they want to get you on their books. Really, this isn’t why I visit Seek.

Suggestion 13: Ban ads for recruitment companies. An ad without a job behind it just undermines the quality of Seek’s database.

What’s also annoying is speling misteaks in job ads. I’m one of those people who notices every single spelling mistake, and when I’m reading ads, it’s like mental speed bumps. Don’t advertisers know how poorly it reflects on them?

Suggestion 14: When an advertiser places an ad, run it through a spell checker, and if there are typos, give the advertiser the chance to fix them. Since ads contain many acronyms and company names, give advertisers the chance to tell the spell checker that words it highlighted are actually correct, for next time.

All that raises another question: What are you doing to engage your users, Web 2.0-style?

Suggestion 15: Give users a score, called a “reputation”. If they correctly flag ads with incorrect location, no underlying job, or typos, their score goes up. Users with scores higher than a certain amount have proven themselves and are trusted, and their reports are acted upon immediately, rather than needing moderation by Seek staff or other high score users. This would be in place of the current “Something fishy?”

Suggestion 16: Give advertisers a publicly visible reputation. If they keep posting ads that raise the ire of your users, don't take ads from them. Do you really want their business? If you do, what does it say about your business?

What you get out of all this is improved data quality, which makes it more attractive for people to seek on Seek.

Another part of Web 2.0 is inviting your users to produce content. At the moment, the Seek model is “all push”: You produce content (ads) and Seek users passively consume it. But Web 2.0 is a two-way street.

Suggestion 17: Do as eBay does: Let users give feedback, and allow them to ask questions of advertisers.

Suggestion 18: Consider the idea of web forums where job seekers can hang out, talk about their experiences, and create a community and buzz around the Seek name.

Suggestion 19: Implement an online suggestion box, and invite your users to tell you what you can do better. Don’t bury it in the middle of a boring survey!

I’m in the position where I have to use your site, as it has great jobs. Yet the user experience is pretty dated and frustrating. In order to make my job-hunting life bearable, I’ve fixed as many of these suggestions as I can on my end, using a Firefox plugin called “GreaseMonkey”. It lets me change web pages to be how I wish they’d be, and when I sit down to look for jobs, it’s as if you’ve done suggestions 2, 6, 7, 8, 9, 11, and 14. So I have road-tested these particular enhancements. (The other suggestions would need changes on your end of the deal, so I can’t use GreaseMonkey to fix them). But when I go to look at jobs on another computer, I’m back in “lame Seek” land, and the pain comes back.

I’ve now spent about two hours of my time writing 2000+ words to you. I hope you guys actually read it, and even better, implement some of them!

Suggestion 20: Call me. Seriously. If you’re not sure what I mean, I’d be happy to further explain some of these suggestions. Or if you’ve implemented some of them, and want someone to road test them, I’m happy to do that too. Just make your site a bit less painful, please?

Ignacio Garcia, dingux.com: GPIO tables updated

noreply@blogger.com (booboo) — Sun, 10 Oct 2010 16:41:16 +0000

ChinaChip provided the A320 schematic, so after studying it I've completed the A320 GPIO table here:

http://code.google.com/p/dingoo-linux/wiki/GPIO?ts=1286716650&updated=GPIO

Some interesting updates:

PD3 and PD4 are unused GPIO but connected to test pads. Could be used for hardware mods (but first those pads would have to be located on the PCB). I'll open one of the A320 this evening and have a look.
PD22 is connected to the HOLD key (0=pressed, already pointed out in the comments by BouKiCHi).
PB30 confirmed to be battery charge status input.
PD20 is the battery charge control output (1=charge enabled). Actually, this turns on a NMOS which shunts a resistor to ground. This resistor is used to set the charge control, so in theory a PWM output could be used to achieve lower charge current. However, this pin's alternate function is SSI data output, so PWM might be achieved by spitting out continuously the appropriate data.

Not related to GPIO, but also interesting:

The FM chip audio output is (as expected) connected to the LINE_IN inputs of the JZ4732.
As I had guessed, the LCD read signal is not connected, and thus it is not possible to identify the LCD type or synchronize the GRAM refresh to the VSYNC.

As I mentioned earlier, I also have the x760+ schematics and I'm making the GPIO tables, soon to be published.

Capn's Tech: Replacing DS touchscreens (part II): When it starts to go right but something else goes wrong

noreply@blogger.com (mjd) — Sat, 09 Oct 2010 16:08:21 +0000

Last article in this series, I replaced a Nintendo DS touchscreen, but in doing so, broke the touchscreen connector (whoops). I ordered a new connector from GoldenBridge, but surprisingly enough, they didn't ship it until two weeks after I placed the order! So including the shipping time, the connector ended up taking nearly a month to get here. GoldenBridge, no cookie for you!

Well, the connector finally arrived, and I took the DS and the connector to our weekly hackerspace meeting.

I don't have any pictures at present, but the good news is that I was able to desolder the connector from the board, and resolder on the new connector. Took me a few goes, and use of flux and desolder wick and magnification, but I did it.

Only problem is, when I was reassembling the board, I broke the slider off the power switch. Ouch!

I ordered a new power switch from DealExtreme, and when it arrived, I replaced the power switch. Put it all back together and now I have a working Nintendo DS again. I'm now out of danger of being disowned by the kids!

Ignacio Garcia, dingux.com: A personal note

noreply@blogger.com (booboo) — Fri, 01 Oct 2010 21:31:13 +0000

When I sat to write the previous post didn't initially intend to get into the personal side. However, I felt I sort of owed you some explanation on my sudden disappearance, and besides that, I thought that remembering and summarizing the last year of frantic work would help venting a bit. Now that I read it again I have the feeling that I may have painted a gloomy picture on my job status and short-term future, but that would be a bit untrue, and I don't want anyone to worry about it. So, just to clarify: I'm not worried. If things end up well here where I'm now, fine. If they don't, I'm pretty sure I'll be able to find a new job, and in such case I'd really want it to be in another country (so does my wife), so moving abroad is actually an appealing possibility (and to some extent and foreseeing where this country is heading for, I even feel I owe it to my two daughters). And even if it's not that easy to find another job, I have no debt and savings to live on in the meantime.

Ignacio Garcia, dingux.com: Back

noreply@blogger.com (booboo) — Thu, 30 Sep 2010 14:46:56 +0000

Hi all,

Yes, I'm alive. I'll develop later a bit on what's happened for the last year, but first I'd like to apologize to all those disappointed by the sudden stop in A320/x760+ development. I was certainly forced by the circumstances, but that doesn't change the fact that some of you donated money and you probably feel it's not been put to good use. If you want your donation back, please email me.

Now for the blast:

I have now sometime to work again on dingux.
Someone from ChinaChip, from the team that developed the A320, contacted me.
They want to support dingux development for the A330.
They will provide hardware info on the A320.
They will provide hardware info on the A330.
They will provide couple of A330 machines.
They already provided schematics and some source code for the x760+.
They will try to provide a second x760+.

Bam.

The A320 is legacy and is no longer being manufactured (plus there seem to be quite a bunch of knock-offs), so they want to focus on the A330. The A330 is based on an ARM SoC (CC1800) for which, as far as I know, there's not already a linux port (as opposed to the Ingenic SoCs)... so this might be a bit off my skills. We'll see. The x760+ is no longer produced so it might not be possible to get another one (remember, I already have one purchased with donations), which would be helpful because there are two x760+ LCD types.

Having the schematics and example source code for the x760+ should make it much easier to get dingux up and running on it.

Hate to say this, but don't hold your breath. Now I have some time and I'm very motivated (the ChinaChip support is a blast), but my personal situation might change at any time and the job that pays the bills will always be the topmost priority.

And on the personal side (feel free to stop reading here): what's happened in the last year?.

By the time I was forced to put dingux on hold my company was struggling to survive, and downsizing like mad, up to the point that the I was the entire development department. Soon I became also the administrative, customer relations, manufacturing, and installation/repair department. Really. My gmail inbox just collapsed and at a certain point I just gave up trying to reply messages. I'm really sorry if some people felt ignored.

I was working on the hardware and OS of an OMAP3530 based facial biometrics access control system which was itself a quite complex project and wasn't expected to yield some income in the short term, so future looked grim. Then, all of a sudden, two customers (the local government of two small villages) contacted us regarding an outdoor wireless mesh PA system we used to develop and sell. There was an special stimulus plan from the spanish government which would provide financing for those two installations. This was unexpected, since the local governments are literally struggling to pay wages and as a contractor, you're lucky if you get paid six months after invoicing, but the stimulus plan changed the whole thing. It was evident that this was a one-time chance to get good, immediate revenue with a nice profit margin (not really, but we would be using stock that would otherwise have zero value), so I sort of finished the biometrics thingie as fast and as good as I could and jumped on to it.

That was about april.

To make things more fun, there were two choices: either use the v1 system, which had some problems, or finish the design of the v2 system, which would work much better, be easier to maintain, and allow to use all the existing equipment stock. So, I don't fucking know why, I went with the second, and from april to june (remember, at that time I was pretty much the whole company):

Designed a new 200W class D weathertight amplifier. S/PDIF over RS422 and streaming over ethernet inputs. It has two microcontrollers inside, a PIC24 and a LPC1768, and I had never worked before with the later, though had some exprience with the luminary cortex-M3 parts.
Built 20 units of the above, together with another 20 units of a specially modified wireless mesh node. I mean I literally built them. Ordered all the parts, soldered each and every component on the PCBs, machined the 20 cases and assembled it all. Well, actually my wife helped a lot by soldering most of the 0603 caps and resistors.
Loaded my car with all the equipment and went on to install it. Climbing on top of a crane to put it on the top of the 14m poles and on roofs. Fortunately I'm not afraid of heights.
Bought the two computers for the control centers, installed the OS, control application and configured it.

In retrospective, I just don't know how I could do it all myself. One man band working 16 hours a day. I guess it was a combination of good engineering and luck, lots of luck (never ever had a first prototype errorless and straight to production). The installations were finished on time and are being used now to do all the public announcements. Now that I think about it, in between all that, I had also to do some repairs on another old installation and fix some issues in the biometrics thingie. What a madness.

I spent july doing some adjustments to the wireless mesh nets. The customers paid promptly (nice special requirement of the stimulus plan, they must pay you before they get paid by the central government, otherwise... you know... six months to one year), which means we would be able to close the year in the green.

So I needed some rest and time with my family and went on vacation for the whole month on august. The last month I've been working a bit more on the biometrics stuff and developing an asterisk based voice inbox for the PA system, which is a late special request by one of the customers, but makes a good addition to the feature list of the system (which I'm not sure matters at all because I think we're not selling any more for a long time, at least here in Spain). The outdoor IP amplifier is a good piece of engineering and there's a slight chance that could be sold to another company. We'll see.

As I said, we're on the green up to the end of 2010, but there's no income prospect for 2011. So, while now I have some time to work on dingux, and I intend to take it easy for the next months, I will be looking for a new job, new city, new country, not necessarily in that order :-)

Capn's Tech: Touchscreen update

noreply@blogger.com (mjd) — Fri, 17 Sep 2010 22:44:11 +0000

It's been a very long time since I've posted any articles. However I've been working slowly but consistently on my touchscreen. I'll have some more info later, but here's a sneak preview:

New touchscreen, wood case, direct USB.

I know, terrible photo, but that's the best my phone cam can do. It looks heaps better in real life.

This is a straight USB device, connected directly to my PC, and with no need of an Arduino. As far as the PC is concerned, it looks like a USB mouse, except that the coordinates are absolute, not relative.

There's a microcontroller inside the case: A Teensy 2.0 running LUFA.

More details to follow!

Zedstar: btlogger updated to support OAuth

Fri, 17 Sep 2010 11:02:23 +0000

Twitter pulling the plug on basic authentication meant I had to make changes to btlogger to support OAuth. Fortunately, librest made the code changes trivial. However, I ran into some problems. The clock was out of sync on the PC where btlogger runs. This caused the authenticate process to fail at the token request stage and was not easy to debug. The other issue which has been heavily documented is how to support authentication keys in FOSS. Currently configure.ac requires an edit to supply the key information. In theory I could supply the keys to somebody who wants to build the software from source until I figure out another way to handle this. I think they call this “best effort security”.

btlogger is now running from its own twitter account at: http://twitter.com/bluetoothlogger

Village Telco: Mesh Potatoes Go On Sale

Fri, 03 Sep 2010 12:50:00 +0000

This is a big moment for the Village Telco. We have finally arrived at the of the journey that began in June 2008 when I sat down with some very, very bright and innovative people and together we decided not to re-purpose rich world technology for Africa but to boldly design our tech to meet our own requirements. Don’t get me wrong, if something vaguely similar had already existed we would have jumped at it but at the time no one was manufacturing a mashed up WiFi AP and Analogue Telephony Adaptor. They still aren’t.

You can see the final design of the Mesh Potato at the right. Those of you are familiar with the Ubiquiti Nanostation II will know that we borrowed wholesale from their excellent enclosure design. They say imitation is the sincerest form of flattery. In this case, it is certainly true. We love Ubiquiti gear.

What we’ve borrowed from Ubiquiti is the sealed-unit design which makes for a sturdy weather-proof enclosure. What’s a little bit different is the back mounting which has a slip-on piece that can be screwed to a wall. Without the screw-on piece there is a similar mounting to the Nanostation for mounting on a pole.

The best news of all is that Mesh Potatoes are now available for purchase by anyone. Simply click on the Products link above to buy them from our webstore. The cost of each Mesh Potato is USD 119 but for the next two weeks we’re making them available at the wholesale price of USD 89 per unit. In order get that price, enter “afinemesh” as a coupon code on the Checkout page after you have selected the number of Mesh Potatoes that you’d like. Shipping is calculated via DHL from Atcom in China. Please contact us if you’d like to make other shipping arrangements. Orders placed now will ship by the end of September.

Finally, I would just like to express ongoing amazement and appreciation of the many, many people who have contributed to making the Mesh Potato a reality in small ways and in big earth-shaking ways. You know who you are. You all seriously rock. Open Software, Open Hardware refreshes the parts that other intellectual property regimes can’t reach. Thank you.

Village Telco: Dili Village Telco Rolls Out

Mon, 30 Aug 2010 21:27:46 +0000

I’ve just blogged on the latest stage of the Dili Village Telco roll out in Timor Leste. Fascinating what can be learnt from a real world deployment. I find the social and business issues just as fascinating as the technical problems us geeks usually focus on.

Test call by HAFOTI Director. HAFOTI is an NGO working on Womens issues in Timor Leste

Links

1. More photos of the Dili Village Telco roll out.
2. The Dili Village Telco Wiki.
3. Other blog posts in the Dili Village Telco series.

Gerard Braad: Fedora visits China (Beijing/Shanghai)

noreply@blogger.com (gbraad) — Mon, 02 Aug 2010 15:54:45 +0000

A lot of things have happened in China relating to Fedora; our MIPS port gained attention from Loongson and we made Fedora 13 available on our servers. Although it has not been mirrored yet to secondary.fedoraproject.org, you can already try it out. The other thing is about what Kaio and I have been busy with for the last half year, the Chinese Fedora Community!

It seems our efforts have not been unnoticed and the Fedora Community Architecture team sent Mel Chua to China. Yesterday she arrived in Beijing and we immediately started to discuss about our community and future activities and how to gain a more widespread acceptance of Open Source in China.

One of the things we immediately agreed upon was, luckily her explanation was less morbid, to 'Raptor-proof our community'. Our community is fragile when it comes to responsibilities and the load carried upon those shoulders. For this to succeed we would like you to propose people or yourself for a role within the community.

It would be ideal if some of you would step forward and become a regional ambassador who can represent key regions in China, like Shanghai, Hong Kong, etc. The workload for this is low and when we can balance it out it would even be minimal. You would take care of distributing Fedora swag, like t-shirts in your area.

This Raptor issue also troubles our MIPS port. Currently we have three members and of this only the lead role can be performed by someone else. We have a nice group of people around us, but we are always searching for new members. If you want to help with documenting or other activities, just get in touch. No, you don't need to be Chinese :-P. If you have a Yeeloong netbook and got tired or Mandriva, help us test and build third-party packages.

We would really like to know about Open Source activities happening all over China or maybe you have suggestions. If you want to discuss this with us, join #fedora-zh and mailinglist. Mel's agenda for this week is still open, so if you want to meet her in Shanghai, this is your chance.

Thanks to all the members of the Chinese Fedora Community!

Geoffrey L. Barrows - DIY Drones: User programmable sub-gram optical flow / vision sensor

Wed, 07 Jul 2010 03:41:35 +0000

For a long time I've been wanting to make an ultra minimalist vision / optical flow sensor for the hobbyist and experimentalist community. I've been pursuing this as a small IR&D pet project at Centeye. We're almost there.

The above photo shows one of these sensors next to a millimeter scale. The part count is small- One of our 64x64 custom image sensors, an Atmel ATmega644 processor, several resistors and capacitors, and some lightweight flat optics we developed. Two complete sensors are shown, including with mounted optics (yes it's that thin!). Total mass is about 440mg. The primary interface is via I2C/TWI, which will allow many sensors to be hooked up to a common bus. A secondary connector includes the interface with the ISP for uploading firmware.

We chose to use an ATmega processor since they are loved by hardware hackers and are easy to use. Ideally for a single sensor, one can upload any number of different "application firmwares" to the sensor to make it whatever one wants, limited by just the processor and the base resolution. One firmware will turn it into an optical flow sensor . Another firmware will let it track bright lights. Yet another firmware could turn it into something else. Or someone could write their own firmware, whether by tweaking existing source code (yes I plan to share it) or writing something completely new.

An ATmega644 may not sound like much for image processing- 64kB flash, 4k SRAM, 2k EEPROM, 20MHz max. Neither does a 64x64 array. But the reality is if you are witty you really don't need at lot of resolution or processing power to get some nice results. (We once did an altitude hold demo with just 16 pixels an 1MIPS back in 2001.)

We've already made our first batch of these (about 20) and handed them out to a few close collaborators. Based on feedback we are preparing our second run. The new sensors will be slightly larger and heavier (thicker PCB) but more rigid, and use strictly 0.1" headers for all IO and power (including programming). Mass should still be under a gram.

We also have an even smaller version in the works, shown below with a chip mounted and wire bonded (sorry about the mess). This board uses ATtiny and the 7mm x 8mm board alone weighs about 95mg. I think we can get a whole sensor made for about 120mg, if only I had the time! (Maybe some brave person here would like to take a stab at programming it???)

Gerard Braad: Installing SELinux on Linode (CentOS profile)

noreply@blogger.com (gbraad) — Tue, 22 Jun 2010 08:52:20 +0000

Recently I signed up for a different VPS hosting partner as the one I was using had a dreadful latency when dealing with international connections. The new VPS at Linode I am using has good ping times, the control panel often does correctly what it should do, but the out-of-the-box CentOS profile was in my opinion not what I am used to.

RHEL and Fedora sys-admins know about SELinux and the pains and pleasures it can induce. If you are new to SELinux, be sure to read a little bit of background: SELinux for dummies and Dan Walsh's Blog. Or watch these videos recorded by Scott Dowdle: "SELinux demystified", "Intro to SELinux" Part 1, Part 2.

It seems Linode does not provide SELinux support with their provided kernel. I do not know what their motivation is. Maybe they want to relieve their support of troubling questions (to which I would say: permissive or enforcing=0) or maybe they just don't see the need. However after reading several reports on the web I am sure people want this functionality, but have been troubled by out-of-date resources about recompilation of the kernel to get the needed SELinux support and paravirtualization operations (pv_ops), setting up pv-grub, etc.

Well, things are now much simpler as RHEL/CentOS provides the needed pv_ops kernels. The only missing part is to setup grub and get SELinux going. In several steps I will explain what needs to be done.

Instructions
For these instructions I created a standard CentOS 5.5 (64bit) profile VPS using Linode's Dashboard option 'Deploy a distribution'. Start the node and from the console or ssh perform these steps.

1. Install grub
Grub is not installed on the base system. You will need to install the package, create some symlinks and an empty configuration file which you will need later.

# yum install grub
# mkdir /boot/grub
# cd /boot/grub/
# touch grub.conf
# ln -s ../boot/grub/grub.conf /etc/grub.conf
# ln -s ./grub.conf menu.lst

2. Install kernel with pv_ops
You will need to install a Xen enabled kernel which are provided by CentOS. But for some reason the xennet and xenblk are provided as modules and fail during startup. To solve this issue we create a new initrd which can load these. Be sure to specify your kernel version correctly. You will also need this later for Grub.

# yum install kernel-xen
# mkinitrd -v -f --with=ext3 --with=xennet --with=xenblk /boot/initrd-2.6.18-194.3.1.el5xen-custom.img 2.6.18-194.3.1.el5xen
# echo "devpts    /dev/pts    devpts    defaults  0 0" > /etc/fstab

3. Edit grub.conf
To enable the new kernel, you need to add this to our empty grub.conf. Be sure to verify your version.

# vi /etc/grub.conf

The contents of the grub.conf are:

#boot=/dev/vxda
default=0
timeout=1
hiddenmenu
title CentOS
root (hd0)
kernel /boot/vmlinuz-2.6.18-194.3.1.el5xen ro root=/dev/xvda
initrd /boot/initrd-2.6.18-194.3.1.el5xen-custom.img
title CentOS (enforcing=0)
root (hd0)
kernel /boot/vmlinuz-2.6.18-194.3.1.el5xen ro root=/dev/xvda enforcing=0
initrd /boot/initrd-2.6.18-194.3.1.el5xen-custom.img

The above configuration will automatically boot to the default option which is a pv_ops kernel which has SELinux enabled. The second boot option is handy of you encounter some issues during the next step. If you are uncertain, you can uncomment the following lines, but this means the boot will be interrupted by grub and needs you to select the boot option from the lish console.

#default=0
#timeout=1

4. Install SELinux
Installing SELinux now is a breeze.

# yum install libselinux selinux-policy selinux-policy-targeted
# genhomedircon
# touch /.autorelabel
# shutdown -h now

Now you only need to set your node to use pv-grub to boot from the configuration profile. This is briefly explained in this article on the Linode Library. Boot up your node and allow some time for the relabeling. It might be wise to verify the progress from the lish console. If everything went well, the filesystem should have been been relabeled after a while and the system should operate 'as normal' ;-). You can verify the state of SELinux from ssh using the command sestatus.

There is however still one issue I have not resolved, as soon as the console is handled by mingetty, it seems the lish console does not properly handle this. It might be an issue to use xvc0 instead, but I see this as a minor problem and rather have SELinux enabled.If you have a fix, please let me know so I can improve these instructions.

Capn's Tech: Computer assisted Chinese (part VII): Touchscreen 5

noreply@blogger.com (mjd) — Wed, 12 May 2010 11:50:54 +0000

Last entry, I had the larger touchscreen working with X, and I worked out how to map the touchscreen data to a rectangular area on-screen. This time, I will try to get a Nintendo DS touchscreen working with X.

Although my ultimate goal is to make a true USB device, for the moment I'm going to use an Arduino as the microcontroller.

http://www.arduino.cc/

The Arduino has an FTDI FT232RL chip on it. This speaks USB on one side, and TTL-level RS-232 on the other. On the Arduino board, the FTDI's serial port connects to pins 0 and 1 of the Arduino, which is the microcontroller's UART port. This lets you send information to and from the microcontroller over USB, and what the PC sees is a USB serial port.

My plan is to make a serial port based touchscreen which emulates one of the existing serial port touchscreens supported by Linux. Hopefully this means I don't have to write any kernel code.

I looked around in the kernel's drivers/input/touchscreen directory for the serial port touchscreen driver with the simplest protocol. The most likely candidate seemed to be the driver for the 3M MicroTouch. It's a five byte protocol, and the driver looks pretty simple. I'll come back to the protocol later. For the moment, I want to see if I can read the touchscreen ok.

A touchscreen is a sandwich of two transparent plastic plates. Each plate is covered with a conductive film, and one plate is printed with tiny plastic bumps to keep the two plates apart when not being touched. You can find out more about how touchscreens work here.

My touchscreen has four wires. These wires must be connected to the Arduino board, so I made my own "breakout" board. I used one of the Sparkfun connectors I bought to fix my Nintendo DS touchscreen.

Soldering the touchscreen connector was "fun". Remember, there's four conductors in the space of 1.5mm. I had a lot of problems with solder bridges between the pins. I eventually solved this problem by using a jig made of polyimide tape with three fingers, which fit between the pins and make a physical barrier to prevent solder getting from one pin to the next. After completing the soldering, I removed the fingers.

Polyimide tape is a heat-resistant film that is sold by DuPont under the name of Kapton. Cheap polyimide film can be bought here.

The wire I'm using is wire-wrap wire. Four of these wires next to each other give exactly the right spacing.

In order to prevent the tiny wires on the connector from breaking, I wanted to put the connector on a board. I didn't want to glue the connector, as there's a risk that glue will get inside. So I made my board out of a small piece of unetched printed circuit board, and soldered the connector to the board. The 4-pin connector has solder pads on the bottom: how to solder it to the board?

Recently I bought myself a small tub of solder paste. This is a mix of microscopic solder balls, suspended in a liquid to make a paste. Although it looks a dull grey to the eye, I looked at it under the microscope at our hackerspace, and yes, it's a sea of unbelievably tiny balls. How cool!

I used a pen to draw the dimensions of the connector onto the end of the PCB, then used a rotary cutting tool to remove the copper where the touchscreen conductors go. There's still copper underneath the solder pads on the connector, but no copper under the touchscreen wires.

Using a jeweller's screwdriver, I applied a tiny amount of solder paste to the copper of the board where the connector's solder pads will go, and placed the connector. Holding the connector in place with my finger, I touched the soldering iron to the copper next to the connector. The copper conducted the heat into the solder paste, and I could see the paste turn from a dull grey to a lovely silver. I could also see surface tension pull the solder into a nice shape around the solder pads. Result: One nice strong strain relief for the connector and the wires. This solder paste worked very well, and I will definitely use it more in the future. I bought it very cheaply here.

Next, I used 4 header pins to join the wire-wrap wire to the four-conductor flexible ribbon cable, and used 4 right-angle header pins at the other end to make a plug for the Arduino. To finish off. I used hot glue to lock the ribbon cable in place at both ends. Here's the result:

The breakout board is a bit rough, but it's a prototype.

(If you have keen eyes, you may note a button attached to the lower Arduino connector. More about that later)

Well, that's the mechanicals done, now for some software!

Capn's Tech: Replacing DS touchscreens (part I): When it all goes wrong

noreply@blogger.com (mjd) — Wed, 12 May 2010 11:50:54 +0000

The other day I was talking about the cheapie touchscreens from DealExtreme:

http://www.dealextreme.com/details.dx/sku.3245

I bought a few for experimenting with, and one for replacing the touchscreen in my sons' Nintendo DS, as that touchscreen has developed problems.

To find out how to replace the touchscreen, I watched these guides:

http://www.youtube.com/watch?v=5a1AIWYXPmg

http://www.youtube.com/watch?v=lir1HCupK9Q

They make it look so easy!

Anyway, I successfully opened up that Nintendo DS, and was able to split the old touchscreen from the LCD and replace it with a new one. The problem came when I tried attaching the new touchscreen to the connector on the PCB. That connector has a tiny black plastic lid, and unfortunately for me, one of the legs on the lid broke off. You can see the connector here:

That connector is tiny as! To give you an idea of scale, the touchscreen ribbon cable you can see in the lower left is 2.5mm across: Just 1/10th of a inch!

Without the lid, the connector doesn't push down on the touchscreen cable, and the touchscreen doesn't work. What to do? Without a working DS, my kids will kill me!

I thought of trying to hot-wire the touchscreen cable to the board, either directly or via four tiny wires, but I couldn't think of a way that wouldn't risk damage to the PCB, so I decided to buy a new connector.

The first place I looked was SparkFun. I found this connector:

(Click on image to go to the product page)

Although the shape is different, they are only about US$1 each, so I bought a few. Actually, I bought them from SparkFun's local distributor, Little Bird Electronics.

The connectors arrived in about a week, and when I got them, I noticed something rather unfortunate: The connectors on the Nintendo DS PCB are designed to have the contacts on the touchscreen facing down, whereas the SparkFun connectors are designed to have the contacts facing up. I don't think that's going to work!

In order to confirm this, I spent more than two hours at our hackerspace, soldering wires onto those four pins under a microscope. And yes, that connector is the wrong way around and not suitable.

So, I did some more web digging, and found a company called Golden Bridge in Hong Kong. It seems they're not dissimilar to Deal Extreme, and they have what appear to be the proper DS connectors:

(Click on image to go to the product page)

I ordered a few connectors a week ago, and I'm waiting for them to arrive, which they should do any day now. Unless they arrive tomorrow, I won't get them in time to solder at hackerspace. Which is unfortunate, as if my kids don't get their DS back soon, I think I'm going to be buying them a new DS. Either that or I think I'll have to leave home...

Capn's Tech: Computer assisted Chinese (part VI): Touchscreen 4

noreply@blogger.com (mjd) — Wed, 12 May 2010 11:50:54 +0000

Last article, I had a working touchscreen where the whole of the touchscreen surface was mapped to the whole of the display.

Skritter is a flash-based web app. In scritter, there's an area in the middle of the window in which you can use your input device to enter the strokes for the character:

So I have the requirement that I want to map the touchscreen area just into that rectangular area.

Here's another requirement: A 15cm x 9cm touchscreen is designed to fit over a display, not sit on one's desk.

It's too large to comfortably write on, as my wrist hits the surface when writing and throws off the cursor. So I only want to use a small area of it.

And since I eventually want to build this with a cheap nintendo touchscreen, not a full-sized one, I'd like to just use one corner of the large touchscreen.

Further, I want size and aspect ratio of my small corner of the large touchscreen to be roughly the same as for the nintendo touchscreen. Fair enough.

But it gets better: When I finally use the nintendo touchscreen, I want the aspect area of that touchscreen to be the same as Skritter's on-screen drawing area. Since the aspect ratio of the Skritter writing area is slightly different to the nintendo touchscreen area, I will only use about 85% of the nintendo touchscreen area.

So, somehow I have to map a small corner of the large touchscreen, onto this particular on-screen rectangle.

The 11-eGalax.fdi file mentioned in the last article has a line of calibration data:

<merge key="input.x11_options.Calibration" type="string">32 3990 48 3990</merge>

Those four values are the data values one should expect to get from the touchscreen when touching the minimum x, maximum x, minimum y and maximum y positions on the touchscreen. The reason we can provide the numbers is to allow for variations in the properties of each touchscreen, although in general, the values will be around the minimum and maximum values the touchscreen can produce. But what if I fake these values? Can I use this to trick X into mapping one area onto another? Let's try...

One thing to note is that from my testing: I've found that the X axis and the Y axis are reasonably independent of each other: Running the stylus along a horizontal or vertical ruler on the touchscreen shows one axis changing a lot but not the other. Therefore I think the number crunching for the X and Y axes can be done independently.

Mapping an input range of numbers onto an output range of numbers isn't hard. We can visualise the map as a graph, where the X axis shows the input range, and the Y axis shows the output range. The limits of the input and output range correspond to two points on the graph. We can then find the linear equation which describes the line, and once we know that, find the output value for any input value. This should map the touchscreen area to the on-screen area, but also, if we reverse the mapping and feed in the dimensions of the screen, we should be able to find the four calibration values we need to give us the desired mapping.

The first thing I did was work out how much of the touchscreen I want to use. I first considered the case of the nintendo touchscreen.

The pixels on my LCD display are square, so the aspect ratio is 1:1. When the web page is fully maximised, the size of the Skritter writing area on my screen is 347 pixels by 402 pixels. That's an aspect ratio of 0.86. I want to keep the same ratio on my touchscreen.

If I place the nintendo touchscreen with the long axis vertically, the active area is 47.5mm across by 63.5mm high, which is an aspect ratio of 0.75. Note the two aspect ratios aren't the same. If I want to keep the aspect ratio the same, I'll have to give up using a small area of the touchscreen.

If I map the width of the touchscreen to the width of the Skritter writing area, the height of the part of the nintendo touchscreen I'll be using is 47.5mm / 0.86 = 55mm. (I can use the remainder for not-on-screen special functions).

Note this picture is not to the same scale as the previous picture.

I then got an index card and cut out a rectangle 47 x 55mm. I can then place this on top of the larger touchscreen to show me the useable area of the smaller touchscreen:

For comparison, here's the nintendo touchscreen on top of the larger touchscreen:

(The colour difference is because I took the two pictures at different times of the day)

Then I ran the evtest program again,and recorded the touchscreen values for the top left and bottom right corners of the uncovered area on the card. (The values are backwards because I'm using the touchscreen rotated by 180°).

Tscreen Point	X data value	Y data value
top left	1940	1850
bottom right	950	203

Skritter Point	X data value	Y data value
top left	504	285
bottom right	851	687

Screen Point	X pixel	Y pixel
top left	0	0
bottom right	1680	1050

Now, time for some number crunching. Treating the X and Y axes separately, we can find the m and c in y=mx+c to map the touchscreen coordinates to screen coordinates. Then, using x = (y-c)/m, we can feed in the boundaries of the screen, and found out the effective values if the touchscreen was big enough to cover the whole screen, and mapped our touchscreen area onto the Skritter writing area.

I cooked up a spreadsheet to do the number crunching. I typed in all the coords, and it spits out the four "calibration values" I needed. You can find the spreadsheet here:

http://spreadsheets.google.com/ccc?key=0Av3tC4mEgkZPdEl5cl9IR09RdzktUmJvWjEwQURoelE

If I use the data from the tables above, I get the following four values:

Min X	3378
Max X	-1415
Min Y	3018
Max Y	-1284

Note that two of the four numbers are negative. That's to be expected. It just means that with the mapping we have, the lower right corner of the touchscreen is inside the display area. That's ok for us, because we'll never be sending negative values anyway. (I'm feeling pretty lucky that whoever wrote the HAL and X stuff didn't disallow negative calibration values....)

So, then I plugged these values into the 11-evdev.fdi file:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- 10-synaptics.fdi is claiming all input.touchpad's as its
     own. This file is meant to be loaded afterwards and to undo
     any wrong assignments it did.
-->
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.touchpad">
      <match key="info.product" contains="eGalax">
        <merge key="input.x11_driver" type="string">evdev</merge>
        <merge key="input.x11_options.Calibration" type="string">3378 -1415 3018 -1284</merge>
      </match>
    </match>
  </device>
</deviceinfo>

Enough talking, what happened after I restarted HAL and X? Well, it worked first time! A light touch to the corners of the restricted touchscreen area goes straight to the corners of my on-screen input area. I love it when something works first time! To celebrate, I went and practised Chinese characters for three hours. So much nicer with a pen rather than a mouse!

What's next? Well, now that I have the larger touchscreen working, I want to get the cheapy nintendo touchscreen working. Oh, and practice Chinese more :-)

Capn's Tech: Computer assisted Chinese (part V): Touchscreen 3

noreply@blogger.com (mjd) — Wed, 12 May 2010 11:50:54 +0000

In the last article, I was getting good sample data from the touchscreen. But does it work in X? Sadly, it doesn't. Or at least not straight away.

(Note, you'll need to make sure the xorg-x11-drv-evdev package is installed).

When a new USB device (such as that touchscreen) is plugged in, the kernel tells the HAL subsystem. HAL notices the new input device, and tells X about it, and X starts listening to the new device. The beauty of this system is that X can respond correctly as input devices are connected and disconnected from the machine.
The problem is that the standard Fedora kernel treats this kind of touchscreen as an evdev device (good), but HAL makes a mistake about what kind of device it is. There's a rule in HAL which says "any touchscreen which I don't know about must be a "Synaptics" touchpad". This bad guess gets passed onto X, and X tries to interpret the device as a Synaptics touchpad. Since the device (by the time it gets to X) is really an evdev device, X doesn't know how to handle the touchscreen properly.

So in order to get the touchscreen to work, I had to work out how to convince HAL that the touchscreen was an evdev device, not something else.

This problem has also been experienced by others, and is covered in Fedora bug 473144. To cut a long story short, the most convenient solution is to create a file which tells HAL which kind of input device it really is. Comment 45 of that bug contains a suitable .fdi file:

https://bugzilla.redhat.com/show_bug.cgi?id=473144#c45

<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- 10-synaptics.fdi is claiming all input.touchpad's as its
     own. This file is meant to be loaded afterwards and to undo
     any wrong assignments it did.
-->
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.touchpad">
      <match key="info.product" contains="eGalax">
        <merge key="input.x11_driver" type="string">evdev</merge>
        <merge key="input.x11_options.Calibration" type="string">32 3990 48 3990</merge>
      </match>
    </match>
  </device>
</deviceinfo>

That bug mentions a file in /etc/hal/fdi/policy called 10-synaptics.fdi. I don't have a file of that name in that directory. Instead, on my machine, it's in /usr/share/hal/fdi/policy/20thirdparty. So I decided to copy the file from that bug report into a file called 11-evdev.fdi in that directory. Then I had to restart HAL in order for it to see the new .fdi file:

  service haldaemon restart

After doing that, I can now see the touchscreen in the output of lshal.

What happens when I restart X? Well, the touch screen works. Sort of.

Note that the maximum X and Y values in that file for the touchscreen axes are 3990. But the evtest utility reported maximum values of 2047. I found that if I use 3990, I can only use the touchscreen for the top left quarter of the screen. Obviously those numbers are wrong for my touchscreen.

When I changed the numbers to 32 2000 32 2000, the touchscreen could point at any location on the X display. Success!

So, what I have now is a working touchscreen, and a setup which maps the whole of the touchscreen to the whole of the display. For reasons I'll go into soon, that's not what I want. But, good progress so far.

Capn's Tech: Computer assisted Chinese (part IV): Touchscreen 2

noreply@blogger.com (mjd) — Wed, 12 May 2010 11:50:54 +0000

I want to use Skritter with a pen, not a mouse. Commercial products are too expensive for me, so I want to make something using a touchscreen.

While I plan to eventually use a cheap Nintendo touchscreen, I want to start with a touchscreen that I already have, one that used to be in my EeePC. This way, I don't have to deal with as many variables at once.

The interface board for this touchscreen usually speaks to a proprietary kernel module, and proprietary X driver. I would rather not use proprietary software, as proprietary software doesn't let me change things if I need to.

Once upon a time, X was configured with a file called /etc/X11/xorg.conf. This file was a description of all the input and output devices that X had to speak to. You could tell X about a device such as a touchscreen, by having an InputDevice stanza in /etc/X11/xorg.conf, which would cause X to load a driver for that input device. The touchscreen maker provides a proprietary driver for this purpose.

Those days are now gone. In Fedora (and probably in other recent Linux distributions), there's no longer an /etc/X11/xorg.conf file. Instead, it's all done with auto-detection.

The Linux kernel has a subsystem called evdev. It unifies handling of keyboards and pointing devices (and can even "mix" different input devices into one virtual device). The kernel contains drivers for many input devices, which use the services of evdev. One of those drivers is for the touchscreen I have. And for each input device, there'll be a device file in /dev/input.

To start off, I did an ls of /dev/input for files matching event*:

mjd@blackcat [/] ls /dev/input/event*
/dev/input/event0  /dev/input/event2  /dev/input/event4
/dev/input/event1  /dev/input/event3  /dev/input/event5

After I plugged in the touchscreen, I saw this:

mjd@blackcat [/] ls /dev/input/event*
/dev/input/event0  /dev/input/event2  /dev/input/event4  /dev/input/event6
/dev/input/event1  /dev/input/event3  /dev/input/event5

So it appears that /dev/input/event6 is the device file for the touchscreen. I ran evtest on this device: (evtest is in the evtest package)

[root@blackcat /]# evtest /dev/input/event6
Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0xeef product 0x1 version 0x100
Input device name: "eGalax Inc. USB TouchController"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 330 (Touch)
  Event type 3 (Absolute)
    Event code 0 (X)
      Value    249
      Min        0
      Max     2047
    Event code 1 (Y)
      Value   1397
      Min        0
      Max     2047
Testing ... (interrupt to exit)
Event: time 1265760809.718325, type 1 (Key), code 330 (Touch), value 1
Event: time 1265760809.718331, type 3 (Absolute), code 0 (X), value 246
Event: time 1265760809.718332, type 3 (Absolute), code 1 (Y), value 1390
Event: time 1265760809.718335, -------------- Report Sync ------------
Event: time 1265760809.770319, type 3 (Absolute), code 1 (Y), value 1389
Event: time 1265760809.770322, -------------- Report Sync ------------
Event: time 1265760809.810320, type 3 (Absolute), code 1 (Y), value 1388
Event: time 1265760809.810325, -------------- Report Sync ------------
Event: time 1265760809.822320, type 3 (Absolute), code 0 (X), value 303
Event: time 1265760809.822322, type 3 (Absolute), code 1 (Y), value 1331
Event: time 1265760809.822326, -------------- Report Sync ------------
Event: time 1265760809.834320, type 3 (Absolute), code 0 (X), value 331
Event: time 1265760809.834322, type 3 (Absolute), code 1 (Y), value 1303
Event: time 1265760809.834326, -------------- Report Sync ------------
Event: time 1265760809.846321, type 3 (Absolute), code 0 (X), value 403
Event: time 1265760809.846323, type 3 (Absolute), code 1 (Y), value 1235
Event: time 1265760809.846326, -------------- Report Sync ------------
Event: time 1265760809.878320, type 1 (Key), code 330 (Touch), value 0
Event: time 1265760809.878326, -------------- Report Sync ------------
^C
[root@blackcat mjd]#

When I touch the touchscreen, I get data! And the data looks sensible, with values for each axis from 0-2047! Now to get it working with X...

Capn's Tech: Computer assisted Chinese (part II): Touchscreen 1

noreply@blogger.com (mjd) — Wed, 12 May 2010 11:50:54 +0000

In learning Chinese, I want computers to assist me in two ways. The first is in learning Chinese characters, and the second is as an in-class dictionary/reference.

The first is just a follow-on step from my flashcards and Chutor phone program. But I need to get smarter about how I learn characters. For that reason, I'm using Skritter, a great web service which uses spaced repetition to teach you characters:

  http://www.skritter.com/

To use Skritter, you have to write Chinese characters in an on-screen scribble area. You can do this with a mouse, but it's fiddly, and I think it's not very good for your wrist, as you're using wrist muscles to try and get the fine motor control you usually get with your fingers on a pen.

A better solution is to use some kind of pen input device. This is a much more natural way of doing things. Commercial pen input devices are far too expensive in Australia (at least A$60 for an entry level model). So I am thinking of using one of these extremely cheap touchscreens, which are intended as replacements for the Nintendo DS:

  http://www.dealextreme.com/details.dx/sku.3245

Eventually I want to read this touchscreen with a small microprocessor, and present this to the computer as a USB touchscreen. For the moment, I'm going to take a number of half-way steps.

The first half-way step is to start with the larger, commercial touchscreen that used to be inside my EeePC. The touchscreen size is 15cm by 9cm, which is a lot bigger than I need, but it already has a working controller board.

Once I have that working, I plan to move to one of the smaller replacement touchscreens, and use an Arduino to make it appear as a USB device.

  http://www.arduino.cc/

I think if I can get all this working, I can replace the Arduino with a smaller dedicated micro, put it in a nice, flat case, and make a pen input device for about A$20.

Second project in next post.

Gerard Braad: Chinese Fedora Community and Fedora-MIPS Port

noreply@blogger.com (gbraad) — Sat, 08 May 2010 23:29:53 +0000

Currently I'm getting ready to move to Beijing (北京), China (中国) in June. While I am still looking for employment I have also been busy with assisting the Chinese Fedora Community (FZUG/中文用户组). As part of some our activities I will give presentations about Fedora and the community at the BeijingLUG. It is a growing community... but we are still looking for new users, ambassadors and contributors. We would also really like to work together with other other user groups in the APAC. If you are Chinese, in China or interested, drop by in our IRC channel #fedora-zh on freenode or get in touch with me (吉拉德, gbraad), Caius Chance (kaio) or Yuan Yijun (袁乙钧, bbbush). We are looking forward to seeing you!

Part of building the Fedora brand, some friends of the Chinese community and I started to port Fedora to the MIPS architecture. MIPS is an architecture that gained a lot of attention recently with the release of the Loongson processor. This processor is Chinese made and ended up in several netbooks and mini-pc's. While they were only available on the Chinese market, they are now being sold in America and Europe, e.g. by the Freedom Included initiative.

Currently we have chosen to target the Loongson 2F, but in time we will also support other MIPS-compatible processors. The primary goal of this project is to provide support for MIPS as a secondary architecture in Fedora. Just like the ARM port, our secondary goal is to enable derivative distributions based on the Fedora package collection and repository that are more suitably optimized for embedded and mobile use-cases. For this we want to work together with the Mini SIG as we can both benefit from this.

We now have a test build available of Fedora 12 (as n32 mipsel) which should be able to run on Qemu or MIPS-based hardware, like the Fuloong. While we are in the process of fixing some remaining build and technical issues and submitting the patches, you are invited to help us test this release. The Fuloong is currently the platform we build and test on ourselves. Be warned, expect to do some DIY especially since no documentation is available yet... and your mileage may vary.

The team currently consists of me (project-lead), FaiWong (technical lead, lazyfai) and XinZhen (co-lead, lonestar). If you want to contribute or donate hardware, please get in touch with us. More information can be found on the Fedora-MIPS wiki page, or just drop by in our IRC channel #fedora-mips on freenode.

Zedstar: GNU Guile on a Ben NanoNote with command line history (readline support)

Sun, 02 May 2010 21:20:40 +0000

I have been hacking at the OpenWrt Makefile and now have command line history working within the REPL.
opkg install http://zedstar.org/guile/libgmp_4.3.1-2_xburst.ipk opkg install http://zedstar.org/guile/libltdl_1.5.26-1_xburst.ipk opkg install http://zedstar.org/guile/guile_1.8.7_xburst.ipk

Once installed setup a .guile file:
root@BenNanoNote:~# cat /root/.guile (use-modules (ice-9 readline)) (activate-readline)

When you run guile now you should be able to use the up and down cursor keys to go through your command history etc.

Zhou Yajin, vm-kernel.org: Gdium linux kernel support status

Fri, 16 Apr 2010 13:20:42 +0000

After several days working, the 2.6.34-rc2 kernel is working on gdium expect sound. Of course most of the codes are from mandriva and Philippe's work.

I will make some code clean and make the sound work in the next few days. It seems the sm501 sound driver needs a hardcoded 8051 firmware to work. Damn it. After these works are done, I will send the patches to loongson-dev maillist and merge it to linux-loongson-community and linux-mips mainline at last.

I am keeping moving....... Please wait.

ps: The linux kernel for gdium repository is here.

kill-bill:~# uname -a
Linux kill-bill 2.6.34-rc2 #24 PREEMPT Fri Apr 16 21:01:51 CST 2010 mips64 GNU/Linux
kill-bill:~# cat /proc/cpuinfo
system type : dexxon-gdium-2f-10inches
processor : 0
cpu model : ICT Loongson-2 V0.3 FPU V0.1
BogoMIPS : 598.01
wait instruction : no
microsecond timers : yes
tlb_entries : 64
extra interrupt vector : no
hardware watchpoint : yes, count: 0, address/irw mask: []
ASEs implemented :
shadow register sets : 1
core : 0
VCED exceptions : not available
VCEI exceptions : not available

Zhou Yajin, vm-kernel.org: Install debian lenny on yeeloong 8089/8101

Sat, 27 Mar 2010 06:28:51 +0000

NOTICE/TIPS:
[For one want to install the debian 6.0, there is a more easy way. See the following link.
http://www.anheng.com.cn/loongson/install/readme.txt (In Chinese).]

Yesterday I installed the debian lenny on yeeloong 8101, the 10.1 inch notebook based on loongson 2F CPU for a friend. Then I find there is less English document describing how to do this. So I write the process down to anyone who is interested in installing debian on yeloong. There are many ways to do it I choose the way of using a debian network installer. Please make sure you have a internet connection first.

1. First download the kernel and initrd to your PC.

wget http://dev.lemote.com/drupal/sites/default/files/kernel-2.6.27-LM8089.tar.gz
wget http://dev.lemote.com/drupal/sites/default/files/initrd_yl_netboot.gz

2. Decompress kernel on your PC.

tar zxvf kernel-2.6.27-LM8089.tar.gz

You will get the kernel vmlinux and the directory named lib. The lib directory contains all the kernel modules.

3. Format your USB disk with ext2 partition and copy vmlinux, directory lib and initrd_yl_netboot.gz to the usb disk.

4. Insert the usb disk to your netbook and boot it

5. Enter the PMON command line.

There are two ways to enter the PMON(the bootloader of yeeloong) command line. One is press DEL when booting. The other way is click C when you see the boot menu.

Use the following commands to load the kernel and initrd, which contains the debian network installer.

load /dev/fs/ext2@usb0/vmlinux
initrd /dev/fs/ext2@usb0/initrd_yl_netboot.gz

Please be patient. The initrd command may need more than 5 miniutes to be finished.

Sometimes the PMON bootloader may hang when you boot with a usb disk inserted. I do not know why. The workaround is booting into the default linux system and inserting the usb disk and then rebooting. Or you can use a tftp method to load the kernel and initrd.

At last use the following command to launch the debian network installer.

g console=tty no_auto_cmd

Then just install the debian as normal.

6. Install debian lenny

After debian configurating the DHCP, it will complain about "no kernel modules were found" and will let you choose "continue the install without loading kernel modules?", just choose Yes(the default answer is No) to continue.

When in the part of Partition disks, it will complain about "The current kernel doesn't support the Logical Volume Manager. You may need to load the lvm-mod modules" and the background becomes red. Do not be scared. Just click continue.

Then everything goes as it should be. But at last, debian installer will say "no installable kernel was found in the defined APT sources.... Continue without installing a kernel". Do not click Yes too quickly. We need to copy the kernel and all the modules into new system first. Please make sure that the USB disk is still inserting on the notebook. Use ALT+F2 to active a console. Mount the use disk and copy kernel and libs.

mount /dev/sda1 /target/mnt
cp /mnt/vmlinux /target/boot
cp -rf /mnt/lib/modules /target/lib/

Then click ALT+F1 return to the debian installer. Click Yes to continue installing.

7. Install Desktop environment

You can install LXDE or gnome as your desktop. I prefer LXDE because it is light.

apt-get install lxde

Install the X server driver.

wget http://www.anheng.com.cn/loongson2f/lenny/xorg-server/xserver-xorg-video-siliconmotion_2.2.8-lemote.r04_mipsel.deb
dpkg -i xserver-xorg-video-siliconmotion_2.2.8-lemote.r04_mipsel.deb

Change the xorg.conf according to this link.

8. Trouble shooting

(1) My wifi does not work

You can see "rtl8187: rtl8187_open process failed because radio off" if you use dmesg to see the message. Use FN+F5 to turn on the wifi first. You will see such message "rtl8187: SCI interrupt Methord Will Turn Radio On" on your console.

(2) My sound does not work

Use alsamixer to adjust the volume. But install alsa-utils first.

(3) OOPS, I forget to copy kernel to my new installed system. I can not boot it now. What should I do?

You can load the kernel using tftp method.

Methril: My 0x1F day

noreply@blogger.com (Methril) — Tue, 16 Mar 2010 19:55:22 +0000

As a bit mask, today is my 0x1F (31) birthday (i´m almost 0x20). But the day is going ok.

A lot of changes happens lately:

In my personal life, i moved my house from Spain to Brazil (really big change). One of the best consequence of this movement is the people i met at my new job, really nice people with a nice job.
In the job side i´ m working in a open-minded company for the hardwar/embedded path. That gets me happier.

So i´m comfortable and almost fully installed in my new home.

In the Open projects side, i´m improving my knowledge and i´m proud to announce that Wolfgang added me to the qie-hardware planet [1] :)
I´ve been testing the Ben Nanonote. A wonderful and amazing gadget that promise a lot. Wolfgang, with his efforts, is also engaging me to all the projects they are raising. I love the Milkymist project and the SAKC is a good hardware device for approaching the FPGA development. He is also encouraging some open-like hardware projects & putting them (or us) in contact to deal with "open philosophy" together.

Thanks Wolfgang & all the people involved in Qi-hardware. Some of them: Mirko. Xiao. Adam. .... & some old friends Tuxbrain (David & Victor), Ida Systems (Rakshat) I hope to see more people involved & growing this community effort.

See you soon.

[1] http://en.qi-hardware.com/planet/

Capn's Tech: Computer assisted Chinese (part III): Dictionary

noreply@blogger.com (mjd) — Thu, 04 Mar 2010 21:37:48 +0000

The second project stems from my deep unhappiness with the Chinese electronic dictionaries that are out there. Most of them are aimed at Chinese people learning English, not westerners learning Chinese, and they really suck. The only thing more awful than the software that's generally on them is the horrid dictionary databases in use. If there are five ways of saying the same thing, how do we know which one is right for the situation? And which are current and not archaic?

When I've read English dictionaries for Chinese people, the English seems about 100 years old and quite laughable. I get the same impression when trying to find words I want in a Chinese-English dictionary: It's not clear which one I want, and when my Chinese friends see my choice, they just tell me "oh, we don't use that word". Pah. And don't get me started about how inflexible the searching is. I should have the ability to click on a character, break it down into components, then see other words with the same components. That will help me sort out whether I want 青、晴、清、情，or 请!

When I'm online, I'm constantly using the dictionary at MDBG. It's aimed at Chinese for westerners, and the English descriptions are carefully worded so that in general, it's possible to tell which of the five ways of saying something you actually want. And seeing which HSK level a word is rated at also gives an idea of how common it is.

  http://www.mdbg.net/chindict/
http://en.wikipedia.org/wiki/HSK_test

This website uses the CC-CEDICT database, which can be downloaded and used for free! Since I like the database so much, I've been dreaming of writing my own Chinese dictionary program which uses that database. And I intend to turn that dream into reality. But in order to do that, I need a platform to run it on.

I have looked around, and I've decided to write it for the Nintendo DS. This is a mature platform, with 4M of RAM, two nice screens, long battery life, a free toolchain, a GUI library, and as much read-only data as you can fit on an SDHC SD card. And cheap too: I picked up a grey market one the other day for A$130.

http://en.wikipedia.org/wiki/Nintendo_DS_homebrew

As far as a user interface goes, I am thinking of making it work somewhat like this program called Pablo:

  http://ehaton.blogspot.com/2007/02/learning-chinese-pablo-my-personal.html
  http://haton.free.fr/chino/pabloscreenshot.jpg

There are also some free handwriting recognition engines which I plan to try, with a view to giving my dictionary handwriting recognition:

  http://www.tegaki.org/
http://www.kiang.org/jordan/software/hanzilookup/
http://hanzirecognizer.sourceforge.net/
http://zinnia.sourceforge.net/

The DS doesn't come with a UI library, so I would either have to write that myself, or use someone else's. I am intending to use the "Woopsi" library:

http://ant.simianzombie.com/?page_id=128

I think my first task will be to port my Chutor program from J2ME to the DS. As well as being useful in it's own right, it will be a good test of the UI library, and my ability to port Java to C++.

Once that's done, I will move onto doing the dictionary program. I'm likely to leave the handwriting recognition to last.

Capn's Tech: International Space Station radio link-up

noreply@blogger.com (mjd) — Fri, 26 Feb 2010 14:32:27 +0000

I just had a lovely evening at my kids' primary school. A group of staff, parents and amateur radio enthusiasts have worked for months to organise a very special event: A radio link-up with the international space station.

To talk to the ISS, some local amateur radio enthusiasts hooked a phone line up to the PA, and this phone line went to Shane Lynd of Glendon, Queensland. Using his aerial, radio equipment and phone patch, we were able to talk with astronaut Timothy "T. J." Creamer while the ISS was within line-of-sight of Glendon, which was about six or seven minutes.

The link-up was arranged by Tony Hutchison of Kingston SE, South Australia, who coordinates ARISS (Amateur Radio on the International Space Station). ARISS lets crew members talk with family and schools, and provides backup comms with the station. There's a nice video about Tony's work here

http://www.youtube.com/watch?v=2KL8TGTUBTU

The students took turns to say their name, ask their question, and finish with "over". Here's the list of questions, plus my unreliable recollection of the answer T. J. gave [and some comments by me]:

At what stage in your life did you decide you wanted to be an astronaut?

He said it wasn't a sudden choice, a lot of things he'd done beforehand prepared him for it and when he had the chance, he said yes. [His bio is here]
Does living in a zero gravity environment cause long term health problems?

There are changes to bone density, to the muscles of the heart, and even to the structure of the eye.
How far have astronauts ever been in space?

To the moon. Most people don't realise that only 12 people have been to the moon. Everything else has been done in low Earth orbit.
Who was the youngest astronaut to go into space? How old was she or he?

T. J. didn't know the answer to this one, but he suggested that the student go to nasa.gov or Google for it.
How do you exercise in space?

He said he uses a treadmill, with bungees that keep him in place so he doesn't float away.
How did you get into space?

He said he was launched on a Soyuz rocket from Baikonur Khazakstan.
What if there is a fire? Can you get rescued?

He said that the space station is designed so that in general, things can't catch fire. But if there was a fire, they'd cut the power and the fire would likely go out. They can also use fire extinguishers. If the fire was too serious, they could come home in the Soyuz capsule that is always docked to the station.
What’s the most interesting thing about space?

He said floating around, and looking at the Earth.
How do you drink in space because there is no gravity in space?

He told us about how they drink from fluid pouches.
How do you control the space ship when it is floating in space?

He said that attitude control is done with gyrodynes [but I think he means control moment gyroscopes, as gyrodynes are a type of aircraft]. If the gyrodynes become saturated, small thruster rockets take over to correct the situation.
Are there aliens in space?

He said he hadn't seen any, but he'd sure be glad to meet and talk with them.
How do you sleep in the space station?

He said he zips himself into his sleeping bag, that has straps which stop him floating around. He said he sleeps very well.
What is your favourite food you eat in the space station?

Fresh fruit. He said it was great when the Space Shuttle brought up some fresh fruit.
What do you do on the space station to relax?

He mentioned that he likes to go into his bedroom and read or use the internet to research things. [He also likes running]
What happens if you run out of air?

He said that this is managed pretty closely from the ground, so it's unlikely to happen.
What happens to all the rubbish from the space station?

All the trash gets put into the Progress resupply vehicle, which is undocked and deorbited. The vehicle and the trash burns up in the Earth's atmosphere.
How often do you have to do space walks to make repairs to the space station?

He said that they don't generally go outside to fix things. He said that he's done spacewalks, but he's not scheduled to do any spacewalks on this expedition.
When you are in space are you ever nervous about anything?

He said that in general, he's not.
When you swallow your food, does it feel funny in your stomach when in zero gravity?

[out of range]

Unfortunately the 19th question couldn't be asked, as the station had moved out of range. I feel sorry for that student. If I was that student, that would be one of my "life's regrets". (And I have so few)

In all, well over 200 people enjoyed the evening. A big thank you to T.J., Tony, Shane, the local amateur radio enthusiasts, and all the others who made this possible. It was certainly a night I'll never forget!

Hawkboard: Active discussions

Fri, 26 Feb 2010 11:32:44 +0000

Subscribe to RSS headline updates from:
Powered by FeedBurner

Zedstar: Guile on a Ben NanoNote

Thu, 25 Feb 2010 22:58:36 +0000

Received a Ben NanoNote today. It is a really natty little device with a lot of potential.

My standard test on how hackable a device is involves getting Guile running. Anyway, it was pretty easy to accomplish this despite not using openWrt before.

root@BenNanoNote:~# root@BenNanoNote:~# guile guile> (map (lambda (x) (+ x 1)) '(1 2 3 4 5)) (2 3 4 5 6) guile>

To install get the 3 xburst packages from here.

Happy Scheming!

Bearstech Hackable:1: Openmoko devroom at the fosdem

Mon, 15 Feb 2010 18:08:52 +0000

Hello hackable:1 users !

Serdar Dere, from #openmoko-cdevel managed to get a devroom at this year's fosdem for the openmoko community !
First things first, huge thanks to him.

Second, we get the room on Sunday morning and the schedule is here. As you can see, it is full of talks and hackable:1 has a slot.

Meet you there ! Who's coming ?

EDIT: The slides

Capn's Tech: Computer assisted Chinese (part I)

noreply@blogger.com (mjd) — Tue, 09 Feb 2010 15:35:23 +0000

I am learning Chinese. Since I hate doing things by hand that can be automated (and because it's much more fun to hack with the the computer than do work), I like to use the computer to help me whenever I can.

For me, the hardest thing about Chinese is learning the characters. Unless you're actively learning and reviewing them every day, you're forgetting. And the techniques I've seen my classmates use (such as just writing them a few times) doesn't seem to help me.

When I was learning Chinese in 2005, I typed the word list from each chapter of the textbook into my computer. From this, I could print the lists on labels, and make flash cards. Each flash card had the Chinese character and the pinyin (pronounciation) on one side, and the English meaning on the other. It took a lot of time to enter the characters, and a lot of time to make the flash cards, but I found it a very effective way of learning. I'd stick a bundle about 6cm x 4cm and 3cm high into my pocket, and be all set to learn when I had some free time, such as waiting for a train.

I'd start with all the cards in my hand, and look at each one in turn. If I knew the card (for example, I could write the character from memory, given the meaning and the pronunciation), I'd remove that card from my hand, and put it on my discard pile. Otherwise I'd move that card to the back of the pile I was holding. The cards I knew well would quickly leave my hand, and my time would be spent working on the ones I didn't know. For reasons I don't fully understand, some characters are easy for me to remember, and others give me such trouble. It was years before I could remember to write such every-day things as 喜欢 and 意思! When I'm learning, I might need to see some cards ten times before it will finally sink in.

What I had implemented was a real-world form of a "spaced repetition" learning system, and it worked really well for me:

http://en.wikipedia.org/wiki/Spaced_repetition

The drawback of this approach, as well as the preparation time, is that I ended up with a bag of some 22 bundles, which is a pile around 60cm high! That was quite unwieldy to carry around, so I'd have to put some thought into the bundles I wanted to carry, and leave the rest at home.

After a while I got tired of the physical nature of the cards, so I decided to do it with a computer program. But lugging around a laptop is not really an option! What could I run the software on?

I eventually decided to write the app as a J2ME Java app, as J2ME programs will run on most phones. Over the course of 2007, I worked on the program when I had some spare time (mostly on the train). I finally released the program in 2007 as "Chutor", which is a portmanteau of "Chinese Tutor".

http://sf.net/projects/chutor

It shipped with the word lists from the New Practical Chinese Reader volumes I, II and III, because that was the textbook I was using at the time, but it can be tailored to take any vocab. When I was in China in 2008, I reworked it to use the vocab of the textbooks were were using there.

Although the program has a number of non-critical bugs, I find it very convenient for reviewing characters when I have a few spare minutes: waiting for a train, or for a few minutes before going to sleep (and yes, learning characters is very effective at inducing sleep).

The missing feature I'd like most is spaced repetition (although I really want and need it, and adding it wouldn't be hard). At the moment, if you get a character right, that character gets dropped until you go and select a new set of chapters. But even so, the program is useful enough.

Give Chutor a try on your phone. Does it work for you? Does it help?

Capn's Tech: First post!

noreply@blogger.com (mjd) — Mon, 08 Feb 2010 18:53:02 +0000

Well, hardly surprising as it's my blog :-)

I've created this blog to put tech stuff in that wouldn't appeal to the sort of people who read my other blog. Expect stuff about electronics, creative spaces, Linux and coding.

Geoffrey L. Barrows - DIY Drones: Micro Helicopter Hovering in Place Using Vision Sensing

Wed, 27 Jan 2010 21:30:00 +0000

Find more videos like this on DIY Drones

Find more videos like this on DIY Drones
Some of you may have seen Centeye's old website showing our earlier work flying optical flow sensors on small RC-class aircraft. Much of this work was sponsored by DARPA and the U.S. Air Force. More recently we have been hacking an eFlite Blade mCX, a very stable small 7" contra-rotating coaxial helicopter.

The helicopter is a basic mCX airframe, minus the front canopy, and with the out-of-box green receiver / controller board replaced with one of our own design. Our own board sports an Atmel AVR32 microcontroller and an AT86RF230 wireless chip as well as carbon resistor strips and transistor circuits to implement the swashplate servos and rotor speed controllers. We have also integrated into the board a 6DOF IMU using standard MEMS components.

In front of our controller board is a sensor ring with eight custom designed vision sensors mounted on a flexible circuit board and a processor board having another AVR32. They are stacked vertically via 0.8mm board-to-board connectors- Thank You cell phone industry! The processor board operates the eight vision sensors (which form an nice parallel system), acquires the imagery, computes optical flow, and sends high level control signals to the controller board. The whole sensor ring, including processor, flexible ring, vision sensors, and optics together weigh about 3 grams.

Using a variation of control algorithms developed by Sean Humbert's lab at the University of Maryland at College Park, we were able to have this helicopter "hover in place" for up to six minutes straight. We could even perturb the helicopter slightly by manually moving it, and it would attempt to return to its original position. We have been able to get this demonstration working in a variety of room sizes and illumination levels. For these experiments, we did not use the IMU- the helicopter held its position (including yaw angle) using purely visual information. The man in the videos above is Travis Young, who has been executing the control aspects of this project at Centeye.

Just to make it clear- All sensing, processing, and control is being performed on the helicopter. There is no human in the loop in these videos.

Centeye is participating in the NSF-funded Harvard RoboBees project, led by Harvard EECS professor Rob Wood. As part of this project, we will be building vision sensors weighing on the order of tens of milligrams. If all goes well, we should have our first prototype at this scale by this summer!

The RoboBee project will also let us do something that I personally have been wanting to do for a long time- to develop a portfolio of purely consumer/academic/hobbyist vision sensors that I can get into the hands of people like the members of this community! I'll be starting a thread soon in the "Sensors and IMUs" forum where I'd enjoy discussing this with everyone.

Zhou Yajin, vm-kernel.org: UNSW Advanced OS about L4

Fri, 22 Jan 2010 08:18:05 +0000

For someone who is interested in OS and micro-kernel especially L4.

Part 1:

Part 2:

Part 3:

Part 4:

Part 5:

Part 6:

Part 7:

Part 8:

Methril: A lot of time without news

noreply@blogger.com (Methril) — Wed, 20 Jan 2010 21:43:40 +0000

I've been busy with my daily/paid job, and i have not be able to put any update to this blog.
We start a new year and it's time to post some updates of whats going on from my part ;)

First, i'm moving to Brazil. This give me a lot of headaches, as i need to do a lot of paperwork. I'm almost finishing this issue, as i'm going to travel in 9 days!!

I would like to say thank you to my TuxBrain coleages (we get fun together and we work nicely together); i could not forget IdaSystems (that always believe in my hard work); news projects evolving like Genesi-USA (they finally sent me the EfikaMX board!! :D), Qi-hardware, Harald Welte & other hackers that are giving some GSM freedom :D; all OpenEmbedded hackers, that give me one of the better development tools that i never tested; all SHR & Openmoko comunity (they persist on this device and give us some usable software in that piece of hardware - and maybe a little bit more); and all the FOSS developers/hackers & communities that i'm involved :D (i don't have enough space to put all of them here).

I don't know if i'm going to post anything before i move, but.. this is my first 2010 post & i'm really happy with my future plans.

See you soon (from the south hemisphere) :D

Bearstech Hackable:1: New feature for rev5: h1settings

Tue, 22 Dec 2009 14:30:21 +0000

In this article I'm going to describe a new feature which will be available in rev5: h1settings.

h1settings is a library which handles the global settings of the phone. It is a basic wrapper upon some gconf keys and has functions to :

read and update key values
listen to gconf key changes

Currently, only a few keys are available :

Device states :

gprs on/off : /desktop/h1/phone/enable_gprs
gsm on/off : /desktop/h1/phone/enable_gsm
gps on/off : /desktop/h1/gps/enable_gps
wifi on/off : /desktop/h1/phone/enable_wifi
bluetooth on/off : /desktop/h1/phone/enable_bluetooth

Power management :

power management enabled / disabled

The idea behind this library is to add loose coupling between components. For example the power management key is used by the gsm applet when a call is in progress (to fix this silly bug: http://trac.hackable1.org/trac/ticket/42 ) in order to disable power management (i.e. suspend). The gsm applet does not know how to disable PM but neod knows.

Currently, all the actions related to key states except gsm are handled by neod, the central daemon. It registers itself for these keys changes and sets the state of the devices. For the gsm part, it is handled by the gsm applet because it has already everything needed to switch on/off the antenna.

Another advantage is that an independant settings app can be built very easily without any dependencies with the underlying system, and this app already exists : h1settings.
See some screenshots below :

Bearstech Hackable:1: Running hackable:1 on the ROAD Officer S101

Tue, 22 Dec 2009 14:29:59 +0000

Within my position for the promotion of free, open-source hardware solutions in general (and currently, telephony in particular), I am of course trying to keep in touch with the latest developments in this field. Eventually, I have met the fine people at ROAD, a small company in Berlin developing a phone: the Officer S101.

If you don't know about it already, its form-factor will remind you of the Nokia Communicator: from the outside, it looks like a regular candy-bar phone, but it also reveals a full keyboard and wide-screen display when opened. What interests us here is that its inside is open, too :)

The device is not in production yet, but they have been so kind as to let me borrow a sample for a while, which I demonstrated during my hackable:Device workshops at HAR2009 by the way. This is where I managed to install hackable:1 on the phone.

On the hardware side, it was difficult to let it be easier to test. Let me stress first that this was a pre-production device, and all of this may be subject to changes! So here we are:

the phone has an internal flash memory but can also boot on an SD card, which is conveniently replaceable without opening the phone or even removing the battery,
the first partition of the SD card must be formatted as a FAT filesystem,
I was provided with two second-stage bootloaders: one that boots the phone from flash, and the other which updates it.

Therefore, it was just a matter of copying the correct bootloader on the SD card, along with the root filesystem to flash if desired.

About the software now, this device happens to use the same architecture as the Openmoko Freerunner within Debian, "armel". One only has then to choose the right packages, configure them accordingly and generate a filesystem archive.

First, I have added a generic device definition file in trunk/build/profiles/ROAD-Officer.include:

DEBIAN_ARCH="armel"
STRIP="arm-linux-gnueabi-strip"

The "STRIP" line is necessary because of the way we are currently cross-compiling Debian packages: the native tools are unable to strip the binaries cross-compiled. Therefore, strap:1 is currently doing it instead, while generating the images.

#this device is a phone
. "profiles/generic-phone.include"
#add bluetooth support
. "profiles/generic-bluetooth.include"
#add GPS support
. "profiles/generic-gps.include"
#add touchscreen support
. "profiles/generic-touchscreen.include"
#add wifi support
. "profiles/generic-wifi.include"

This should be self-explanatory :)

#packages
#Debian
PACKAGES="$PACKAGES
[...]
xserver-xorg-core
xserver-xorg-input-kbd
xserver-xorg-input-tslib
xserver-xorg-video-fbdev
zlib1g"

Unlike the Openmoko Freerunner, which has its own dedicated X server, we are using the generic framebuffer-based X server. It just works :)

#specific kernel
#FIXME still needs to be packaged
PACKAGES_BLACKLIST="xserver-xorg-video-all"

In order to gain space, we are blacklisting this meta-package: xserver-xorg-core dependencies are actually satisfied with at least one video driver installed, which is the case here.

Next comes the actual profile definition, in trunk/build/profiles/ROAD-Officer-user.profile:

. "profiles/ROAD-Officer.include"
#blacklist packages to gain space
PACKAGES_BLACKLIST="bash
debconf-i18n"
#additional dependencies adjustments
PACKAGES="$PACKAGES
debconf-english"
CLEAN_DOC=yes
CLEAN_LOCALES=yes

This was directly taken from the Openmoko Neo1973 profile, which has tough space constraints on the flash. Here we do not have such limitations, however it made the testing process slightly faster.

Anyway, after some more tuning in trunk/build/packages, it was time to generate the filesystem archive:

$ ./build.sh VENDOR=ROAD MODEL=Officer PURPOSE=user archive

At this stage, the only missing bit was the kernel. I simply used the one already flashed onto the device, but I still needed some modules. They were of course provided to me in source and binary forms, but I don't think this kernel tree is available publicly at the moment. I am sure it will be as soon as the ROAD developers can manage.

Unfortunately, I could only get this far yet. It boots all the way to the graphical user interface, where the Om2007.2 design does not really fit the rather wide screen. We are currently working hard on the next release, rev5, and focusing on the Openmoko Freerunner first, but I will be resuming this work soon enough!

Bearstech Hackable:1: Temporary issues with emdebian's toolchain solved

Tue, 22 Dec 2009 14:29:24 +0000

When cross-compiling hackable:1 packages, we are relying on the stable emdebian toolchain to compile our programs. Apparently, there has been a problem last week, where the toolchain was erroneously recompiled and from then on depending on packages not available on Debian Lenny.

We have coordinated this issue with emdebian's team, and are glad to announce that everything seems to be back in order.

If you have been upgrading your hackable:1 cross-compilation environment during this window, there is a simple way to get it to work again:

# apt-get remove --purge libgcc1-armel-cross
# apt-get install gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi

Then you should be able to cross-compile again!

Bearstech Hackable:1: Study boot process to improve boot time

Tue, 22 Dec 2009 14:29:05 +0000

One thing I'll certainly work on in the upcoming weeks is boot time improvement.
So far, booting takes quite a long time. But instead of looking at my clock when powering up my FreeRunner, I installed a tool to go deeper in the boot process and analyse its (non-)performance.

This tool is called Bootchart-lite, a clone of the well known Bootchart on desktop systems.
That's a basic rewrite from embedded systems that create similar logs as its big brother bootchart, meaning bootchart can compute them.

If you are interested in working on boot time improvement, you should install it !

Uboot configuration

The bootloader must be configured to add a kernel parameter. Here is the way for Uboot. Adapt it for Qi if you use it.

    # apt-get install fso-utils # from FSO
    # mkdir /tmp/uboot && cd /tmp/uboot
    # dfu-util -a u-boot_env -U env.u-boot
    # uboot-envedit -i env.u-boot -p > env_modified.u-boot.tx

Edit env_modified.u-boot.txt to tell the kernel to use bootchart-lite instead of init as first process.

    boot_menu_timeout=300
    bootargs_base=rootfstype=jffs2 root=/dev/mtdblock6 quiet bootlevel=8 init=/usr/bin/bootchart-lite console=ttySAC2,115200 console=tty0 loglevel=8 regular_boot
    ...

    # uboot-envedit -i env.u-boot -f env_modified.u-boot.txt -o env_modified.u-boot
    # dfu-util -a u-boot_env -D env_modified.u-boot

* Install the packages *

On your FreeRunner running Hackable:1, install bootchart-lite: (As of september, 18, it is packaged for daily builds, and will be packaged for rev5)

    hackable1# apt-get install bootchart-lite
    hackable1# reboot

Get data and render the image

On your computer, install bootchart-view (from the big brother bootchart project), and get the logs.
Then, render the PNG (or SVG) image.

    # apt-get install bootchart-view 
    $ scp -r root@hackable1:/etc/bootchart-lite .
    $ cd bootchart-lite
    $ tar czf bootchart.tgz *.log
    $ bootchart -f png bootchart.tgz

Analysis

That's the most difficult step :) !

I'll have a look on that later, I'm focusing on rev5 for now.

Eh ! There are "beta2" images available on http://build.hackable1.org. Would you give it a try ?

Please let us know how you like it and if bugs remain !

Bearstech Hackable:1: Hackable:1 rev5 is out !

Tue, 22 Dec 2009 13:27:04 +0000

Dear Hackable:1 users,

After rev5rc1, we spent hours and hours debugging this or improving that to finally get the rev5 out today. Yep, that's right: hackable:1 rev5 (Codename: Chuck) is there!

First of all, you can grab the different flavours (user for the flash and developer for the SD) here: http://download.hackable1.org/rev5

Changelog
Here are the changes since rev4:

+ End users matters

Most of the software stack now runs under the 'hackable1' user, for security purposes.
SMS proper implementation
The contact list bug has been found and fixed!
Power management improvements, suspend works, bluetooth and wifi are no longer turned on by default.
An application called 'h1settings' can be used to configure phone features, (enable / disable GSM / Wireless / GPS, power management, ...) as well as time and date.
We created a new theme to celebrate this new release!
We got a splashscreen! It features a Chuck figure to reflects the rev5 codename: Chuck
For those who used to love the games on OM2007.2, we put them back !
Boot time seems to have been improved a bit

+ Power users / developers matters

This rev5 release has entirely been built from the automatic build system.
A Linux kernel is now packaged in hackable:1, in order not to rely on fso-pkg anymore.

Debugging has been disabled (boot time improvement)
Easier kernel upgrade when using an ext2 partition to store the kernel on µSD cards
Separation of kernel modules in three sets: essential (comes with the kernel), common modules and "more modules"
You can read a bit on http://zecrazytux.net/Embedded/Hackable1/Custom_Kernel.html

CDBS is now used for some packages.

the package h1packtools contains a CDBS rule that may suffice for simple programs with the autotools
this rule also enables cross-compilation ; it is based on previous works on this subject

Git repositories can now be used as sources for remote projects.

Where can I find it? Where can I get it? I didn't understand last time, so I ask again : what is the answer to the ultimate question about life, the universe, and everything?

As ever, you can download hackable:1 on http://download.hackable1.org/rev5.

All the necessary information can be found on http://trac.hackable1.org as ever, that is documentation, installation instructions as well as known issues.

It's obvious that the answer to the aforementioned question is "Chuck".

Who should I thank for all that stuff?

Among the people who worked on this release, the most notorious are (alphabetically):

Marcus Bauer (mbauer)
Jérome Blondon (jbl2024)
Sébastien Bocahu (zecrazytux)
Pierre Pronchery (khorben)
David Wagner (Deubeuliou)

We'd also like to thank all the testers, among them most notably Bearstech employees, and regular contributors/users of hackable:1, who kept us going forward.

What should I expect next?
Due to a very good number of good reasons, which could all of them be summed up by a minute of one of khorben's rants against libgsmd, we'll switch to Freesmartphone.Org for rev6.
We will also switch from xserver-xglamo to xserver-xorg for the sake of more responsive graphics.
On the developer side, we will of course continue to improve the packaging system and lower the entry barrier.

All in all, more reliable GSM & suspend, and almost all the features one may need. Stay tuned!

The hackable:1 team

Gerard Braad: Migrating from VMware to KVM

noreply@blogger.com (gbraad) — Mon, 14 Dec 2009 19:14:40 +0000

A lot of reports on the internet talk about the reduction of costs when you invest in virtualization. This is something I will certainly not deny after many years of experience with VMware Workstation, VMware Fusion, VMware GSX (now VMware Server) and VMware ESX and having implemented several high-availability setups using ESX. Even at home I had several whitebox servers with Virtual Center... until I migrated away to KVM. In this article I will explain the reason of the migration and how to perform it with an example. It is written towards people who currently run VMware GSX or VMware Server on Linux.

Motivation
It is undeniable that virtualization provide you with a lot of benefits; consolidation of servers will save you money. Maintaining your virtualized servers becomes a breeze, since they are all accessible from a single front-end. But implementing your environment on VMware comes at a price... even for the free version VMware Server; maintenance. You will still need to monitor your virtualization servers for performance and distribute your virtual machines among your servers or resource pools according to load. Although there are tools available to assist you, it is not the biggest issue.

VMware Server requires an additional operating system like Linux (or Windows). This introduces an added maintenance dependency; kernel modules which VMware uses need to be recompiled when the kernel gets updated. If a security exploit is found in the kernel, the virtualization host can be compromised and therefore jeopardize the continuity of your business. To prevent this, you update the kernel, but on reboot you notice that VMware does not start properly. On the command line you will need to perform a vmware-config.pl which build the modules. Unfortunately, your kernel headers are newer and either vmmon (virtual machine monitor) or vmnet (network component) does not build properly. Because of this, your whole infrastructure is offline until VMware provides new components or the release of the community patch package 'vmware-any-any'.

Users of VMware ESX will not have this issue, since the operating system and modules are provided in the form of the VMware's vmkernel. If a security update is needed, you only need to install an update. The previously mentioned issue has happened to me often enough and I I wanted to have the same solution as ESX, but with the convenience of using Un*x/Linux experience for maintenance without the dependency of a third-party product. Since RHEL 5.4 this is provided as an enterprise supported solution; KVM, the Kernel-based Virtual Machine, once developed by Qumranet and now owned by RedHat. And by using CentOS this is available to everyone without too much trouble.

There are some differences between VMware and KVM. KVM is provided as part of the kernel, so any Linux distribution can provide it as part of their offering. KVM supports different formats for a virtual hard disk, while VMware only uses their own VMDK format. VMware can run in a full virtualized mode and is therefore suitable for older hardware. KVM needs a processor that provides VT-x (Intel) or AMD-V (AMD) to operate. VMware can run x86_64 guests on a i686 host, while KVM can not.

Because of this last reason, I had to reinstall CentOS on one of my systems, since it still ran an i686 version of CentOS 5.4 (on a Core2Duo E6600). This provides a good overview of what needs to be done to run KVM on CentOS.

Note: since KVM uses qemu to emulate any hardware you can also choose to use qemu without KVM as the hypervisor, but instead use the kqemu kernel module.

Installation

You will need to download an installation disc of CentOS 5.4. Prefer to use the x86_64 version; CentOS-5.4-x86_64-bin-DVD.iso. During the installation you can keep the default settings and when asked for the 'additional tasks' you will perform, do not select the 'Virtualization' option. After the installation finished, you will need to update the system to the latest updates.

From the reinstall I noticed a minor error in the CentOS 5.4 x86_64 installation. Due to installing openssl.i686 it also installed a lot of other standard i386-arch libraries. You can find out if you also have those packages installed as described in a earlier post. If you also want to remove those packages, perform the following command line option before continuing.

$ rpm -e `rpm -qa --qf '%{name}.%{ARCH}\n' |grep i386` openssl.i686

To update your system:

$ yum update

If your system is up-to-date, continue to install the needed packages for KVM and Virt-Manager.

$ yum install bridge-utils kvm kvm-qemu virt-manager virt-viewer python-virtinst

In later versions of CentOS it might suffice to issue the command "yum groupinstall 'Virtualization'", but currently this installs a Xen enabled kernel. According to the used processor, you can test to load the needed kernel module and start the libvirt daemon.

$ modprobe kvm
$ modprobe kvm-intel (or kvm-amd)
$ service libvirtd start

I normally use a different management workstation. And as an example I use a Fedora 12 installation to connect to the virtualization host (beibei). First from a tunneled connection to the host (with X11 forwarding).

$ ssh -X root@beibei
root@beibei's password: **************
# virt-manager

This will start the Virtual Machine Manager from which you can create new instances. You can of course use a Gnome desktop from the CentOS system to manage your virtual machines, but it pays off to try a seperate management workstation. This will allow you to try additional features, like live migrations between KVM virtualization servers.

This is all it needs to install KVM on a CentOS 5.4 installation. For an earlier version of CentOS, it is best to consult the wiki article about KVM.

Network settings
A default VMware Server installation will bridge the network card you have. You will probably want to have the same configuration for your KVM environment. For this you need standard Linux bridging utilities.

$ yum install bridge-utils

You only need to edit (or create) some network-scripts to make a bridge work.

$ vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
 HWADDR=00:1a:2b:3c:4d:5e
ONBOOT=yes
BRIDGE=br0

And create the bridge

$ vi /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
 BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge

When you start the network again, you will have a br0 and eth0 device.

$ service network restart

You will now be able to select a bridged network card inside the KVM virtual machine configuration. If you have more network card, create a bridge per network card.

Converting the virtual disk files
For the migration part I choose a virtual machine who once began it's life as a physical machine; forum.survion.net. It is a Linux installation once based on FC3, got migrated to CentOS... and then ran as a VMware virtual machine.

The VMware virtual machine consists of one or more hard disk files, with the extension .vmdk and a description file, with the extension .vmx. A listing of server-forum.vmwarevm looks like:

[root@beibei server-forum.vmwarevm]# ls -al
total 29405144
drwxr-xr-x  2 root users        4096 Dec 12 20:53 .
drwxr-xr-x 21 root root         4096 Dec  9 17:32 ..
-rwxr-xr-x  1 root vmware       8684 Dec  7 21:09 nvram
-rw-------  1 root vmware          0 Jan  3  2009 Red Hat Linux.vmsd
-rwxr-xr-x  1 root vmware       2369 Dec  7 21:09 Red Hat Linux.vmx
-rw-r--r--  1 root vmware        268 Jan  3  2009 Red Hat Linux.vmxf
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:22 storage-f001.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:20 storage-f002.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:21 storage-f003.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:20 storage-f004.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:22 storage-f005.vmdk
-rw-r--r--  1 root vmware 2147221504 Aug 30 14:45 storage-f006.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:22 storage-f007.vmdk
-rw-r--r--  1 root vmware 2147221504 Oct 25 19:18 storage-f008.vmdk
-rw-r--r--  1 root vmware 2147221504 Nov 30 04:05 storage-f009.vmdk
-rw-r--r--  1 root vmware 2147221504 Nov 30 04:04 storage-f010.vmdk
-rw-r--r--  1 root vmware    2621440 Jul 23  2008 storage-f011.vmdk
-rw-r--r--  1 root vmware        749 Dec  7 21:11 storage.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:22 system-f001.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:22 system-f002.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:22 system-f003.vmdk
-rw-r--r--  1 root vmware 2147221504 Dec  7 22:22 system-f004.vmdk
-rw-r--r--  1 root vmware   17659904 Jul 23  2008 system-f005.vmdk
-rw-r--r--  1 root vmware        616 Dec  7 21:11 system.vmdk

As you can see, there are two hard disks (system and storage) and several other files. The hard disk as shown here is a fully allocated file which is divided up in seperate 2Gb files (handy for use on a FAT32 filesystem for portability). We have to convert it back into a monolithic file for use on KVM. Luckily KVM understands the monolithic VMDK file format, so we will choose this for interoperability. To convert the file you can use a VMware provided tool called vmware-vdiskmanager (includes with VMware products).

$ vmware-vdiskmanager -r system.vmdk -t 0 forum-system.img
$ vmware-vdiskmanager -r storage.vmdk -t 0 forum-storage.img

After this you will have two files that need to be copied to the in the images folder of libvirt on the virtualization host (/var/lib/libvirt/images/). You can do this using scp, ftp or mount an NFS export. From here we can create a virtual machine to connect these disk files to. Connect to the virtualization host and start the Virtual Machine Manager.

Create the Virtual Machine
Select localhost and create a new virtual machine using the context menu. Give it a unique name that identifies it easily for you, as I did: server-forum. If KVM is installed properly, you can only select "Full virtualized' from the Virtualization Method. Select the CPU architecture that fits your former VMware virtual machine and as the hypervisor: kvm.

On the 'Installation Method' page choose 'Network boot (PXE)' so you don't have to select a installation disk image.

On the 'Storage' page you deselect the 'Allocate entire virtual disk now' since we will not use the create virtual hard disk image. Beware; don't let the size become 0, since this way libvirt will not create the disk file and will fail to create the virtual machine.

On the 'Network' page you will probably want to select the bridged network card. This gives you the same functionality as VMware did as default option. On the 'Memory and CPU Allocation page' you can adjust the settings which are most close to your former virtual machine. After the summary the virtual machine will start automatically. Immediately issue a 'Force Off' as Shut down option. Now select the 'Hardware' tab.

Remove the 'Disk hda' and add new hardware of the type 'Storage' and select the system file from the storage location. If you have selected the file, you will see the correct size. Do the same of the other disks you have.

Be sure to change the boot device in the Boot options of this VM. Else it will try to start using Network (PXE) instead of the virtual hard disk.

Now everything should be ok to start the virtual machine.

Issues you might encounter
The conversion will probably not be without problems. For instance, I had a common issue with the kernel of the virtual machine. Due to a kernel panic it did not start properly. Fortunately tools are available to perform actions of the virtual hard disk files. One of those tools is guestfish. On CentOS and Fedora you can install this tool using:

$ yum install guestfish

For instance, I had to download a newer kernel and try to install this inside the virtual machine. The following commands show what I did:

$ guestfish
fs# add /var/lib/libvirt/images/forum-system.img
fs# run
Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory
fs# mount /dev/sda2 /
fs# mount /dev/sda1 /boot
fs# upload /tmp/downloaded.rpm /tmp/kernel.rpm
fs# command "rpm -ivh /tmp/kernel.rpm"
fs# vi /boot/grub/grub.conf

These commands will add the forum-system.img to a qemu instance. Inside the qemu instance you will then mount the mountpoints, upload the kernel RPM from the local path to the tmp inside the filesystem. From here nothing special... and then it will issue a command inside qemu to install the kernel package. This command will run inside the filesystem as if it performed the command from the commandline. Finally I verify the grub configuration and change it if necessary. From here I was able to start the virtual machine without any errors.

Note: If you convert Windows virtual machines you might encounter more issues. Those conversion steps are outside the scope of this document, but are not impossible to perform.

Fedora 12
The latest release of Fedora includes many improvements which are virtualization related. If you want to try KVM on a workstation, you should definitely try Fedora 12.

Below here you can see virt-manager. The interface has changed a little. As you can see from the screenshot, it is connected to the local machine and two remote hosts. The console is shown from the remote host (using ssh and vnc). For this no additional configuration was needed.

It is easy to monitor the performance of a virtual machine using the Virtual Machine Manager. Here you can see the server-forum instance with an overview of CPU/Memory usage and Disk/Network activity.

Just a few days ago SPICE was released. This is an alternative to vnc to view the console of a virtual machine. It is target towards the use of a Virtual Desktop. More information about this can be found on the SPICE website. A how-to for Fedora 12 is available.

Zedstar: Scripting with Guile on Openmoko

Sat, 05 Dec 2009 13:44:07 +0000

Having Guile running on an embedded device is very powerful. You can add scripting capabilities to a C program and avoid some of the cross compilation -> deploy cycles by simply editing the script to change some functionality. As an example I have taken the code from the excellent introductory article Scripting with Guile. I packaged the code so that if you install the tarball or the ipk it will install both the binary and script to a suitable place.

Tarball: http://zedstar.org/tarballs/square-0.1.tar.gz

ipk: http://zedstar.org/ipk/square_0.1-r0_armv4t.ipk

After installing Guile do:

root@om-gta02 ~/ipks $ opkg install square_0.1-r0_armv4t.ipk Installing square (0.1-r0) to root... Configuring square root@om-gta02 ~/ipks $ square result of square is 49 result of square2 is 81

Gerard Braad: Maemo 5 SDK on Fedora 12

noreply@blogger.com (gbraad) — Mon, 23 Nov 2009 00:41:36 +0000

It is possible to install the Maemo 5 SDK (final) on Fedora 12. It only takes two minor edits to the installer script. You first need to make sure you have installed Xephyr. You can do so with the command:

$ yum install Xephyr

since the installer is not able to do so for other distributions than Ubuntu and debian. You can download the GUI installer script from Forum Nokia: Maemo 5 SDK.

In the file maemo-sdk-install-wizard_5.0.py you can change line 129 to

SB_PATH="/opt/scratchbox"

It is just optional. But to me this location feels more appropriate then '/scratchbox'. On my system it is linked to another location with other hardware and software development tools.

The current version of the script seems to fail on Fedora because of not being able to install scratchbox due to a missing path.

Change line 2311 to:

exec_cmd(sb_installer_fn + opt + "-s " + SB_PATH)

Change line 2351 to:

cmd = "%s -d -m %s -s %s" % (sdk_installer_fn, self.__sdk_inst_m_opt_arg, SB_PATH)

This includes the Scratchbox path during the command invocation. You can then install the SDK by running the script. It will handle the download of PyQT and sip itself.

After the install you can start Xephyr. However you can not use the -kb option:

$ Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac &

The first start of af-sb-init.sh failed for me with a coredump and several segmentation faults. try to close the scratchbox environment and try again.

Note: I haven't tried it with SELinux as enforcing since I currently run my workstation as permissive. Discussion is possible on the Maemo developer's forum posting.

Gerard Braad: Using Mono 2.4 on coLinux to ease .NET development

noreply@blogger.com (gbraad) — Sun, 22 Nov 2009 00:30:39 +0000

Currently I deal a lot with .NET development in my daily work. Most of the development is done on Windows. When you need to develop cross-platform .NET you would like to use Mono. Mono is binary compatible with .NET and allows .NET applications to run on Linux distributions. If you would develop from Visual Studio you want to easily test the binary directly in a mono session on Linux!

To test software both platforms in a convenient way mostly virtualization is chosen. Of course you can use VMware or VirtualBox when you use Windows, but you can also use coLinux. coLinux is a port of the Linux kernel that allows it to run cooperatively alongside another operating system on a single machine. My choice of distribution to use on top of coLinux is the open version of SUSE, both supported by Novell.

This description does expect you to have understanding of a Linux environment and administrative rights on your Windows system.

Installation (Windows side)
First of all you would need to coLinux installer. This file is available from the coLinux website. The downloads section will point you to the latest stable, as of writing v0.7.3. On the website of Henry Nestler you can also find development and daily builds for 0.8.0. This installation is pretty straightforward, just keep the default settings. When the installer asks you 'Hardware installation' you need to press 'Continue anyways', this will allow the TAP network driver to be installed.

To use a desktop environment from coLinux you need to install a X server. The more difficult way would be to use Cygwin/X... this way you will have a complete GNU system running on top of Windows to provide a Linux-like experience. The fastest and easy way is to use a tool like Xming. The installer you need is the Xming or Xming-portablePuTTY (Mesa is not needed). Also, this installation is quite straightforward. After the installation start the X server from the start menu (Programs → Xming → Xming).

In the posting 'openSUSE 11.1 on coLinux' I described a way to make a base installation of openSUSE for use with the coLinux environment. The file 'colinux-opensuse-111.exe' (113Mb) [VIPeers] [dropbox] contains all you need to run the openSUSE environment. As you can see from the size, it contains only a base system. After you have extracted the file, you will still need to perform some additional installations to make the Mono development work.

Before you start the Mono installation inside the coLinux environment, you need to reserve a directory for your development files or some other shared directory. I choose to use 'D:\Development'. In the run.txt file in the openSUSE directory, you can add a line which says:


cofs1="D:\Development"

This will later be mounted inside the Linux environment.

Installation (Linux side)
Now you can start the environment from the 'runonce.bat'. This one time start is needed to finalize the installation (describe in the 'openSUSE on coLinux' posting as the post-install). You will see something similar to:

Logon using the credentials: 'root' and the password 'password'. Immediately change the password using


passwd

Enable the network using the command:


for i in 0 1
do
cat > /etc/sysconfig/network/ifcfg-eth$i << END BOOTPROTO='dhcp' STARTMODE='auto' USERCONTROL='no' END done

Add a mount point to your shared directory


mkdir /media/Development
vi /etc/fstab

and add the following line to this file


cofs1    /media/Development  cofs     defaults        0 0

To enable the shared directory you need to mount it


mount /media/Development

You can now shutdown...


shutdown -hn now

... the system will halt and closes the console. From now on you are able to start the environment using the normal 'run.bat'. Do so and log on using your new password.

Your network should now use eth0 as a serial line and eth1 as a bridged network using the device called 'Local Area Connection'. If your Windows network device is called differently, please change it in the 'run.txt' file. IP addresses are assigned using DHCP. The device eth0 will probably be assigned the address 10.0.2.15/24. For device eth1 this will depend on your local network settings. I will just assume that eth1 is configured and provides the Internet connection.

To allow packages to be installed you would need to add the standard repositories to this installation.


zypper ar http://download.opensuse.org/distribution/11.1/repo/oss/ openSUSE111
zypper ar http://download.opensuse.org/distribution/11.1/repo/non-oss/ openSUSE111_NonOSS 
zypper ar http://download.opensuse.org/update/11.1/ openSUSE-11.1-Updates

Enabling the User Interface
You can use a full-blown desktop environment as GNOME, but since coLinux does not provide a framebuffer device it is not advisable at the moment. We will use the Xming as the X server for our desktop. The X protocol is a client/server model for user interfaces. To keep the installation small, we use a very lightweight Desktop Environment on top of X, namely LXDE.

Install the LXDE packages using:


OCICLI http://download.opensuse.org/repositories/home:/swyear/openSUSE_11.1/LXDE-desktop.ymp

This will start the One-Click-Install. You will need to agree to some questions and lean back... this might take some time.

If this finished, you can test if the installation finished correctly. You will need to set the DISPLAY parameter to specify where the X server is running. Now let's start the appearance settings...


export DISPLAY=10.0.2.2:0.0
lxappearance

and choose a theme that suits your current Windows theme.

This means your desktop environment works.

If you would receive a 'Gtk-WARNING **: cannot open display:' this means your connection might be blocked for some reason. Check your settings or disable a firewall/virus scanner.

Mono installation
Mono will provide a Linux/Unix system with support to run .NET applications. Originally this description was written to use Mono 2.2 which was provided from the openSUSE repository. To install these packages issue a simple


zypper in -t pattern devel_mono

would be sufficient to install a development environment. To start the Monodevelop you can start this using the command:


export DISPLAY=10.0.2.2:0.0
monodevelop &

Since the 30th of March a newer release of Mono (v2.4) is available. To install you will need to specify the mono repository and upgrade the previous installation.


zypper addrepo http://ftp.novell.com/pub/mono/download-stable/openSUSE_11.1 mono-stable
zypper refresh --repo mono-stable
zypper dist-upgrade --repo mono-stable

You can now start Monodevelop 2.0 and use managed debugging!

That's it for now... In later posts I will automate the startup and show how to do development using this environment.

Have a lot of fun...

Notes
If you think VMware provides a better solution you can make use of the files that the Mono Project provide in their download section. Either download the generated VMware image of the LiveCD.

If you want to use GNOME as your desktop environment you are advised to remove the gnome-screensaver package and it's dependent, since it can cause issues during use. If you want to experiment with the LXDE environment, you are advised to use the lxpanel and pcmanfm. In a later post these will be explained in more detail.

Gerard Braad: 聚集：Fedora 12 正式发布 from LinuxTOY

noreply@blogger.com (gbraad) — Wed, 18 Nov 2009 00:17:29 +0000

以技术创新驰名的 Fedora Project 今日发布了代号 Constantine 的 Fedora 12 ，口号 Unite，取意“聚集开源软件智慧”。

新特性

性能优化：在 32 位平台上全部软件包针对 i686 架构重新编译，并对 Intel Atom 处理器进行性能调优。
NetworkManager ：改善了对于宽带、蓝牙和 IPv6 的连接配置过程。配合 PolicyKit ，网络配置只需要点击鼠标即可轻松完成。
下一代 Theora 编码支持：Fedora 12 集成了最新的开源视频编解码器 Theora 1.1 版本（详情见本站此文）。
更好的显卡支持：针对 Nvidia Nouveau 驱动和 AMD R600/700 系列的 KMS 支持，同时为 Intel 显卡引入 DisplayPort 支持。
虚拟化支持：改善了 KVM 性能，并提供虚拟机磁盘镜像监控工具 guestfish。
自动臭虫汇报系统和 SELinux：新的崩溃收集程序 abrt 只需要点击几下鼠标即可将遇到的软件或 SELinux 提交至 Bugzilla，方便开发者修复。
新的 Dracut initrd 启动系统：并行、以事件为单位的 Dracut 系统进一步加快启动速度。
PackageKit 插件：当用户尝试运行一个包含在尚未安装的软件包中的命令时，PackageKit 可以自动提示安装相应软件包。
按需蓝牙服务：蓝牙服务会根据需要自动启动和停止。
Moblin 桌面环境：增加了 Moblin 桌面环境软件包组以及Fedora Moblin Spin 。
PulseAudio ：增添了 UPnP 和 DLNA 支持，可以直接将音频流发送至 PS3 等设备。同时改善了热拔插和蓝牙设备支持。
更加安全：降低了部分系统文件和进程的运行访问权限，避免使用 root 权限访问。同时为 SELinux 增添了沙箱支持。
Broadcom 固件：默认包含了 Open Broadcom 固件，对部分 Broadcom 无线网卡提供 out-of-the-box 支持。
混合 Live 镜像：现在只需要使用 dd 即可创建光盘或者 USB Live 镜像，不过还是推荐使用 Livecd-tools 以获得诸如保留空间等功能。
更好的摄像头支持：改善了部分摄像头的成象质量，尤其是很多廉价摄像头。
GNOME 2.28：使用 Gnote 替代了 Tomboy 成为默认便签，用 Empathy 替代了 Pidgin 成为默认即时通讯客户端。
GNOME-shell 预览：尽管 GNOME 3.0 延期了，但是依然可以在 Fedora 12 中提前体验下 GNOME Shell 的。
KDE 4.3：升级版的 Air 主题，可配置的快捷键支持，新的窗口管理器特效以及更好的红外线遥控支持。
开发者：Eclipse Galileo, Perl 6, PHP 5.3, Netbeans 6.7.1
管理员：GFS2 集群 Samba 管理
X.org 1.7.1：包含支持多指点设备支持的 XI2。

英文原文及详细贡献者
官方镜像下载
完整功能列表

Thanks 黑日白月, Orginal article

Gerard Braad: Get to know a Fedora Ambassador or User

noreply@blogger.com (gbraad) — Sat, 07 Nov 2009 16:14:16 +0000

Name: Gerard Braad
IRC-Nick: gbraad
IRC-Channels: #fedora-ambassadors, #maemo, #beijinglug on freenode (seldom)
Location: Apeldoorn, NL / Beijing, CHN
Fedora Ambassador: Netherlands
FAS username: gbraad

Zhou Yajin, vm-kernel.org: performance of loongson 2f

Fri, 30 Oct 2009 09:11:31 +0000

Some friends ask me about the performance of loongson2f. They want to know whether the performance of loongson 2f can surpass Marvell Sheeva CPU. Well I can not just say it's better or worse without giving the benchmark data.
Since there is a benchmark result of Marvell Sheeva CPU, we can run the same benchmark program on loongson 2f. The benchmark program is nbench.
Machine: gdium
OS: Debian squeeze
Kernel: Linux

1. gcc-4.3.4
CFLAGS = -s -static -Wall -O3

TEST	Iterations/sec.	Old Index	New Index
		Pentium 90*	AMD K6/233*
NUMERIC SORT	358.24.	9.19	3.02
STRING SORT	33.041	14.76	2.29
BITFIELD	5.5164e+07	9.46	1.98
FP EMULATION	47.402	22.75	5.25
FOURIER	4721.1	5.37	3.02
ASSIGNMENT	7.0534	26.84	6.96
IDEA	1597.4	24.43	7.25
HUFFMAN	575.17	15.95	5.09
NEURAL NET	4.2065	6.76	2.84
LU DECOMPOSITION	107.28	5.56	4.01

==========ORIGINAL BYTEMARK RESULTS========
INTEGER INDEX : 16.297
FLOATING-POINT INDEX: 5.864
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==========LINUX DATA BELOW============
CPU                 :
L2 Cache            :
OS                  : Linux 2.6.24-gdium-1
C compiler          : gcc version 4.3.4 (Debian 4.3.4-5)
libc                : libc-2.9.so
MEMORY INDEX        : 3.156
INTEGER INDEX       : 4.918
FLOATING-POINT INDEX: 3.252
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

2. gcc-4.4
CFLAGS = -s -static -Wall -O3 -fomit-frame-pointer -funroll-loops
CFLAGS += -march=loongson2f -mtune=loongson2f -mabi=n32

TEST	Iterations/sec.	Old Index	New Index
		Pentium 90*	AMD K6/233*
NUMERIC SORT	366.08	9.39	3.08
STRING SORT	46.686	20.86	3.23
BITFIELD	4.764e+07	8.17	1.71
FP EMULATION	90.2	43.28	9.99
FOURIER	5171.9	5.88	3.30
ASSIGNMENT	11.094	42.21	10.95
IDEA	1726.9	26.41	7.84
HUFFMAN	605	16.78	5.36
NEURAL NET	9.761	15.68	6.60
LU DECOMPOSITION	215.64	11.17	8.07

==========ORIGINAL BYTEMARK RESULTS========
INTEGER INDEX       : 20.035
FLOATING-POINT INDEX: 10.100
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==========LINUX DATA BELOW============
CPU                 :
L2 Cache            :
OS                  : Linux 2.6.24-gdium-1
C compiler          : gcc-4.4
libc                : libc-2.9.so
MEMORY INDEX        : 3.922
INTEGER INDEX       : 5.997
FLOATING-POINT INDEX: 5.602
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

Gerard Braad: Nokia N900; the geek-device!

noreply@blogger.com (gbraad) — Fri, 30 Oct 2009 01:31:55 +0000

During the Maemo Summit 2009 I was given a Nokia N900 for evaluation and development. For about three weeks now I have been able to use the device and got used to it in such a way that I seldom check the internet on my notebook or desktop. Here you will find my thoughts on using this 'pre-production' model.

Services I often use, like Identi.ca and Twitter, are consolidated using my Google Mail account. Normally I would quickly browse the web to check my mail and check the messages I received while I was offline. During a working day, I tended to use my other Nokia phone for tethering to my N810. This way I was mostly always online (Bluetooth sometimes wouldn't re-establish until a power down of both devices)... I was able to receive VoIP calls (SIP) on both my phone and internet tablet. Most of the time I would still use my notebook to have a full web experience or respond to my emails... and for calendar-keeping? I gave up on that... Symbian's calendar isn't comparable to the Palm calendar (or Agendus!). I have tried to use the N810 as a PDA, but the GPE tools didn't work well for me... I missed a good synchronization and integration: then came the N900.

Near desktop experience
The N900 is very powerful! That needs to be said. It is powered by a Texas Instruments OMAP3430. This processor is comparable to the BeagleBoards OMAP3530. The ARM Cortex-A8 core runs at 600Mhz and has the same PowerVR SGX 530 GPU. Only the DSP core is a little slower with 430MHz (TMS320C64x). The device gives a feeling of having more than enough power. When you start a game, like Bounce, you can still see it being active in the task-switching overview; true multi-tasking.

The OMAP-series processor can provide a full desktop experience, like the BeagleBoard can do with for instance Fedora and Ubuntu. However, this is also where the N900 falls a little short. Instead of providing a mini-HDMI connector it only has a composite out. After some tweaks in the OS you can connect a Bluetooth keyboard and mouse... and using the correct cables even USB. But you can't connect a larger screen... this way it is not a convergence device which could replace a desktop computer. Compare this to the the Creative Zii which I have for development; it provides HDMI-out and can playback a HD video in 1080p (but it can't do the desktop experience at the moment). The composite image quality is in my opinion too blurry. For games it works well, but viewing photos or a video felt a little disappointing.

Battery time and use
Lately I have seen a lot of news about the Motorola Droid. This device is also powered by the OMAP3430 and would be thinner than a iPhone 3GS. I am curious to see how they deal with battery time... since that battery must be small! The N900 is quite large and the capacity of the BL-5J battery is less than the one in the N810. The battery is empty after half a day of extensive use; GPS always on, always online (using 3G or lower depending on the location in NL, WLAN at home), FM transmitter on when I go to work (and back home) while playing music of course.

Luckily you can charge the device using the MicroUSB connector and at work I always have to do so. During this 'extensive' use I seldom made a phonecall! For me the N900 is primarily a mobile computer and a phone second. The GSM functionality provides me with the cellular data service I was missing the N810. Most of my phonecalls were done using VoIP (over 3G) and were short. I did notice the device became VERY HOT during a VoIP (over WLAN) of about 30 minutes.

Internet
If you want the full Internet in a device, the N900 is what you want. It has a Firefox browser which loads pages fast and plays Flash videos from YouTube without any hiccup. Photos you take with the camera can be immediately uploaded to remote services, like Flickr and Ovi. GPS information can be set as a status message for your IM. Maemo uses the telepahy framework for messaging and video/voice calls. Out-of-the-box it provides support for SIP, Jabber/XMPP (and Google Talk, Ovi), Skype and GSM (Voice calls, SMS). What I really like is the way conversations are kept or started. Last messages are all easily viewed from the Conversations application.

All contacts are aggregated from the IM accounts I use. This immediately fills the gap of not having a phonebook service for my SIP accounts. Contacts from different sources can be merged into a single contact entry. If you want to call a contact from the phone application you can easily see if he is online using Google Talk or Skype and even initiate such a call.

You can send a message from either the contacts or conversations (or even desktop shortcut) and it will open a separate window in which you can see the chat. I haven't felt the need to install Pidgin, unlike what I did for the N810. By installing the telepathy-extras package you can also integrate MSN, Yahoo, ICQ, IRC and more.

Closing thoughts
Maemo 5 includes a simple calendar which for the moment works quite well for me. Although you can not sync it to a remote service, it works very intuitive. Notes, calendar entries and your contacts can be synchronized using the Nokia PC Suite or SyncML compatible client.

The camera in the device is 5 mega-pixels and can really make very good quality photos. Just take a look at the Photojourney with N900 from tigert.

As a game device the N900 could be a very good competition against the iPhone. It easily plays games like Quake3. Just connect it to the TV and play using the keyboard and the accelerometer! It is almost like having an embedded Wiimote. While the N810 still had a D-pad, this was dropped on the N900. The cursor keys feel more natural for typing emails... but for gaming it feels like you miss some control. Also the screen does not allow multitouch... so no on-screen joysticks for now.

Although the device has a complete open development model it currently lacks commercial support of big game companies. I have to admit, this is still where the iPod Touch and iPhone excels... it has a lot of available games. This will be addressed in the next release of Maemo (codenamed Harmattan). It allows a security model which will probably attract a lot more commercial development.

Last week Nokia postponed the release of the N900 to allow more feedback from developers and evaluators. It also gives developers more opportunity to get familiar to the N900. As an example, most applications were installed in the / (root) filesystem, while large datafiles should have been installed to the user directory (/home/user). I had suffered from an almost complete device lock-up due to system memory being full. This should not happen to a none experienced (Linux) users. So I really think Nokia does a good thing here... They really want to give new users of Maemo a good experience.

So if you are searching for a game console rather buy a PSP Go or even iPhone. But if you bought a Macbook with the idea of having Un*x under the hood (and a terminal) you should buy a N900. Even the Android falls short in this area. If you want a phone with mobile computer ambitions (being powerful and useful) buy a N97.

For me the iPhone is a good sheep-phone, while the N900 is the real geek-phone (/device)!

Take note, I have been using a 'pre-production' model. The full production model will likely provided a much better experience.

Gerard Braad: FreeSWITCH packages for CentOS 5.3

noreply@blogger.com (gbraad) — Sun, 25 Oct 2009 20:48:30 +0000

Recently I built and packaged the 1.0.4 release of FreeSWITCH for CentOS 5.3 as i386 and x86_64. They are hosted on a temporary location http://files.spotsnel.net/freeswitch/. Eventually they will move to a repository for use with yum.

Ignacio Garcia, dingux.com: New system/toolchain

noreply@blogger.com (booboo) — Thu, 22 Oct 2009 14:03:56 +0000

Quick post. I just uploaded the latest system files and toolchain.

Changes are:

Compiled for MIPS32. Previous toolchain release was wrongly compiled again for MIPS I.
The whole system (libraries and executables) have been compiled with -O3.
Fixed MP3/OGG integer decoding in SDL_mixer.

Now for something completely different: if you are having trouble getting dingux up and running, try the following as suggested by some users:

If you can't get the dual-boot installer to start, that is, you see nothing on the A320 screen after successfully running the two usbtool commands, try to unplug then the USB cable. No idea at all what's the problem and how unplugging the cable fixes it, though (I would need such an A320 and attach a serial console).
If, after installing the dual-boot, you cannot get dingux running, try to do a complete FAT32 format of your card (with ot without partition, dingux now supports both), and then copy zImage and rootfs before anything else. There might be some problem in u-boot-1.1.6 preventing it from reading FAT32 files in some circumstances, though I tried to fix it by backporting code from the latest u-boot.

Bearstech Hackable:1: Hackable:1, rev5rc1, at last!

Thu, 15 Oct 2009 15:58:10 +0000

Dear Hackable:1 users,

We are glad to announce that, after long & thorough efforts from the development team, after a bunch of testing hours, after a long time spent on arguing whether we should include this or that feature, we made it: hackable:1 rev5rc1 (Codename: Chuck) is there!

Here is a changelog of corrected bugs and added features from rev4.

Changelog

+ End users matters

Most of the software stack now runs under the 'hackable1' user, for security purposes.
SMS proper implementation
The contact list bug has been found and fixed!
Power management improvements, suspend works (well almost each & every time, sadly we're still hunting GSM issues for that matter)!
An application called 'h1settings' can be used to configure phone features, (enable / disable GSM / Wireless / GPS, power management, ...)
We created a new theme to celebrate this new release!
We got a splashscreen! It features a Chuck figure to reflects the rev5 codename: Chuck
Boot time seems to have been improved a bit

+ Power users / developers matters

This RC1 and the upcoming final rev5 release are now built from the automatic build system.
A Linux kernel is now packaged in hackable:1, in order not to rely on fso-pkg anymore.

Debugging has been disabled (boot time improvement)
Easier kernel upgrade when using an ext2 partition to store the kernel on µSD cards
Separation of kernel modules in three sets: essential (comes with the kernel), common modules and "more modules"
You can read a bit on http://zecrazytux.net/Embedded/Hackable1/Custom_Kernel.html

Where can I find it? Where can I get it? What is the answer to the ultimate question about life, the universe, and everything?

As ever, you can download hackable:1 on http://download.hackable1.org/rev5rc1.
All the necessary information can be found on http://trac.hackable1.org as ever, that is documentation, installation instructions as well as known issues.
It's obvious that the answer to the aforementioned question is "Chuck".

Who should I thank for all that stuff?

Among the people who worked on this release, the most notorious are (alphabetically):

Marcus Bauer (mbauer)
Jérome Blondon (jbl2024)
Sébastien Bocahu (zecrazytux)
Pierre Pronchery (khorben)
David Wagner (Deubeuliou)

Zhou Yajin, vm-kernel.org: qemu mips msub instruction emulation bug

Thu, 15 Oct 2009 05:06:22 +0000

It's really a long time since last post. Now I am working on the android mips porting project. I want to run android on the MIPS emulator.

The problem is that when I run mips-android on qemu, it hangs when executing init program in the initramfs root file-system. Then I use the remote gdb to debug the init and finds out that it it because pa_workspace is not initiated.

Function ashmem_create_region will open /dev/ashmem and return the fd if succeed. However, it returns -1 and the errno is 19 which means NO SUCH DEVICES.

fd = ashmem_create_region("system_properties", size);

The problem is who is responsible for creating /dev/ashmem?

In fact, in android it uses udev mechanism to create devices in /dev when executing function device_init. The full cold patch to create a device is as following:

device_init->coldboot->do_coldboot->write(fd, "add\n", 4)->handle_device_fd->handle_device_event->make_device

In function parse_event, it will parse the uevent msg and then pass uevent to handle_device_event. However, I find that the uevent message is a little weird. I use remote gdb to dump this message.

0x7ff3d250:    "add@/class/tty/console"
0x7ff3d267:    "ACTION=add"
0x7ff3d272:    "DEVPATH=/class/tty/console"
0x7ff3d28d:    "SUBSYSTEM=tty"
0x7ff3d29b:    "MAJOR=+"
0x7ff3d2a3:    "MINOR=/"
0x7ff3d2ab:    "SEQNUM=31+"
0x7ff3d2b6:    ""
0x7ff3d2b7:    ""
0x7ff3d2b8:    ""

You see, in the message the MAJOR is +. It will confuse the parse_event so that the corresponding device won't be created.

It looks the kernel passes wrong uevent message to user space. So the question is who has messed up the uevent message?

Then I recall that when booting linux kernel, there are some weird messages.

Primary instruction cache .kB, VIPT, 2-way, linesize 1* bytes.
Primary data cache .kB, 2-way, VIPT, no aliases, linesize 1* bytes

You see the instruction cache is .kB and linesize is 1* bytes, not a valid number at all.

Then I suspect that something is wrong in kernel when parsing the numbers. So I use the remote gdb to debug the kernel again.

r4k_cache_init->probe_pcache->printk->vprintk->vscnprintf->vsnprintf->number->put_dec->put_dec_trunc

Function put_dec_trunc uses a unsigned int between[0,99999] as input and outputs the number as a string. But I find that when the input is 2, the output is '.', not the expected '2'. So maybe this function is the bad boy.

In the following function I assume q=2.

277 static char* put_dec_trunc(char *buf, unsigned q)
278 {
279         unsigned d3, d2, d1, d0;
280         d1 = (q>>4) & 0xf;            /*d1=0*/
281         d2 = (q>>8) & 0xf;            /*d2=0*/
282         d3 = (q>>12);                 /*d3=0*/
283
284         d0 = 6*(d3 + d2 + d1) + (q & 0xf); /*d0=2*/
285         q = (d0 * 0xcd) >> 11;              /*q=0*/
286         d0 = d0 - 10*q;                     /*d==2*/
287         *buf++ = d0 + ''; /* least significant digit */
288         d1 = q + 9*d3 + 5*d2 + d1;   /*d1=0*/
289         if (d1 != 0) {               /* it is false so we won't get into here.*/
290                 q = (d1 * 0xcd) >> 11;
291                 d1 = d1 - 10*q;
292                 *buf++ = d1 + ''; /* next digit */
293
294                 d2 = q + 2*d2;
295                 if ((d2 != 0) || (d3 != 0)) {
296                         q = (d2 * 0xd) >> 7;
297                         d2 = d2 - 10*q;
298                         *buf++ = d2 + ''; /* next digit */
299
300                         d3 = q + 4*d3;
301                         if (d3 != 0) {
302                                 q = (d3 * 0xcd) >> 11;
303                                 d3 = d3 - 10*q;
304                                 *buf++ = d3 + ''; /* next digit */
305                                 if (q != 0)
306                                         *buf++ = q + ''; /* most sign. digit */
307                         }
308                 }
309         }
310         return buf;
311 }

/* MIPS uses a0/a1 to pass arguments.
* a0= address of bu
* a1= q = 2
*/
8015a040 <put_dec_trunc>:
8015a040:    00051202     srl    v0,a1,0x8        /* v0= q>>8*/
8015a044:    00053102     srl    a2,a1,0x4        /* a2= q>>4*/
8015a048:    30c6000f     andi    a2,a2,0xf        /* a2= (q>>4) & 0xf = d1 in line 280*/
8015a04c:    3048000f     andi    t0,v0,0xf        /* t0 = (q>>8) & 0xf = d2 in line 281*/
8015a050:    00054b02     srl    t1,a1,0xc        /* t1= (q>>12) = d3 in line 282*/
8015a054:    00c81021     addu    v0,a2,t0
8015a058:    00491021     addu    v0,v0,t1          /* v0 = d1+d2+d3 in line 284*/
8015a05c:    24030006     li    v1,6
8015a060:    70433802     mul    a3,v0,v1          /*a3= 6*(d3 + d2 + d1)*/
8015a064:    30a5000f     andi    a1,a1,0xf         /*a1= q & 0xf*/
8015a068:    24020009     li    v0,9               /*v0=9*/
8015a06c:    00e56021     addu    t4,a3,a1          /*t4= 6*(d3 + d2 + d1) + (q & 0xf) = d0 in line 284*/
8015a070:    240b00cd     li    t3,205            /*t3= 0xcd*/
8015a074:    71223802     mul    a3,t1,v0          /*a3= 9*d3 in line 288. Apparently gcc has reordered the code.*/
8015a078:    718b1802     mul    v1,t4,t3          /*v1= (d0*0xcd)*/
8015a07c:    24020005     li    v0,5
8015a080:    00e62821     addu    a1,a3,a2          /*a1= 9*d3 + d1 in line 288*/
8015a084:    71023002     mul    a2,t0,v0          /*a2= 5*d2 in line 288*/
8015a088:    00031ac2     srl    v1,v1,0xb         /*v1= (d0*0xcd)>>11 in line 285*/
8015a08c:    240a000a     li    t2,10             /*t2=10*/
8015a090:    01800013     mtlo    t4                /*put t4->lo. lo=t4= 6*(d3 + d2 + d1) + (q & 0xf) = d0 in line 284 */
8015a094:    706a0004     msub    v1,t2             /*hilo = v1*t2 - hilo = 10*(q) - hilo in line 286*/
8015a098:    00c51021     addu    v0,a2,a1
8015a09c:    00002812     mflo    a1                /*lo->a1*/
8015a0a0:    00431821     addu    v1,v0,v1
8015a0a4:    24a20030     addiu    v0,a1,48
8015a0a8:    00803821     move    a3,a0
8015a0ac:    a0820000     sb    v0,0(a0)

We just need to see the instruction in 0x8015a094, it is a msub instruction. The defination of msub is as following:

(HI,LO) = (HI,LO) - (GRP[RS]*GPR[RT])

Then after executing the instruction in 0x8015a094, the HI/LO should be 0/2. But qemu produces the value 0xffffffff/0xfffffffe, which is -2 indeed. Maybe this is the problem.

Then I need to find how qemu emulates msub instruction.

2178     case OPC_MSUB:
2179         {
2180             TCGv r_tmp1 = tcg_temp_new(TCG_TYPE_I64);
2181             TCGv r_tmp2 = tcg_temp_new(TCG_TYPE_I64);
2182             TCGv r_tmp3 = tcg_temp_new(TCG_TYPE_I64);
2183
2184             tcg_gen_ext32s_tl(t0, t0);
2185             tcg_gen_ext32s_tl(t1, t1);
2186             tcg_gen_ext_tl_i64(r_tmp1, t0);
2187             tcg_gen_ext_tl_i64(r_tmp2, t1);
2188             tcg_gen_mul_i64(r_tmp1, r_tmp1, r_tmp2); /*r_tmp1= gpr[rs]*gpr[rt] */
2189             gen_load_LO(t0, 0);                /*t0 <- lo*/
2190             gen_load_HI(t1, 0);                /*t1 <- hi*/
2191             tcg_gen_extu_tl_i64(r_tmp2, t0);   /*r_tmp2 = 64bit expand of lo*/
2192             tcg_gen_extu_tl_i64(r_tmp3, t1);   /*r_tmp3 = 64bit expand of hi*/
2193             tcg_gen_shli_i64(r_tmp3, r_tmp3, 32);
2194             tcg_gen_or_i64(r_tmp2, r_tmp2, r_tmp3);
2195             tcg_temp_free(r_tmp3);
2196             tcg_gen_sub_i64(r_tmp1, r_tmp1, r_tmp2); /*r_tmp1= r_tmp1 - r_tmp2 = gpr[rs]*gpr[rt] - HI/LO */
2197             tcg_temp_free(r_tmp2);
2198             tcg_gen_trunc_i64_tl(t0, r_tmp1);
2199             tcg_gen_shri_i64(r_tmp1, r_tmp1, 32);
2200             tcg_gen_trunc_i64_tl(t1, r_tmp1);
2201             tcg_temp_free(r_tmp1);
2202             tcg_gen_ext32s_tl(t0, t0);
2203             tcg_gen_ext32s_tl(t1, t1);
2204             gen_store_LO(t0, 0);
2205             gen_store_HI(t1, 0);
2206         }
2207         opn = "msub";
2208         break;

You see, qemu makes an error emulation of msub instruction. It uses gpr[rs]*gpr[rt]-HI/LO and then put the results to HI/LO, which is different from the defination of msub instruction. I patched the qemu code and it works.

BTW: MIPS32 4KTM Processor Core Family Software User’s Manual version MD00016 gives an error operation of msub instruction on papge 253.

Operation:
   temp ← (HI || LO) - (GPR[rs] * GPR[rt])
   HI ← temp63..32
   LO ← temp31..0

Maybe this misleads the qemu developers. The latest qemu version has fixed this bug. We can see this instruction emulation in qemu-svn-20091014.

2195     case OPC_MSUB:
2196         {
2197             TCGv_i64 t2 = tcg_temp_new_i64();
2198             TCGv_i64 t3 = tcg_temp_new_i64();
2199
2200             tcg_gen_ext_tl_i64(t2, t0);
2201             tcg_gen_ext_tl_i64(t3, t1);
2202             tcg_gen_mul_i64(t2, t2, t3); /*t2=GPR[RS]*GPR[RT] */
2203             tcg_gen_concat_tl_i64(t3, cpu_LO[0], cpu_HI[0]); /*t3= HI/LO*/
2204             tcg_gen_sub_i64(t2, t3, t2); /*t2= HI/LO - GPR[RS]*GPR[RT] */
2205             tcg_temp_free_i64(t3);
2206             tcg_gen_trunc_i64_tl(t0, t2);
2207             tcg_gen_shri_i64(t2, t2, 32);
2208             tcg_gen_trunc_i64_tl(t1, t2);
2209             tcg_temp_free_i64(t2);
2210             tcg_gen_ext32s_tl(cpu_LO[0], t0);
2211             tcg_gen_ext32s_tl(cpu_HI[0], t1);
2212         }
2213         opn = "msub";
2214         break;

See this link for more information.

So finding this bug is really not easy. I have to dig dig and dig from userland to linux kernel and then to qemu until catching this bad qemu bug. Thanks to the remote gdb and gdb stub in qemu, it makes life easier.

Following is the patch of qemu.

diff --git a/target-mips/translate.c b/target-mips/translate.c
index 3dded6c..0a1b461 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -2193,7 +2193,11 @@ static void gen_muldiv (DisasContext *ctx, uint32_t opc,
             tcg_gen_shli_i64(r_tmp3, r_tmp3, 32);
             tcg_gen_or_i64(r_tmp2, r_tmp2, r_tmp3);
             tcg_temp_free(r_tmp3);
-            tcg_gen_sub_i64(r_tmp1, r_tmp1, r_tmp2);
+            /* msub means HI/LO = HI/LO - GPR[RS]*GPR[RT],
+             * not HI/LO = GPR[RS]*GPR[RT] - HI/LO
+             */
+            //tcg_gen_sub_i64(r_tmp1, r_tmp2, r_tmp2);
+            tcg_gen_sub_i64(r_tmp1, r_tmp2, r_tmp1);
             tcg_temp_free(r_tmp2);
             tcg_gen_trunc_i64_tl(t0, r_tmp1);
             tcg_gen_shri_i64(r_tmp1, r_tmp1, 32);

Ignacio Garcia, dingux.com: Progress on x760+ / buildroot published

noreply@blogger.com (booboo) — Mon, 28 Sep 2009 14:53:21 +0000

First and foremost: sorry for being so hard to get in touch with lately. We've been in defcon 1 for the last week at work preparing a demo for the current project (OMAP3530 based) which is crucial to the future of the company, so I had reduced my daily routine to sleep-eat-work-sleep. My inbox is exploding.

Sweetlimre commented on having a writable home directory (see interview). If I recall correctly, I wrote about this already. The main application executed by busybox's init process is responsible for this. At this stage in the boot process no HOME environment variable has been set. I could easily modify busybox's init to set it to "/usr/local/home", but I felt it's better to stick to a vanilla busybox as much as possible. Oh, wait: maybe if (as I recommended) the main menu application is using exec() to launch emus/apps things are not so simple. Need some input from devs here, and if the only solution is to modify busybox's init, so be it.

Regarding the modified buildroot I'm using, as he requested it's now available for download at the google code project page. I hadn't published it before just because I could not find time to fix all the dirty hacks I used, which resulted in a partially manual build. I'll be glad to add anything developers suggest. Just send me the buildroot recipe. I would really like to stay away from OpenEmbedded. I have to use it for the OMAP3530 and IMHO it is way overengineered.

Some good news on the Ingenic front: the Qi-Hardware guys have managed to get Ingenic to release their kernel development trees DAILY. This means immediate access to any useful fix they make. There are 2.6.24.3 and 2.6.27 branches, and I'm working on porting the A320 support code to the later, mostly to see if it helps somehow with the USB/DMA and SD/MMC standing bugs. Note that in the case of embedded devices like the A320 I don't think that newer kernel is necessarily better.

Regarding the Gemei x760+ things are going slower than expected. I dumped the hardware initialization .DL from NAND flash and disassembled it, only to discover I was looking in the wrong place. Let me explain:

When the JZ4740 boots a piece of code called the IPL (Initial Program Loader) is executed from ROM. Depending on the state of some pins this code either enters USB boot mode or boots from NOR or NAND flash. In the A320 we can only choose to enter USB boot mode or boot from NAND. The IPL only supports 512 and 2048 page size NAND, so despite the fact that the NAND chip in the A320 has a 4096 page size it is handled by the IPL as if it was 2048.

The IPL reads the four first pages (8KB total) of NAND into the instruction cache (because the SDRAM is not yet available). This is called the SPL (secondary program loader) and its purpose is to do a basic hardware initialization, most notably making the SDRAM available, and load the system loader from NAND. The A320 SPL also handles the NAND as if it was 2048.

In the original firmware the SDL is stored in the first 8KB of the first NAND block (0x00000-0x3FFFF). It loads the system loader from 0x50000-0xBFFFF. Before loading the operating system the A320 system loader does something interesting: it loads from 0x40000-0x4FFFF a piece of code that I call the hardware initialization DL. It is a dynamic linked object code chunk that does board-specific hardware initialization: GPIO, LCD, etc. This is the interesting stuff. In both the older and newer A320 the LCD initialization code was reverse engineered from this DL.

However, the x760+ LCD initialization seems to be mostly done by the system loader itself. It stil loads the DL and uses it for some GPIO initialization that is also related to the LCD controller, but not much more. The DL does contain a large LCD register initialization code routine, but it is unused (and I lost a lot of time reverse engineering it).

Since the system loader code is much larger (~260KB) than the DL code (~10KB), it's gonna take some time to reverse engineer the LCD handling code. Note also that I had already reverse engineered the A320 DL code and that helped a lot, but the system loader is unexplored territory.

Gerard Braad: Fedora 11 on coLinux (fixes)

noreply@blogger.com (gbraad) — Mon, 21 Sep 2009 16:47:47 +0000

Recently HenryN (of coLinux) made some minor changes to the Fedora 11 image for coLinux. The new image is available from the coLinux forum at SourceForge or directly from [FedoraPeople] or [MegaUpload] (70.3 MB).

Thanks!

Note: the original image has been replaced by this fixed image. If needed the original image is available upon request. However it should be considered obsolete.

Gerard Braad: Fedora 11 on coLinux

noreply@blogger.com (gbraad) — Mon, 21 Sep 2009 16:46:18 +0000

After some minor issues I managed to install Fedora 11 on coLinux. Normally I would perform a manual installation by creating a basic rpm environment, but with Fedora 11 I encountered problems during the installation; first the version of squashfs was different. This was easily fixed with a dump from Fedora 10... but second, rpm packages were all of a sudden not available halfway a rpm transaction. Since it occurred more than once, I settled for using qemu again.

The file colinux-fedora11.exe (82MB) is published on [fedorapeople], [dropbox] and [files]. It does have some minor issues during startup, but besides this it is operational. The installation was performed as a basic installation; so it does not contain any graphical environment, no additional network servers, no updates, etc. This way the download is small. The only added packages are wget, mc and my kernel modules RPM.

All you need to run it is: coLinux, winpcap and the archive. The file 'run.bat' would start the cooperative environment. Any tweaks you would like to make can be placed in the 'run.txt' file. The user is 'root' without a password. After you start it, do set a password for this user.

Personally I use the environment for Fedora Electronic Lab which coexists with Cygwin. Not all the tools I use for electronics are available on Linux... yet!

Note: I have used version 0.7.3 of coLinux because the current stable release 0.7.4 suffers from a problem with the tap device.

Note 21-09-09: The original image has been replaced by the updated image from HenryN. IF needed the original image is available upon request. It should however be considered as obsolete.

Ignacio Garcia, dingux.com: Testing new dual-boot installer

noreply@blogger.com (booboo) — Fri, 18 Sep 2009 10:35:40 +0000

I've just released a new dual-boot installer in the hope that it fixes the "flash write error" problem some users have experienced. The error is caused by one or more bad pages in the first block of NAND. This is normal and there is a mechanism that was supposed so handle it but wasn't working. As I don't have bad pages in this first block in my two A320s, I can't test it myself, so, until someone reports that it is working for him, consider it beta.

UPDATE 1: so far three success reports. Yeah, looks like this bug is squashed!.

UPDATE 2: confirmed. No more flash write errors.

Gerard Braad: Beijing LUG meeting (8th of September 2009)

noreply@blogger.com (gbraad) — Wed, 09 Sep 2009 05:47:27 +0000

Last night I attended a meeting of the Beijing Linux User Group. It was for me the first time I could attend it during my time in Beijing and it is certainly something I will do more often. Every 2nd Tuesday of the month they will have a group meeting in which they will have speakers about a subject. I was lucky to listen to Coly Li and Ulrich Drepper.

Coly Li is a kernel developer who supervised a Google Summer of Code student, YuEr, who ported openSUSE to MIPS. YuEr showed what he had done, the results and the errors still left. He was able to start a X11 session using FVWM on a Gdium (MIPS-based smartbook). For this he had used a cross-platform RPM build environment targeting MIPS and qemu. Amazing results for such a short period he was able to work on it.

Ulrich Drepper gave the same talk as he did at the RedHat Summit in Chicago about 'Acceleration Through Stream Computing'. In this talk he explains how to speed up applications by using vectorization and the vector extensions as provided by SSE. Using templates and partial specialization in C++ it is possible to speed up applications without a lot of changes. The specialized critical code could be altered by experts and just a rebuild would suffice. He explains this for instance with a simple example of a vector scaling and translation... the result speaks for themselves. It was also apparent that Ulrich is not a promoter of CUDA (or even CTM) either. In my opinion they result in vendor-lockin. The alternative to look for is OpenCL...

Overall it was a nice evening. I talked to a talented bunch of 'folklore dancers' wearing T-Shirts. If you ever have the chance to be in Beijing, stop by... you will not regret it.

Methril: What i've been doing

noreply@blogger.com (Methril) — Wed, 02 Sep 2009 02:23:01 +0000

Hello to all specially to openmokers, as this is my first post that is going to appear at planet.openmoko.org

I'm being a little bit silent lately.
The good news is that i've not been quiet :)
What i've been doing? Well, first of all i'm being too busy with a lot of tuxbrain stuff :)
I put a smile because they are giving me the opportunity to develop/hack a lot of devices and they give e the opportunity to hardware hacking, that is not an easy one :)

I've been doing some buzz fixes [1] [2] [3] [4].

I've been hacking some devices [5] [6].

I've been hacking some OE recipes (Porting some shr recipes from import/shr to org.openembedded.dev), and putting some patches [7].

I've been following new interesting companies [8].

And off course i've been having a lot of fun, a real life, a paid job and a wonderful wife that supports me ;) until one holiday week :)

I put this post because i've one specific blog with some new stuff [9] An i.MX515 [10] development platform that i'm going to start to hack.

I'm reading my mails from the last weeks (now last month), and i'm getting up to date.

.....

Stay tunned to know what i've been doing in next weeks :)

Hope to write here soon.

Greetings

--
The links
[1] http://www.openmoko-spain.org/tiki-view_blog_post.php?blogId=1&postId=10
[2] http://www.tuxbrain.com/en/content/buzz-fix-party-barcelona-movie
[3] http://www.tuxbrain.com/en/content/buzz-fix-party-madridphotos
[4] http://www.tuxbrain.com/en/content/there-and-back-againtuxbrain-debconf09-pics
[5] http://www.compulab.co.il/x270em/html/x270-em-datasheet.htm
[6] http://openinkpot.org/wiki/NetronixEB600
[7] http://article.gmane.org/gmane.comp.handhelds.openembedded/25655
[8] http://www.qi-hardware.com/
[9] http://projects.powerdeveloper.org/project/imx515/752
[10] http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX515

Gerard Braad: Accidently installed i386 packages on x86_64?

noreply@blogger.com (gbraad) — Tue, 25 Aug 2009 23:16:45 +0000

If you have a CentOS installation (or Fedora) running as x86_64 architecture, be sure to install your packages with yum using the following command:

$ yum install [packagename].x86_64

This way you will specify the architecture to use. If you do not specify the architecture you might end up installing both the x86_64 and the i386 packages with all it's dependencies.

If you have already done so in error, you can easily query for these packages using the following command:

$ rpm -qa --qf '%{name}.%{ARCH}\n' |grep i386

this command returns all i386 packages. You can pipe it directly into rpm -e or choose to uninstall them by hand.

Bearstech Hackable:1: Run Ogsmd on Hackable:1

Wed, 19 Aug 2009 21:31:46 +0000

As you may know, we are willing to migrate to FSO. As part of it, we made ogsmd running on H:1 and we will rewrite phone-kit to use libfso-glib instead of libgsmd.

Until we get all the stuff packaged, here are the step to make ogsmd running on a Hackable:1 rev4 installation.

Install the framework

We will use a git version that I know working. On your computer:

git clone git://git.freesmartphone.org/framework.git
cd framework
git checkout 17898fc0f73453c11d1b1e8db57f8e8a0cfbc943 .
cd ..
scp -r framework root@192.168.0.202: # I assume that it is you FR's IP

SSH into your freerunner and:

cd framework
python setup.py install
cd ..

Install the muxer

We will use SHR packages which a copy of them is on our trac.

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/fso-abyss_0.3.5+gitr67+ff68be1581069ca494a559e85f6299246888d3b5-r0_armv4t.ipk"
ar -x fso-abyss_0.3.5+gitr67+ff68be1581069ca494a559e85f6299246888d3b5-r0_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libgsm0710mux0_0.3.5+gitr35+8e3e7533b286d8086bce8fa09bce23bb9f18bb98-r1_armv4t.ipk"
ar -x libgsm0710mux0_0.3.5+gitr35+8e3e7533b286d8086bce8fa09bce23bb9f18bb98-r1_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libgsm0710-0_1.1.1+gitr15+3bb80ba6cc9f86ed3996f88bfa2986cc572489d6-r1_armv4t.ipk"
ar -x libgsm0710-0_1.1.1+gitr15+3bb80ba6cc9f86ed3996f88bfa2986cc572489d6-r1_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libfsotransport0_0.9.3+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk"
ar -x libfsotransport0_0.9.3+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libfsobasics0_0.8.1.0+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk"
ar -x libfsobasics0_0.8.1.0+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk
tar -xvzf data.tar.gz -C /

We will use SHR frameworkd.conf:

wget "http://git.shr-project.org/git/?p=shr-themes.git;a=blob_plain;f=frameworkd/frameworkd-config-shr/om-gta02/frameworkd.conf;hb=HEAD" -O /etc/frameworkd.conf

If the following file doesn't exists, libgsm0710mux segfaults (see http://trac.freesmartphone.org/ticket/467)

cat << __EOF > /etc/abyss.conf
[omuxerd]
autoopen = 1
autoclose = 1
autoexit = 1
[session]
mode = 1
framesize = 98
port = /dev/ttySAC0
speed = 115200

[device]
wakeup_threshold = 6
wakeup_waitms = 200

__EOF

And if this one doesn't exists, fso-abyss claims it doesn't provide any channel

touch /etc/cornucopia.conf

A file may have permissions problem, first check it:

ls -l /usr/lib/dbus-1.0/dbus-daemon-launch-helper

If the group isn't messagebus:

chgrp messagebus /usr/lib/dbus-1.0/dbus-daemon-launch-helper
chmod u+s /usr/lib/dbus-1.0/dbus-daemon-launch-helper # because chgrp removes the SUID

Launch Ogsmd

Let's kill the old stuff...

killall -9 ogsmd

...and launch te framework:

frameworkd -s ogsmd

If no error (Python Traceback) occurs, we can move on:

libfso-glib sample
Install libfso-glib

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/libfso-glib/libfso-glib0_0.2.0-gitrx44+9d292508739452b55b80ec40ec57405a5de2159f-r0_armv4t.ipk"
ar -x libfso-glib0_0.2.0-gitrx44+9d292508739452b55b80ec40ec57405a5de2159f-r0_armv4t.ipk
tar -xvzf data.tar.gz -C /

Install the sample (See the sources)

wget http://trac.hackable1.org/trac/raw-attachment/wiki/libfso-glib/sample-libfso-glib_0.1-1_armel.deb
dpkg -i sample-libfso-glib_0.1-1_armel.deb
sample-w

You will be asked for your PIN (unless you are already authentified) and you will be registered.

Then, it will catch several signals. after that, you can call yourself and see the signals "CallStatus" be matched. These signals are sent whenever the status of a call (which ID is specified, i.e. "1") change. (ie "incoming" or "release"). See FSO doc for further information.

And now what ? You can already, by reading freesmartphone.h, find any interesting function you need and write nice applications.

Any question ?
If you have any question about this manipulation or about Hackable:1, feel free to ask in the comments.

You can fin updates of this tutorial on our trac

Bearstech Hackable:1: hackable:1 makes your device happy

Mon, 17 Aug 2009 14:11:00 +0000

As a lot of you know, at Bearstech, we're very serious with hackable:1 and what we intend to do with it.

If you were to ask to a typical hackable:1 developer, he'd probably say he crafts his code as he would paint an art piece or carve a nice wooden table. All the development is done for your GTA02 pleasure.

As can prove the following pictures, left alone, our GTA02s are not that happy. See how they seem to whine or just how they seem alone, oblivious to the fact that they're with their peers:

But then, a little bit of H:1 magic, and look at how they seem to shine in happiness, all directed towards the same common objective, united to fight for their common goal:

There is no ~~spoon~~ more proof needed to say that hackable:1 will make your device happy. Up to you guys !

Bearstech Hackable:1: Welcome on our new hackable:blog !

Thu, 13 Aug 2009 17:35:21 +0000

Hey everyone,

Long time no see. At last, we decided to setup a blog in order to keep you all in touch with what you need to know about hackable:1, and about the new things we do.

Stay tuned, as we're bounded to put a lot of things here sooner than later!

Zhou Yajin, vm-kernel.org: qemu internal part 3: memory watchpoint

Wed, 15 Jul 2009 09:31:00 +0000

In qemu there is an amazing feature – memory watchpoint. It can watch all the memory access including memory read, write or both of them. When guest os/application touches the memory region watched by qemu, a registered function will be called and you can do everything as you want in this function. The gdb stub in qemu uses it to implement the memory watch command.

The implemention of memory watchpoint is tricky in qemu. In last article of qemu internal, we know that when emulating memory access, qemu needs to distinguish the normal RAM read/write from memory mapped I/O read/write. If it is a memory mapped I/O address access, qemu will dispatch this access to the registered I/O emulation functions. Qemu use this mechanism to implement the memory watchpoint. When accessing the memory address watched by qemu, qemu will dispatch this access to the registered memory watch functions, even if this address is normal guest RAM address or memory mapped I/O address! Qemu will do all the magic things in these memory watch functions.

In the following, I will use an example to explain the whole process of memory watch implement of qemu.

80103c60 <memcpy>:
80103c60: 00801021 move v0,a0
80103c64 <__copy_user>:
80103c64: 2cca0004 sltiu t2,a2,4
80103c68: 30890003 andi t1,a0,0x3
80103c6c: 15400068 bnez t2,80103e10 <__copy_user+0x1ac>
80103c70: 30a80003 andi t0,a1,0x3
80103c74: 1520003d bnez t1,80103d6c <__copy_user+0x108>
80103c78: 00000000 nop
80103c7c: 15000046 bnez t0,80103d98 <__copy_user+0x134>
80103c80: 00064142 srl t0,a2,0x5
80103c84: 11000017 beqz t0,80103ce4 <__copy_user+0x80>
80103c88: 30d8001f andi t8,a2,0x1f
80103c8c: 00000000 nop
80103c90: 8ca80000 lw t0,0(a1)

These asm lines are objdumped from linux 2.6.30 kernel for mips malta. Assume that I want to watch the memory access of virtual address 0x804cd000(swapper_pg_dir in linux kernel).

First I insert the watchpoint into cpu.

cpu_watchpoint_insert(env, 0x804cd000, 4, BP_GDB | BP_MEM_ACCESS,
NULL);

And then I need to register the vm state changing call back functions.

qemu_add_vm_change_state_handler(spy_vm_state_change, NULL);

If register a1=0x804cd000, guest linux kernel will touch the watched memory region when pc is 0x80103c90, then qemu dispatches this access to the registered memory watch function, even if this access is a noram guest RAM access.The memory watch functions in qemu are in array watch_mem_read/watch_mem_write.

exec.c

2649 static CPUReadMemoryFunc *watch_mem_read[3] = {
2650 watch_mem_readb,
2651 watch_mem_readw,
2652 watch_mem_readl,
2653 };
2654
2655 static CPUWriteMemoryFunc *watch_mem_write[3] = {
2656 watch_mem_writeb,
2657 watch_mem_writew,
2658 watch_mem_writel,
2659 };

In function watch_mem_readl, it will call function check_watchpoint first.

exec.c

2622 static uint32_t watch_mem_readl(void *opaque, target_phys_addr_t addr)
2623 {
2624 check_watchpoint(addr & ~TARGET_PAGE_MASK, ~0x3, BP_MEM_READ);
2625 return ldl_phys(addr);
2626 }

2563 static void check_watchpoint(int offset, int len_mask, int flags)
2564 {
2565 CPUState *env = cpu_single_env;
2566 target_ulong pc, cs_base;
2567 TranslationBlock *tb;
2568 target_ulong vaddr;
2569 CPUWatchpoint *wp;
2570 int cpu_flags;
2571
2572 if (env->watchpoint_hit) {
2573 /* We re-entered the check after replacing the TB. Now raise
2574 * the debug interrupt so that is will trigger after the
2575 * current instruction. */
2576 cpu_interrupt(env, CPU_INTERRUPT_DEBUG);
2577 return;
2578 }
2579 vaddr = (env->mem_io_vaddr & TARGET_PAGE_MASK) + offset;
2580 TAILQ_FOREACH(wp, &env->watchpoints, entry) {
2581 if ((vaddr == (wp->vaddr & len_mask) ||
2582 (vaddr & wp->len_mask) == wp->vaddr) && (wp->flags & flags)) {
2583 wp->flags |= BP_WATCHPOINT_HIT;
2584 if (!env->watchpoint_hit) {
2585 env->watchpoint_hit = wp;
2586 tb = tb_find_pc(env->mem_io_pc);
2587 if (!tb) {
2588 cpu_abort(env, "check_watchpoint: could not find TB for "
2589 "pc=%p", (void *)env->mem_io_pc);
2590 }
2591 cpu_restore_state(tb, env, env->mem_io_pc, NULL);
2592 tb_phys_invalidate(tb, -1);
2593 if (wp->flags & BP_STOP_BEFORE_ACCESS) {
2594 env->exception_index = EXCP_DEBUG;
2595 } else {
2596 cpu_get_tb_cpu_state(env, &pc, &cs_base, &cpu_flags);
2597 tb_gen_code(env, pc, cs_base, cpu_flags, 1);
2598 }
2599 cpu_resume_from_signal(env, NULL);
2600 }
2601 } else {
2602 wp->flags &= ~BP_WATCHPOINT_HIT;
2603 }
2604 }
2605 }

When check_watchpoint is executed in the first time, env->watchpoint_hit is null. Then it will check whether the address is a watched address. If so, set the flag BP_WATCHPOINT_HIT in wp->flags(line 2583) and set env->watchpoint_hit to wp. Then it will find and invalidate the current translation block(line 2586-2592). If the flag BP_STOP_BEFORE_ACCESS in wp is not set, then qemu will translate the code from current pc(line 2596-2597) and resume the guest instruction emulation(line 2599). Function cpu_resume_from_signal will jump to line 256 in cpu-exec.c and rerun the emulation process from the lw instruction(pc=0x80103c90).

cpu-exec.c

255 for(;;) {
256 if (setjmp(env->jmp_env) == 0) {
257 env->current_tb = NULL;
258 /* if an exception is pending, we execute it here */
259 if (env->exception_index >= 0) {
260 if (env->exception_index >= EXCP_INTERRUPT) {
261 /* exit request from the cpu execution loop */
262 ret = env->exception_index;
263 if (ret == EXCP_DEBUG)
264 cpu_handle_debug_exception(env);
265 break;
266 } else {

Why do qemu need to invalidate current translation block and regenerate the code? Because this memory access(pc=0x80103c90) is in the middle of a translation block. If we want to rerun this instruction, we need to regenerate the code from this instruction(pc=0x80103c90). Moreover before invalidating the translation block, qemu needs to sync the cpu state to guest cpu(cpu_restore_state). That’s because the cpu state in the middle of translation block is different from the actual cpu state. Understanding this process needs some knowledge of binary translation. If you find it is hard to understand, just ignore it.

Now qemu rerun the guest os from pc=0x80103c90. Because the memory address is a watched memory address, qemu will call watch_mem_readl->check_watchpoint again. But this time, env->watchpoint_hit is not null(qemu set it in last call), then it will call cpu_interrupt and return from function check_watchpoint. Then in watch_mem_readl it will call ldl_phys to fetch the value from guest RAM. Function cpu_interrupt in check_watchpoint sets the CPU_INTERRUPT_DEBUG to flag to env->interrupt_request.

Then qemu runs normally just like nothing has happened. Because the CPU_INTERRUPT_DEBUG has been set in env->interrupt_request, the main loop of cpu emulation will return.

cpu-exec.c

355 if (interrupt_request & CPU_INTERRUPT_DEBUG) {
356 env->interrupt_request &= ~CPU_INTERRUPT_DEBUG;
357 env->exception_index = EXCP_DEBUG;
358 cpu_loop_exit();
359 }

54 void cpu_loop_exit(void)
55 {
56 /* NOTE: the register at this point must be saved by hand because
57 longjmp restore them */
58 regs_to_env();
59 longjmp(env->jmp_env, 1);
60 }

Function cpu_loop_exit will do longjmp to line 256 in cpu-exec.c. Because env->exception_index is EXCP_DEBUG, it will break from the loop of function cpu_exec. Function cpu_exec returns to main_loop in vl.c.

vl.c

3800 ret = cpu_exec(env);

3850 if (unlikely(ret == EXCP_DEBUG)) {
3851 gdb_set_stop_cpu(cur_cpu);
3852 vm_stop(EXCP_DEBUG);
3853 }

It will call gdb_set_stop_cpu and then vm_stop to stop the qemu. It the virtual state is changed, qemu will the call the callback functions registered by qemu_add_vm_change_state_handler. So the function spy_vm_state_change will be called.

In sum, when accessing the watched memory address, the memory watch functions will be called. It will call function check_watchpoint. Function check_watchpoint will set env->watchpoint_hit to current watchpoint and rerun the guest os/applicaton from current pc. Then memory watched functions will be called again. It will call function check_watchpoint. This time, function check_watchpoint just set the flag in env->interrupt_request and tells cpu to interrupt the emulation process. And then qemu will return to the main_loop and stop the vm. At last it will call the registered vm change state callback functions.

Zhou Yajin, vm-kernel.org: qemu internal part 2: softmmu

Fri, 10 Jul 2009 03:14:00 +0000

Qemu uses softmmu to accelerate the process of finding the mapping between guest physical address and host virtual address and the mapping between guest I/O region and qemu I/O emulation functions. In this article, I assume the guest page table size is 4K.

1. the two level guest physical page descriptor table

Qemu uses a two level guest physical page descriptor table to maintain the guest memory space and MMIO space. The table is pointed by l1_phys_map. Bits [31:22] is used to index first level entry and bits [21:12] is used to index the second level entry. The entry of the second level table is PhysPageDesc.

exec.c

146 typedef struct PhysPageDesc {
147 /* offset in host memory of the page + io_index in the low bits */
148 ram_addr_t phys_offset;
149 ram_addr_t region_offset;
150 } PhysPageDesc;

If the memory region is RAM, then the bits [31:12] of phys_offset means the offset of this page in emulated physical memory. If the memory region is memory mapped I/O, then the bits of [11:3] of phys_offset means the index in io_mem_write/io_mem_read array. When accessing this memory region, the functions in io_mem_write/io_mem_read of index phys_offset will be called.

2. register the guest physical memory

Function cpu_register_physical_memory is used to register a guest memory region. If phys_offset is IO_MEM_RAM then it means this region is guest RAM space. If the phys_offset >IO_MEM_ROM, then it means this memory region is MMIO space.

898 static inline void cpu_register_physical_memory(target_phys_addr_t start_addr,
899 ram_addr_t size,
900 ram_addr_t phys_offset)
901 {
902 cpu_register_physical_memory_offset(start_addr, size, phys_offset, 0);
903 }

Function cpu_register_physical_memory_offset will first find the PhysPageDesc in table l1_phys_map using the given guest physical address. If finding the entry, qemu will update the entry. If not finding the entry, then qemu creates a new entry and updates its value and insert this entry to the table at last.

In malta emulation, the following is the code to register malta RAM space.

hw/mips_malta.c

811 cpu_register_physical_memory(0, ram_size, IO_MEM_RAM);

3. register the mmio space

Before registering mmio space using cpu_register_physical_memory, qemu uses the function cpu_register_io_memory to register the I/O emulation functions to array io_mem_write/io_mem_read.

exec.c

2851 int cpu_register_io_memory(int io_index,
2852 CPUReadMemoryFunc **mem_read,
2853 CPUWriteMemoryFunc **mem_write,
2854 void *opaque)

This function will return the index in array io_mem_write/io_mem_read and this index will be passed to function cpu_register_physical_memory via parameter phys_offset.

hw/mips_malta.c

malta = cpu_register_io_memory(0, malta_fpga_read,
malta_fpga_write, s);

cpu_register_physical_memory(base, 0x900, malta);

4. softmmu

Given the guest virtual address, how does qemu find the corresponding host virtual address? First qemu needs to translate the guest virtual address to guest physical address. Then qemu needs to find the PhysPageDesc entry in table l1_phys_map and get the phys_offset. At last qemu should add phys_offset to phys_ram_base to get the host virtual address.

Qemu uses a softmmu model to speed up this process. Its main idea is storing the offset of guest virtual address to host virtual address in a TLB table. When translating the guest virtual address to host virtual address, it will search this TLB table firstly. If there is an entry in the table, then qemu can add this offset to guest virtual address to get the host virtual address directly. Otherwise, it needs to search the l1_phys_map table and then fill the corresponding entry to the TLB table. The index of this TLB table is bits [19:12] of guest virtual address and there is no asid field in tlb entry. This means the TLB table needs to be flushed in process switch!

This TLB table idea is just like the most traditional hardware TLB. However, to MIPS cpu, there is another mmu model in qemu. Unlike x86 cpu, MIPS does NOT care about hardware page table. Instead it uses hardware TLB which is NOT transparent to software. Maybe It is another topic I will explain in another article. What we need to understand here is that the softmmu model in this article is not the mmu model of MIPS cpu itself.

Moreover, besides helping speed up the process of translating guest virtual address to host virtual address, this softmmu model can speed up the process of dispatching I/O emulation functions according to guest virtual address too. In this case, the idex of I/O emulation functions in io_mem_write/io_mem_read is stored in iotlb.

The format of TLB entry is as flowing:

cpu-defs.h

176 CPUTLBEntry tlb_table[NB_MMU_MODES][CPU_TLB_SIZE]; \
177 target_phys_addr_t iotlb[NB_MMU_MODES][CPU_TLB_SIZE];

108 typedef struct CPUTLBEntry {
109 /* bit TARGET_LONG_BITS to TARGET_PAGE_BITS : virtual address
110 bit TARGET_PAGE_BITS-1..4 : Nonzero for accesses that should not
111 go directly to ram.
112 bit 3 : indicates that the entry is invalid
113 bit 2..0 : zero
114 */
115 target_ulong addr_read;
116 target_ulong addr_write;
117 target_ulong addr_code;
124 target_phys_addr_t addend;
131 } CPUTLBEntry;

Field addr_read/write/code stores the guest virtual address for TLB entry. It is the tag of this entry. Filed addend is the offset of host virtual address to guest virtual address. We can add this value to guest virtual address to get the host virtual address.

addend = host_virtual_address – guest_virtual_address

host_virtual_address = phys_ram_base(qemu variable) + guest_physical_address – guest_physical_address_base(0 in MIPS)

The iotlb stores the index of I/O emulation function in io_mem_write/io_mem_read.

Function __ldb_mmu/__ldl_mmu/__ldw_mmu is used to translating the guest virtual address to host virtual address or dispatching guest virtual address to I/O emulation functions.

softmmu_template.h

86 DATA_TYPE REGPARM glue(glue(__ld, SUFFIX), MMUSUFFIX)(target_ulong addr,
87 int mmu_idx)
88 {
89 DATA_TYPE res;
90 int index;
91 target_ulong tlb_addr;
92 target_phys_addr_t addend;
93 void *retaddr;
94
95 /* test if there is match for unaligned or IO access */
96 /* XXX: could done more in memory macro in a non portable way */
97 index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
98 redo:
99 tlb_addr = env->tlb_table[mmu_idx][index].ADDR_READ;
100 if ((addr & TARGET_PAGE_MASK) == (tlb_addr & (TARGET_PAGE_MASK | TLB_INVALID_MASK))) {
101 if (tlb_addr & ~TARGET_PAGE_MASK) {
102 /* IO access */
103 if ((addr & (DATA_SIZE - 1)) != 0)
104 goto do_unaligned_access;
105 retaddr = GETPC();
106 addend = env->iotlb[mmu_idx][index];
107 res = glue(io_read, SUFFIX)(addend, addr, retaddr);
108 } else if (((addr & ~TARGET_PAGE_MASK) + DATA_SIZE - 1) >= TARGET_PAGE_SIZE) {
109 /* slow unaligned access (it spans two pages or IO) */
110 do_unaligned_access:
111 retaddr = GETPC();
112 #ifdef ALIGNED_ONLY
113 do_unaligned_access(addr, READ_ACCESS_TYPE, mmu_idx, retaddr);
114 #endif
115 res = glue(glue(slow_ld, SUFFIX), MMUSUFFIX)(addr,
116 mmu_idx, retaddr);
117 } else {
118 /* unaligned/aligned access in the same page */
119 #ifdef ALIGNED_ONLY
120 if ((addr & (DATA_SIZE - 1)) != 0) {
121 retaddr = GETPC();
122 do_unaligned_access(addr, READ_ACCESS_TYPE, mmu_idx, retaddr);
123 }
124 #endif
125 addend = env->tlb_table[mmu_idx][index].addend;
126 res = glue(glue(ld, USUFFIX), _raw)((uint8_t *)(long)(addr+addend));
127 }
128 } else {
129 /* the page is not in the TLB : fill it */
130 retaddr = GETPC();
131 #ifdef ALIGNED_ONLY
132 if ((addr & (DATA_SIZE - 1)) != 0)
133 do_unaligned_access(addr, READ_ACCESS_TYPE, mmu_idx, retaddr);
134 #endif
135 tlb_fill(addr, READ_ACCESS_TYPE, mmu_idx, retaddr);
136 goto redo;
137 }
138 return res;
139 }

In this function, it will get the index of TLB table and compare the guest virtual address with the address stored in this tlb entry(line 97-100). If these two addresses match, it means this guest virtual address hits the tlb entry. Then qemu will determine this virtual address is a MMIO address or RAM address. If it is a MMIO address, get the index of IO emulation functions from env->iotlb and call these functions(line 103-117). If it is a RAM space, add the guest virtual address to addend to get the host virtual address(line 118-128). If there is no matched tlb entry, then fietch the entry from table l1_phys_map and insert the entry to tlb table(line 135).

5. an example

When fetching code from guest memory, the whole code path is as flowing:

cpu_exec->tb_find_fast->tb_find_slow->get_phys_addr_code->(if tlb not match)ldub_code(softmmu_header.h)->__ldl_mmu(softmmu_template.h)->tlb_fill->cpu_mips_handle_mmu_fault->tlb_set_page->tlb_set_page_exec

Zhou Yajin, vm-kernel.org: qemu internal part 1: the code path of memory load emulation

Wed, 08 Jul 2009 06:58:00 +0000

In qemu, there are two different meanings of target. The first meaning of ‘target’ means the emulated target machine architecture. For example, when emulating mips machine on x86, the target is mips and host is x86. However, in tcg(tiny code generator), target has a different meaning. It means the generated binary architecture. In the example of emulating mips on x86, in tcg the target means x86 because tcg will generate x86 binary.

This article is based on qemu version 0.10.5 and target machine emulated is little endian mips. I will summarize the code path of mips lw instruction emulation in qemu.

Function decode_opc is used for decoding all the fetched instructions before tcg generating the target binary.

target-mips/translate.c

7566 static void decode_opc (CPUState *env, DisasContext *ctx)

7960 case OPC_LB ... OPC_LWR: /* Load and stores */
7961 case OPC_SB ... OPC_SW:
7962 case OPC_SWR:
7963 case OPC_LL:
7964 case OPC_SC:
7965 gen_ldst(ctx, op, rt, rs, imm);
7966 break;

It will call function gen_ldst which is also in target-mips/translate.c.

target-mips/translate.c

973 static void gen_ldst (DisasContext *ctx, uint32_t opc, int rt,
974 int base, int16_t offset)

1046 case OPC_LW:
1047 op_ldst_lw(t0, ctx);
1048 gen_store_gpr(t0, rt);
1049 opn = "lw";
1050 break;

Function op_ldst_lw will generate the target binary which fetches the value from the emulated guest memory and gen_store_gpr will store this value to the emulated cpu’s general register rt.

Function op_ldst_lw is generated by the macro OP_LD.

target-mips/translate.c

901 #define OP_LD(insn,fname) \
902 static inline void op_ldst_##insn(TCGv t0, DisasContext *ctx) \
903 { \
904 tcg_gen_qemu_##fname(t0, t0, ctx->mem_idx); \
905 }

910 OP_LD(lw,ld32s);

We can find that op_ldst_lw is a function which calls function tcg_gen_qemu_ld32s. It will output the OPC(INDEX_op_qemu_ld32u) and args to gen_opc_ptr.

tcg/tcg-op.h

1793 static inline void tcg_gen_qemu_ld32s(TCGv ret, TCGv addr, int mem_index)
1794 {
1795 #if TARGET_LONG_BITS == 32
1796 tcg_gen_op3i_i32(INDEX_op_qemu_ld32u, ret, addr, mem_index);
1797 #else
1798 tcg_gen_op4i_i32(INDEX_op_qemu_ld32u, TCGV_LOW(ret), TCGV_LOW(addr),
1799 TCGV_HIGH(addr), mem_index);
1800 tcg_gen_sari_i32(TCGV_HIGH(ret), TCGV_LOW(ret), 31);
1801 #endif
1802 }

99 static inline void tcg_gen_op3i_i32(int opc, TCGv_i32 arg1, TCGv_i32 arg2,
100 TCGArg arg3)
101 {
102 *gen_opc_ptr++ = opc;
103 *gen_opparam_ptr++ = GET_TCGV_I32(arg1);
104 *gen_opparam_ptr++ = GET_TCGV_I32(arg2);
105 *gen_opparam_ptr++ = arg3;
106 }

The path of generation of target binary code of tcg is as following.

cpu_gen_code->tcg_gen_code->tcg_gen_code_common->tcg_reg_alloc_op->tcg_out_op

tcg/i386/tcg-target.c

856 static inline void tcg_out_op(TCGContext *s, int opc,
857 const TCGArg *args, const int *const_args)

1041 case INDEX_op_qemu_ld32u:
1042 tcg_out_qemu_ld(s, args, 2);
1043 break;

431 static void tcg_out_qemu_ld(TCGContext *s, const TCGArg *args,
432 int opc)

508 #if TARGET_LONG_BITS == 32
509 tcg_out_movi(s, TCG_TYPE_I32, TCG_REG_EDX, mem_index);
510 #else
511 tcg_out_mov(s, TCG_REG_EDX, addr_reg2);
512 tcg_out_movi(s, TCG_TYPE_I32, TCG_REG_ECX, mem_index);
513 #endif
514 tcg_out8(s, 0xe8);
515 tcg_out32(s, (tcg_target_long)qemu_ld_helpers[s_bits] -
516 (tcg_target_long)s->code_ptr - 4);

In line 514, tcg outputs 0xe8 which means a call instruction in x86. It will call the functions in array qemu_ld_helpers. The args to the functions is passed by registers EAX,EDX and ECX.

tcg/i386/tcg-target.c

413 static void *qemu_ld_helpers[4] = {
414 __ldb_mmu,
415 __ldw_mmu,
416 __ldl_mmu,
417 __ldq_mmu,
418 };

These functions __ldb_mmu/__ldw_mmu are defined in softmmu_template.h.

softmmu_tempate.h

DATA_TYPE REGPARM glue(glue(__ld, SUFFIX), MMUSUFFIX)(target_ulong addr,
int mmu_idx)

In sum, function gen_ldst outputs the OPC(INDEX_op_qemu_ld32u) to gen_opc_ptr and tcg_out_op will generates the target binary according to the OPC. In the lw instruction emulation, it will generate the x86 binary calls the functions in softmmu_template.h.

Open Electrons: Using Fedoras Windows cross compilers to extend EDA software distribution

Sun, 14 Jun 2009 13:38:09 +0000

Last week announced the availability of Fedora 11. This new release entails Windows cross-compilers
introduced by Fedora’s MinGW Special Interest Group.

The aim is to eliminate duplication of work for application developers by providing a range of libraries and development tools which have already been ported to the cross-compiler environment. This means that developers will not need to recompile the application stack themselves, but can concentrate just on the changes needed to their own application.

Though this feature will interest a wide range of software developers, I believe EDA vendors will also be very interested. I will demonstrate a quick example of how to use these Windows cross-compilers.

In this demo, I will use gerbv, a gerber viewer and the example “Temperature Collector” developed by Levente Kovacs.

To install gerbv on fedora,

# yum install gerbv

The above screenshot shows gerbv compiled under a normal Linux “configure && make”. Now we will compile the same gerbv for Windows.

1. Download the sources of gerbv.

2. Setup your Fedora 11 Linux

# yum install mingw32-gcc mingw32-gtk2 mingw32-crossreport mingw32-nsiswrapper wine

3. Configure Wine.

4. Extract gerbv sources.

5. Compilation of gerbv for Windows
$ cd gerbv-2.2.0
$ mingw32-configure
$ mingw32-make

The final Windows executable file of gerbv will be stored in src/.libs/ as gerbv.exe together with its DLL file, libgerbv-1.dll.

6. Launch gerbv.exe under wine

$ wine src/.libs/gerbv.exe

7. Test gerbv.exe under windows.

Under windows, extra DLLs are required and these can be downloaded from The GTK+ Project or simply from here.

The gerber files used in this example, my compiled gerbv.exe and libgerbv-1.dll can be downloaded from here.

mingw32-nsiswrapper can later be used for building automated Windows installers for distribution.

I hope this short crash course will help you. For any additional details, please join the Fedora Mingw mailing list or IRC: #fedora-mingw on FreeNode.

References:

Fedora IRC Classroom – Using the Windows cross-compiler with Richard Jones
Windows cross compiler Feature wiki page

Open Electrons: FEL: Improving collaborative hardware development experience

Thu, 11 Jun 2009 19:06:37 +0000

One of the many faces of digital hardware design entails tracking many files to be fed to multiple EDA tools. The eventual reports or netlists are carefully analysed and logged as part of the sign-off methodology. Each company tracks these project dependent files under a certain directory structure and under a certain revision controlled system of their choice.

The development cycle Fedora Electronic Lab 12 has started. One key feature for the next Fedora 12 release will be improving “collaborative hardware development experience” on Fedora. As a test-case scenario, let’s imagine 4 persons (from 4 different continents) have encountered each other using a particular social networking medium and want to engage into the development of a FPGA project.

While Fedora Electronic Lab already includes the respective simulators for digital design (VHDL/Verilog), waveforms viewers, schematic editors, PCB layout editor and Fedora’s different webserver and security solutions, these 4 persons (test-case scenario) should not have any issue with the latest Fedora 11 release.

For Fedora 12, we want to ensure that these persons have adequate tools to set up a webserver dedicated for hardware design and help them improve their sign-off and code review methodologies. Hardware code review for small inexperienced companies is often misguided and ends up wasting work hours in unnecessary meetings. Designers often have mixed feelings about code reviews. Sometimes when the code review is outsourced to a third party, source codes are sent in the form of tarballs and tracked as tarballs instead of files, which this is no means an efficient way.

We are currently including an efficient and reliable code review solution into the Fedora collection. This free and opensource solution will also help create links and seamless references between bugs, tasks, changesets and files. Project coordinators will have a more realistic the overview of the on-going project and track the progress very easy with respect to different milestones and deadlines.

Coupled with Fedora’s commitment in Virtualization and SELinux, hardware designers will benefit with a free and robust platform which can easily be deployed.

Zhou Yajin, vm-kernel.org: a little progress on qemu-loongson

Wed, 10 Jun 2009 03:15:00 +0000

Hi guys, it is about one month since posting last blog entry. These days I am really very busy preparing the GRE and Tofel test. Moreover I have to work to support my life. So I have to spend less time on qemu-loongson.

Anyway, there are progress these days.

Rewrite the GPIO I2C emulation for gdium. Now it is more clear than before.
add st4180 rtc emulation to qemu
add stds75 temperature sensor emulation to qemu
change a little in uart emulation to satisfy pmon’s uart probing process
fix a little bug in pflash_cfi02.c
fix gdb stub bug in qemu to support mips64

Follow is the uart output of qemu-loongson.

kill-bill:/home/root/sdd/gdium/qemu-loongson/mips64el-softmmu# ./qemu-system-mips64el -M gdium -pflash gzrom.bin.gdb -nographic -S -s
Register sst39vf040 size 80000 at offset 08800000 addr 1fc00000 'pflash0' 80
devfn 70
unassigned_mem_readl Unassigned mem read 000000001fbffffc
unassigned_mem_readl Unassigned mem read 000000001fbffffc
new_sm502_mm_io 7000000 pci_mem _base 10000000
PMON2000 MIPS Initializing. Standby...
PRID=00006302
enable register space of MEMORY
DDR2 config begin_whd
DIMM read
0000008000000008read DIMM number of rows
read number of cols
module data width
DIMM SIZE=20000000
cols rows:
04030940DDR2 config end
DDR2 DLL locked
00000004
disable register space of MEMORY
jlliu : rom speed reg : 0x00000f8c
Init SDRAM Done!
Sizing caches...
Init caches...
godson2 caches found
Init caches done, cfg = 00030932
Copy PMON to execute location...
copy text section done.
Copy PMON to execute location done.
sp=80ffc000...............new_sm502_mm_io 6000000 pci_mem _base 10000000
cmd 7
mmio 6000000
FREQ
FREI
DONE
DEVI
ENVI
MAPV
nvram=bfc00000
NVRAM is invalid!
NVRAM@bfc00000
STDV
80100000: heap is already above this point
SBDD
P12PCIH

Open Electrons: Hello EDACafe!

Mon, 01 Jun 2009 18:18:55 +0000

It is with great pleasure that today I’ve a featured blog on EDACafe. My name is Chitlesh Goorah. I will be exposing different opensource solutions which will interest both EDA engineers and ASIC designers.

Some of you may know me from my work behind Fedora Electronic Lab. For about three years now, we are proposing an opensource ASIC design and simulation platform, which is fairly well accepted by many universities around the world. We are working closely with many upstream projects such as gEDA, veripool, open circuit design, … in order to ensure interoperability between our solutions.

At the same time, Fedora developers are introducing Windows cross-compilers for the next version. Thereby, EDA vendors can also use Fedora or entreprise-class distribution such as RHEL or CentOS as a development ground for their products.

Later, I will introduce other features such as virtualisation, mass deployment, various design handoff checking facilities, … etc each accompanying with at least an example. Many designers and CAD engineers are already using opensource tools such as Vi, Emacs, svn, … I am looking forward to read your comments on my next posts.

Gerard Braad: Linux distributions for ARM

noreply@blogger.com (gbraad) — Sat, 02 May 2009 00:09:41 +0000

Recently there is a lot of attention for the ARM port of Linux. This is of course related to the netbooks and specialized distributions like Maemo for the Nokia Internet Tablets and Android from Google. Earlier I wrote a short post about the Hasty Hippogriff release of the Mojo Project. This Nokia-sponsored project ported Ubuntu's Hardy Heron to the ARM architecture. It allowed a full desktop distribution to be run on hardware like BeagleBoard. Luckily the major distributions also have increased their support for ARM. openSUSE, Debian and Ubuntu officially announced their support for the ARM architecture in their next release. This will allow companies to use a distribution like openSUSE as a thin client solution or for hardware developers to use Debian as their base system.

The distributions I have tried are Fedora 10, Debian 5.0 (Lenny) and Ubuntu 9.04. Debian 5.0 (Lenny) and Ubuntu 9.04 (Jaunty Jackalope) are now released. Debian provides downloads and bootstrap tools in their distro and lots of documentation. Despite the announcement it seems Ubuntu only has a release candidate?! So the release schedule seemed to not apply for the ARM architecture. Fedora however did not official announce any ARM support, but has a wiki page which describe how to use their distribution. openSUSE recently released a testing milestone for their 11.2 release, but I was unable to find the packages necessary to make a base system. I do have to make a note here: the openSUSE Build Service (OBS) provides ARM support for building packages for Fedora 10, Debian 5.0 and Ubuntu 9.04.

Below you can find the images I have created or used to test the distributions and the information I have used. These images are all base systems to get you started. They can serve as a starting point to create a build environment.

Fedora 10
Fedora does not provide official downloads, but all the files are provided on the wiki. To ease the deployment from a Windows system I created a usable root image which you can download from dropbox or vipeers and the kernel (dropbox). The archive can be unpacked using a tool like Winrar.

With the following command will start the qemu environment without networking:


qemu-system-arm.exe -M versatilepb -kernel zImage-versatile-2.6.24-rc7.armv5tel -hda rootfs-f10.img -append "root=/dev/sda"

You can login with username: root, without a password.

Ubuntu 9.04
Canonical only provides a Release Candidate for their ARM port of Jaunty Jackalope. You can find a the downloads from the cdimage server, such as a general image and an image for the NSLU2. I however built a new rootfs using the information provided on the wiki and the build-arm-rootfs script. This script will use debootstrap and qemu to produce a usable tarball or qemu image. I used the script to create a tarball and dumped this in a mounted image (the same as done for the fedora image).

You can download the root image from dropbox or vipeers and the kernel (dropbox).

To start the environment:


qemu-system-arm.exe -M versatilepb -kernel vmlinuz-2.6.28-11-versatile -hda rootfs-jaunty.img -append "root=/dev/sda"

To login use the username: ubuntu and the password: ubuntu.

Debian 5.0
The ARM support for Ubuntu is no miracle, as their base distribution Debian has support for this architecture. The installation guide can be found on the debian website. Using the debootstrap tool you can easily create your own rootfs. On the webpage of Aurélien Jarno (aurel32) you can find a complete article which describe the process of getting debian running on an emulated ARM using qemu on Linux. The root images and kernel he uses can be found here.

To start the environment:


qemu-system-arm.exe -M versatilepb -kernel vmlinuz-2.6.26-2-versatile -hda debian_lenny_arm_small.qcow -append "root=/dev/sda1"

To login using the username: user and password: user. The password for root is root.

Notes
Read the How to use Network if you want to enable networking for the qemu environment on Windows.

Gerard Braad: Mojo's Hasty distribution for use with qemu.

noreply@blogger.com (gbraad) — Fri, 01 May 2009 21:40:06 +0000

As part of a test I am doing, I started to use the Mojo distribution. This is a desktop distribution compiled for mobile and embedded devices. Currently they provide a Ubuntu Hardy (8.04) which is known as Hasty. Since the installation can be a little troubling at first, I will provide a full installation of the Mojo distribution I use. Hopefully it will encourage other to also use it.

You need the following files:
mojo-hasty.tar.bz2.00 [rapidshare] [dropbox] (100mb)
mojo-hasty.tar.bz2.01 [rapidshare] [dropbox] (100mb)
mojo-hasty.tar.bz2.02 [rapidshare] [dropbox] (100mb)
mojo-hasty.tar.bz2.03 [rapidshare] [dropbox] (32mb)

Mirrors are welcome... please post your locations in the comments of this article. After download you can extract the files using the command

$ cat mojo-hasty.tar.bz2.* | tar -xvj

Included are the scripts to install (will overwrite hasty.img) and to start the emulation environment.

Installed as described at Using the Debian Installer with QEMU
with all the missing bits added:

during the installtion it will ask you to provide a mirror location:
host: repository.handhelds.org
path: /hasty-armv5el

continue without installing the kernel and bootloader. Do not try to install the desktop environment; due to muine being missing it is not possible at the moment to do so. After installation of the base system, I installed xfce4 xfce4-terminal gdm and xserver-xorg with a configured fbdev device.

username: user
password: user
sudo password: user

It will start from the start script as a recovery console. This can be handy if you encounter unforeseen difficulties, else just continue normal boot. If you don't want this behaviour, just remove 'single' from the append command for qemu.

Additional actions I did to make the experience a little bit more enjoyable are:

$ mkdir /lib/modules/2.6.25.10/
$ depmod -a

xfce: changed panel to a fixed position (bottom, size 24)
xfce: changed terminal font to monospace 4
xfce: changed background color rgb(0, 112, 224)
gdm: enabled automatic login, User: user
gdm: changed local theme to 'Happy GNOME'
gdm: changed background color rgb(0, 112, 224)
user, root:

$ rm ~/.bash_history

Tested with the qemu installation as provided by CentOS 5.2, Fedora 9 and Ubuntu 8.04. Any comments are welcome at 'me+mojo-hasty [monkey] gbraad [dot] nl'.

Note:
In the published files I forgot to mention I also installed the xorg meta package. This is needed to install the fonts for the X server.

$ apt-get install xorg

This action does not need to be performed, since GDM starts. But for a reinstall, this is needed to run the X environment.

Links
Mojo Handhelds,
Qemu, processor emulator

Zhou Yajin, vm-kernel.org: what's the difference between these two definitions

Thu, 23 Apr 2009 01:39:03 +0000

I write this article because some guys are talking about it in CLF. The question is: what is the difference between the two following definitions:

A. const char temp[]="abc";

B. const char *temp="abc";

You may have your own answer already. But wait a moment, let me write some test cases first and you can see whether your answer is right or not.

(1) Test case 1

const char temp[]="abc";
int main()
{
temp[0]='c';
printf("temp %s \n",temp);
}
debian:~# gcc -o test test.c
test.c: In function `main':
test.c:8: error: assignment of read-only location `temp[0]'

(2) Test case 2

const char temp[]="abc";
char temp1[]="def";
int main()
{
temp = temp1;
printf("temp %s \n",temp);
}
debian:~# gcc -o test test.c
test.c: In function `main':
test.c:8: error: assignment of read-only variable `temp'

(3) Test case 3

const char* temp="abc";
char temp1[]="def";
int main()
{
temp = temp1;
printf("temp %s \n",temp);
}
debian:~# gcc -o test test.c
debian:~# ./test
temp def

(4) Test case 4

const char* temp="abc";
int main()
{
temp[0] = 'd';
printf("temp %s \n",temp);
}
debian:~# gcc -o test test.c
test.c: In function `main':
test.c:8: error: assignment of read-only location `*temp'

So the definition A means both temp and array is const and you can not change it. Definition B means temp points to a const string, which you can not change its content. But you can change temp itself.

Gerard Braad: CentOS 5.3 image for coLinux

noreply@blogger.com (gbraad) — Fri, 03 Apr 2009 22:54:57 +0000

A few days ago CentOS 5.3 was finally released. Just like what I have done with the previous version, I created a coLinux environment. This installation is a base system performed using the previously described manual method. Updated instructions are included in the published archive.

For now you can find the files here:
colinux-centos53.exe [VIPeers] [dropbox] (98mb)

It is configured to use DHCP on the network connections eth0 (slirp) and eth1 (bridged). The user account is 'root' without a password. After login, you should change the password. During startup you will see some complaints about the kernel modules. To solve this you can install my kernel modules RPM or use the tarball provided by coLinux.

Gerard Braad: openSUSE 11.1 on coLinux

noreply@blogger.com (gbraad) — Fri, 03 Apr 2009 21:50:19 +0000

To ease cross-platform .NET development, I have installed openSUSE on coLinux. This allows me to develop from Windows and also test and debug the binary on Linux. Advantages are: No need to dual boot and a much better performance than using VMware or other virtualization solution. In this article you can find the base system and I will describe how I did the base installation.

Take note, these instructions do NOT provide any details about the .NET environment. Those are published on my .NET blog.

The files to install and run the environment 'colinux-opensuse-11.1.exe' can be found at [VIPeers], [dropbox] (113Mb). This file contains the base system.img, a swap image and start commands. If you don't want to install it yourself, you can at least immediately start to use openSUSE on coLinux. Take note, network has not been configured yet (see notes). The user account is 'root' with the password 'password'.

Preparation
The installation closely follows the instructions I wrote for CentOS. You will need a clean system.img which you can find in the colinux-centos52-base.rar. Copy the Debian businnesscard init ramdisk to install_initrd.gz. And of course you need to download the openSUSE 11.1 DVD from http://www.opensuse.org/. This file will be about 4.25GB in size.

You can perform a RPM installation, but since openSUSE provides an image-based installation I will use this for the base of the coLinux environment. My main purpose was to keep the installation easy to perform (and if possible small in size). Copy the files base-i386.tar.lzma, base-meta-i386.tar.lzma and common-base-i386.tar.lzma from the openSUSE 11.1 DVD. It is located in the directory images. Since the Debian initrd does not contain the lzma binary, so you will need to decompress the archives with a tool like 7-Zip. The resulting files will be standard tape-archives. Place them in a directory called 'images'. The install.bat will map it to cofs1.

Installation
If you have the install files from the opensuse-11.1.exe file, the images, debian's install_initrd.gz and the system.img from the centos52-base.rar, you are ready to go.

Start the install.bat. You will see a debian installation screen... toggle with ALT-F2 to a console and press Enter.

Please press Enter to activate this console.

From here you can perform the following commands. The line which says 'tar -C /mnt/linux -xf $i' will unpack the image to the system.img. Just be sure to have some coffee ready since it might take some time.


mkswap /dev/cobd7
swapon /dev/cobd7

mkdir /mnt/linux
mkdir /mnt/win
mount /dev/cobd0 /mnt/linux
mount -t cofs cofs0 /mnt/win

mkdir /mnt/images
mount -t cofs cofs1 /mnt/images
cd /mnt/images

for i in *.tar
do
tar -C /mnt/linux -xf $i
done

mkdir -p /mnt/linux/media/cdrom
mount /dev/cobd1 /mnt/linux/media/cdrom

chroot /mnt/linux
cd /media/cdrom/suse/i586

rpm -ivh openSUSE-release-[0-9]*.rpm \
openSUSE-release-dvd-[0-9]*.rpm

echo password | passwd - stdin root 

cat > /etc/fstab  END
/dev/cobd0 / ext3 acl,user_xattr 1 1
/dev/cobd7 swap swap defaults 0 0
proc /proc proc defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
END

exit

After this you can halt the system. And start it for the first time.

Post-install
To finish the installation you need to start it with the coLinux initrd once. The script runonce.bat will take care of that... after you have run it, openSUSE will start properly. Log on and halt again. After this you can start it without a initrd being specified. The script run.bat will start the final system.

It might give some startup errors... nothing serious. I didn't configure the network inside the base system. This can be done using yast or perform the following command:


for i in 0 1
do
cat > /etc/sysconfig/network/ifcfg-eth$i  END
BOOTPROTO='dhcp'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR=''
MTU=''
NAME=''
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'
END
done

This enables both eth0 and eth1 to use DHCP. Kernel modules can be installed with the same RPM I have provided earlier. Just use the following commands:


zypper in http://gbraad.fedorapeople.org/files/kernel-modules-2.6-co0.7.3.i386.rpm

Alternative installation
If you want to perform a RPM-based installation you will still need to install the base-i386.tar image. I tried without, but ended up with a lot of errors during installation. The can find the installation instructions in the file instructions-rpm.txt which is included in the archive. Eventually I have not further tested this alternative installation...

Notes
I have tried to only use the files provided by openSUSE, but somehow they seem to consume too much time. The common filesystem did not provide all the tools I needed (similar to the stage2.img from redhat). If you know another way to install it, let me know. Qemu can also install it, but it consumes a lot more time in my opinion; install, dd, etc.

For the moment it is not possible to perform an image installation without the openSUSE DVD installation media. I do hope they will provide a single CD image installer or provide the images from their 11.1 download site. If it is possible, please enlighten me?!

If you want to install additional software, you will need to add the openSUSE repositories. This can easily be done using zypper.


zypper ar http://download.opensuse.org/distribution/11.1/repo/oss/ openSUSE111
zypper ar http://download.opensuse.org/distribution/11.1/repo/non-oss/ openSUSE111_NonOSS 
zypper ar http://download.opensuse.org/update/11.1/ openSUSE-11.1-Updates

Now you can install Gnome by using a command like:


zypper in -t pattern gnome

More information about installing software can be found on openSUSE Tutorials.


Have a lot of fun...

Gerard Braad: CentOS 5.2 image for coLinux

noreply@blogger.com (gbraad) — Thu, 02 Apr 2009 19:50:23 +0000

Although soon we hope to have the newer 5.3 release of CentOS, I still decided to create a coLinux image of the current release. The problem with this release is that the kernel has issues when run on Qemu as can be seen in this bug report. This issues is known upstream and is solvable by installing 5.1 and then update it beyond the problematic kernel... or you could just wait until CentOS 5.3 is released.

To make CentOS 5.2 usable in coLinux you could install 5.1 in this way using Qemu and update it. I just took a different approach: use RPM. I used a modified initrd image and installed a basic RPM installation (kinda similar to the FC3-CentOS frankenupgrade). More details about how the installation was performed will follow.

For now you can find the files here:
colinux-centos52.exe [VIPeers] [dropbox] (82mb)

The files contain an image with a minimal installation which you can use on coLinux 0.7.3. The startup is not error-free... but you can ignore the failures for now, since I will update the images to reflect the Fedora images. Your suggestions are of course welcome.

It is configured to use DHCP on the network connections eth0 and eth1. The user account is 'root' without a password.

Edit: repacked the archive to be self-extracting and kernel modules (co0.7.3) have been installed by RPM.

Gerard Braad: Manually installing CentOS 5.2 on coLinux

noreply@blogger.com (gbraad) — Sun, 22 Mar 2009 19:18:41 +0000

In the previous post I published a minimal CentOS 5.2 environment for use with coLinux. As I described in the posting, I did a manual installation since I was unable to use Qemu to start the CentOS 5.2 installation process. Although I received a comment that someone else was able to install CentOS, I am still unable to do so... even with the latest build of Qemu (currently 0.9.1) on Windows. Instead of trying to convert a VMware image or using an update process, I wanted to only use coLinux. In this posting I will try to describe what I did.

Requirements
To ease the installation I have created a base which can assist you with installing. It contains the files you need as images (formatted as Ext3). It is available as centos52-base.rar [dropbox] (35kb).

This file contains what is needed to install the CentOS 5.2 image for
use with coLinux:

system.img 4Gb system image, formatted as Ext3

swap512m.img 512Mb swap location

Batch and parameters file needed to start coLinux

install.bat, install.txt for the installation process (needed once)

run.bat, run.txt to start the environment after install

instructions.txt file containing the commands to perform

Extract the base archive and place the CentOS 5.2 (i386) installation media in the same directory. Mirrors are provided on the download page of CentOS. If you do not want to download the DVD file, you can also choose to only download CD 1of6. For this you need to change the install.txt parameters file. After the initial install, you can then rely on YUM to install all additional packages.

I used a custom init ramdisk to create the images and perform the installation. Since this file is still rough, I suggest you to download this business card iso from debian. The businesscard ISO is about 35Mb.

With a tool like winrar (or mount it using a tool like Daemon Tools), you can extract the file /install.386/initrd.gz. If you prefer to only download the initrd.gz. Save this file as install_initrd.gz in the directory where you extracted this base directory. This ramdisk will be used to start a system to perform commands from which will start the RPM install.

After installing coLinux to the standard location you can run the install.bat and start the installation process. It will start the start kernel with the install_initrd.gz as ramdisk. The terminal of choice for this process was a NT terminal, since copy-n-paste was easier to perform. When the installation process interface is shown, you should toggle with ALT+F2 to a console.

Please press Enter to activate this console.

When you do so, you will see a BusyBox prompt where you can perform the instructions as shown in the instructions.txt.

Instructions
You will now perform the instructions needed to do the actual install. We will create a basic environment to perform an RPM installation of the base packages. After this you can use YUM to download and/or install additional packages. To create
the basic layout:


mkswap /dev/cobd7
swapon /dev/cobd7
mkdir /mnt/linux
mkdir /mnt/win
mkdir /mnt/stage2
mount /dev/cobd0 /mnt/linux
mkdir -p /mnt/linux/media/cdrom
mount -t cofs cofs0 /mnt/win
mount /dev/cobd1 /mnt/linux/media/cdrom

This will create some swapspace, a mountpoint /mnt/linux which points to the block device cobd0 (system.img), /mnt/win will be used to point to the coLinux program files folder and /mnt/stage2 will later be used to mount the CentOS stage2 image file. Block device cobd1 is used to mount the DVD image to the mountpoint /mnt/linux/media/cdrom. This will later be used to install the base packages from.

The stage2 image file uses the squashfs filesystem. CoLinux provides kernel modules to use this filesystem.


tar xzvf /mnt/win/vmlinux-modules.tar.gz lib/modules/2.6.22.18-co-0.7.3/kernel/fs/squashfs/squashfs.ko
insmod /lib/modules/2.6.22.18-co-0.7.3/kernel/fs/squashfs/squashfs.ko
mount -t squashfs -o loop /mnt/linux/media/cdrom/images/stage2.img /mnt/stage2

The contents then need to be copied to the /mnt/linux to form the basis of our installation process.


cp -a /mnt/stage2/ /mnt/linux
umount /mnt/stage2
mv /mnt/linux/stage2 /mnt/linux/base

This might take some time...

The system needs to have some directories which will form the basis. The following command will create this.


for n in bin dev proc lib usr tmp etc
do
  mkdir -p /mnt/linux/$n
done
touch /mnt/linux/etc/fstab /mnt/linux/etc/mtab
mkdir -p /mnt/linux/var/lib/rpm

The location /var/lib/rpm is needed to store the RPM database files.

Pre-installation
RPM will need some libraries to run. These will be copied to the appropriate location using the following commands:


cd /mnt/linux/lib
ln -s ../base/lib/* .
rm /mnt/linux/lib/udev
rm /mnt/linux/lib/bdevid
mkdir /mnt/linux/usr/lib
cp -a /mnt/linux/base/usr/lib/librpm-* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/librpmio-* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/librpmdb-* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/libpopt.* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/libsqlite3.* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/libelf* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/libbeecrypt.* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/libz.* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/libbz2.* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/libstdc++.* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/rpm /mnt/linux/usr/lib/

All necessary libraries are now available to pivot the root to the /mnt/linux location.


chroot /mnt/linux /base/usr/bin/sh
/base/usr/bin/rpm --initdb

This will create a fresh RPM database which the installation process can use.

Installation
You are now ready to perform the installation.


cd /media/cdrom/CentOS
/base/usr/bin/rpm -ivh setup-*.rpm

The following packages need to be installed at once. These will form a base installation of CentOS.


/base/usr/bin/rpm -ivh \
audit-libs-[0-9]*.rpm \
audit-libs-python-[0-9]*.rpm \
authconfig-[0-9]*.rpm \
basesystem-[0-9]*.rpm \
bash-[0-9]*.rpm \
beecrypt-[0-9]*.rpm \
bzip2-libs-[0-9]*.rpm \
centos-release-[0-9]*.rpm \
centos-release-notes-[0-9]*.rpm \
checkpolicy-[0-9]*.rpm \
chkconfig-[0-9]*.rpm \
coreutils-[0-9]*.rpm \
cpio-[0-9]*.rpm \
cracklib-[0-9]*.rpm \
cracklib-dicts-[0-9]*.rpm \
cryptsetup-luks-[0-9]*.rpm \
cyrus-sasl-lib-[0-9]*.rpm \
db4-[0-9]*.rpm \
dbus-[0-9]*.rpm \
dbus-glib-[0-9]*.rpm \
device-mapper-[0-9]*.rpm \
device-mapper-event-[0-9]*.rpm \
device-mapper-multipath-[0-9]*.rpm \
dhclient-[0-9]*.rpm \
dhcpv6-client-[0-9]*.rpm \
diffutils-[0-9]*.rpm \
dmidecode-[0-9]*.rpm \
dmraid-[0-9]*.rpm \
e2fsprogs-[0-9]*.rpm \
e2fsprogs-libs-[0-9]*.rpm \
ecryptfs-utils-[0-9]*.rpm \
ed-[0-9]*.rpm \
elfutils-libelf-[0-9]*.rpm \
ethtool-[0-9]*.rpm \
expat-[0-9]*.rpm \
file-[0-9]*.rpm \
filesystem-[0-9]*.rpm \
findutils-[0-9]*.rpm \
gawk-[0-9]*.rpm \
gdbm-[0-9]*.rpm \
glib2-[0-9]*.rpm \
glibc-[0-9]*.i686.rpm \
glibc-common-[0-9]*.rpm \
gnu-efi-[0-9]*.rpm \
grep-[0-9]*.rpm \
grub-[0-9]*.rpm \
gzip-[0-9]*.rpm \
hal-[0-9]*.rpm \
hdparm-[0-9]*.rpm \
hwdata-[0-9]*.rpm \
info-[0-9]*.rpm \
initscripts-[0-9]*.rpm \
iproute-[0-9]*.rpm \
iptables-[0-9]*.rpm \
iptables-ipv6-[0-9]*.rpm \
iputils-[0-9]*.rpm \
kbd-[0-9]*.rpm \
kernel-[0-9]*.rpm \
keyutils-libs-[0-9]*.rpm \
kpartx-[0-9]*.rpm \
krb5-libs-[0-9]*.rpm \
kudzu-[0-9]*.rpm \
less-[0-9]*.rpm \
libacl-[0-9]*.rpm \
libattr-[0-9]*.rpm \
libcap-[0-9]*.rpm \
libgcc-[0-9]*.rpm \
libgcrypt-[0-9]*.rpm \
libgpg-error-[0-9]*.rpm \
libhugetlbfs-[0-9]*.rpm \
libselinux-[0-9]*.rpm \
libselinux-python-[0-9]*.rpm \
libsemanage-[0-9]*.rpm \
libsepol-[0-9]*.rpm \
libstdc++-[0-9]*.rpm \
libsysfs-[0-9]*.rpm \
libtermcap-[0-9]*.rpm \
libusb-[0-9]*.rpm \
libuser-[0-9]*.rpm \
libvolume_id-[0-9]*.rpm \
libxml2-[0-9]*.rpm \
libxml2-python-[0-9]*.rpm \
lvm2-[0-9]*.rpm \
m2crypto-[0-9]*.rpm \
MAKEDEV-[0-9]*.rpm \
mcstrans-[0-9]*.rpm \
mingetty-[0-9]*.rpm \
mkinitrd-[0-9]*.rpm \
mktemp-[0-9]*.rpm \
module-init-tools-[0-9]*.rpm \
nash-[0-9]*.rpm \
ncurses-[0-9]*.rpm \
net-tools-[0-9]*.rpm \
newt-[0-9]*.rpm \
nspr-[0-9]*.rpm \
nss-[0-9]*.rpm \
openldap-[0-9]*.rpm \
openssh-[0-9]*.rpm \
openssh-clients-[0-9]*.rpm \
openssh-server-[0-9]*.rpm \
openssl-[0-9]*.i686.rpm \
pam-[0-9]*.rpm \
passwd-[0-9]*.rpm \
pciutils-[0-9]*.rpm \
pcre-[0-9]*.rpm \
pm-utils-[0-9]*.rpm \
policycoreutils-[0-9]*.rpm \
popt-[0-9]*.rpm \
prelink-[0-9]*.rpm \
procps-[0-9]*.rpm \
psmisc-[0-9]*.rpm \
python-[0-9]*.rpm \
python-elementtree-[0-9]*.rpm \
python-iniparse-[0-9]*.rpm \
python-sqlite-[0-9]*.rpm \
python-urlgrabber-[0-9]*.rpm \
readline-[0-9]*.rpm \
redhat-logos-[0-9]*.rpm \
rhpl-[0-9]*.rpm \
rootfiles-[0-9]*.rpm \
rpm-[0-9]*.rpm \
rpm-libs-[0-9]*.rpm \
rpm-python-[0-9]*.rpm \
sed-[0-9]*.rpm \
selinux-policy-[0-9]*.rpm \
selinux-policy-targeted-[0-9]*.rpm \
setools-[0-9]*.rpm \
setserial-[0-9]*.rpm \
shadow-utils-[0-9]*.rpm \
slang-[0-9]*.rpm \
sqlite-[0-9]*.rpm \
sysfsutils-[0-9]*.rpm \
sysklogd-[0-9]*.rpm \
system-config-securitylevel-tui-[0-9]*.rpm \
SysVinit-[0-9]*.rpm \
tar-[0-9]*.rpm \
tcl-[0-9]*.rpm \
tcp_wrappers-[0-9]*.rpm \
termcap-[0-9]*.rpm \
tzdata-[0-9]*.rpm \
udev-[0-9]*.rpm \
udftools-[0-9]*.rpm \
usermode-[0-9]*.rpm \
util-linux-[0-9]*.rpm \
vim-minimal-[0-9]*.rpm \
wireless-tools-[0-9]*.rpm \
yum-[0-9]*.rpm \
yum-metadata-parser-[0-9]*.rpm \
zlib-[0-9]*.rpm

If you perform the command, the following will show indicating that the installation process started.

This will again take some time... and will eventually result in the following.

If no error occurred you can start with the post-installation to make the system usable from coLinux.

Post-installation
We will now perform some post-installation commands to finish the installation. Create the device nodes in the device directory. These will be used by the filesystem table to mount the filesystem. Do not forget to first exit out of the chroot environment.


exit
mknod -m 666 /mnt/linux/dev/null c 1 3
for i in 0 1 2 3 4 5 6 7 8 9 10
do
  mknod -m 660 /mnt/linux/dev/cobd${i} b 117 ${i}
done
chown 0:6 /mnt/linux/dev/cobd*

To have the filesystems mounted on startup you need to have the fstab file being created. Just overwrite the current file:


cat > /mnt/linux/etc/fstab  END
/dev/cobd0   /          ext3     defaults        1 1
/dev/cobd7   swap       swap     defaults        0 0
none         /proc      proc     defaults        0 0
none         /dev/shm   tmpfs    defaults        0 0
none         /dev/pts   devpts   gid=5,mode=620  0 0
none         /sys       sysfs    defaults        0 0
END

Write some basic information to the hosts file.


cat > /mnt/linux/etc/hosts  END
127.0.0.1 localhost localhost.localdomain
END

The following will create the shared memory and the pseudo terminal devices, turns off the hardware daemon and allows you to give an initial password for the root user.


chroot /mnt/linux /sbin/MAKEDEV con
chroot /mnt/linux /bin/bash -c "/bin/mkdir /dev/{shm,pts}"
chroot /mnt/linux /bin/bash -c "/bin/chmod a+rwxt /dev/shm"
chroot /mnt/linux /sbin/MAKEDEV generic
chroot /mnt/linux /sbin/chkconfig haldaemon off
chroot /mnt/linux /usr/sbin/authconfig --enableshadow --update
chroot /mnt/linux /usr/bin/passwd root

To have the network start, you need to create the following files. This way your system will be configured with a basic hostname and two network devices using DHCP.


cat > /mnt/linux/etc/sysconfig/network  END
NETWORKING=yes
HOSTNAME=localhost.localdomain
END


cat > /mnt/linux/etc/sysconfig/network-scripts/ifcfg-eth0  END
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
END


cat > /mnt/linux/etc/sysconfig/network-scripts/ifcfg-eth0  END
DEVICE=eth1
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
END

Cleanup
You can now remove the base directory we had copied from the stage2 image.


rm -rf /mnt/linux/base
halt

After this you can halt the system and start the environment using the run.bat file. If everything went well your system would look like this!

During startup you will notice some minor error which are related to the kernel dependencies file being missing. To solve this, you can extract the kernel modules using the /dev/cofs0 mapping. Although I prefer to use RPMs, since they are easier to cleanup and upgrade when needed.


yum install wget
wget http://gbraad.fedorapeople.org/files/kernel-modules-2.6-co0.7.3.i386.rpm
rpm -ivh kernel-modules-2.6-co0.7.3.i386.rpm

Enjoy using it... If you have suggestions or stories about your use, leave a comment or send me an email.

Methril: Remember my first OpenSource project

noreply@blogger.com (Methril) — Tue, 03 Mar 2009 12:35:38 +0000

Today I'm in a melancholic mod. And i started to think about my collaborations to the OpenSource world. I did a lot of experiments at home, but i didn't made it public available, because i wasn't so proud of my code, and I feel scared that someone laughs about my style or my syntax.

I remember my first public project: RTL-EtherBootD is an Open Source project which consists of porting the Ethernet card drivers provided in the Etherboot project to RTLinux. It was my graduate work at University. Since that project, i didn't publish any OpenSource code. I worked in some different environments, but unluckily at my country (Spain) they didn't work a lot with Linux.

I started my actual job very enthusiastic, i was going to work developing Linux in Embedded Systems, but it's not what i'm doing right now :( I'm sad about that, i hope to work in Embedded Linux environments one day, but for now i've to work on this at home.

At work, i started my small patches to u-boot project here. Not really big, but a small step to start doing it more frequently (i've code to submit, but i didn't find it good enough to send it).

Personally, with the OpenMoko project, i started to hack the IDA Systems project, and the build system Openembedded. I found some problems with my working environment at home (Ubuntu 8.10 with a Core2Duo MacBookPro), but i'm solving the environment problems sending some patches to OpenEmbedded.

What i'd like to do is have a day to day work with Linux in Embedded environments, but actually i'm frustrated with a 8-bit PIC micro that i've to develop in Linux environments. Some time before, i was working with 16-bit Motorola uC, at R&D department devolping embedded systems from scratch, for ships. A lot of restrictions: hard-real time, fast response, 3 redundancy communication channels, .... I miss the hardware hacks that i've to do with our prototypes, the evaluation boards and all the stuff. It was funny and i miss the friends that still are there.

For now, i've to see to the future and look for another comfortable environment, Linux, and OpenSource development. I like to don't have to wait too much to find that change.

In my most important project, at the moment (the collaboration with IDA Systems), i suffer from the combination of OpenEmbedded and my environment. I hope to solve this soon. I'm going step by step :)

Now that i wrote some words about my senses, i start to feel better and i can afford my day-to-day job.

See you soon.

-- Edited --
My u-boot patch (the first): http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/44824/focus=45183
My OpenEmbedded patch: http://article.gmane.org/gmane.comp.handhelds.openembedded/21425

Methril: Delays in my updates

noreply@blogger.com (Methril) — Sat, 21 Feb 2009 20:05:05 +0000

Lately i'm not being really active in my blog.

This is because i had a lot of changes in my personal life, and in my working environment.

First of all i've to announce (if someone has interest in it) that i changed my relationship status. Now i'm married. This has give me a lot of my responsabilities and a lot of housework.
Well, not all is bad, but i've less time ;)

Other delayed cause is that i've been traveling in my honeymoon. Now i'm back and i'm reading the news, and future developments (a lot of news missed).

In other order of things, i've been fighting with fso & openembedded to build some images. As allways, i see a lot of dependencies missed. And my build hardware is not really fast (i'm going to need an update) but it's hard because is a computer. My only options are upgrade the HDD to bigger 7200 rpm & upgrade the RAM from 2 GB to 4 GB, other upgrades means buy another hardware, and actually it's not possible.

More updates soon.

As everybody said:

"I'm trying to be more active in my development efforts, and post more often".

Methril: First post, "First" device

noreply@blogger.com (Methril) — Sat, 21 Feb 2009 18:11:33 +0000

Hello to everybody,

This is my first english post in that blog. I created this blog in order to have the my hardware development in the OpenSource world up to date to the community.

I'm working with some ARM Hardware devices (soon patches are in the kitchen). And in my spare time i'm getting fun hacking the Compulab EM-X270. I get this device thanks to rakshat http://idasystems.net . The goal is to make Openmoko Linux "distro", that was designed for NeoFreerunnere and Neo1973 hardware phones, to work with this device, and I'm hands on it.

I'll try to keep the blog up to date.

Hope you like.

Methril: Trying poky

noreply@blogger.com (Methril) — Sat, 21 Feb 2009 18:11:21 +0000

Well, some Openembedded distros have "support" for the em-x270, but only poky (http://pokylinux.org) is officially supported into the distro.

As a Openembedded distro, i'll try to compile and get it working with the module.
Here you can see some screenshots:

Poky running into the em-x270. No icons loaded.

A better picture of the main screen:

It's not working properly, but it could be because the nfs server. I'll take a look on it.

I'll get working some distros, then: angstrom (the officially compulab distro), and poky linux.
Next step, use the Openmoko distro rootfs.

Methril: First Openmoko image

noreply@blogger.com (Methril) — Sat, 21 Feb 2009 18:11:07 +0000

It's a long time since my last post., but here I come back to show you new progress.

I'm being bussy trying to make the poky trunk build system work in my company server. But the config of that server, makes it almost impossible. As the Ida Systems Ltd. guys send me the new phone Openmoko Neo Freerunner as a present, i though that was time to get hands on it (but, keeping in mind the em-x270). After some compiling warnings and errors with the OE environment, i'll found one really nice, in mix with the FSO (http://www.freesmartphone.org) framework that is going to be used with openmoko in the near future (i hope). This environment works, because the openemebedded repository used was the official one, plenty of configurations and machines.

This gives us the opportunity to make the FSO-image for other machines that om-gta01 or om-gta02. This is what i get, a working image for em-x270 :)

Take a look of the em-x270 and the Openmoko Neo Frerunner:

Bootin the board.

First Openmoko Look

A deeper look.

Booting the FSO image.

Zhone started. (Take a look that the dbus system is not working)

zhone out of time :) Left: mls2 Right mls3

The Home in action (another icon fix problem).

The bad things are:

No dbus properly working (i'd like to help the FSO guys to get more hardware working with the framework)
Some of the devices has to be linked with the touchscreen: ln -s /dev/input/touchscreen0 /dev/ts or ln -s /dev/input/touchscreen0 /dev/touchscreen/0 that are the ones that the openmoko uses.

All this stuff is working through NFS, because it's easier to has a dev cross env until everything goes working properly.

Well, it needs some real dev work to get the devices working, but it would be a happy hacking time :)

Some more news soon.

P.D. Ah! I forget to said that the poky system, that has official support to the em-x270 machine, has the icons working properly.

Methril: D-BUS working, but not all services available

noreply@blogger.com (Methril) — Sat, 21 Feb 2009 18:10:46 +0000

Hello to everybody,

well, some progress have been made in the desired port. The DBUS systems is up and more or less working. We'll have he zhone app working properly with DBUS connected into the app. To surf deeply into the API, and the services running, we have some usefull commands, thanks to mdbus app provided by Michael Lauer.

root@em-x270:~# mdbus -s
:1.0
:1.1
:1.2
:1.3
:1.4
:1.5
:1.6
:1.7
org.bluez
org.freedesktop.Avahi
org.freedesktop.DBus
org.freedesktop.Gypsy
org.freesmartphone.frameworkd
org.freesmartphone.odeviced
org.freesmartphone.oeventsd
org.freesmartphone.ogpsd
org.freesmartphone.ogsmd
org.freesmartphone.ophoned
org.freesmartphone.opreferencesd
org.freesmartphone.ousaged

We could see a lot of services, but not all of them are working properly.

Now it's time to write some code to add support for the GSM modem, the WiFI, the bluetooh, the GPS, battery, speakers, ...
A lot of things to test :D

Time to dev a litle bit.

See you soon.

Methril: Conference at LUG - Madrid

noreply@blogger.com (Methril) — Sat, 21 Feb 2009 18:10:03 +0000

I'm proud to announce to the community my first presentation about OpenMoko.For the English speakers, i'm so sorry, but it's in english.

The UC3M LUG and the creator of the FDOM distro (es), David Samblas, give me the opportunity to talk about this amazing project.
The event was the Congreso GUL UC3M 2008. A lot of Spanish people talking about OpenSource projects. (i love it :D)

You could see the presentation in two parts.(in Spanish, sorry):

Presentación Openmoko - Neo Freerunner - Parte 1
Cargado por inoxbrain

Presentación Openmoko - Neo Freerunner - Parte 2
Cargado por inoxbrain

And the Presentation in OpenOffice format.

Gerard Braad: libvirt for RHEL5/CentOS 5

noreply@blogger.com (gbraad) — Sun, 15 Feb 2009 20:20:56 +0000

Just built and packaged the libvirt library version 0.6.0 for use with Red Hat Enterprise Linux 5 and CentOS 5 (or any other EL5 compatible system). This library supports the following virtualization systems: Xen, KVM, Qemu and OpenVZ.

Files are located at http://files.gbraad.nl/packages/el5/.

These packages have been signed with my packaging key, which is available here (mirror). More information about this library can be found on the libvirt homepage.

Gerard Braad: The Wizard of Yum: Upgrade from FC3 to CentOS 5.2

noreply@blogger.com (gbraad) — Sun, 01 Feb 2009 14:48:49 +0000

If you have a production server, you would like to stay on the yellow brick road of upgrades for the operating system and installed software. However, it might happen you forget to support a server... and get 'scared' of performing updates: "If it ain't broken, don't fix it"! This mentality is not always correct, since errors you don't have at the moment, might still be a problem later on. The further away you get from the updates, the more difficult it will become to perform an upgrade to a later version of a distribution.

Why to write about it
The motivation to describe my experience of upgrading is because I hear a lot of people still complain about RPM and the dependency issues. Most of them have never used it and call the apt system the best solution. In my opinion, the key to success for apt is the reliance on a single repository. Debian people seldomly use dpkg -i to install package, since they use apt-get install to resolve dependencies. YUM solves the issue for RPM systems in a similar fashion. Instead of using rpm -i you can install packages using yum install, which resolves necessary dependencies from the configured repositories.

Note: With Ubuntu and Maemo I have noticed that more repositories get introduced which cause the same problems for apt-get. Dependency resolving might not work, since packages and depencies get fragmented and sometimes even unavailable or conflicting. The Red Hat community recently merged several repositories (RPM Fusion and RPM Forge) which does solve a lot of issues.

Setup
I was faced with the upgrade problem with my own personal (web)server for quite some time. I have no idea what I originally installed on it, but it has always been a Red Hat Linux system. It has been upgraded many times until it ran Fedora Core 3. At least the oldest file on the server was from January 2000. Since the server ran FC3, there was a problem. Fedora Core 3 was released in November 2004 it therefore only had updates available until about 2006.

Last year the machine was taken apart and virtualized to run on a newer VMware environment. I did update the system quite often... but never upgrade the distribution again. I had strayed from the yellow brick road and had no clear upgrade path any more. To solve this issue I could do to things:

Install a new server and migrate the files
Upgrade to a new distribution and hope this would start

No matter what option I would choose, I wanted to have similar functionality. Currently it runs:

Webserver:
Apache HTTPd (with various modules) → Zope
Mail infrastructure:
Postfix → Amavisd-new → Cyrus-imapd
Database:
PostgreSQL

I wanted to upgrade (option 2) as I had always done. Because of this, my options for upgrade were kinda limited: Fedora Core 4? Fedora Core had no support either... and the support for Fedora 8 would also expire soon (as it did this week). On the internet I had seen people mention it would be impossible to perform an upgrade from FC3 to a later version, like FC9 or they strongly advice others not to do so...

Hmmm, so instead I copied my 'sites', 'imap', 'zope' and database dumps to an NFS. Did I have to start a new installation?!??? All other servers I installed allready ran CentOS, I would also make this a CentOS installation. Well, considering CentOS is derived from RHEL (RedHat Enterprise Linux) it is in fact a Fedora installation. If you look at the release details:

RHEL-4 is based on FC3
RHEL-5 is based on FC6

You can upgrade from RHEL-4 to RHEL-5, this would mean like you jump from FC3 to FC6. CentOS 5.2 is a RedHat derivative from RHEL-5.2... So I wanted to upgrade my FC3 to CentOS 5.2. I know this would be difficult, but in my opinion possible. The key to success would be YUM, the chosen applications and the self-contained installs. The structure I had laid out was simple

Amavisd-new ran its own Perl installation from /opt/activestate/perl/
Zope
ran from a Python installation from /opt/activestate/python/
datafiles are in /home/zope/
Cyrus was built from source
installed in /opt/cyrus/
datafiles are in /home/cyrus/, totalling 7GB.
Each website has its own vhost-[domainname].conf for Apache and a separate directory in /home/sites/[domainname]/[hostname]/web/ which contains the files. Several websites, subdomains and databases, totalling 4GB of data.

Description
The following description are the actions I took, but it is NOT a howto for guaranteed success. It might work for you, although you could also end up with a non-booting system. Only perform this installation if you have enough knowledge of a Linux system and have backups available if it goes wrong.

On VMware I made a snapshot of the VM and opened the console, logged in on the 2nd and 3rd console as root. The main installation I would perform from two SSH connections (one as a backup). The tool I would use for the upgrade is YUM. YUM is a tool which resolves dependencies from repositories you have specified.

As root I created a 'frankenstein' directory with the following files from a CentOS mirror.
centos-release-5-2.el5.centos.i386.rpm beecrypt-4.1.2-10.1.1.i386.rpm centos-release-notes-5.2-2.i386.rpm db4-4.3.29-9.fc6.i386.rpm db4-devel-4.3.29-9.fc6.i386.rpm db4-utils-4.3.29-9.fc6.i386.rpm elfutils-0.125-3.el5.i386.rpm elfutils-libelf-0.125-3.el5.i386.rpm elfutils-libelf-devel-0.125-3.el5.i386.rpm elfutils-libelf-devel-static-0.125-3.el5.i386.rpm elfutils-libs-0.125-3.el5.i386.rpm glib2-2.12.3-2.fc6.i386.rpm glib2-devel-2.12.3-2.fc6.i386.rpm glibc-2.5-24.i386.rpm glibc-common-2.5-24.i386.rpm glibc-devel-2.5-24.i386.rpm glibc-headers-2.5-24.i386.rpm keyutils-1.2-1.el5.i386.rpm keyutils-libs-1.2-1.el5.i386.rpm krb5-devel-1.6.1-25.el5.i386.rpm krb5-libs-1.6.1-25.el5.i386.rpm krb5-workstation-1.6.1-25.el5.i386.rpm libselinux-1.33.4-5.el5.i386.rpm libselinux-devel-1.33.4-5.el5.i386.rpm libsepol-1.15.2-1.el5.i386.rpm libsepol-devel-1.15.2-1.el5.i386.rpm libxml2-python-2.6.26-2.1.2.1.i386.rpm m2crypto-0.16-6.el5.2.i386.rpm mcstrans-0.2.7-1.el5.i386.rpm openssl-0.9.8b-10.el5.i386.rpm popt-1.10.2-48.el5.i386.rpm python-2.4.3-21.el5.i386.rpm python-devel-2.4.3-21.el5.i386.rpm python-elementtree-1.2.6-5.i386.rpm python-ldap-2.2.0-2.1.i386.rpm python-sqlite-1.1.7-1.2.1.i386.rpm python-urlgrabber-3.1.0-2.noarch.rpm readline-5.1-1.1.i386.rpm readline-devel-5.1-1.1.i386.rpm rpm-4.4.2-48.el5.i386.rpm rpm-build-4.4.2-48.el5.i386.rpm rpm-devel-4.4.2-48.el5.i386.rpm rpm-libs-4.4.2-48.el5.i386.rpm rpm-python-4.4.2-48.el5.i386.rpm sqlite-3.3.6-2.i386.rpm sqlite-devel-3.3.6-2.i386.rpm yum-3.2.8-9.el5.centos.1.noarch.rpm yum-metadata-parser-1.1.2-2.el5.i386.rpm

The centos-release file tell your YUM to which repository it should refer for an upgrade. Your version number may differ, but this would generally give you a working YUM installation from a CentOS system. Install all the packages at once.

$ rpm -Uvh *.rpm --nodeps.

This is what my console showed after the installation. Since the berkely database version has been upgraded, you need to remove the previous RPM database and rebuild it.

$ rm -f /var/lib/rpm/__db.* $ rpm --rebuilddb

From this moment on, you could upgrade the system. The command

$ yum upgradewill show you what issues you need to satisfy for the dependencies. These you can install using:

$ yum install [packagename]

Before I upgraded, I disabled several repositories in my /etc/yum.repos.d/ directory. You can do this by adding enabled=0 to a repo definition. Before continuing the upgrade I stopped unnecessary services and disabled SELinux for now. Depending on the use of your installation you may need to also remove some packages. I had to do so.

$ rpm -qa

shows you all the installed packages. For my installation I removed some Novell branded packages for Mono and most of the X11 packages. After this remove the installed kernels. You might to iterate these steps (rpm -qa and rpm -e or yum remove) several times before you can perform the upgrade.

$ yum upgrade

starts the actual upgrade... be careful during the installation, since some services might not function as expected. Do not abort it. This would render your system not usable.

After the yum upgrade has been performed, you need to check if you have a kernel configured in /boot/grub/grub.conf (/etc/grub.conf). I had to install the kernel myself due to architecture conflicts?!

$ rpm -ivh --ignorearch kernel-2.6.18-92.el5.1686.rpm
Even after this installation you would need to check the grub configuration. Reboot the system and when it starts, you would have a CentOS system.

After this you can cleanup your system.

$ rpm -qa > /tmp/rpmlist $ cat /tmp/rpmlist | grep fc3 $ cat /tmp/rpmlist | grep FC3
Remove any remaining package which refer to your previous installation. Note: it is normal to find references to fc6 packages for your CentOS installation.

After the reboot, I noticed that most of the applications still worked as they should. Most of the time went into getting Apache and Zope running well together. Now a week later, I removed the VMware snapshot, even consolidated two harddisc files into one. Cyrus-impad is now makes use of the official release package (using my own config file) and upgraded amavisd-new to the RPMforge release. Only zope is running the old installation...

Conclusion
Always plan your system for future use. A sever has a lifespan which may exceed your initial thoughts. Try to compose the server as seperate responsibilities (mail, web, etc) as this would make upgrade easier. Try to stay close to the release schedule of patches and updates for your system... try to avoid building from source or compiling your own kernels as this would make management more difficult later on. And when a distribution gets the end-of-life status, try to move away from it immediately.

As you can see, it would still be possible to upgrade to CentOS 5.2 from Fedora Core 3... but this is NOT advised or a common practice. For me it shows how well thought the components and layout were, since this is also the setup I had used for SpotlightMedia and my previous employer.

In my opinion it shows how well the YUM dependency resolving and upgrading works. The wonderful wizard of Yum gave me a working CentOS system!

Gerard Braad: Installation of OpenVZ on CentOS 5.2

noreply@blogger.com (gbraad) — Sun, 01 Feb 2009 14:48:16 +0000

OS virtualization allows you to better scale if you need a large amount of similar software installations and you do not want to deploy more than one physical (or even virtual) machine. It creates isolated containers in which your environment run. In a way it is comparable to a jailed environment, but it provides better isolation, security and management. Hardware virtualization, for products as VMware, XEN and KVM, has a different approach in which you run a completely emulated distribution (often paravirualized) on top of your host system. OS and Hardware virtualization can complement each other.

The installation of OpenVZ containers on CentOS (or RHEL5) is very simple. The following steps were performed on a default installation of CentOS 5.2. In my case I use a virtual machine in a VMware environment.

The OpenVZ installation


$ setup

First you need to disable SELinux and the firewall.


$ cd /etc/yum.repos.d
$ wget http://download.openvz.org/openvz.repo
$ rpm --import http://download.openvz.org/RPM-GPG-Key-OpenVZ
$ yum -y install ovzkernel
$ vi /etc/sysctl.conf

In this file change the following lines:


net.ipv4.ip_forward = 1
kernel.sysrq = 1
net.ipv4.conf.default.proxy_arp = 0

In this same file add the following lines:


net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0

Install the OpenVZ service and have it start at boot:


$ yum install vzctl vzquota
$ chkconfig --add vz
$ reboot

Container configuration
After this, you need to create or download an OS template. For keeping this post easy, I use a precreated template:


$ cd /vz/template/cache
$ wget http://mirror.proserve.nl/openvz/contrib/template/precreated/centos-5-i386-default.tar.gz

Now you can create your first OS container from this template. The information we need is an IP address, hostname and nameservers.


$ vzctl create 101 --ostemplate centos-5-i386-default --conf vps.basic --ipadd 10.73.11.150 --hostname c1.survion.net
$ vzctl set 101 --name c1 --nameserver "10.73.11.1 10.73.11.2 10.73.11.3" --diskspace 10G:10G --save
$ vzctl set 101 --userpasswd root:password --save

Each container instance is represented by an CTID. In the previous steps we used id 101 the identify the container. The configured information can now be found in the file /etc/vz/conf/101.conf. Be sure to use your own secret password for the last command.

You can now start this container and list processes


$ vzctl start 101
$ vzctl exec 101 ps ax

You can also issue an enter command:


$ vzctl enter 101

You would then authenticate as root inside the container. On the console you can perform commands as if you would on a normal machine.

That's it! You now have a CentOS container running on top of your CentOS installation.

Links and additional information
Information on how to create a template can be found on http://wiki.openvz.org/OS_template_cache_preparation

OS Templates can be found at:

If you download the minimal template you can not enter the container. This is because the container does not have a console configured. You could still issue commands using the 'vzctl exec' command and be able to configure the console, but YMMV.

You can read more detailed information about the installation on the following websites:

Edit: An interesting experiment performed by Scott Dowdle can be found on his blog called 'How many containers?'.