copyleft hardware planet

OHR Support - OHWR MAINTENANCE ON 2011-01-30 (MONDAY) 08:30 CEST

2012-01-27T10:15:32+00:00

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

White Rabbit - White Rabbit presented in CERN's fieldbus WG

2012-01-26T14:16:04+00:00

WR was successfully presented in CERN's fieldbus working group. You can find the slides and some pictures, including the latest and greatest 18-port switch box at http://www.ohwr.org/documents/148

You Bought It, but Do You Own It?

2012-01-26T07:55:42+00:00

On February 10th, I’m sending a letter to the Library of Congress in support of granting exemptions to the DMCA for jailbreaking your own devices. If you believe that you should be able to run whatever programs you want on your own hardware, please sign my letter to show support; anyone from anywhere in the world can sign. You can also submit your own letter to the Library of Congress, if you feel so inclined or disagree with my opinions.

In 2002, I intercepted a key on the original Xbox that allowed me to encrypt and run my own software on the device. Even though that Xbox had a Pentium processor on the inside — the same CPU found in my desktop PC — without that key, I could only run the limited selection of software provided to me by Microsoft.

When I was informed about the DMCA, which became law in 1998, it was a bucket of cold water thrown at my face; I felt deeply disenfranchised. You see, I was a graduate student at MIT at the time, and up until that point the freedom to create, explore, and overcome barriers was encouraged, even celebrated. It was bewildering that running linux on this PC with the green X is illegal, yet running linux on this architecturally identical beige box next to it was legal. A chill descended upon the situation; MIT sent letters to me officially repudiating involvement in my activities, fearing the worst. Fortunately, brave souls at the MIT AI lab stood up for me in defiance of the campus counsel, and provided me with resources and the connections to the EFF to negotiate with Microsoft and see a positive ending to the whole situation.

I’m lucky. Not everyone has the encouragement, wisdom and strength of a team of MIT faculty and EFF counsel behind them. Without further exemptions to the DMCA enabling jailbreaking, freedom to innovate and tinker withers. Since then, many lawsuits have been filed under the DMCA, creating a tone of fear. Research projects are abandoned, business plans are scrapped; and the stalwart operators left with the will to research jailbreaks work in shadow, a constant fear of lawsuit haunting them for the mere practice of attempting to load their own software onto hardware that they legally own. Entrepreneurs and innovators should not be so burdened, especially at a time when we need their valuable contributions to bootstrap new businesses.

I believe if you buy hardware, you should own it; and ownership means nothing less of full rights to do with it as you wish. If you believe in this too, please sign my letter to the Library of Congress in support of extended exemptions to the DMCA, enabling jailbreaks for more platforms.

A special thanks to the EFF for preparing the website and helping me with the letter!

OP25 project joins hosting on osmocom.org

2012-01-25T01:00:00+00:00

Some days ago, I noticed that the famous OP25 project (a Free Software implementation of the APCO25 system, a digital trunked radio system) was no longer reachable on-line. It seems they were running this on a desktop PC in a university. As nobody in the project still seems to be at that university, a change in the network configuration had accidentally rendered the website unreachable.

After some quick e-mails, I offered to host them within the osmocom.org family of Free Software Projects for mobile communications. This is when op25.osmocom.org was created, and a full-site backup uploaded + installed.

I'm really happy that we were able to do a small part to help to make sure this valuable project remains accessible to interested parties in the signal processing and mobile communications field.

First osmo-nvs-gps evaluation boards soldered

2012-01-25T01:00:00+00:00

At the osmocom project, we recently discovered the most interesting NVS NV08C-CSM module. It not only is a superb GPS receiver, but it includes GALILEO and GLONASS receivers, too. However, it's only available as an industry module, or as an expensive (700 EUR or so) evaluation kit.

Given the cheap PCB prototyping service at seeedstudio, I thought I'd spend an afternoon creating the schematics and PCB layout for an evaluation board. It exports the two 3.3V UARTs on OsmocomBB-style 2.5mm jacks, so they can be used with the T191 cables. I have the feeling this 2.5mm jack is becoming a new standard for low-voltage RS232 links ;)

Furthermore, it exports the SPI, I/O and I2C on a 20pin 2.54mm pitch header, connects to an external antenna via a MCX socket and has an optional footprint for a CR2032 battery on the bottom side.

So far, the board seems to be working fine. If there is interest in the bare PCB itself (without components!), please send me an e-mail. Depending on the amount of interest we might add it to the sysmocom webshop.

Schematics and Gerber files will be available at http://openbsc.osmocom.org/trac/wiki/osmo-nvs-gps soon.

Review of the DMD Dot Matrix Display by John Boxall

2012-01-24T10:58:32+00:00

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

When in Doubt…

2012-01-23T15:55:55+00:00

OHR Meta Project - 23-01-2012: Creotech produces 4 CERN OHR designs

2012-01-23T15:12:38+00:00

The Polish company Creotech, that was already involved in the design of the SPEC PCIexpress FMC carrier, has decided to commercialise three Open Hardware designs that were initiated by CERN: SPEC, FMC ADC 100M 14b 4cha, the FMC DEL 1ns 4cha and the FMC DIO 5ch TTL a.
The same company has also created modified versions of the CERN's SPEC board for dedicated applications of its clients. These designs will soon be published on the ohr site as Open Hardware designs.

Name that Ware January 2012

2012-01-23T09:42:11+00:00

The Ware for January 2012 is shown below. Click on the image for a much larger version.

Ok, let’s get the obvious bit out of the way with — it’s a speakerphone of some type, as evident from the gross construction. The question is what make and what model?

I wanted to highlight in this ware a couple of interesting construction points. A speakerphone needs to have excellent echo cancellation, otherwise you get feedback from the speaker to the mic. This speakerphone does a great job in the physical construction to create as much isolation as possible. First, the speaker is isolated from the rest of the body on an “island” of plastic. The housing itself uses a rubber gasket with an air-tight (hot-glue filled) through-hole providing a quality acoustic suspension speaker enclosure.

Then, the microphone is basically in a cradle of rubber. There’s a rubber gasket to isolate the microphone enclosure from the case, and then the microphone itself is suspended in yet another rubber holder. The hole for the microphone to the outside world is generously sized to eliminate the resonant filtering effects of going through a tube, and then the whole assembly is angled with respect to the table to mitigate reflections from the housing to the table.

Even though there is a substantial amount of DSP in the box doing echo-cancellation, there’s nothing like good and simple mechanical design principals to make a product even better.

Winner, Name that Ware December 2011

2012-01-23T09:41:57+00:00

The Ware for December 2011 was a Nichia NDV4313, or a fake of it. The NDV4313 is a 120mW, 405nm laser diode. However, there is another part running around China that seems nearly identical in spec and construction to the NDV4313, but the cost is over two orders of magnitude cheaper. I thought this was an interesting differential in pricing, so I bought some samples to investigate.

When I looked at the ware under a microscope, I was struck by its magnificent construction. If you notice from the photo, the very top chip on the stack has a clear substrate. That’s a near-perfect crystal of sapphire, onto which a thin layer of Gallium Nitride is deposited. The sapphire crystal is cleaved and polished so that the ends form the mirrors for the laser cavity. The laser itself is bonded to the monitor photodiode, which I’m guessing is made out of silicon, and then that is mounted to a gold slug which serves as the ultimate heat sink. It’s quite a work of art.

I’m guessing that no Chinese manufacture is actually “faking” a process this intricate, so most likely these diodes came from a Nichia fab, but are either rejects, relabels, or excess quantities of a legitimate, high-volume product washed through the gray market onto the shores of my lab bench.

Picking a winner was difficult as usual. A lot of correct answers; plum33 was first (and also last month’s winner), but f4eru actually mentioned Nichia in his response. Exercising fully arbitrary judgement authority, I’ll say f4eru is the winner. Congrats, email me to claim your prize!

Detecting and locating lights using an Arduino and an image sensor

2012-01-23T06:00:00+00:00

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

HEX at Space Studios

2012-01-21T15:31:37+00:00

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

pyturtle

2012-01-21T06:59:30+00:00

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.

edubuntu

2012-01-21T05:36:05+00:00

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.

Flight Assembled Architecture

2012-01-20T15:00:33+00:00

Flight Assembled Architecture is a demonstration project that exhibits research conducted on flying machine enabled construction by ETH Zürich professor Raffaello D’Andrea and architects Gramazio & Kohler. The first installation to be built by flying machines, Flight Assembled Architecture utilizes software-controlled flying robots to place foam bricks individually in order to construct a large open-weave structure. Imagined as a scale representation of a 600 m tall towering city, the installation “addresses radical new ways of thinking and materializing architecture as a physical process of dynamic formation,” says D’Andrea.

Contact: ETH Zürich, Zürich, Switzerland.

New quarterly newsletter: 2011 report, best wishes and 2012 plans

2012-01-19T14:33:28+00:00

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 quarterly news about Free Electrons.

The Free Electrons team wishes you a Happy New Year 2012 and all the best for your professional and personal projects. We are taking this opportunity to give some news about Free Electrons.

In 2011, Free Electrons has:

Worked on multiple development projects for various customers. Amongst the most important ones:

development of an embedded Linux system and Qt-based application for a RFID/GSM device based on the AT91 ARM processor
boot time reduction on a MIPS-based point-of-sale system, by improving the embedded Linux system integration
development of an embedded Linux system for an AT91-based device for the medical field (kernel and bootloader adaptation, system integration, application porting)
porting of the PREEMPT_RT patch set to the 2.6.32 kernel delivered by Texas Instruments
developed the driver for the Analog to Digital converters built-in the AT91 processors
conducted a real-time performance analysis of the PREEMPT_RT and Xenomai solutions on AT91 based processors
developed an Ubuntu-based embedded system on a BeagleBoard, for image acquisition and analysis with OpenCV
boot time reduction on an i.MX-based device, with major bootloader modifications
developed a demonstration system for a racing car control panel on a AT91-based device, with a Qt graphical application

Helped customers solve various embedded Linux related problems, through the support provided by Free Electrons engineers

Contributed to various open-source projects:

167 patches to the Buildroot build system
6 patches to the Linux kernel, and more are coming with the mainlining of our AT91 ADC driver
6 patches to the Barebox bootloader
4 patches to the U-Boot bootloader
3 patches to the LTT-ng project

Given multiple sessions of our Embedded Linux system development and Linux kernel and driver development courses. The materials of these courses are being constantly updated and are still freely available under a Creative Commons license.

Prepared materials for a new Android system development course. A four days training session to understand the Android system architecture, how to build and customize an Android system for a given hardware platform, how to extend the Android platform to take new hardware devices into account. A first public session will be organized in June in Toulouse.

Switched the hardware platform used in our Embedded Linux system development course from the aging Calao USB-A9263 platform (AT91-based) to the much more powerful IGEPv2 platform from ISEE (OMAP3-based), offering more possibilities to improve our course.

Hired a new engineer, Maxime Ripard, with Android and embedded Linux experience, and created a new office in Toulouse, France.

Moved its headquarters to Orange, France. While we remain reasonably close the Nice area, where we started, we get closer to other parts of France.

Given two presentations at the Embedded Linux Conference Europe in Prague (Using Buildroot for real projects and Qt for non-graphical applications), gave one presentation on boot time reduction at the GENIVI meeting in Dublin, and gave five editions of an embedded Linux introduction seminar in France.

Attended multiple conferences, for which the Free Electrons team also recorded and published videos of the talks:

Participated to the development of the community of Linaro, an engineering organization working on improving Linux on the ARM platform. In addition to making sure that Linaro has all the infrastructure required to nurture a community of developers and users, we also supported Linaro release users on AskLinaro.

In 2012, we expect to:

Work on more development projects in the field of kernel porting, boot time reduction, power management and embedded Linux system integration.

Announce several new training sessions:

Git training. A two days training session to clearly understand how to use the Git distributed version control system, both for internal projects and for contribution to open-source projects.
Advanced Buildroot training. A three days training session to get a clear and detailed understanding of the Buildroot embedded Linux build system: how to add new packages, how to customize it to generate the embedded Linux system for a given hardware platform.

As we are currently preparing those courses, we are definitely interested in having feedback. Do not hesitate to contact us with your ideas and needs about those topics.

Switch our Linux kernel and driver development course to an OMAP3-based platform, and expand it to the development of a driver for an I2C-attached device.

Convert our training materials to a text source format (LaTeX), and maintain them in a public git tree, making it easier to contribute to them and to follow changes between between versions.

Participate to multiple conferences. Free Electrons will be present at the FOSDEM in Brussels in February, at the Android Builders Summit and the Embedded Linux Conference in San Francisco in February, and also at the Embedded Linux Conference Europe in Barcelona in October. This participation to conferences allows Free Electrons engineers to remain up-to-date with the latest developments in the embedded Linux area and to create useful contacts in the community.

You can follow Free Electrons news by reading our blog (24 articles in 2011) and by following our quick news on Twitter.

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!

Best regards, and again, Happy New Year 2012!

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

…and We’re Back

2012-01-19T06:20:45+00:00

Site’s been restored after a blackout in solidarity with the anti-SOPA protests around the internet. Looks like a few congressmen got the message!

Wifi and the Internet of Things

2012-01-18T17:24:00+00:00

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...

CERN Open Hardware Licence - 18-01-2012: Call for Comments on OHL v1.2

2012-01-18T10:44:41+00:00

From: cernohl-request@ohwr.org [mailto:cernohl-request@ohwr.org] On Behalf Of Myriam Ayass
Sent: 18 January 2012 11:15
To: cernohl@ohwr.org
Subject: CERN OHL v.1.2

Hi,

Thanks to all the feedback we have received on the CERN OHL v.1.1, we have made a few revisions and are now submitting the CERN OHL v.1.2 for comments and feedback (see text of the licence at http://www.ohwr.org/documents/144). The main changes were introduced in article 3 of the licence.
One point in particular is still under discussion and concerns article 3.3(e) – attempting to send modifications to the Licensors whose design was modified and those who requested it. On the one hand questions of practicalities arise – does every minor modification/debugging need to be sent to everyone? – while on the other it may be perceived as a fair return, for contributors, to be notified of modifications that were made. Your input and suggestions on this point are most welcome!

Another point which we would like also to consider is the question of compatibility with other licences.
David Mellis (of the Arduino team)had made the following suggestion:
"what about the possibility of aligning this license with the TAPR one, so that they could, for example, serve as localized versions of the same license? The licenses seem very similar in intent and approach (at least to a legally-naive reader) - it would be great if we didn't have to worry about choosing between them. At a minimum, maybe there's a way to allow for compatibility between them (i.e. the ability to combine TAPR OHL-licensed documentation with CERN OHL-licensed documentation)?

We hope to make the CERN OHL v.1.2 practical to use for anyone, so let us know if you think there are other points that could be improved as well.

Best regards,
Myriam

Development Kits Live!

2012-01-18T04:31:00+00:00

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.

Icarus mining report

2012-01-18T03:12:00+00:00

15 days mining about Total: 4.04000000 BTC， the mining software restart about 850 times.

Live USB/CD/DVD

2012-01-17T08:15:15+00:00

We made a new Live USB version of Elphel Toolkit. It is available for downloading here. Software It is an entire Operating System that can be booted from a USB drive or DVD (of course you can install it on your computer as well) and comes with all Elphel relevant software preinstalled. As the basis [...]

Subpixel Registration and Distortion Measurement

2012-01-17T08:15:15+00:00

Motivation While working on the second generation of the Eyesis panoramic cameras, we decided to try go from capturing the series of the individual panoramic images to the 3d reconstruction. There are multiple successful implementations of such process, we just plan to achieve higher precision of capturing the 3d worlds using Elphel ability to design [...]

Michael Matos CUSP

2012-01-17T01:41:20+00:00

"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

Having Fun with DHL Express!

2012-01-17T01:00:00+00:00

This is what I got when tracking one of my inbound shipments:

It seems DHL is having fun bouncing the package back and forward between Hong Kong and Leipzig(Germany). So far, it started in HK, then arrived in Leipzig on January 8, went back to HK, back to Leipzig, back to HK, back to Leipzig and is currently allegedly again in Hong Kong _after_ succesfully passing German customs clearance on January 15.

For the TCP/IP nerds among the readers: I wonder when the TTL expires.

Old shots of Lucky PDF karaoke with Taki and Lucy

2012-01-16T10:57:50+00:00

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

Sync Generator + Encoder + Modular Synth = Video!

2012-01-16T10:38:57+00:00

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.

NeTV Website

2012-01-16T09:54:48+00:00

I’ve created a wordpress site dedicated to NeTV documentation. You can view documentation and ask questions in forums at this site. I’ll also feature NeTV posts on this blog from time to time. There is also a wiki for those who want to contribute new information to the project.

CERN Open Hardware Licence - 11-01-2012: CERN's Director General cites OHL

2012-01-16T08:31:39+00:00

In his New Year's presentation 2012 to all CERN's personnel, CERN Director General Rolf Heuer devoted one slide on the CERN Open Hardware Licence.
The slide reads:

Implementing new IP schemes
to bridge the gap between CERN and society¶

CERN Open Hardware Licence¶

A legal framework to facilitate knowledge exchange
across the electronic design community.
Version 1.1 of the Licence was issued in July 2011.

In the spirit of knowledge and technology dissemination,
the CERN OHL was created to govern the use, copying,
modification and distribution of hardware design documentation,
and the manufacture and distribution of products

Knowledge Transfer | Accelerating Innovation

(from https://indico.cern.ch/getFile.py/access?resId=0&materialId=slides&confId=171463, slide 64)

First BGA board

2012-01-15T19:42:21+00:00

(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.

First assembled prototypes of osmo-e1-xcvr

2012-01-14T01:00:00+00:00

I mentioned it briefly before: I've designed a small E1/T1/J1 transceiver board, which is going to be used for experimentally interfacing such a TDM line with microcontroller and/or FPGA. The name of this board is osmo-e1-xcvr.

The first prototype PCBs have arrived yesterday, and despite lots of other more important work I couldn't resist but to actually solder some of the units. The result can be seen here:

I don't have time to do anything beyond very basic testing right now, but so far the boards seem to be doing fine. Now we need a driver for the transceiver chip, and connect its control interface over SPI to some microcontroller (likely sam7s/sam3s/sam3u in my case). The actual serial bitstream will end up at the SSC peripheral of the controller.

OHR Meta Project - 13-01-2012: Journal of Instrumentation published OH article

2012-01-13T09:51:16+00:00

The article Open Hardware for CERN’s Accelerator Control Systems, by E. van der Bij et al, has been published in the Journal of Instrumentation JINST Vol.7, January 2012. It presents concisely the different aspects of CERN's Open Hardware developments.

The article is related to the poster Open Hardware for CERN’s Accelerator Control Systems presented at the TWEPP 2011 conference in Vienna, Austria.

Arduino-driven Christmas light display

2012-01-13T03:10:46+00:00

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 at NAMM 2012

2012-01-12T15:33:24+00:00

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!

A Note About Cost

2012-01-12T14:23:39+00:00

Wow. What an amazing first week-or-so. Hackaday, Adafruit, BoingBoing, and Make. It’s almost too much to ask! Thanks to everyone for the positive feedback.

In the midst of this there is one recurring concern that I wanted to address. Many people seem to be comparing this thing to the $30 PID controllers you can get on ebay. I want to take this opportunity to highlight some of the features that set the osPID apart from the low-end competition.

More Sensor Interfaces
By default, the osPID can read either a K-Type thermocouple or a Thermistor. With more input cards on the way (RTD, Voltage, etc..) this allows you to use the osPID in more situations.

Desktop Configuration / Graphing Application

When configuring and monitoring a PID controller, having a graph in front of you is indispensable. The osPID comes with a free (and Open) java application that allows you to interact with the controller from the desktop. You’ll be hard-pressed to find this with any PID controller, and if you do it’ll cost you.

Autotuning
Settling on the correct P, I, and D parameters can be time consuming. Most expensive PID controllers provide an “autotune” which automatically determines good values. The osPID has this. Many cheap controllers do not.

Open Hardware / Software
If your $30 PID controller breaks, or it doesn’t do something you’d like it to, you’re stuck. The osPID is completely open. All software, hardware plans, and firmware code is freely available to download and modify. If you want it do something different, go for it! If a bug is discovered, it can be fixed and downloaded by everyone.

Support
Initially from me, but ultimately (hopefully) from a community of people that have been there, with this specific controller.

So yes. It costs $85
What we have here isn’t an open knock-off of a $30 PID controller. The osPID has, in many cases, better functionality than even a $200 PID controller. Combine this with an unprecedented level of hackability and community, and I’d say that makes this a pretty good buy. (OF COURSE I would say that, but hopefully you agree.)

The Maker Faire is coming to Melbourne!

2012-01-11T13:28:46+00:00

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.

OsmoSDR status update

2012-01-10T01:00:00+00:00

It's already two weeks since my last post mentioning OsmoSDR only very briefly. By now, OsmoSDR is fully public and you can read all about it on the http://sdr.osmocom.org/ website.

Specifically, the website includes Schematics, and one of my colorful block diagrams. I am a text guy and really hate to work with graphics, but the block diagram of the Calypso has helped a lot in the context of making people understand OsmocomBB, so I tried again for OsmoSDR:

So as you can see, it is a very simple, straight-forward design with a chip tuner, direct I/Q down-conversion, ADC for differential I and Q signals as well as a small FPGA for basic filtering and serial format conversion, followed by a Atmel SAM3U microcontroller (Cortex-M3, high speed USB).

And yes, it's receive only. However, it has a stacking connector for later addition of a transmit daughter-board which may eventually follow later in 2012.

So what is this OsmoSDR going to be used for? Well, for receiving any kind of signals between 64 MHz and 1700 MHz (possibly up to 1800 MHz, untested). We don't build it for a specific application, but we simply thought that for many applications a member of the USRP family is expensive overkill, and the FCDP has this arbitrary restriction at 96 kHz sampling frequency.

Please note that while I may be the only OsmoSDR developer that blogs about this project, it is very much a team effort and I'm only a minor part of that team. Apart from selecting the SAM3U, writing firmware and drivers for it as well as some discussions early on in the project, I didn't have any involvement in the Hardware design. Those credits go to Christian Daniel and Stefan Reimann.

So where do we stand? There are 5 prototypes of the first generation, they look like this:

There are some smaller hardware issues that were easy to work around, but one bigger problem related to the fact that the Si570 programmable oscillator output levels didn't match quite with what the FPGA clock input requires.

There will be a second generation board fixing this and other problems, and hopefully we'll see some progress in the weeks to come.

Firmware-wise, the code is currently scattered over a couple of different repositories, but I'm going to consolidate that soon. If you've worked with OpenPCD or SIMtrace, you will find some similarities: We split the flash of the controller into two partitions: One for the DFU bootloader, and one for the application code. You can then use the USB DFU (Device Firmware Upgrade) standard to quickly update the actual firmware of the device, without having to resort to jumpers or un-plugging and re-plugging of the hardware.

This also meant that I had to re-implement the old sam7dfu code for the SAM3U, which has considerable differences in the USB peripheral, cpu core, board startup code, etc. So it's really a reimplementation than a port. The good news is that I tried to make it as general as possible and integrate it with at91lib, Atmels reference code. So it should be easier to use it with other Atmel SoCs like the sam3s which I want to use e.g. in SIMtrace v2.

CERN Open Hardware Licence - 06-01-2012: Tinkerforge German startup uses CERN OHL

2012-01-06T10:21:20+00:00

The German start-up company Tinkerforge explains its modular hardware kit at http://youtu.be/3DwzskCmTgE
According to their Press release, they have chosen the CERN Open Hardware License for their designs.

Gennum GN4124 core - 05-01-2012: Gennum allows open publishing of modified cores

2012-01-05T16:14:25+00:00

CERN has adapted for its particular applications the original GN4124 VHDL and Verilog examples from Gennum. Alan Hutton, Gennum director of Global Distribution Sales & Marketing, has given CERN the green light to publish this modified code as open source.
Gennum just likes the references to Gennum be removed from the original code. Of course Gennum cannot support this modified code, but they will have their usual support and Tim Fairfield's blog

Simple PCIe FMC carrier (SPEC) - 05-01-2012: 70 SPEC cards produced in 2011

2012-01-05T12:32:24+00:00

In the year 2011 the company Creotech has produced and sold fifty SPEC boards. With the twenty cards from the pre-production of the seventy that CERN has ordered from the company Seven Solutions, in total seventy SPEC boards have been produced in 2011.

A/V Geeks and LoVid Present “The Tricks That TV Plays” and “A Tone”

2012-01-04T17:03:32+00:00

"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

TCR update

2012-01-04T14:23:38+00:00

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.

Initial Release is Finally Here!

2012-01-03T21:23:28+00:00

The website is still a little rough around the edges, but the product is ready for initial release, so here goes! Let me introduce you to the osPID:

We’ve been working hard over the last several months to build a fully-featured, open source PID controller that’s every bit as capable as its closed brethren.

There’s a bunch of information on this site regarding technical details, purchasing information, and even a quick PID primer. Take a look around, and let us know what you think!

(If you’re so inclined, there’s also a post on my personal blog with some introductory videos)

[FEL]: fritzing as new year gift

2012-01-03T21:01:26+00:00

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 !

[FEL]: Fix for strange characters on Arduino Ethernet

2012-01-02T13:05:28+00:00

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.

Processing Galileo PFM

2012-01-01T13:25:00+00:00

Hello,

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.

More to follow soon!

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).

SITREP - December 2011

2011-12-31T23:10:33+00:00

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!

Multiple Lithography in Homemade PCBs

2011-12-31T23:09:27+00:00

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.

Fabfi In Domus Magazine

2011-12-31T19:21:00+00:00

Yesterday Amy and I received a belated Christmas present via DHL. Though we knew it was coming, we had no idea what it might be. Upon opening it we discovered a thick, colorful book from Italy, entitled DOMUS. Domus is an Italian architectural magazine packed full of colorful images and stories about art and design. I'm always surprised how often Fabfi gets picked up in the design-world media. Perhaps designers and architects are freer to follow ambitious visions undeterred by technical challenges of implementation; or maybe they just think fluorescent orange acrylic looks snazzy. Either way, we're grateful for the publicity, and the clever re-rendering of my graphics as seen below (see how CC-BY-SA is useful!). I'll refrain from commentary on the editorial itself, which is roughly historical in nature. One geeky side point is that anyone with the magazine has all the data they need to build a Fabfi reflector.

Find the article online article HERE.

Happy New Year everyone!

OsmoSDR hardware verification at 28C3

2011-12-31T14:51:55+00:00

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.

About OsmocomSDR

2011-12-31T14:44:42+00:00

This is the blog of the OsmoSDR project, a small-size, low-cost Software Defined Radio hardware/firmware project.

Peter Donebauer "Entering" (1974)

2011-12-31T04:26:37+00:00

"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)

Sabrina Ratté at Bubble Byte

2011-12-30T12:13:48+00:00

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."

Implementation of MITM Attack on HDCP-Secured Links

2011-12-29T21:11:29+00:00

Today, I gave a talk on an implementation of a man in the middle (MITM) attack on HDCP-secured video links. Here is a full copy of the slides that I presented (with explanatory diagrams), as well as the text-only of the paper which accompanies the slides, below.

Also, please note that the hardware disclosed in this talk is now available for purchase from the good folks at Adafruit. You can find more technical documentation about the NeTV at the kosagi.com wiki, and you can discuss at the kosagi.com forum.

ABSTRACT

A man-in-the-middle attack on HDCP-secured video links is demonstrated. The attack is implemented on an embedded Linux platform, with the help of a Spartan-6 FPGA, and is capable of operating real-time on HD video links. It utilizes the HDCP master key to derive the corresponding private keys of the video source and sink through observation and computation upon the exchanged public keys. The man-in-the-middle then genlocks its raster and cipher state to the incoming video stream, enabling it to do pixel by pixel swapping of encrypted data. Since the link does no CRC or hash verification of the data, one is able to forge video using this method.

Significantly, the attack enables forging of video data without decrypting original video data, so executing the attack does not constitute copyright circumvention. Therefore, this novel and commercially useful application of the HDCP master key impairs equating, in a legal sense, the master key with circumvention. Finally, the embodiment of the exploit is entirely open-source, including the hardware and the Verilog implementation of the FPGA.

BACKGROUND & CONTEXT

In September 2010, the HDCP master key was circulated via Pastebin. Speculation ensued around the application of the master key to create HDCP strippers, which would enable the circumvention of certain copyright control mechanisms put in place around video links. Unfortunately, this is a legally risky application, for a number of reasons, including potential conflicts with DMCA legislation that criminalizes the circumvention of copyright control mechanisms.

This talk discloses a new use for the HDCP master key that side-steps some of the potential legal issues. This hack never decrypts video; without decryption, there is no circumvention, and as a result the DMCA cannot apply to this hack. Significantly, by demonstrating a bona-fide commercially significant purpose for the HDCP master key that does not circumvent an access control measure, this hack impairs the equating of trafficking or possession of the HDCP master key to circumvention and/or circumvention-related crimes.

The main purpose of this hack is to enable the overlay of video content onto an HDCP encrypted stream. The simple fact that a trivial video overlay becomes an interesting topic is illustrative of the distortion of traditional rights and freedoms brought about by the DMCA. While the creation of derivative works of video through dynamic compositing and overlay (such as picture in picture) seems intuitively legal and natural in a pre-HDCP world, the introduction of HDCP made it difficult to build such in-line equipment. The putative purpose role of HDCP in the digital video ecosystem is to patch the plaintext-hole in the transmission of otherwise encrypted video from shiny disks (DVDs, BDs) to the glass (LCD, CRT). Since the implementation of video overlay would typically require manipulation of plaintext by intermediate processing elements, or at least the buffering of a plaintext frame where it can be vulnerable to readout, the creation of such devices has generally been very difficult to get past the body that controls the granting of HDCP keys, for fear that they can be hacked and/or repurposed to build an HDCP stripper. Also, while a manufacturer could implement such a feature without the controlling body’s blessing, they would have to live in constant fear that their device keys would be revoked.

While the applications of video overlay are numerous, the basic scenario is that while you may be enjoying content X, you would also like to be aware of content Y. To combine the two together would require a video overlay mechanism. Since video overlay mechanisms are effectively banned by the HDCP controlling organization, consumers are slaves to the video producers and distribution networks, because consumers have not been empowered to remix video at the consumption point.

The specific implementation of this hack enables the overlay of a WebKit browser over any video feed; a concrete example of the capability enabled by this technology is the overlay of twitter feeds as “news crawlers” across a TV program, so that one may watch community commentary in real-time on the same screen. While some TV programs have attempted to incorporate twitter feeds into the show, the incorporation has always been on the source side, and as such users are unable to pick their hashtags. Now, with this hack, the same broadcast program (say, a political debate) can have a very different viewing experience based on which hashtag is keyed into the viewer’s twitter crawler.

TECHNICAL IMPLEMENTATION

A Spartan-6 FPGA was used to implement a TMDS-compatible source and sink. TMDS is the signaling standard used by HDMI and DVI. The basic pipeline within the FPGA deserializes incoming video and reserializes it to the output. In this trivial mode, it is simply a signal amplifier for the video.

In order to enable the overlay of a WebKit browser, an 800 MHz ARM-based Linux computer is connected to the FPGA. The Linux computer is based upon the PXA168 by Marvell, and it features 128 MB of DDR2 and a microSD card for firmware. The distribution is based upon Angstrom and it is built using OpenEmbedded with the help of buildbot. The entire build system for the Linux computer is available through a public EC2 cloud image that anyone can copy and rent from Amazon.

From the Linux computer’s standpoint, the FPGA emulates a parallel RGB LCD, and thus from the programming standpoint looks simply like a framebuffer at /dev/fb0. There is also a device management interface revealed through I2C that is managed using the standard Linux I2C driver. The I2C management interface handles routine status requests, such as reading the video timing and PLL state, and also handles reading out sections of snooping buffers, the significance of which will be discussed later. The FPGA also has a chroma-key feature where a magic color (240,0,240) is remapped to “transparent”.

The FPGA itself is bootstrapped through a programming interface where the device’s compiled bitstream is sent to the FPGA by writing to /dev/fpga. There are also IOCTLs available on /dev/fpga that enable other meta-level functions such as resetting the FPGA or querying its configuration state.

In addition to passing through the TMDS signal, the FPGA also has the ability to listen to *and* manipulate the DDC. The DDC is an I2C link found on HDMI cables that enables the reporting of monitor capability records (EDIDs) and also is the medium upon which the key exchange happens. Therefore, being able to listen to this passively is of great importance to the hack. The FPGA implements a “shadow-RAM” which records all reads and writes to specific addresses that fall within the expected address ranges for EDID and HDCP transactions.

The FPGA also implements a “squash-RAM” which is used to override bits on the I2C bus. Since I2C is an open collector standard, overriding a 1 to a 0 is trivial; but, overriding a 0 to a 1 requires an active pull-up. The hardware implements a beefy FET on the DDC to enable overriding 0′s to 1′s. The DDC implementation uses a highly oversampled I2C state machine. I2C itself only runs at 100 kHz, but the state machine implementation runs at 26 MHz. This allows the state machine to determine the next state of the I2C bus and decide to override or allow the transaction on-the-fly. The “squash-RAM” feature is used to override the EDID negotiation such that the video source is only informed of modes that the FPGA implementation can handle. For example, this implementation cannot handle 3D TV resolutions, so the reporting of such capabilities from the TV is squashed before it can get to the video source. This causes the source to automatically limit its content to be within the hardware capabilities of the FPGA, and to be within the resolutions that are supported by the WebKit UI.

The key exchange on HDCP consists of three pieces of data being passed back and forth: the source public key (Aksv), the sink public key (Bksv), and a piece of shared state (An). The order in which these are written is well-defined. The completion of the transfer of the final byte of Aksv serves as a trigger to initialize the cipher states of the source and the sink. During this time period, each device computes the dot-product of the other device’s KSV with their internal private key (which is a table of forty 56-bit numbers) and derives a shared secret, known as Km. This is basically an implementation of Blom’s Scheme.

In order to implement the man-in-the-middle attack, the three pieces of data are recorded, and the authentication trigger is passed from the FPGA to the Linux computer through an udev event. udev triggers a program that reads the KSVs from the snoop memory, and performs a computation upon the HDCP master key and the KSVs to derive the private keys that mirrors those found in each of the source and sink devices. In a nutshell, the computation loops through the 40×40 matrix of the HDCP master key, and based upon the KSV having a 1 at a particular bit position it sums in the corresponding 40-entry row or column of the master key to the 40-entry private key vector. The use of a row or columns depends upon if the KSV belongs to a source or a sink.

Once the private keys vectors have been derived, they can be multiplied in exactly the same fashion as would be found in the source or sink to derive the shared secret, Km.

This shared secret, Km, is then written into the FPGA’s HDCP engine, and the cipher state is ready to go. In practice, the entire computation can happen in real-time, but some devices go faster or slower than others, so it is hard to guarantee it always completes in time, particularly with the variable interrupt latency of the udev handler. As a result, the actual link negotiation caches the value of Km from previous authentications, and the udev event primarily verifies that Km hasn’t changed (note that for each given source and sink pair, Km is static and never changes, so unless users are pulling cables out and swapping them between devices, Km is essentially static). If the Km has changed, it updates the Km in the FPGA and forces a 150ms hot plug event, which re-initiates the authentication, thereby making the transaction fairly reliable yet effectively real-time.

Significantly, this system as implemented is incapable of operating without having the public keys provided by both the source and the sink. This means that it cannot “create” an HDCP link: this implementation is not an operational HDCP engine on its own. Rather, it requires the user of this overlay hack to “prove” it has previously purchased a full HDCP link through evidence of valid public keys.

Once the FPGA’s HDCP cipher state is matched to the video source’s cipher state, one can now selectively encrypt different pixels to replace original pixels, and the receiver will decrypt all without any error condition. This is because encryption is done on a pixel by pixel basis and the receiver does little in the way of verification. The lack of link verification is in fact quite intentional and necessary. The natural bit error rate of HD video links is atrocious; but this is acceptable, because the human eye probably won’t detect bit errors even on the level of 1 in every 10,000 bits (at high error rates, users see a “sparkle” or “snow” on the screen, but largely the image is intact). Therefore, this latitude in allowing pixel-level corruption is necessary to keep consumer costs low; otherwise, much higher quality cables would be required along with FEC techniques to achieve a bit error rate that is compatible with strict cryptographic verification techniques such as full-frame hashing.

The selection of which pixel to swap is done by observing the color of the overlay’s video. The overlay video is not encrypted and is generated by the user, so there is no legal violation to look at the color of the overlay video. Note that other pixel-combining methods, such as alpha blending, would necessitate the decryption of video. If the overlay video matches a certain chroma key color, the incoming video is selected; otherwise, the overlay video is selected. This allows for the creation of transparent “holes” in the UI. Since the UI is rendered by a WebKit browser, chroma-key is implemented by simply setting the background color in the CSS of the UI pages to magic-pink. This makes the default state of a web page transparent, with all items rendered on top of it opaque.

Note that pixel-by-pixel manipulation of the incoming video feed is done without any real buffering of the video. A TMDS pixel “lives” inside the FPGA for less than a couple dozen clock cycles: the lifetime of a pixel is simply the latency of the pipelines and the elastic buffers required to deskew wire length differences between differential pairs. This means that the overlay video from the Linux computer must be strictly available at exactly the right time, or else the user will see the overlay jitter and shake. In order to avoid such artifacts, the time resolution requirement of the pixel synchronization is stricter than the width of a pixclock period, which can be as short as dozen nanoseconds.

In order to accomplish this fine-grain synchronization, a genlock mechanism was implemented where vertical retrace signals (which are unencrypted) trigger an interrupt that initiates the readout of /dev/fb0 to the FPGA. However, the interrupt jitter of a non-realtime Linux is much larger than a single pixel time, so in order to absorb this uncertainty, a dynamic genlock engine was implemented in the FPGA. An 8-line overlay video FIFO is used to provide the timing elasticity between the Linux computer and the primary video feed; and the vertical sync interrupt-to-pixel-out latency of the Linux computer is dynamically measured by the FPGA and pre-compensated. In effect, the FPGA measures how slow the Linux box’s reflexes are, and requests for the frame to start coming in advance of when the data is needed. These measures, along with a few lines of FIFO, ensure pixel availability at the precise time when the pixel is needed.

SUMMARY

A system has been described that enables a man-in-the-middle attack upon HDCP secured links. The attack enables the overlay of video upon existing streams; an example of an application of the attack is the overlay of a personalized twitter feed over video programs. The attack relies upon the HDCP master key and a snooping mechanism implemented using an FPGA. The implementation of the attack never decrypts previously encrypted video, and it is incapable of operating without an existing, valid HDCP link. It is thus an embodiment of a bona-fide, non-infringing and commercially useful application of the HDCP master key. This embodiment impairs the equating of the HDCP master key with copyright circumvention purposes.

Textures

2011-12-29T15:00:47+00:00

R-Cast Textures acrylic material weighs half as much as glass but is 17 times stronger. It is also four times stronger than concrete. Textures are acrylic panels that feature customized patterns sculpted deep into the surface. Without any special illumination, the panels reflect available ambient lighting to produce deep and dramatic shadows. Textures panels are available in opaque, clear, and translucent colors, and may be but to custom shapes and sizes.

Contact: Reynolds Polymer Technology, Inc., Grand Junction, CO, USA.
Find more information in Transmaterial 3.

NVS08C-CSM, the first mass market receiver to track Galileo

2011-12-27T07:19:00+00:00

I would like to report the great work done by NVS which -to my knowledge- is the first Company to produce a mass market single frequency four constellation receiver tracking Galileo.

Figure 1: NVS Storegis displaying simultaneous tracking of GPS, Glonass, and Galileo PRN11 (in yellow).

The receiver was flashed with a custom firmware kindly provided by the manufacturer to us on Boxing Day and was then perfectly able to track GALILEO-PFM (GSAT0101). Elevation and azimuth are -obviously-
not measured as the satellite transmits dummy data and it's therefore marked as unhealthy right now.

Other bespoke versions of the firmware enable tracking of GIOVE A and B or raw observables on all constellations, which shows the potential of this little module.

Another good thing is that the NVS08C-CSM is easily available for purchase through NVS reps as well as here:
http://it.farnell.com/nvs-technologies/nv08c-csm/receiver-sat-navigation-smt/dp/1902504

Merry Christmas to all the GNSS community!

All the best,
Michele

OpenSC/PKCS#11 driver development

2011-12-27T00:43:02+00:00

Dear Crypto Stick Friend, we need your support!

PKCS#11 is a popular interface to connect smart cards (also Crypto Stick) with various software applications such as Firefox, TrueCrypt, Mozilla Thunderbird, PuTTY and many more. The current driver for the Crypto Stick works well but it is not open source and hence not well integrated to Linux systems and also lacks full write support. The OpenSC framework is the dominating open source PKCS#11 library but it can't be used with the Crypto Stick yet. We want to achieve full read and write support of the Crypto Stick in OpenSC and the driver will be released as open source and can be used by all Crypto Stick users. Because our time and resources are dedicated to the development of Crypto Stick 2 we need Euro 900 to delegate this task to an external developer. We already collected Euro 500 (thanks to Kicktipp) and need another Euro 400 to have sufficient funding. Please support this effort with a donation.

Because we are a non-profit organization, if we receive your donation before New Year's Eve, we are glad to provide you a donation receipt of 2011. (Of course, otherwise you will get a donation receipt of 2012.)

PayPal: Send your donation to spende@privacyfoundation.de and state "Crypto Stick" as purpose.

Wire transfer:

Recipient: German Privacy Foundation e.V.
Account number: 329 31 80
BLZ: 100 700 24
Institute: Deutschen Bank
IBAN: DE13100700240329318000
BIC: DEUTDEDBBER
Purpose: Crypto Stick

We wish you a Happy New Year!

Crypto Stick Team

Russ Cogdell Apeirogon

2011-12-26T02:43:01+00:00

russcogdell

Linux version usbboot for Ingenic xburst 4770

2011-12-24T08:23:48+00:00

‘Yuenshu Fong’ create a Linux version usbboot for xburst 4770 cpu. you can find the source tar ball here

Neil Gravander

2011-12-23T09:40:14+00:00

Neil Gravander
http://www.myspace.com/luckyb0ne
scroll down for article

CernFIP - 16-12-2011: Large scale nanoFIP radiation tests ☢

2011-12-21T16:14:34+00:00

Valmet Children Glitch Workshop

2011-12-21T10:07:42+00:00

http://matiaswilkman.blogspot.com/

New Year – New Gear: Milkymist Video Synthesizer Makes 2012 Awesome

2011-12-20T00:44:28+00:00

Season’s greetings friendz.

As you know the folks here at Fabricatorz have been collaborating with an international crew to develop and manufacture the Milkymist one. We’ve launching our new Milkymist website complete with a tutorial section. In addition to adding .jpeg support and more documentation, we’ve had users tell us how they used the Milkymist in a professional and educational atmosphere.

Recently architect Naihan Li has used the Milkymist to “perform” a presentation.

Free technology is beautiful. So get your own Milkymist today.

[FEL]: gplcver crash fix and openocd update

2011-12-19T21:31:58+00:00

Shakthi updated gplcver to fix a crash upon launch.

Dean Glazeski updated openocd to 0.5.0.

[FEL]: Some minor updates

2011-12-18T15:04:56+00:00

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.

Wide field 4D optical flow odometry using Arduino and Stonyman image sensor

2011-12-16T16:39:09+00:00

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.)

TDC core test results

2011-12-16T13:03:44+00:00

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.

OHR Support - OHWR maintenance on 2011-12-19 (Monday) 08:30 CEST

2011-12-15T09:25:42+00:00

Hello everyone,

Next Monday morning we'll perform a maintenance update on the ohwr site.

On this update we'll add a new section to the top menu (Home, My Page, Projects, Companies) called "Licenses". It will include all licenses used in OHWR, including the CERN OHL license.

We'll also change the order in which the project tabs are presented (placing the "Wiki" tab in second place) and will darken the text tone a bit, to increase its legibility.

The upgrade process is scheduled to start at 08:30 CEST and is estimated to take around 20 minutes. The ohwr website will not be available during that time.

Thanks and regards,

The OHR-Support team

Lunalite

2011-12-09T15:00:22+00:00

Lunalite decorative surfaces exhibit a range of effects, from rustic textures to metallic shimmer. This collection of sophisticated interlayers features materials like mica, gold flake and sisal fibers, giving surfaces depth and complexity. Custom fabrication ensures that each organic Lunalite surface is unique. Natural, metallic, holographic and recycled inclusions are embedded in a range of materials including glass and acrylic, and glass panels may be tinted to match virtually any color. Lunalite technology can be applied to doors, windows, dividers, walls, counter tops, and displays.

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

Copyleft FPGA board: Icarus

2011-12-08T19:44:46+00:00

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.

New device: Hall Effect and Proximity Sensor Module

2011-12-08T07:01:33+00:00

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.

TronixStuff review of our modules

2011-12-08T05:37:14+00:00

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/

SPI Board Package - SPICONTROLLER second prototype delivered !

2011-12-07T08:58:10+00:00

After the correction of few bugs identified on the first prototype of the board, the second prototype of SPICONTROLLER had been delivered. After power up the board, RTX OS create the TCP task and it can talk to the Soleil Control System.
We use the occasion to share the schematic of the board in the OHWR, and present the first picture of the board.

Warner Jepson

2011-12-06T17:19:05+00:00

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

SwitchSmart!

2011-12-06T09:55:08+00:00

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

Naihanli’s crates and milkymist one

2011-12-06T04:21:31+00:00

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

Make an optical flow sensor using an Arduino, CdS cells, and a shoebox!

2011-12-05T23:25:12+00:00

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!

mkenvimage: a tool to generate a U-Boot environment binary image

2011-12-05T20:56:06+00:00

Many embedded devices these days use the U-Boot bootloader. This bootloader stores its configuration into an area of the flash called the environment that can be manipulated from within U-Boot using the printenv, setenv and saveenv commands, or from Linux using the fw_printenv and fw_setenv userspace utilities provided with the U-Boot source code.

This environment is typically stored in a specific flash location, defined in the board configuration header in U-Boot. The environment is basically stored as a sequence of null-terminated strings, with a little header containing a checksum at the beginning.

While this environment can easily be manipulated from U-Boot or from Linux using the above mentioned commands, it is sometimes desirable to be able to generate a binary image of an environment that can be directly flashed next to the bootloader, kernel and root filesystem into the device’s flash memory. For example, on AT91 devices, the SAM-BA utility provided by Atmel is capable of completely reflashing an AT91 based system connected through the serial port of the USB device port. Or, in factory, initial flashing of devices typically takes place either through specific CPU monitors, or through a JTAG interface. For all of these cases, having a binary environment image is desirable.

David Wagner, who has been an intern with us at Free Electrons from April to September 2011, has written a utility called mkenvimage which just does this: generate a valid binary environment image from a text file describing the key=value pairs of the environment. This utility has been merged into the U-Boot Git repository (see the commit) and will therefore be part of the next U-Boot release.

With mkenvimage you can write a text file uboot-env.txt describing the environment, like:

bootargs=console=ttyS0,115200
bootcmd=tftp 22000000 uImage; bootm
[...]

Then use mkenvimage as follows:

./tools/mkenvimage -s 0x4200 -o uboot-env.bin uboot-env.txt

The -s option allows to specify the size of the image to create. It must match the size of the flash area reserved for the U-Boot environment. Another option worth having in mind is -r, which must be used when there are two copies of the environment stored in the flash thanks to the CONFIG_ENV_ADDR_REDUND and CONFIG_ENV_SIZE_REDUND. Unfortunately, U-Boot has chosen to have a different environment layout in those two cases, so you must tell mkenvimage whether you’re using a redundant environment or a single environment.

This utility has proven to be really useful, as it allows to automatically reflash a device with an environment know to work. It also allows to very easily generate a different environment image per-device, for example to contain the device MAC address and/or the device serial number.

New device: Microphone Sound Input Module

2011-12-05T03:08:52+00:00

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.

Buildroot 2011.11 released: details on new features

2011-12-04T22:30:33+00:00

As planned, Buildroot 2011.11 has been released at the end of November. You can download this release as a tarball or through the Git repository.

This release brings a set of new features on which I thought it would be nice to give some details.

The `file` and `local` site method

Each package in Buildroot defines from where the source code for the particular component being built is fetched. Buildroot has of course always supported fetching a tarball from HTTP of FTP servers. Later on, Buildroot has added support for fetching from Git, Subversion and Bazaar repositories, for example by doing:

MYPKG_SITE = http://somelocation.com/svn/foobar/trunk
MYPKG_SITE_METHOD = svn

MYPKG_SITE = git://somelocation.com/foobar.git

The <pkg>_SITE_METHOD variable allows to define the fetching method. When not specified, Buildroot tries to guess it from the <pkg>_SITE value. Of course, in ambiguous cases such as Subversion or Git repositories over HTTP (as shown in the first example), the <pkg>_SITE_METHOD must be specified.

This new version of Buildroot brings two new site methods: file and local.

The file site method allows to specify the location of a local tarball as the source code for the component to be built. For example:

MYPKG_SITE = /opt/software/something-special-1.0.tar.gz
MYPKG_SITE_METHOD = file

This can be useful for internal software that isn’t publicly available on a HTTP or FTP server or in a revision control system. This new site method was added by David Wagner, who has been an intern at Free Electrons between April and September this year.

The new local site method allows to specify the location of the source code to be built as a local directory. Buildroot will automatically copy the contents of this directory into the build directory of the component and build it from here. This is very useful because it allows to version control your source code as you wish, make changes to it, and easily tell Buildroot to rebuild your component. Note that the copy is using rsync so that further copies are very fast (see the pkg-reconfigure and pkg-rebuild targets below). An example of using the local site method:

MYPKG_SITE = /opt/software/something-special/
MYPKG_SITE_METHOD = local

This new site method has been implemented by myself, as the result from my experience of using Buildroot with various Free Electrons customers.

The source directory override mechanism

The local site method described above is great for packaging special components that are specific to the embedded device one is working on, like the end-user application, or special internal libraries, etc.

However, there are cases where it is needed to work with a specific version of an open-source component. This is typically the case for the Linux kernel or the chosen bootloader (U-Boot, Barebox) or with other components. In that case, one may want to keep using Buildroot to build those components, but tell Buildroot to fetch the source code from a different location than the official tarball of the component. This is what the source directory override mechanism provide.

For example, if you want Buildroot to use the source code of the Linux kernel from /opt/project/linux/ rather than download it from a Git repository or as a tarball, you can write the following variable definition in a board/company/project/local.mk file:

LINUX_OVERRIDE_SRCDIR = /opt/project/linux

Then, you reference this file through the BR2_PACKAGE_OVERRIDE_FILE option, in Build options -> location of a package override file. When building the Linux kernel, Buildroot will copy the source code from /opt/project/linux into the kernel build directory, output/build/linux-VERSION/ and then start the build process of the kernel.

Basically, this mechanism is exactly like the local site method described previously, except that it is possible to override the source directory of a package without modifying the package .mk file, which is nice for open-source packages supported in Buildroot but that require local modifications.

To summarize, here is my recommendation on how to use Buildroot for packages that require project-specific modifications:

You are using an existing open-source component on which you make some tiny bug fixes or modifications. In this case, the easiest solution is to add additional patches to the package directory, in package/<thepackage>/.
You are using an existing open-source component, but are making major changes to it, that require proper version control outside of Buildroot. In this case, using the source directory override feature is recommended: it allows to keep the Buildroot package .mk file unmodified while still using your custom source code for the package.
You have project-specific libraries or applications and want to integrate them in the build. My commendation is to version control them outside of Buildroot, and then create Buildroot packages for them using the local site method. Note that in the pkg_SITE variable, you can use the $(TOPDIR) variable to reference the top source directory of Buildroot. I for example often use MYAPP_SITE = $(TOPDIR)/../myapplication/.

The `<pkg>-rebuild` and `<pkg>-reconfigure` targets

For a long time, when one wanted to completely rebuild a given package from scratch, a possibility was has been to remove its build directory completely before restarting the build process:

rm -rf output/build/mypackage-1.0/
make

Or, using the -dirclean target available for each package:

make avahi-dirclean
make

As these commands remove completely the build directory, the build process is restarted from the beginning: extracting the source code, patching the source code, configuring, compiling, installing.

In 2011.11, we have added two new per-package targets to make it easy to use Buildroot during the development of components:

make mypkg-reconfigure will restart the build process of mypkg from the configuration step (the source code is not re-extracted or repatched, so modifications made to the build directory are preserved)
make mypkg-rebuild will restart the build process of mypkg from the compilation step (the source code is not re-extracted or repatched, the configuration step is not redone)

So, a typical usage could be:

emacs output/build/mypkg-1.0/src/foobar.c
make foobar-rebuild

However, beware that all build directories are removed when you do make clean, so the above example is only useful for quick testing of changes.

The case where the -reconfigure and -rebuild are really useful is in combination with the local site method or the source override directory mechanism. In this case, when pkg-reconfigure or pkg-rebuild is invoked, a synchronization of the source code is done between the source directory and the build directory is done before restarting the build.

Let’s take the example of a package named mypkg for which package/mypkg/mypkg.mk contains:

MYPKG_SITE = /opt/mypkg
MYPKG_SITE_METHOD = local

Then, to work on your package, you can simply do

emacs /opt/mypkg/foobar.c    # Edit as usual your project
make mypkg-rebuild           # Synchronizes the source code from
                             # /opt/mypkg to the build directory
                             # and restart the build

Integration of real-time extensions

In this 2011.11, an interesting addition is the integration of the Xenomai and RTAI real-time extensions to the Linux kernel. The Xenomai integration was initially proposed by Thomas de Schampheleire and then extended by myself, and I have also added the RTAI integration. This integration allows to seamlessly integrate the kernel patching process and the compilation of the required userspace libraries for those real-time extensions.

Conversion of the documentation to asciidoc

Back in 2004, one of my first contribution to Buildroot was to start writing documentation. At the time, the amount of documentation was small, so a single and simple HTML document was sufficient. Nowadays, Buildroot documentation has been extended significantly, and will have to be extended even further in the future. The approach of a single raw HTML document was no longer up to the task.

Therefore, I have worked on converting the existing documentation over to the asciidoc format. This allows us to split the source of the documentation in several files, for easier edition, and allows to generates a documentation in multiple formats: single HTML, split HTML, raw text or PDF.

Just run make manual in Buildroot 2011.11 to generate the manual. Note that the version available on the website is still the old HTML version, but it should soon be updated to the new asciidoc version.

Free Electrons contributions

Free Electrons has again contributed to this Buildroot release:

$ git shortlog -sen 2011.08..2011.11 | head -12
   126	Peter Korsgaard
   104	Gustavo Zacarias
    62	Thomas Petazzoni, from Free Electrons
    27	Yann E. MORIN
    21	Sven Neumann
    13	Yegor Yefremov
    10	Thomas De Schampheleire
     7	H Hartley Sweeten
     5	Frederic Bassaler
     4	Arnout Vandecappelle (Essensium/Mind)
     4	Maxime Ripard, from Free Electrons
     3	Baruch Siach

Our contributions have been:

Implementation of the source directory override mechanism
Implementation of the local and file site methods
Implementation of the pkg-rebuild and pkg-reconfigure targets
Conversion of the documentation to asciidoc and documentation improvements
Various improvements for external toolchain support: optimization of the toolchain extraction and copy (reduced build time), integration of the support of the CodeSourcery x86 toolchains, update of all CodeSourcery toolchains to the latest available versions
Removed useless arguments from the CMAKETARGETS, AUTOTARGETS and GENTARGETS macros, used by all packages in Buildroot. Instead, such pieces of information are automatically figured out from the package .mk file location in the source tree
Added the cifs-utils package (for mounting CIFS network filesystems), the libplayer package, the picocom package.
Cleanup, improve and merge the Xenomai integration done by Thomas de Schampheleire, and implement the RTAI integration
Did a lot of cleanup in the source tree by creating a new support/ directory to contain various tools and scripts needed by Buildroot that were spread over the rest of the tree: the kconfig source code, the special libtool patches, various scripts, etc.

Next release cycle and next Buildroot meeting

The next release cycle has already started. After the meeting in Prague, it was decided that Peter Korsgaard (Buildroot maintainer) would maintain a next branch between the -rc1 and the final version of every release, in order to keep merging the new features for the next release while debugging the current release. This next branch for 2012.02 has already been merged. For example, the addition of the scp and Mercurial site methods has already been merged for 2012.02, as well as numerous other package updates.

On my side, besides usual package updates, I’d like to focus my work for this 2012.02 cycle on improving the testing coverage and on improving the documentation. My colleague Maxime Ripard is working on integrating systemd into Buildroot, as an alternate init mechanism.

The Buildroot community will also be organizing its next meeting in Brussels, on Friday February, 3rd 2012, right before the FOSDEM conference. Buildroot users and developers are invited to join, just contact us through the Buildroot mailing list.

[FEL]: archimedes 2.0.0 stable release

2011-12-04T13:31:58+00:00

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

[FEL]: Bug fix release pcb-0.20110918-3

2011-12-03T19:36:05+00:00

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

[FEL]: ngspice-23 stable release

2011-12-03T19:35:00+00:00

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.

64bit and 32bit SDK/Toolchain for Ben Nanonote

2011-12-03T13:43:50+00:00

你可以在这里找到Ben Nanonote 的SDK(64bit)，我将在我的服务器上编译相应的 32bit 版本。

而且在下一版本的Ben Nanonote Image 中。我们将加入Ben WPAN支持。以及升级内核到Linux-3.0

Ben Nanonote atBen, atUSB

[1]http://en.wikipedia.org/wiki/Wireless_personal_area_network#Wireless

[2]http://downloads.qi-hardware.com/people/werner/wpan/web/

[3]wpan-ipv4 ben nanonote

Create xburst-tools Debian package under Ben Nanonote

2011-12-03T11:09:31+00:00

Why compile xburst-tools under ben nanonote, please checkout this bug(xburst-tools: contains precompiled binaries in debian/). this means we have to compile the target firmware under a MIPS Debian system. that is why I try to compile xburst-tools under ben nanonote. I just write down the command I used :

0. follow this link install debian in your Nanonote.
1. add this like to /etc/apt/sources.list
deb-src http://ftp.debian.org/debian sid main

2. install packages for compile xburst-tools
apt-get update
apt-get install build-essential autoconf automake libusb-dev libconfuse-dev
apt-get install debhelper pkg-config devscripts
apt-get install libusb-1.0-0-dev libreadline-dev dpkg-dev
apt-get -b source xburst-tools

3. then all you need do is follow the debian/README compile xburst-tools. it’s simpile

4. problem is this work have to be done by a package sponsor. I have to find a DD who have a MIPS EL machine or give one Ben Nanonote to a DD.

u-boot support Ben Nanonote (Ingenic JZ4740)

2011-12-03T11:09:19+00:00

Thanks to Shinya Kuribayashi, we added the Ben Nanonote support to u-boot[1].

[1] http://lists.denx.de/pipermail/u-boot/2011-October/105044.html

Prepare Milkymist One for Nanhaili’s event

2011-12-03T11:09:01+00:00

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

My Router has a bad case of S.A.D.*

2011-12-02T14:02:00+00:00

In the last post I blathered on quite a bit about sizing solar panels for routers. As it turns out, the theoretical and the empirical don't match up so well. Instead of running 24h/day, the Farm School solar nodes are currently running more on the order of 6h. I suspect this has mostly to do with the fact that the sun is so low for much of the day in this part of the world that it's behind trees, but it's also possible the new charge controllers aren't as efficient as billed. Whatever the reason, I'm about 18h/day short of the full monte (translate: waaaaay short), which has me thinking about power optimization.

In laptops, a very common way to save juice is to adjust the clock speed down when the device is idle, and it seems someone has built a package to control CPU clock for the RouterStation. It would be a great project for someone to wrap this with a script that measures load and adjusts speed accordingly. Anyone interested??

*S.A.D. stands for Seasonal Affective Disorder

EDIT: I took a few minutes to try manually switching the clock speed with the above package. A few Results:

Changing speed requires a reboot (the package is simply a command line tool for rewriting the bootloader)
The overall reduction in power going from 680Mhz to 200Mhz is only abvout .25W at idle
Running a RouterStation at 200Mhz makes it boot waaaaay slower

EtherTen / Siri hack by Marcus Schappi featured in the Sydney Morning Herald

2011-12-02T02:25:18+00:00

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!

RC micro helicopter hover (yaw and height) using millimeter thick vision camera

2011-12-02T00:24:55+00:00

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.")

New device: Addressable RGB LED Module

2011-12-01T23:21:32+00:00

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.

Impromptu in-store Arduino display at Jaycar Newcastle

2011-12-01T03:26:34+00:00

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.

New device: Sound and Buzzer Module

2011-12-01T01:35:12+00:00

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.

New device: Humidity and Temperature Sensor

2011-11-29T11:25:51+00:00

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.

New device: Shift Register / Expansion Module

2011-11-29T10:59:44+00:00

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.

New device: Logic Level Converter Module

2011-11-28T23:52:25+00:00

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.

New device: Light Sensor Module

2011-11-28T23:40:15+00:00

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.

New York Video Synthesis Workshop & Showcase

2011-11-28T17:02:49+00:00

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

Open 7400 Logic Competition prize pack winner

2011-11-28T03:22:05+00:00

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.

GPS-SDR on the Milkymist (Update 2)

2011-11-26T22:57:49+00:00

~/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

Observing internal FPGA signals

2011-11-26T15:33:40+00:00

By Werner Almesberger

Sometimes, when debugging some firmware or hardware, it is necessary to see how the internal state of a chip changes in response to external signals.

With microcontrollers, this can be accomplished by adding code that toggles some pin that is then used for debugging, and watching that pin with an oscilloscope. Such a pin can also serve as sophisticated trigger, e.g., to capture some input signal only when an error is detected.

With M1, we can do the same, e.g., make LM32 or Navre toggle an I/O under software control. But we can do better: we can also route “hardware” signals directly, without involving software.

Here are three ways to do this:

Change the Verilog to properly route the signal to the output pad. This is nice and clean but has the following disadvantages:
- need to run the full build process for each change of taps,
- need to edit the sources (and remember to undo all the changes once the problem is fixed),
- the signals need to be propagated step by step up the module hierarchy (*), which means a lot of small changes in many files,
  (*) Verilog should support also direct references that “jump” the hierarchy, but this doesn’t seem to be properly implemented in the Xilinx tools.
The pros just edit the FPGA with a WYSIWYG editor (Part three shows how to route signals to a pad). What I don’t like about this is that it’s not script-friendly. I’d also suspect that the changes are lost or at least in danger when re-synthesizing.
Like above, but edit non-interactively. This is an experimental hack I’ve now implemented.

Read the rest from the Milkymist mailing list…

QDR II controller for Virtex 6 - QDRII memory controller core

2011-11-24T18:06:48+00:00

The prototype of the QDRII controller is based on the Switch Core Board version 3 (SCBv3) developed by Seven Solutions.
The ongoing work of this memory controller is available in the SVN repository.

Guest Post: Adapting Mesh Potatoes for Emergency Work

2011-11-24T15:43:03+00:00

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

ZIO - ZIO presented in the ht section

2011-11-24T15:05:23+00:00

http://www.ohwr.org/attachments/881/zio-111123.pdf

On Nov 23rd 2011, the project has been presented to the hardware and timing section in Geneve. On Nov 24th we had a brainstorming session to refine requirements and increase our TODO list

Introducing the FredBoard and Mothership Hackermoms!

2011-11-20T23:23:52+00:00

FredBoard (aka FreakLabs Breadboard) (http://www.freaklabsstore.com/index.php?main_page=product_info cPath=22 products_id=194) and it started its life as a learning tool inside Tokyo Hackerspace (http://tokyohackerspace.org/) . We needed something that could be used to teach electronics and Arduino programming since the line between the two has gotten blurrier over time. I was discussing it with one of the workshop instructors (Emery Premaux (http://www.amazon.com/Arduino-Projects-World-Emery-Premeaux/dp/143023623X/ref=sr_1_1?ie=UTF8 qid=1321860649 sr=8-1)) and he was using separate breadboards and Freakduinos to teach the class. I casually mentioned that we should combine...

Using Handbag with the USBDroid and Android

2011-11-18T02:41:22+00:00

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

chibiArduino v0.54 Release - Fixed Previous Broken Release

2011-11-16T22:32:18+00:00

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 Transmitter Experiments

2011-11-15T11:08:41+00:00

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

Johnny Woods and Dpony VHS Movie/Album

2011-11-15T01:41:18+00:00

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/

zenit

2011-11-14T09:29:44+00:00

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/

bdale's rocket blog: RF Immunity

2011-11-14T08:39:45+00:00

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.

BCNDEVCON... Open Source, Al ataqueeeerrrrr !!!

2011-11-13T18:25:14+00:00

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.

Television Magazine April 1976

2011-11-08T09:34:12+00:00

from this auction

New Video

2011-11-08T01:05:07+00:00

circle distortions from Chris King on Vimeo.

Embedded Linux Conference Europe 2011 videos

2011-11-07T06:31:18+00:00

One week after the end of the Embedded Linux Conference Europe 2011, we are pleased to release the videos of all talks that took place during this event. We would like to thank the Linux Foundation for allowing us to record those talks and to share freely the resulting videos on-line, and also thank the Clarion Congress Hotel technical staff for helping us with technical details related to video recording.

Below, you’ll find 51 videos, in both a 1920×1080 HD format and a reduced 800×450 format. In total, it represents 28 GB of video, for a duration of 2214 minutes, that is more of 36 hours of video. We hope that you will enjoy those videos and that these will be useful to those who couldn’t attend the conference.

Jim Zemlin
Executive Director of The Linux Foundation
Imagine a World Without Linux
Video (24 minutes):
full HD (220M), 450×800 (76M)

Linus Torvalds, Alan Cox, Thomas Gleixner, Paul McKenney
moderated by Lennart Poettering
Kernel Developer Panel
Video (55 minutes):
full HD (622M), 450×800 (191M)

Zach Pfeffer
Linaro
Linaro’s Android Platform
Video (45 minutes):
full HD (604M), 450×800 (164M)

Thomas Gleixner
Linutronix
State of PREEMPT_RT
Video (46 minutes):
full HD (374M), 450×800 (147M)

Jessica Zhang
Intel
The Yocto Project Eclipse plug-in: An effective IDE environment for both Embedded Application and System developers
Video (45 minutes):
full HD (431M), 450×800 (118M)

Satoru Ueda
Sony Corporation / Japan OSS Promotion Forum
Contributing to the Community? Does your Manager Support You?
Video (42 minutes):
full HD (556M), 450×800 (140M)

Benjamin Zores
Alcatel-Lucent
Embedded Linux Optimization Techniques: How Not To Be Slow
Slides
Video (44 minutes):
full HD (328M), 450×800 (125M)

Ohad Ben-Cohen
Texas Instruments
Remote Processor Messaging
Slides
Video (48 minutes):
full HD (433M), 450×800 (131M)

Jeff Osier-Mixon
Intel
Collaborative Initiatives in Embedded Linux
Video (26 minutes):
full HD (266M), 450×800 (73M)

Karim Yaghmour
Opersys Inc.
Leveraging Android’s Linux Heritage
Video (51 minutes):
full HD (419M), 450×800 (168M)

Pierre Tardy
Intel
Using pytimechart For Real World Analysis
Slides
Video (51 minutes):
full HD (495M), 450×800 (132M)

Arnd Bergmann
Linaro
Optimizations for Cheap Flash Media
Video (44 minutes):
full HD (524M), 450×800 (146M)

Vitaly Wool
Sony Ericsson
Saving Power with Wi-Fi: How to Prolong Your Battery Life and Still Stay Connected
Slides
Video (50 minutes):
full HD (371M), 450×800 (143M)

David Stewart
Intel
Developing Embedded Linux Devices Using the Yocto Project and What’s new in 1.1
Slides
Video (47 minutes):
full HD (370M), 450×800 (124M)

Tetsuyuki Kobayashi
Kyoto Micro Computer
Android is NOT Just “Java on Linux”
Slides
Video (37 minutes):
full HD (542M), 450×800 (129M)

Thomas Petazzoni
Free Electrons
Using Buildroot For a Real Project
Slides
Video (55 minutes):
full HD (408M), 450×800 (156M)

Tim Bird
Sony Network Entertainment
Status of Embedded Linux BoFs
Slides
Video (60 minutes):
full HD (877M), 450×800 (213M)

Lauro Ramos Venancio and Samuel Ortiz
Instituto Nokia de Tecnologia, Intel
The Linux NFC Subsystem
Slides
Video (31 minutes):
full HD (229M), 450×800 (87M)

David Anders
Texas Instruments
Board Bringup: LCD and Display Interfaces
Slides
Video (39 minutes):
full HD (242M), 450×800 (98M)

Antti Aumo
President of Global Solutions at Ixonos
Re-Defining the Cloud Phone
Video (32 minutes):
full HD (360M), 450×800 (108M)

Dirk Hohndel
Chief Linux and Open Source Technologist at Intel
Reflection on 20 Years of Linux
Video (30 minutes):
full HD (235M), 450×800 (92M)

Grant Likely
Secret Lab
Device Tree Status Report
Video (51 minutes):
full HD (775M), 450×800 (178M)

Laurent Pinchart
Ideas on Board
Success Story of the Open-Source Camera Stack: The Nokia N9 Case
Slides
Video (48 minutes):
full HD (308M), 450×800 (120M)

Avinash Mahadeva and Vishwanth Sripathy
Texas Instuments
SOC Power Management – Debugging and Optimization Techniques
Video (41 minutes):
full HD (288M), 450×800 (108M)

Rafael J. Wysocki
Faculty of Physics, U. Warsaw / SUSE Labs
Power Management Using PM Domains on SH7372
Slides
Video (46 minutes):
full HD (692M), 450×800 (157M)

Sascha Hauer
Pengutronix e.K.
A Generic Clock Framework in the Kernel: Why We Need It and Why We Still Don’t Have It
Video (45 minutes):
full HD (345M), 450×800 (134M)

Ruud Derwig
Synopsys
Android Platform Optimizations
Slides
Video (43 minutes):
full HD (266M), 450×800 (105M)

Inki Dae
Samsung Electronics
DRM Driver Development For Embedded Systems
Slides
Video (22 minutes):
full HD (367M), 450×800 (91M)

Lorenzo Pieralisi
ARM Ltd.
Consolidating Linux Power Management on ARM Multiprocessor Systems
Slides
Video (46 minutes):
full HD (283M), 450×800 (113M)

Thomas Petazzoni
Free Electrons
Using Qt For Non-Graphical Applications
Slides
Video (49 minutes):
full HD (340M), 450×800 (124M)

Marek Szyprowski and Kyungmin Park
Samsung Electronics
ARM DMA-Mapping Framework Redesign and IOMMU Integration
Slides
Video (49 minutes):
full HD (790M), 450×800 (195M)

Keerthyd Jagadeesh and Vishwanath Sripathy
Texas Instruments
Thermal Framework for ARM based SOCs
Video (42 minutes):
full HD (316M), 450×800 (113M)

Marc Titinger
ST Microelectronics
Efficient JTAG-Based Linux Kernel Debugging
Slides
Video (57 minutes):
full HD (382M), 450×800 (141M)

Tsugikazu Shibata
NEC and Linux Foundation Board Member
Toward the Long Term Stable Kernel tree for The Embedded Industry
Video (32 minutes):
full HD (606M), 450×800 (145M)

Lisko Lappalainen
MontaVista Software
Secure Virtualization in Automotive
Video (40 minutes):
full HD (301M), 450×800 (116M)

Jeff Osier-Mixon
Intel
Yocto Project Community BoFs
Video (60 minutes):
full HD (451M), 450×800 (167M)

Jon Corbet
Editor at LWN.net
The Kernel Report: 20th Anniversary Edition
Video (28 minutes):
full HD (218M), 450×800 (88M)

Wim Coekaerts
Senior Vice President, Linux and Virtualization Engineering at Oracle
Engineered Systems With Linux
Video (21 minutes):
full HD (175M), 450×800 (68M)

Andrea Gallo
ST-Ericsson
ARM Linux Kernel Alignment and Benefits For Snowball
Slides
Video (47 minutes):
full HD (394M), 450×800 (133M)

Liam Girdwood and Peter Ujfalusi
Texas Instruments
Smart Audio: Next-Generation A SoC For Smart Phones
Video (50 minutes):
full HD (367M), 450×800 (124M)

Pawel Moll
ARM Ltd.
Linux on Non-Existing SoCs
Video (52 minutes):
full HD (483M), 450×800 (143M)

Koen Kooi
The Angstrom Distribution
Integrating systemd: Booting Userspace in Less Than 1 Second
Slides
Video (44 minutes):
full HD (343M), 450×800 (125M)

Sylvain Leroy and Philippe Thierry
Grsecurity in Embedded Linux Used in Android Operating System
Slides
Video (40 minutes):
full HD (384M), 450×800 (110M)

MyungJoo Ham
Samsung Electronics
Charger Manager: Aggregating Chargers, Fuel-Gauges and Batteries
Slides
Video (33 minutes):
full HD (434M), 450×800 (109M)

Arnd Bergmann
Linaro
News From the ARM Architecture
Video (49 minutes):
full HD (421M), 450×800 (150M)

Frank Rowand
Sony Network Entertainment
How Linux PREEMPT_RT Works
Slides
Video (45 minutes):
full HD (378M), 450×800 (135M)

Catalin Marinas
ARM Ltd.
Linux Support for the ARM Large Physical Address Extensions
Slides
Video (52 minutes):
full HD (594M), 450×800 (170M)

Jim Huang
0xlab
Build Community Android Distribution and Ensure the Quality
Video (44 minutes):
full HD (472M), 450×800 (143M)

Till Jaeger
JBB Rechtsanwälte
The Case AVM v. Cybits: The GPL and Embedded Systems
Video (42 minutes):
full HD (362M), 450×800 (124M)

Darren Hart
Intel
Tuning Linux For Embedded Systems: When Less is More
Slides
Video (45 minutes):
full HD (482M), 450×800 (135M)

Wolfram Sang
Pengutronix e.K.
Developer’s Diary: It’s About Time
Video (49 minutes):
full HD (482M), 450×800 (141M)

Report from the Buildroot Developer Day

2011-11-05T13:34:18+00:00

Right after the Embedded Linux Conference Europe, a new edition of the Buildroot Developer Day took place on Saturday, 29th October 2011 in Prague.

Unlike past Buildroot Developer Day that were followed only by Buildroot developers and Yann E. Morin as the crosstool-NG maintainer, this edition of the Buildroot Developer Day was followed by developers of other build systems: Robert Schwebel from PTXdist, Esben Haabendal from OE-lite and we also had the opportunity to discuss with Benjamin Zores and Davide Calvalca from OpenBricks. This made the day very interesting, even though if it was a bit less focused on Buildroot than expected.

I have written and sent a complete report of the discussions, which were about the following topics:

Expanding the send-patches.org initiative. This was an important topic, as developers of several build systems had the opportunity to discuss it during this meeting.
The testing infrastructure of Buildroot, how to improve it.
Package management. A long requested feature for Buildroot, but which would make Buildroot a lot more complicated and probably less reliable. Following this meeting, our position is to not implement such a feature and to keep Buildroot simple. Should package management be necessary, there are other build systems that implement such a feature (at the expense of higher complexity, of course).
Toolchain backend. We will soon switch to using the crosstool-NG backend as the default method of building toolchains in Buildroot. Long term, we would like to get rid of the code that builds a toolchain in Buildroot in order to factorize the efforts at the level of the crosstool-NG project.
Migration of the documentation to the asciidoc format has been accepted, and the next version of Buildroot will feature this updated documentation.
Out-of-tree build of packages. This is a very internal question to how Buildroot builds package. See the report for details.
Website improvement, because the current Buildroot website is quite ugly.
Maintenance process. We are seeing a quite significant increase in the number of contributions to Buildroot and some of these contributions are taking more and more time to get integrated. We discussed the topic and came up with a few proposals on how to improve the situation.
Host packages visible in menuconfig. Traditionally, packages built for the host are not user-selectable as Buildroot since they are just dependencies to build target packages. However, we had the case of some host packages that should be user-selectable. The principle has been agreed upon.
Per-package device file handling. A mechanism proposed by Maxime Ripard, from Free Electrons, to allow each package to specify special permissions/owernships/device files to install in the target filesystem.
Relocatable toolchain and SDK. Buildroot produces a SDK (set of utilities and libraries to build applications for the target independently from Buildroot), but this SDK is currently not relocatable. We discussed the various issues to fix to make it relocatable.
Licensing report generation, which is also a feature that has been requested in the past.

All in all, it was a very interesting and motivating day, that got closed by a short visit of Prague’s center and a nice dinner. The next edition of the Buildroot Developer day will take place on Friday, 3rd 2012 in Brussels, the day before the FOSDEM conference. It is open to all Buildroot users and developers!

Regarding Buildroot itself, the maintainer Peter Korsgaard will release 2011.11-rc1 early next week, and 2011.11 by the end of November. This release will have several new useful features, which we will cover in details in a future blog post.

Maplin Magazine Dec 1995

2011-11-04T12:45:10+00:00

looks like it has a kaleidoscope style video effects project posibly the one posted on audio visualizers
source here

Vortexya Video Kaleidoscope

2011-11-04T12:18:13+00:00

this is a super cool video kaleidoscope based on feedback
more info here

"Electric kaleidoscope battling the nightGlow and dance in your own resonance

Allow us to zoom into your depths and
Mesmerize us with your infinite patterns"

see this post for more on video kaleidoscopes

Back from Embedded Linux Conference Europe 2011

2011-11-03T08:51:36+00:00

As we announced in a previous blog post, a large part of the Free Electrons team attended the 2011 edition of the Embedded Linux Conference Europe in Prague last week.

This was the first european edition of the conference to last three days, and this was much appreciated as it gave the opportunity to attend a lot more conferences and to spend more time talking with developers of the community. My colleagues Michael Opdenacker and Maxime Ripard as well as myself really enjoyed this conference. It really allows to connect with members of the community, learn a lot of new things, and bring home a huge motivation to work on various projects. Despite a few marketing-oriented keynotes, the conference has kept its highly-technical profile, which is great.

We have recorded all the talks of the three tracks of the Embedded Linux Conference Europe (unfortunately, there wasn’t a similar video crew for the LinuxCon Europe conference which was taking place at the same time). Many of those videos should have a much higher audio quality than what we had in the past, since we could capture the audio directly for the conference room sound system. Unfortunately, one of our camcorders generates a loud noise when connected both to the audio system of the conference room and to the power adapter (this noise disappears when the camcorder is on battery). Therefore, not all conferences could be recorded with this improved audio quality. The encoding and upload of those videos has started on Sunday evening, just a few hours after landing in Toulouse when coming back from ELCE. The process is running 24/24 on two machines in parallel, and we therefore hope to be able to provide those videos online by the end of the week, or at worst at the beginning of next week.

Kernel Developer Panel. From left to right: Linus Torvalds, Paul McKenney, Alan Cox, Thomas Gleixner and the moderator, Lennart Poettring

As we also announced, I gave two talks at this Embedded Linux Conference Europe event. One on Buildroot, titled Using Buildroot for real projects, whose slides are available on the elinux.org site. More than 50 persons attended the conference which seems to indicate that there is interest around Buildroot. I had a few questions but unfortunately had to stop the conference after just 2/3 questions since I had exhausted my time slot. My second conference was titled Qt for non-graphical applications, and the slides are also available on the elinux.org site. About 45-50 persons attended the conference and in this case as well, I had to speak quite fast to make the 40+ slides discussion fit within the time slot allocated for the conference, which gave only the time for a few questions at the end. Generally speaking, these talks have attracted a nice number of attendees compared to many other talks I’ve seen, so it seems that all the preparation work was not done needlessly.

Nicolas Deschene (TI) and Loïc Minier (Linaro)

If you couldn’t attend ELCE and are waiting for the videos, I’m sure you’ll also be interested by the date and locations of the next editions of the conference :

The next Embedded Linux Conference, US edition, will take place on February 14-16 2012 in Redwood City, near San Francisco in California. This is an unusual date for the ELC (which traditionally took place in April), but it allows the conference to match with the Linaro Connect event for the first quarter of 2012.
The next Embedded Linux Conference Europe will take place on November 6-9 2012 in Barcelona, Spain. This is a just a ~4h drive from Toulouse, so definitely, several Free Electrons people should be there.

The Project Showcase competition: tell us about your project to win a prize!

2011-11-02T23:44:24+00:00

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

The Freetronics forum goes live

2011-11-02T09:19:37+00:00

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!

Gieskes Hacked Composite to VGA Video Synth now easier to get!

2011-11-01T17:42:52+00:00

Gieskes Hacked Composite to VGA Video Synth now easier to get thanks to Bleep Labs

http://bleeplabs.com/hss3i/
http://gieskes.nl/

Flöt by Studiokeks

2011-11-01T17:29:48+00:00

http://youtu.be/dLiN43iCaKc

very nicely done simple feedback video

Fabricatorz and Friendz In The Newz: Fine Art to Milkymist One MIDI Control (video)

2011-10-31T23:47:36+00:00

Our friend Robin Peckham announces the launch of Saamlung, a new gallery and project office for Hong Kong. The forthcoming exhibitions will represent a survey of Post-Internet art as well as curatorial exhibitions alternating between project-based solo presentations and thematic group shows.

Nadim Abbas, I Would Prefer Not To, 2009, Digital photograph (C-print), 42 x 64 cm

The Saamlung model is research-driven and focuses on placing work within the exciting collections currently restructuring global visual culture to tell the story of a cosmopolitan present.

Get to Saamlung in person for the grand opening in February 2012.

map

: 26/F Two Chinachem Plaza
68 Connaught Rd. C.
(135-137 Des Voeux Rd. C.)
Central, Hong Kong

Pre-opening projects include:

João Vasco Paiva, “Palimpseptic,” 18 November – 5 December
Opening Friday 18 November, 19:00-21:00

Charles LaBelle, “Guilty,” 9 December – 7 January
Opening Friday 9 December, 19:00-21:00

For more information on the projects, please visit their website: http://www.saamlung.com

Our Friend Werner Almesberger states “You haven’t really seen what the Milkymist One (M1) really can do if you haven’t used it with some MIDI controls.”

Here’s Werner’s step-by-step instructions on how to make the Qi Hardware video synthesizer Milkymist One really pop. Get your very own Milkymist One here!

Welcome to our new Californian reseller, EpicTinker

2011-10-30T22:04:32+00:00

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.

Using the Altera USB-Blaster on Fedora

2011-10-28T21:14:16+00:00

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?

Nancy Buchanan - Tech-Knowledge (video art) 1984

2011-10-24T10:16:10+00:00

via denshiblocks

Combining the LCD & Keypad Shield and the USBDroid

2011-10-21T11:34:49+00:00

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

Bruce Perens to keynote LCA2012

2011-10-19T23:48:00+00:00

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/

Mesh Potatoes now FCC and CE Approved

2011-10-18T12:35:34+00:00

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.

First look: EtherMega production samples

2011-10-18T11:15:33+00:00

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.

First atempt to listen weather satellites

2011-10-17T17:59:34+00:00

~/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

"State of Electronics" documentary preview

2011-10-16T10:37:41+00:00

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.

Trinity: I need LEDs. Lots of LEDs

2011-10-15T13:04:54+00:00

This video of a machine for sorting and testing loose LEDs is mesmerising. I'm not sure what they're doing with them all, but it looks like they're loading up a big LED matrix.

Robots and LEDs for the win!

Vanguard Exhibition (Rich's Video Synths)

2011-10-13T17:28:18+00:00

This Friday!

PostgreSQL – altering table name does not update references to its primary key and sequence automatically

2011-10-13T10:27:42+00:00

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!

reflash D-LINK DIR-300 back to original firmware

2011-10-13T09:25:27+00:00

I have flashed OpenWrt on my D-LINK DIR-300, but the signal goes very bad. only 3 meters can receive signal (Link Quality=2/5). here is some steps flash DIR-300 back to original firmware.

1. connect the serial, check here, it’s TTL not 12v so you have but a RS232 <–> TTL converter

+-----+ +---+ +-----------------+ +---+
|Power| |Wan| |Ethernet x4 ports| |Ant|
+-------------------------------------+
|TXD|
|GND|
|VCC|
| . |
|RXD|
+-------------------------------------+

2. download redboot at 1 2 3

3. setup TFTP server, put redboot to TFTP server folder, connect to DIR-300 WAN port.

4. boot DIR-300, press Ctrl + C at serial terminal. input those command:

DD-WRT> ip_address -l 192.168.1.1 -h 192.168.1.2
Default server: 192.168.1.2
DD-WRT> fis init
About to initialize [format] FLASH image system – continue (y/n)? y
*** Initialize FLASH Image System
… Erase from 0xbffe0000-0xbfff0000: .
… Program from 0x80ff0000-0x81000000 at 0xbffe0000: .
DD-WRT> load -r -b %{FREEMEMLO} dir300redboot.rom
Using default protocol (TFTP)
Raw file loaded 0×80040800-0x800607ff, assumed entry at 0×80040800
DD-WRT> fis create -l 0x30000 -e 0xbfc00000 RedBoot
An image named ‘RedBoot’ exists – continue (y/n)? y
… Erase from 0xbfc00000-0xbfc30000: …
… Program from 0x80040800-0x80060800 at 0xbfc00000: ..
… Erase from 0xbffe0000-0xbfff0000: .
… Program from 0x80ff0000-0x81000000 at 0xbffe0000: .
DD-WRT> reset

5. download DIR-300 firmware page at D-Link Singapore.

6. Getting into Emergency Recovery Page
Reset DIR-300, setup your IP address to 192.168.20.80
Open up your web browser and go to http://192.168.20.81.
You should be able to see the emergency recovery page as seen below.

7. select Firmware you download, click ‘upload’

8. wait until serial console show flash finished. reset your DIR-300

More Info check http://www.shadowandy.net/2007/10/flashing-dir-300-back-to-original-firmware.htm

Fake RAM, load/store and push

2011-10-12T03:00:59+00:00

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.

Source code for acquisition and tracking algorithms of GLONASS L3 signals

2011-10-09T18:05:50+00:00

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.

New product: AM3X 3-axis accelerometer module

2011-10-09T08:54:10+00:00

Freetronics started out its product range with shields related to the book "Practical Arduino", then rapidly expanded into Arduino-compatible boards, and now we're expanding again into a third stage of product development: a handy range of add-on modules to let you easily and quickly add sensors, actuators, sound, light, and other features to your projects. Over the next month we'll be releasing about a dozen new products, and the first one is here right now.

Meet the AM3X 3-axis accelerometer module:

It's hard to tell from that photo, but the module is tiny: it's just 22mm long by 15mm high. There's a lot of functionality packed in though, including independent X, Y, and Z axis outputs (easy to read using analog inputs on your Arduino!), a freefall (0g) output so your project can detect if it has been dropped, selectable +/-1.5g and +/-6g ranges, an onboard 3.3V voltage regulator, and 5V-compatible I/O lines so you don't need level shifters.

It's really easy to hook up, and we've included an example wiring diagram and sample source code on the AM3X Quickstart Guide so you can jump right in and start using it.

We'd love to hear what you build with the AM3X, so please submit comments or send us an email!

Infermental 4 at Chisenhale

2011-10-07T01:12:07+00:00

Saturday 8 October, 11.30am-7pm
Screening of the pioneering videocassette magazine Infermental. Issue Four, a 1985 edition of the magazine, will be shown in its seven hour entirety. Introduced by James Richards and Dan Kidner, in advance of their publication ‘A Journey Around Infermental’, edited with George Clark and published by Focal Point Gallery, Southend-on-Sea.

Chisenhale Gallery
64 Chisenhale Road
London E3 5QZ

Trees Fall Live 9-17-11

2011-10-03T14:35:39+00:00

Sorry I haven't posted in a while I have been super busy, anyway here is something cool from synchroton

DOES IT TURN PAGES?

2011-09-29T16:49:06+00:00

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:

bdale's rocket blog: AltOS 1.0.2 Released

2011-09-29T16:29:12+00:00

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.

News Release: VJing Made So Simple Anyone Can Do It

2011-09-28T15:00:00+00:00

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)

Tuxbrain vuelve de la OSHWCon 2011... con ganas de más (fotos)

2011-09-27T19:01:03+00:00

Señoras y señores ha nacido un nuevo evento , volvemos de la Open Source Hardware Convention 2011 organizada por Synusia, simplemente excelente, excelente calidad de los ponentes, excelente calidad de los asistentes (y numerosos ) , y sobre todo excelente calidad de la organización.
A continuacion fotos con comentarios del evento:

All source code is moving to Google Code

2011-09-24T08:26:16+00:00

All source code is moving to Google Code now.

Current project list includes:
1) GNSS-SDR front-end project wich include:
a) PCB designed in KiCAD;
b) CPLD-project made in Xilinx ISE WebPack;
c) Firmware for USB-bridge cy7c68013a;
2) Real-time GPS receiver GPS-SDR addition to work with gnss-sdr front-end;
3) None real-time GLONASS receiver for SCILAB;
4) Console MS Windows program for streaming data to HDD from gnss-sdr front-end;
5) Hardware project wich include:
a) Namuru based correlator ported to work with Wishbone bus;
b) OSGPS based single channel GPS receiver (example of how acquisition and tracking is made in hardware receiver). This projects works in conjuction with Namuru based correlator;

Order #600 has shipped, so it's free

2011-09-21T04:37:20+00:00

On Thursday September 15th we received our 600th retail order, placed by a local: Tim from Melbourne, Australia, who ordered:

Of course it's our tradition that every 100th retail order ships free of charge, so Tim received his order for the princely sum of $0!

Congratulations Tim!

Local US stock at reseller Kineteka Systems

2011-09-16T00:21:55+00:00

Right from the early days when Freetronics first opened for business we've been shipping orders to US customers, so it's our great pleasure to announce that we now have a US reseller carrying local stock: Kineteka Systems.

Kineteka are based in Texas, so if you're in the US they're just a little closer to you than the Freetronics team down here in Melbourne, Australia. That means our valued North American customers can now get much faster shipping and also transactions directly in US$.

Welcome, Kineteka!

Introduction

2011-09-13T14:11:23+00:00

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

Chip design, open source, and DIY: Part 3, batch fabrication of chips

2011-09-12T14:17:18+00:00

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.

John Foxx

2011-09-10T16:21:33+00:00

Recently super nice guy and talented Graphic designer Jonathan Barnbrook asked me to help him out with including some analogue and hardware based effects on a video he was putting together for John Foxx, here are the results (mostly Jonathan's hard work with some image processing by me)

It was a great experience to work on

Free Electrons at Embedded Linux Conference Europe 2011

2011-09-07T19:46:16+00:00

The next Embedded Linux Conference Europe will take place from October 26th to October 28th in Prague, together with the first edition of LinuxCon Europe and just after the Kernel Summit, the GStreamer conference and the Real-time Linux workshop: it’s a really impressive concentration of interesting talks for embedded Linux developers. Linus Torvalds is already announced as a keynote speaker of the LinuxCon Europe.

As ELCE is a conference that embedded Linux developers simply can’t miss, the complete team of Free Electrons will be there: my colleague and Free Electrons founder Michael Opdenacker (Michael is part of the organization committee for this event), my engineer colleagues Grégory Clément and Maxime Ripard and myself, Thomas Petazzoni.

I will also have the chance to give two talks during this edition of ELCE:

Using Buildroot for real products. As Free Electrons has used and is using Buildroot for multiple customer projects, this talk will share our experience on how to configure and setup Buildroot properly to build embedded Linux systems and include in a clean and nice way all of the specificities of each product.
Using Qt for non-graphical applications. Qt is often seen only as a graphical library, but it is in fact much more than that. Based on the experience of a customer project, this presentation will detail all the nice features that Qt offers to build embedded applications.

We highly recommend this conference to European embedded Linux developers and hope to meet some of our readers there! We will be the guys behind the video cameras in the embedded rooms. It’s worth mentioning that ELCE attendees are also granted, for free, the right to access LinuxCon Europe talks.

Buildroot 2011.08 released!

2011-09-07T19:24:29+00:00

As promised by the time-based release schedule, a new version 2011.08 of Buildroot has just been released. For those just coming in, Buildroot is a utility that automates the process of building an embedded Linux system: generating a cross-compilation toolchain or importing an existing one, cross-compiling multiple user-space libraries or applications, generating a root filesystem image and building the kernel or bootloader images. We use it extensively at Free Electrons for various projects and therefore contribute regularly to this project.

The major highlights of this version are :

An updated version of udev. For a long time, Buildroot has been stuck with an ancient udev release, due to the slightly more complicated dependencies of newer udev versions. Fortunately, Yegor Yefremov and other contributors have done the work to integrate those dependencies and get a modern version of udev to work in Buildroot.
An updated version of util-linux has been integrated. Here as well, updating it wasn’t completely straightforward, due to utility libraries such as libuuid, which is also present and e2fsprogfs, and used by multiple other packages.
The conversion of the Linux kernel build process and the bootloaders build process to the GENTARGETS infrastructure of Buildroot. This makes the build process of the kernel and the bootloaders much more similar to regular packages, and allows to provide the capability of fetching kernel sources not only from tarballs over http/ftp, but also from Git or Subversion repositories.
The kernel build process has been extended to support Linux 3.x versions and also release candidates versions.
Some improvements for using Buildroot to generate systems for non-MMU targets
Some new packages have been added: acl, attr, ebtables, gnutls, inotify-tools, ipset, libargtable2, libiqrf, libmnl, libnspr, libnss, libroxml, libyaml, live555, mxml, orc, rsyslog, sredird, statserial, stunnel, ti-utils, uboot-tools, yajl, and many, many packages have been upgraded or fixed.

The amount of patches merged for this release (287) is almost identical to the number of patches for the past release (286), but the number of contributors has increased from 28 to 35. Generally speaking, we are seeing an increasing number of requests and contributions from users :

   143  Peter Korsgaard
    36  Thomas Petazzoni
    21  Sven Neumann
    13  Gustavo Zacarias
    13  Yegor Yefremov
     9  Maxime Ripard
     7  Yann E. MORIN
     4  Baruch Siach
     4  Daniel Mack
     4  Luca Ceresoli
     3  Jean-Christophe PLAGNIOL-VILLARD
     3  Thomas De Schampheleire
     2  Allan W. Nielsen
     2  Mike Williams
     2  Phil Edworthy
     2  Will Newton
     1  Arnout Vandecappelle (Essensium - Mind)
     1  Arnout Vandecappelle (Essensium/Mind)
     1  Benoit Mauduit
     1  Benoît Mauduit
     1  Daniel Hobi
     1  Daniel Nyström
     1  Danomi Mocelopolis
     1  Evgeni Dobrev
     1  Francis Mendes
     1  Frederic Bassaler
     1  Frederik Pasch
     1  H Hartley Sweeten
     1  Heiko Helmle
     1  Marek Belisko
     1  Michael J. Hammel
     1  Milton Soares Filho
     1  Philippe Reynes
     1  Robin Holt
     1  Tristan Lelong

Two developers from Free Electrons have contributed patches for this release: my colleague Maxime Ripard has contributed 9 patches (Python build fixes, toolchain configuration fix, new rsyslog package, rework of the logging init scripts, new stunnel package, /dev/shm fix for the initialization scripts, code cleanup) and I (Thomas Petazzoni) have contributed 36 patches (conversion of the kernel and bootloaders to the GENTARGETS infrastructure, support for Linux 3.x and release candidates, improvements for non-MMU targets, the new scons package, upgrade of valgrind, some other code cleanup and fixes).

For the next release, I expect to contribute a set of patches that has already been reviewed on the list, and which adds the possibility of building packages from an existing source directory instead of letting Buildroot handle the download/extract/patch part of the build process. This feature will make it much much easier to use Buildroot during the development of the kernel, an application or a library for the target embedded system. I have also posted patches that convert the documentation over to the asciidoc format and I intend to do various additions to this documentation.

It is also worth mentioning that the Buildroot developers (Peter Korsgaard and myself) and the Crosstool-NG maintainer Yann E. Morin are organizing a Developer Day on October, 29th in Prague, the day after the Embedded Linux Conference Europe. All developers or users interested in Buildroot and/or Crosstool-NG are invited to join. See http://lists.busybox.net/pipermail/buildroot/2011-August/045066.html for more details.