copyleft hardware planet

January 27, 2012

Open Hardware Repository

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

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

by Enrique García (egarcia@splendeo.es) at January 27, 2012 10:15 AM

January 26, 2012

Open Hardware Repository

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

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

by Javier Serrano at January 26, 2012 02:16 PM

Bunnie Studios

You Bought It, but Do You Own It?

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!

by bunnie at January 26, 2012 07:55 AM

January 25, 2012

Harald Welte

OP25 project joins hosting on osmocom.org

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.

January 25, 2012 01:00 AM

First osmo-nvs-gps evaluation boards soldered

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.

January 25, 2012 01:00 AM

January 24, 2012

Freetronics

Review of the DMD Dot Matrix Display by John Boxall

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

by Jonathan Oxer at January 24, 2012 10:58 AM

January 23, 2012

Open Hardware Repository

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

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.

by Erik van der Bij (Erik.van.der.Bij@cern.ch) at January 23, 2012 03:12 PM

Bunnie Studios

Name that Ware January 2012

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.

by bunnie at January 23, 2012 09:42 AM

Winner, Name that Ware December 2011

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!

by bunnie at January 23, 2012 09:41 AM

Geoffrey L. Barrows - DIY Drones

Detecting and locating lights using an Arduino and an image sensor

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

by Geoffrey L. Barrows at January 23, 2012 06:00 AM

January 21, 2012

Video Circuits

HEX at Space Studios

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









by Chris (noreply@blogger.com) at January 21, 2012 03:31 PM

Mark Adrian Bell

pyturtle

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

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.


by Mark Adrian Bell at January 21, 2012 06:59 AM

edubuntu

Edubuntu

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.


by Mark Adrian Bell at January 21, 2012 05:36 AM

January 20, 2012

Transmaterial

Flight Assembled Architecture

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.

by Blaine Brownell at January 20, 2012 03:00 PM

January 19, 2012

Free Electrons

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

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

by Michael Opdenacker at January 19, 2012 02:33 PM

Bunnie Studios

…and We’re Back

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!

by bunnie at January 19, 2012 06:20 AM

January 18, 2012

FabFi Wireless

Wifi and the Internet of Things

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


by noreply@blogger.com (Keith Berkoben) at January 18, 2012 05:24 PM

Open Hardware Repository

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

From: [mailto:] On Behalf Of Myriam Ayass
Sent: 18 January 2012 11:15
To:
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

by Erik van der Bij (Erik.van.der.Bij@cern.ch) at January 18, 2012 10:44 AM

FabFi Wireless

Development Kits Live!

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.

by noreply@blogger.com (Keith Berkoben) at January 18, 2012 04:31 AM

Liu Xiangfu, openmobilefree.net

Icarus mining report

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

by Xiangfu Liu at January 18, 2012 03:12 AM

January 17, 2012

Elphel

Live USB/CD/DVD

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

January 17, 2012 08:15 AM

Subpixel Registration and Distortion Measurement

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

January 17, 2012 08:15 AM

Video Circuits

Michael Matos CUSP



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

by Chris (noreply@blogger.com) at January 17, 2012 01:41 AM

Harald Welte

Having Fun with DHL Express!

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.

January 17, 2012 01:00 AM

January 16, 2012

Video Circuits

Old shots of Lucky PDF karaoke with Taki and Lucy

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

by Chris (noreply@blogger.com) at January 16, 2012 10:57 AM

Sync Generator + Encoder + Modular Synth = Video!

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.





by Chris (noreply@blogger.com) at January 16, 2012 10:38 AM

Bunnie Studios

NeTV Website

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.

by bunnie at January 16, 2012 09:54 AM

Open Hardware Repository

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

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)

by Erik van der Bij (Erik.van.der.Bij@cern.ch) at January 16, 2012 08:31 AM

January 15, 2012

Andrew Zonenberg, Silicon Exposed

First BGA board

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

by Andrew Zonenberg (noreply@blogger.com) at January 15, 2012 07:42 PM

January 14, 2012

Harald Welte

First assembled prototypes of osmo-e1-xcvr

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.

January 14, 2012 01:00 AM

January 13, 2012

Open Hardware Repository

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

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.

by Erik van der Bij (Erik.van.der.Bij@cern.ch) at January 13, 2012 09:51 AM

Freetronics

Arduino-driven Christmas light display

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:

by Jonathan Oxer at January 13, 2012 03:10 AM

January 12, 2012

LZX Industries

LZX Industries at NAMM 2012

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!

by elecktron at January 12, 2012 03:33 PM

osPID

A Note About Cost

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

by Brett at January 12, 2012 02:23 PM

January 11, 2012

Freetronics

The Maker Faire is coming to Melbourne!

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!

Maker Faire Melbourne

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.

by Jonathan Oxer at January 11, 2012 01:28 PM

January 10, 2012

Harald Welte

OsmoSDR status update

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.

January 10, 2012 01:00 AM

January 05, 2012

Open Hardware Repository

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

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

by Erik van der Bij (Erik.van.der.Bij@cern.ch) at January 05, 2012 04:14 PM

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

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.

by Erik van der Bij (Erik.van.der.Bij@cern.ch) at January 05, 2012 12:32 PM

January 04, 2012

Video Circuits

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

"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





HUGE thanks to youtuber toner for the tip off 

by Chris (noreply@blogger.com) at January 04, 2012 05:03 PM

Zedstar

TCR update

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.

by john at January 04, 2012 02:23 PM

January 03, 2012

osPID

Initial Release is Finally Here!

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)

by Brett at January 03, 2012 09:23 PM

Chitlesh Goorah

[FEL]: fritzing as new year gift

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 !

by Chitlesh at January 03, 2012 09:01 PM

January 02, 2012

Chitlesh Goorah

[FEL]: Fix for strange characters on Arduino Ethernet

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.


by Chitlesh at January 02, 2012 01:05 PM

January 01, 2012

Michele's GNSS blog

Processing Galileo PFM

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

by noreply@blogger.com (Michele Bavaro) at January 01, 2012 01:25 PM

December 31, 2011

Andrew Zonenberg, Silicon Exposed

SITREP - December 2011

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!

by Andrew Zonenberg (noreply@blogger.com) at December 31, 2011 11:10 PM

Multiple Lithography in Homemade PCBs

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.

by Andrew Zonenberg (noreply@blogger.com) at December 31, 2011 11:09 PM

FabFi Wireless

Fabfi In Domus Magazine

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!



by noreply@blogger.com (Keith Berkoben) at December 31, 2011 07:21 PM

OsmoSDR

OsmoSDR hardware verification at 28C3

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.

by laforge at December 31, 2011 02:51 PM

About OsmocomSDR

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

by laforge at December 31, 2011 02:44 PM

Video Circuits

Peter Donebauer "Entering" (1974)



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

by Chris (noreply@blogger.com) at December 31, 2011 04:26 AM

December 30, 2011

Video Circuits

Sabrina Ratté at Bubble Byte















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

by Chris (noreply@blogger.com) at December 30, 2011 12:13 PM

December 29, 2011

Bunnie Studios

Implementation of MITM Attack on HDCP-Secured Links

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.

by bunnie at December 29, 2011 09:11 PM

Transmaterial

Textures

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.

by Blaine Brownell at December 29, 2011 03:00 PM

December 27, 2011

Michele's GNSS blog

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

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

by noreply@blogger.com (Michele Bavaro) at December 27, 2011 07:19 AM

Crypto Stick

OpenSC/PKCS#11 driver development

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

by webmaster at December 27, 2011 12:43 AM

December 24, 2011

Liu Xiangfu, openmobilefree.net

Linux version usbboot for Ingenic xburst 4770

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

by Xiangfu Liu at December 24, 2011 08:23 AM

December 20, 2011

Fabricatorz

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

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.

by hypermodern at December 20, 2011 12:44 AM

December 19, 2011

Chitlesh Goorah

[FEL]: gplcver crash fix and openocd update

Shakthi updated gplcver to fix a crash upon launch.

Dean Glazeski updated openocd to 0.5.0.

 


by Chitlesh at December 19, 2011 09:31 PM

December 18, 2011

Chitlesh Goorah

[FEL]: Some minor updates

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.

by Chitlesh at December 18, 2011 03:04 PM

December 16, 2011

Geoffrey L. Barrows - DIY Drones

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

 

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

by Geoffrey L. Barrows at December 16, 2011 04:39 PM

Sebastien Bourdeauducq, lekernel.net

TDC core test results

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.

by lekernel at December 16, 2011 01:03 PM

December 15, 2011

Open Hardware Repository

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

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

by Enrique García (egarcia@splendeo.es) at December 15, 2011 09:25 AM

December 09, 2011

Transmaterial

Lunalite

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.

by Blaine Brownell at December 09, 2011 03:00 PM

December 08, 2011

Liu Xiangfu, openmobilefree.net

Copyleft FPGA board: Icarus

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.

IMG_1219_Icarus_case IMG_1221_Icarus Icars

by Xiangfu Liu at December 08, 2011 07:44 PM

Freetronics

New device: Hall Effect and Proximity Sensor Module

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.

by Jonathan Oxer at December 08, 2011 07:01 AM

TronixStuff review of our modules

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/

by Jonathan Oxer at December 08, 2011 05:37 AM

December 07, 2011

Open Hardware Repository

SPI Board Package - SPICONTROLLER second prototype delivered !

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.

by Yves-Marie ABIVEN (abiven@synchrotron-soleil.fr) at December 07, 2011 08:58 AM

December 06, 2011

Video Circuits

Warner Jepson

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

by Chris (noreply@blogger.com) at December 06, 2011 05:19 PM

Mirko Vogt, nanl.de

SwitchSmart!

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

by mirko at December 06, 2011 09:55 AM

Liu Xiangfu, openmobilefree.net

Naihanli’s crates and milkymist one

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:

IMG_1128_Intro IMG_1188_Media_wall IMG_1126_Chairs IMG_1141_technology_behind IMG_1176_Bar IMG_1177_Media_wall_2 IMG_1180_More_stuff IMG_1181_Chairs IMG_1194_Small_bar

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

by Xiangfu Liu at December 06, 2011 04:21 AM

December 05, 2011

Geoffrey L. Barrows - DIY Drones

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

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!

by Geoffrey L. Barrows at December 05, 2011 11:25 PM

Free Electrons

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

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.

by Thomas Petazzoni at December 05, 2011 08:56 PM

Freetronics

New device: Microphone Sound Input Module

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.

by Jonathan Oxer at December 05, 2011 03:08 AM

December 04, 2011

Free Electrons

Buildroot 2011.11 released: details on new features

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

or

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.

by Thomas Petazzoni at December 04, 2011 10:30 PM

Chitlesh Goorah

[FEL]: archimedes 2.0.0 stable release

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

 


by Chitlesh at December 04, 2011 01:31 PM

December 03, 2011

Chitlesh Goorah

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

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

by Chitlesh at December 03, 2011 07:36 PM

[FEL]: ngspice-23 stable release

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.

by Chitlesh at December 03, 2011 07:35 PM

Liu Xiangfu, openmobilefree.net

64bit and 32bit SDK/Toolchain for Ben Nanonote

你可以在这里找到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

by Xiangfu Liu at December 03, 2011 01:43 PM

Create xburst-tools Debian package under Ben Nanonote

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

by Xiangfu Liu at December 03, 2011 11:09 AM

Prepare Milkymist One for Nanhaili’s event

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:Screenshot-03-JJ at the end of the day we project the milkymist one performance to the wall just for fun :)

by Xiangfu Liu at December 03, 2011 11:09 AM

December 02, 2011

FabFi Wireless

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

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




by noreply@blogger.com (Keith Berkoben) at December 02, 2011 02:02 PM

Freetronics

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

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!

by Jonathan Oxer at December 02, 2011 02:25 AM

Geoffrey L. Barrows - DIY Drones

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

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

by Geoffrey L. Barrows at December 02, 2011 12:24 AM

December 01, 2011

Freetronics

New device: Addressable RGB LED Module

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.

by Jonathan Oxer at December 01, 2011 11:21 PM

Impromptu in-store Arduino display at Jaycar Newcastle

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.

by Jonathan Oxer at December 01, 2011 03:26 AM

New device: Sound and Buzzer Module

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.

by Jonathan Oxer at December 01, 2011 01:35 AM

November 29, 2011

Freetronics

New device: Humidity and Temperature Sensor

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.

by Jonathan Oxer at November 29, 2011 11:25 AM

New device: Shift Register / Expansion Module

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.

by Jonathan Oxer at November 29, 2011 10:59 AM

November 28, 2011

Freetronics

New device: Logic Level Converter Module

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.

by Jonathan Oxer at November 28, 2011 11:52 PM

New device: Light Sensor Module

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.

by Jonathan Oxer at November 28, 2011 11:40 PM

LZX Industries

New York Video Synthesis Workshop & Showcase

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

by elecktron at November 28, 2011 05:02 PM

Freetronics

Open 7400 Logic Competition prize pack winner

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.

by Jonathan Oxer at November 28, 2011 03:22 AM

November 26, 2011

Kristian Paul

GPS-SDR on the Milkymist (Update 2)

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

November 26, 2011 10:57 PM

Sebastien Bourdeauducq, lekernel.net

Observing internal FPGA signals

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:

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

  2. 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.
  3. Like above, but edit non-interactively. This is an experimental hack I’ve now implemented.

Read the rest from the Milkymist mailing list

by lekernel at November 26, 2011 03:33 PM

November 24, 2011

Open Hardware Repository

QDR II controller for Virtex 6 - QDRII memory controller core

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.

by Miguel Mendez Macias (mmendez@sevensols.com) at November 24, 2011 06:06 PM

Village Telco

Guest Post: Adapting Mesh Potatoes for Emergency Work

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

by steve at November 24, 2011 03:43 PM

Open Hardware Repository

ZIO - ZIO presented in the ht section

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

by Alessandro Rubini (rubini@gnudd.com) at November 24, 2011 03:05 PM

November 20, 2011

FreakLabs

Introducing the FredBoard and Mothership Hackermoms!

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

November 20, 2011 11:23 PM

November 18, 2011

Freetronics

Using Handbag with the USBDroid and Android

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

by Jonathan Oxer at November 18, 2011 02:41 AM

November 16, 2011

FreakLabs

chibiArduino v0.54 Release - Fixed Previous Broken Release

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

November 16, 2011 10:32 PM

November 15, 2011

Video Circuits

Video Transmitter Experiments

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  







































by Chris (noreply@blogger.com) at November 15, 2011 11:08 AM

Johnny Woods and Dpony VHS Movie/Album

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)













by Chris (noreply@blogger.com) at November 15, 2011 01:41 AM

November 14, 2011

Video Circuits

zenit

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/

by Chris (noreply@blogger.com) at November 14, 2011 09:29 AM

Altus Metrum

bdale's rocket blog: RF Immunity

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.

November 14, 2011 08:39 AM

November 13, 2011

Tuxbrain

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

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.

read more

by Victor Remolina at November 13, 2011 06:25 PM

November 07, 2011

Free Electrons

Embedded Linux Conference Europe 2011 videos

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 ZemlinVideo capture
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 McKenneyVideo capture
moderated by Lennart Poettering
Kernel Developer Panel
Video (55 minutes):
full HD (622M), 450×800 (191M)



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



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



Jessica ZhangVideo capture
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 UedaVideo capture
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 ZoresVideo capture
Alcatel-Lucent
Embedded Linux Optimization Techniques: How Not To Be Slow
Slides
Video (44 minutes):
full HD (328M), 450×800 (125M)


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


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



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



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


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



Vitaly WoolVideo capture
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 StewartVideo capture
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 KobayashiVideo capture
Kyoto Micro Computer
Android is NOT Just “Java on Linux”
Slides
Video (37 minutes):
full HD (542M), 450×800 (129M)


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


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


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


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


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



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



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



Laurent PinchartVideo capture
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 SripathyVideo capture
Texas Instuments
SOC Power Management – Debugging and Optimization Techniques
Video (41 minutes):
full HD (288M), 450×800 (108M)



Rafael J. WysockiVideo capture
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 HauerVideo capture
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 DerwigVideo capture
Synopsys
Android Platform Optimizations
Slides
Video (43 minutes):
full HD (266M), 450×800 (105M)


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


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


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


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


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



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


Tsugikazu ShibataVideo capture
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 LappalainenVideo capture
MontaVista Software
Secure Virtualization in Automotive
Video (40 minutes):
full HD (301M), 450×800 (116M)



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



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



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



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


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



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



Koen KooiVideo capture
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 ThierryVideo capture
Grsecurity in Embedded Linux Used in Android Operating System
Slides
Video (40 minutes):
full HD (384M), 450×800 (110M)



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


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



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


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


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



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



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


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



by Thomas Petazzoni at November 07, 2011 06:31 AM

November 05, 2011

Free Electrons

Report from the Buildroot Developer Day

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.

by Thomas Petazzoni at November 05, 2011 01:34 PM

November 04, 2011

Video Circuits

Maplin Magazine Dec 1995

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

by Chris (noreply@blogger.com) at November 04, 2011 12:45 PM

Vortexya Video Kaleidoscope

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

by Chris (noreply@blogger.com) at November 04, 2011 12:18 PM

November 03, 2011

Free Electrons

Back from Embedded Linux Conference Europe 2011

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.

Prague

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

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)

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.

by Thomas Petazzoni at November 03, 2011 08:51 AM

November 02, 2011

Freetronics

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

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!

by Jonathan Oxer at November 02, 2011 11:44 PM

The Freetronics forum goes live

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!

by Jonathan Oxer at November 02, 2011 09:19 AM

October 31, 2011

Fabricatorz

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

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

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

Robin Peckham announces the launch of Saamlung, a new gallery and project office for Hong Kong.
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!

by hypermodern at October 31, 2011 11:47 PM

October 30, 2011

Freetronics

Welcome to our new Californian reseller, EpicTinker

EpicTinker

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.

by Jonathan Oxer at October 30, 2011 10:04 PM

October 28, 2011

Moxie Processor

Using the Altera USB-Blaster on Fedora

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?

by green at October 28, 2011 09:14 PM

October 21, 2011

Freetronics

Combining the LCD & Keypad Shield and the USBDroid

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

by Jonathan Oxer at October 21, 2011 11:34 AM

October 19, 2011

Freetronics

Bruce Perens to keynote LCA2012

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/

by Jonathan Oxer at October 19, 2011 11:48 PM

October 18, 2011

Village Telco

Mesh Potatoes now FCC and CE Approved

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.

 

by steve at October 18, 2011 12:35 PM

Freetronics

First look: EtherMega production samples

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.

by Jonathan Oxer at October 18, 2011 11:15 AM

October 17, 2011

Kristian Paul

First atempt to listen weather satellites

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

October 17, 2011 05:59 PM

October 16, 2011

Freetronics

"State of Electronics" documentary preview

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.

by Jonathan Oxer at October 16, 2011 10:37 AM

October 15, 2011

Freetronics

Trinity: I need LEDs. Lots of LEDs

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!

by Jonathan Oxer at October 15, 2011 01:04 PM

October 13, 2011

Mirko Vogt, nanl.de

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

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!

by mirko at October 13, 2011 10:27 AM

Liu Xiangfu, openmobilefree.net

reflash D-LINK DIR-300 back to original firmware

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 

by Xiangfu Liu at October 13, 2011 09:25 AM

October 12, 2011

Moxie Processor

Fake RAM, load/store and push

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.

by green at October 12, 2011 03:00 AM

October 09, 2011

GNSS-SDR

Source code for acquisition and tracking algorithms of GLONASS L3 signals

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.

October 09, 2011 06:05 PM

Freetronics

New product: AM3X 3-axis accelerometer module

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!

by Jonathan Oxer at October 09, 2011 08:54 AM

October 07, 2011

Video Circuits

Infermental 4 at Chisenhale

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




by Chris (noreply@blogger.com) at October 07, 2011 01:12 AM

October 03, 2011

Video Circuits

Trees Fall Live 9-17-11

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

by Chris (noreply@blogger.com) at October 03, 2011 02:35 PM

September 29, 2011

Dan Reetz

DOES IT TURN PAGES?

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:

by danreetz at September 29, 2011 04:49 PM

Altus Metrum

bdale's rocket blog: AltOS 1.0.2 Released

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.

September 29, 2011 04:29 PM

September 28, 2011

Qi Hardware

News Release: VJing Made So Simple Anyone Can Do It

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)

by Qi team at September 28, 2011 03:00 PM

September 27, 2011

Tuxbrain

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


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:

read more

by David Samblas at September 27, 2011 07:01 PM

September 24, 2011

GNSS-SDR

All source code is moving to Google Code

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;

September 24, 2011 08:26 AM

September 21, 2011

Freetronics

Order #600 has shipped, so it's free

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!

by Jonathan Oxer at September 21, 2011 04:37 AM

September 16, 2011

Freetronics

Local US stock at reseller Kineteka Systems

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!

by Jonathan Oxer at September 16, 2011 12:21 AM

September 13, 2011

Crypto Stick

Introduction

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

by webmaster at September 13, 2011 02:11 PM

September 12, 2011

Geoffrey L. Barrows - DIY Drones

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

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.

 

by Geoffrey L. Barrows at September 12, 2011 02:17 PM

September 10, 2011

Video Circuits

John Foxx



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 





by Chris (noreply@blogger.com) at September 10, 2011 04:21 PM

September 07, 2011

Free Electrons

Free Electrons at Embedded Linux Conference Europe 2011

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.

ELCE 2011

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.

by Thomas Petazzoni at September 07, 2011 07:46 PM

Buildroot 2011.08 released!

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

by Thomas Petazzoni at September 07, 2011 07:24 PM

Geoffrey L. Barrows - DIY Drones

Chip design, open source, and DIY: Part 2, open source issues

Above: Concept for an "abstract layout" workflow that could reconcile open source circuit designs with "closed" process design rules and libraries. First the designer would generate an abstract layout by instancing cells for various components. The above example shows a 2-input AND gate, with one input pulled to ground with a 10k resistor, and a tri-state buffer as an output. The designer would instance these cells, and then route connections between them. The designer would also place cells corresponding to "pads" at the periphery of the chip. The designer would not need to know the exact layout of the cell interiors- this may be kept "closed" even while the abstract layer itself is "open". This abstract layout may then be converted to a full detailed layout that may be used by a foundry to fabricate the chip.

Introduction

This is the second part of a three-part blog posting on chip design and how to reconcile it with the open source and DIY movements. Previously in Part 1, I gave a top level summary of “indie chip design” as I experience it. In this part I will discuss the real issues I would face if trying to “open” up a chip design. There are three areas to consider: the CAD design tools themselves, the design rules for a particular chip fab process, and design libraries.

First a few definitions: The term “foundry” refers to a company that performs the actual chip fabrication. The term “process” refers to a particular fabrication line of a foundry. A foundry may have several processes including ones optimized for digital circuity and others designed for analog. Typically a foundry will have several grades of processes, with more expensive ones having more capabilities or a smaller feature size. The term “design tools” refers to the CAD tools that one may use to design a chip (analogous to Eagle for PCBs). The term “design rules” refers to specifications such as minimum width, spacing, and other requirements for the different layers.

Chip Design Tools: Open source versions do exist!

First I present some good news- Open source chip design tools do exist. One of the most prominent versions is Magic, which was created in the mid 1980’s and has gone through multiple revisions as late as 2008. I personally used versions 6.4 and 6.5 for all of Centeye’s chip designs from 2001 through 2004, including designs with up to 400,000 transistors. Magic is somewhat derided by many chip designers because it automates the generation of some layers and restricts you to purely Manhattan geometries e.g. no diagonal features. However in practice these restrictions affect only a minority of overall chip designs and do not cost much in terms of layout space. Magic has a real-time design rule verifier- you will know pretty much right away if your layout has violated a design rule. I found this useful when first learning chip design. Magic is also able to create CIF and GDSII files, the chip design equivalent of Gerbers used for PCBs.

Magic was originally designed to run on Unix and Linux operating systems, but it has more recently been ported to Windows (using Cygwin) and is maintained here at Open Circuit Design. Unfortunately it appears that recent development efforts have slowed, so I am not sure if Magic is as actively used as in the past.

Other open source layout tools exist as well, for example Electric. There is also a free, but not open source, tool called Lasi (pronounced “lazy”).

For circuit verification there are also free circuit simulators, most notably the venerable SPICE.

Commercial chip design tools exist as well (if you have the money...)

There are a number of commercial design tools available as well. I now use Tanner Tools, while others (with more resources) may use Cadence or Synopsys. The cost of Tanner Tools is within reach for a small company (on the order of the price of a new car- depreciation is my friend!) but is out of reach for most hobbyists. The other latter tools can cost, as far as I know, a upwards to a million dollars per seat, but allow wide-scale cooperation between large teams of designers.

As for why I switched from Magic to Tanner- Around 2005 we were migrating to a new foundry and process and were anticipating designing more complicated chips, so I felt the need for something “professional”. Tanner Tools has worked very well for us. However- and this would be a good story for another post- we succumbed to “complexity creep”, thus producing complicated (and headache inducing) designs, but later reversed course, so that now are designs are more minimalist again. I could go back to Magic, however since I now have the Tanner and have built up my own libraries within it, it is easier stay with Tanner. There are also other issues, which will be discussed next.

The bad news: Design rules, setup files, and design kits are generally not open.

As I see it, the biggest issue preventing bringing open source to the chip design rule is not the design tools themselves, but the design rules! The design rules on a PCB are relatively easy to set up and for programs like Eagle are freely available. They are also easy to understand. For chips, however, the design rules are generally treated as proprietary by the foundry. This is because the design rules contain information that describes the capabilities of a process, and the foundries don’t want that information freely disclosed without restrictions. Yes- I had to sign NDAs to get the design rules for all of the processes we use now! Similarly, the “setup files” that design tools use to configure a design program for designing chips for a particular process are also generally treated as proprietary by the company that sells the tools.

The same applies to the “design kits” themselves- these are basically library files that contain cells for different subcircuits you may want to use in a chip design. This includes cells such as gates, flip flops, or basic analog components. This also includes essential cells such as the “pads” that allow a chip to be interfaced with the outside world.

And this, folks, is why we cannot open source our chip designs- I would be violating all the NDAs I had signed with these companies! The most I could do (which I have already done in one case) is to release a schematic of the chip, in PDF form, that contains details on the circuits I had designed, and then “black boxes” for anything that came from a design kit.

Overall the trend seems to be for new advances to be made in the “closed” world, with open design tools and design kits being increasingly obscure and obsolete.

Is there a workaround?

I can see two possible workarounds. One method is, in fact, a workaround that has been used in the past and (I believe) is still available to an extent. The other is one that comes to my mind. Both would require some level of cooperation from the chip foundry.

Workaround #1: Use simplified, genericized design rules

During 2000 through 2004 when I was using Magic, I also used the MOSIS service for chip fabrications. MOSIS is effectively a brokerage service that places different designs from different people onto the same wafer, thus allowing everyone to share the tooling costs. (I’ll talk more about that in Part 3 of these posts.) When using MOSIS, you had the option of using either the design rules from the foundry (requiring an NDA), or you could use more generic design rules that MOSIS set up and made freely available.

The MOSIS rules had the advantage of being a bit more transparent and easy to understand. Also a design made for one process could be fabricated on any process that supports the same design rules. However they had several weaknesses- First, designs made using these rules are not a compact as they would be using the native foundry rules. In practice this penalty would be small, on the order of a few percent at most. Second, the MOSIS rules may not allow you to use all the features that a particular foundry or process supports. Third, the MOSIS rules are compatible with only a few processes- A look at the MOSIS website reveals that these rules are usable with two foundries. If you are willing to be constrained to just these two foundries (and both are good!), and if you don’t need some exotic unsupported feature, for most designs this approach will work.

The same concept used to make these MOSIS design rules can be applied to other foundries. The only barrier is obtaining the cooperation of the foundry, who may not want details of their process revealed openly or simply may not want to spend resources supporting an additional set of design rules.

Workaround #2: Use an intermediate abstract layout

The second workaround would be to set up an abstract design layer that is more detailed than “schematic” but less than that of “layout”. I envision something like what is depicted on the top of this post- A designer would create an abstract “layout” that instances cells such as gates, pads, or individual discrete components. Each of these cells would have a number of known “ports”, including power/ground lines, inputs, and outputs. For example an “AND2” gate may have two power ports (ground and power), two digital inputs, and one digital output, while a capacitor or resistor may have just two ports. Some cells, of course, would be the pads that allow the chip to be connected to the rest of the world.

The designer would not need to know the specific layout of these cells or even their exact circuit diagram, but would need to know enough to use them in a design. The designer would instead have several page (or more) datasheet describing everything needed to use that cell. For example, it might be known that the AND2 gate requires 5ns to settle and can source up to 10uA of current, or that a specific capacitor cell holds 1pF but has 0.1pF of parasitic capacitance at one node. The designer could then create an abstract layout by dropping these cells at various locations on the chip, much like a PCB designer places “parts” on a circuit board layout. The designer could then draw the wires to connect the components together. Such a design tool could have autorouting features. The design tool would then perform basic design rule checks.

Once the design is complete, this abstract level design file would be exported and sent to either the foundry or a “middle man”. The foundry or middle man would then be responsible for generating the final layout files from the abstract layout. Finally, the foundry could fabricate the chip.

The disadvantage of this approach is that the design is still only “partially open”. However at least the abstract layout could be made “open” and freely shared or released with appropriate open source licenses as desired.

There would be another benefit to this approach- The workflow would be more similar to that of making a PCB, in both the steps taken and the complexity. This approach would make chip design more accessible to a “casual” chip designer.

In my next post, I will discuss economic issues associated with chip fabrication.

by Geoffrey L. Barrows at September 07, 2011 08:00 PM

August 31, 2011

GNU Radio Blog

Howto receive and decode NOAA APT images with the Funcube Dongle and Gqrx

NOAA-18 APT receptionOne of the great advantages of software defined radio receivers is that tuning receiver settings is a matter of adjusting software parameters. Gqrx is no different here and has optimal settings built in for weather satellite reception. This tutorial describes how to receive automatic picture transmissions (APT) from NOAA weather satellites using Gqrx SDR, record them to a WAV file, and finally decode the images using the free and open source Atpdec decoder. If you follow this guide you can end up with very nice results such as the one shown at the end.

I have used the Funcube Dongle with an Arrow antenna for this example but any receiver hardware supported by Gqrx can be used, provided that it can receive the required bandwidth, which is around 40 kHz.

Step 1: Reception and recording

NOAA APT transmissions are analog transmissions. The data coming from the imaging sensors is used to amplitude modulate a 2.4 kHz sub-carrier, which is then used to FM modulate the VHF carrier at 137.x MHz. The FM deviation is 17 kHz and using the Carson bandwidth rule we get a channel bandwidth of

BW = 2 × (17 + 2.4) kHz = 38.8 kHz

Hence the requirement for 40 kHz bandwidth. In fact, a few kHz more will not hurt but allow to track the signal during the whole pass without any active Doppler tuning.

The Funcube Dongle uses 96 ksps sample rate and has an effective bandwidth of 80 kHz. Thus there is just about enough bandwidth to have the APT signal on one side and avoid interference from the DC spike, which can not be completely eliminated at these frequencies.

NOAA-18 APT reception

Start by tuning the FCD PLL to 23 kHz above or below the satellite frequency. For example, NOAA-18 transmits on 137.9125 MHz and I tuned the FCD to 137.935 MHz. Then tune the channel filter so that the RX frequency will correspond to the satellite frequency (see the Gqrx screenshot above).

In the demodulator options select FM with 17k deviation and disable de-emphasis by setting the filter time constant tau to 0.

When the satellite comes in range, start the audio recorder by pressing the red dot in the Audio settings. Note that the red dot in the toolbar is the I/Q data recorder – we don't need that here.

Watch video on YouTube.

As you can see I have very good signal above; about 20 dB C/N when the satellite is close to the horizon and almost 40 dB C/N at the time of closest approach. The recording was made in a relatively quiet area and I had LNA gain reduced to 10 dB.

Don't forget to stop the audio recorder when the pass finishes, otherwise the WAV file will have corrupt header.

Note that Doppler tuning is not necessary as long as the channel filter is wide enough. This is an advantage (maybe the only advantage?) of FM modulation: The Doppler shift will be seen as a moving DC offset in the audio but the audio amplitude, which is the important parameter for APT, will not be influenced. This assumes that the audio level is sufficiently below the maximum level, otherwise a DC shift will saturate and clip the samples. You may have to experiment with the settings before you find the optimal volume; however, the -15 dB audio gain I am using will probably also work for you.

Step 2: Convert the recorded audio

Gqrx records audio WAV files at 48 kHz. We need to convert it to 11.025 kHz WAV. If you have a favorite conversion program just do it your way. I often import the WAV file into Audacity where I can also cut any noise from the beginning and the end. In audacity you need to use Track → Resample, then also change the project rate from 48 to 11.025 kHz (maybe it is sufficient to change the project rate?). When finished export the audio to a new WAV file.

In case you end up with a corrupt WAV file (gqrx is in testing phase ;-) you can still use VLC or Sox to resample it.

Step 3: Decode image from audio recording

Now that we have an 11.025 kHz WAV file we can use Atpdec to decode the APT image from it. The latest stable version is 1.7 from 2005, but it appears to be sufficient and is easy to build compared to the latest code in the CVS repository. If you read the README file you'll see that it requires libsndfile and libpng to compile. All of these are pretty standard and available for all Linux. Remember that we need the -dev or -devel packages when compiling against libraries, i.e. libsndfile-dev or libsndfile-devel.

The README file also contains necessary information about the usage of atpdec. I have used

  atpdec -s 18 -i ab recording.wav

but you can of course use whatever you wish. Note that NOAA-19 is not included in Atpdec version 1.7, for that you will need the latest version from CVS. At the time of writing, the code in CVS does not compile for me.

Step 4: Enjoy and experiment

Below you can see an image I received from NOAA-18 on August 28, 2011. As mentioned above, I used the Funcube Dongle and a simple Arrow antenna.

NOAA-18 APT image received with Gqrx and Funcube Dongle

Once you have mastered basic reception, you should start experimenting with the receiver settings. I would also be interested to see scripts / hacks that perform automatic recording and decoding. I guess that will be easier once I implement the scheduler in gqrx.

In any case, I hope you'll have fun with this area of space communications!

by oz9aec@gmail.com (Alexandru Csete) at August 31, 2011 07:17 PM

August 30, 2011

Video Circuits

Arduino Video Experimenter Shield

Here is a new video interface for the Arduino link here 















"The Video Experimenter shield is an Arduino shield that lets you do all kinds of experiments with video.
Overlay text and graphics onto a video signal from a camera, DVR, DVD player, VCR or any other source of composite video.
Capture low-res video image frames for display or video processing. Give your Arduino the gift of sight!
Perform object detection for computer vision projects.
Decode closed captioning or XDS (extended data services) data embedded in television broadcasts.
Works with NTSC (North America) or PAL (rest of the world) television standards.
Uses digital pins 2, 6, 7, 8, and optionally 9. Uses analog pin 2."

by Chris (noreply@blogger.com) at August 30, 2011 10:08 AM

August 28, 2011

Liu Xiangfu, openmobilefree.net

loop beep after install ubuntu 11.04 on Macbook

Yesterday, after I install ubuntu 11.04 on my macbook, everytime the macbook powerup, there a big loud and long beep,  10 times sleep light flicker,  screen go to blank in next minute, then system continue boot. I found the new ubuntu 11.04 is using a grub-efi, not like before install the grub on /dev/sd5(for example), I guess it’s grub-efi problem, I switched to grub-pc and install it on /dev/sda5, ubuntu can not boot anymore by rEFI :( . try to google about this long beep,  found one command in Mac system fix this problem.

Quote From Links
Download the EFI Firmware update from Apple, unpack the package (e.g. with unpkg) and locate the Firmware in the correspoding app. Or you use the existing app in /Applications/Utilities if you happen to have it already. As I needed to reflash a Unibody MacBook 5,1 (Late ’08), I downloaded the package for it (MB51.007D.003 (EFI 1.3)), unpkged it and located my firmware in the app (MacBook EFI Firmware Update.app/Contents/MB51_007D_03B_LOCKED.scap). This is very important!! One needs to make sure to flash the correct version!!! Else bad things WILL happen! Then open a terminal and use bless (That command is one line and yes, -firmware is an undocumented feature):

xiangfu@macboot:~$ sudo bless -mount / -firmware /Applications/Utilities/MacBook EFI Firmware Update.app/Contents/MB51_007D_03B_LOCKED.scap

Again: BE VERY CAREFUL TO USE THE RIGHT VERSION!!! THIS CAN BRICK YOUR DEVICE!!!

Then shutdown and continue with the default firmware flash procedure for your device (e.g.: Unibody MacBook 5,1 – 1.3 EFI Firmware).
And that’s all folks. The Mac should reboot, flash the firmware and everybody’s happy again. It worked for me like a charm, but ymmv.

Links:
http://pubmem.wordpress.com/2011/04/09/flash-efi-firmware-update-manually-on-a-macbook-51/
http://support.apple.com/kb/HT3260
http://support.apple.com/kb/HT1237
http://ubuntuforums.org/showthread.php?t=1743800

by Xiangfu Liu at August 28, 2011 05:07 AM

August 25, 2011

Geoffrey L. Barrows - DIY Drones

Chip design, open source, and DIY: Part 1, Indie chip design

Above: Simple circuit using a transistor (an N-channel MOSFET), a resistor, and a capacitor. Left shows the schematic, right shows the layout.

Following discussions from a previous post here, I’m writing a three-part blog post on chip design, as I experience it professionally, and how I see it relating to both the open source community and the DIY crowd. This first post will discuss the chip design process itself. I am going to focus on what could be called “indie chip design” as it may be executed by a small company or even a single person. Obviously I can’t explain how to design the next hot microcontroller in a single blog post, but you should get a flavor for how this process is similar to and different from, say, designing a printed circuit board (PCB).

First a little background- I work in a small company Centeye that makes image sensor chips for various embedded vision and robotic applications. These designs incorporate both digital and analog circuitry, including pixel circuits, on the same chip. Due to our size (and budget!) we favor a minimalist approach to these image sensors. The chips themselves typically have anywhere from a thousand to at most several million transistors and are simple enough in architecture that one person (e.g. me) can handle the whole design. Our chips are three to six orders of magnitude simpler (by transistor count) than a contemporary processor or GPU chip, which currently contain up to several billion transistors.

The “complexity” of any design is an important consideration. Consider how much the complexity of a PCB can vary. At one end you have a 10-plus layer state-of-the-art computer motherboard. At the other end you can have a single layer PCB that uses a basic Atmel and a few discrete parts to blink an LED. Both of these are “circuit boards”, but one can be designed by a single person in a fraction of an hour while the other requires specialized (e.g. expensive) software and a team of engineers putting in person-years of effort. The design methodologies are certainly different for each board- You can take a cowboy approach and “wing it” when designing the blinking LED board. But the computer motherboard requires careful and rigorous preliminary research, planning, and coordination between the designers. Now I don’t want to imply that I design chips with a cowboy approach (well not usually) but the simplicity of our designs allows for different methodologies than what are needed for, say, designing a new GPU.

 

The PCB design process

As a starting point, that more people here would be familiar with, let’s first consider the PCB design process that one might follow if using a set of tools like Eagle. You might follow these steps:

Specification: Decide what you want to make. Decide some basic components to include (e.g. what processor to use or other desired components). Decide the interface, for example how you power and “talk to” the board if there is an I/O aspect.

Sketching and Research: Sketch out different sections of the board schematic (on paper or with Eagle), read datasheets, and determine what exact components you need. (For example- what voltage regulators do you need, what caps / resistors do those regulators need, and so on.)

Schematic Entry: Enter the schematic diagram.

Board Layout: Place components in desired locations, and then route, route, route to make all the desired electrical connections between them.

Verification: Run design rule checks. You need to verify, for example, that routed wires are thick enough, that unconnected wires are not too close together, and that no routing is too close to the board's edge or to holes. Run electrical rule checks to make sure that you didn’t accidentally connect two nodes that should be separate.

Fabricate: Generate the Gerbers and get the board made.

Populate: Solder components to the board. When done, power it up and test it.

Depending on the board, you may do some of the above steps in parallel and/or repeat earlier steps if you find some problem with the design, for example if the components don’t fit in a desired space.

 

Chip layout vs. PCB layout

The most fundamental way that chip design is different from PCB design is in the purpose of the layout. For PCBs, the "layers" of the layout define the electrical connections between the different components that will be soldered to the board. Some layers define etched copper patterns to form "wires", while other layers define “vias” for electrical contact between layers.

For an example of chip layout, look at the photo on the top of this post for details. On a chip layout, some layers are similarly used to form such electrical connections. Generally these are the “metal” layers with a low resistance, and are often made on the actual chip with aluminum or copper. This appears as "blue" in the above layout. There are also “via” and “contact” layers defining similar connections between layers, visible above as black squares.

However there are other layers that are used to actually form devices when geometric objects are drawn according to well-defined rules. When designing a chip, you not only draw the wiring between transistors, capacitors, and resistors, but you also draw those transistors, capacitors, and resistors themselves.

For example, there is one red layer called “polysilicon” which is a conductor but generally has a higher resistance. If you draw a long, thin wire of polysilicon, you get a resistor. (A long thin wire of metal also gives you a resistor but of much less resistance.) To form a capacitor, you can draw two plates of polysilicon on top of each other, with one plate located on “polysilicon 1” (light red) which is deeper in the chip and the other plate located higher up on “polysilicon 2 (dark red)”. They will be separated by a thin insulator, so that the two plates and insulator form a capacitor. A transistor (such as a MOSFET) can be formed by crossing a polysilicon wire over a box of “active” layer (green). I won’t describe all the possibilities- that could fill a textbooks- but hopefully you get the basic idea.

In other words, the fundamental difference is that on a PCB, the geometric figures you draw define the electrical connections between components, while on a chip, the geometric figures also create the components themselves.

As you can imagine, the “design rule checks” for chips are much more complicated. Fortunately all that is now automated.

 

Cells

A chip design generally uses a hierarchical structure based on what we call “cells”. A basic cell may be an OR gate, a single capacitor, or a single pixel circuit. Then we can create higher level cells by “instancing” and connecting together existing lower level cells, and optionally adding new layout. For example, a pixel cell may contain a couple transistors and a photodiode, and routing for power line and output. Then a pixel array cell can be constructed from a large 2D array of individual pixel cells. Similarly a flip flop cell can be constructed from a few gates, and a register cell can be constructed from an array of flip flop cells. The “top level cell” would be the whole chip.

This hierarchical structure is analogous to the hierarchical structure of a computer program. You have variables and individual instructions at the bottom level, then lower level functions that use these variables and instructions, higher level functions that call these lower level functions, and finally the “main” function at the top.

In a chip design, the cell structure is present in both the schematic level and the layout. Consider a pixel cell: In the schematic entry software I use, elementary cells like “capacitor”, “resistor”, and “N-type transistor” are already defined. The pictures below show examples. To make a pixel cell I would instance the appropriate components (generally some transistors and a photodiode), draw wires to connect them, and create a “symbol” that represents the pixel cell. Then I would create an associated layout for the cell. This would be a drawing of the different layers (metal, polysilicon, active layer, etc.) that together create the electronic circuitry depicted in the schematic.

Once I have created a cell, I would next “verify” it. This includes running design rule checks such as making sure wires are thick enough and that unconnected wires are not too close (sound familiar?). This also includes other more esoteric design rule checks such as making sure the different layers are properly drawn to form devices like transistors and capacitors. I also run a “layout vs schematic” test to make sure that both the schematic and layout versions of the cell show the same circuit. If needed, I may also perform a circuit simulation (using SPICE) to verify that the circuit should function as I intend. In the SPICE simulation I would present different inputs to the circuit and verify that the simulated output is as expected. For example for a NOT gate I would apply a digital 0 and then 1 and verify that the output was the opposite. I would also verify that the threshold voltage (the crossover from 0 to 1) is appropriate.

Once a cell has been completed, I can then construct and verify higher level cells in the same manner. For example I could create a pixel array by instancing individual pixel cells. I would verify the pixel array cell and move on to the next cells until the chip is finished.

One nice thing about the cell architecture is that once a cell is made, you can reuse it in other chip designs, either verbatim or with some changes. This is much like how you can re-use existing source code to write a new program. Also it is possible to acquire libraries of cells for many common circuits- I never design my own flip flop cells- I used existing flip flop cells that either the CAD tool company or the chip foundry has provided- I not only save time but have the peace of mind of using a cell that I know works.

This ability to reuse cell designs is crucial for reducing design time. My record for designing a chip, start to finish, is three hours sitting in a Dupont Circle coffee house in DC back in 2001. All of the cells were reused, with one or two modified, except for the top level cell which was constructed from scratch. (Yes, that chip did work!)

The three pictures below show sample layout and schematic of pixel cells.

Above: Layout of a single pixel cell. "blue" is the lowest metal layer e.g. metal1, "grey" is the second metal layer e.g. metal2, tan is the third metal layer e.g. metal3. White squares are "vias" between metal layers. The big area with right-hand cross hatches is the "N" side of the photodiode. The "P" side is the chip substrate itself.

Above: Schematic diagram of a single pixel circuit. Node "rowsel" is used to select a row of pixels. Node "out" is the column output. Nodes "prsupply" and "swvdd" are effectively power supplies for the pixel.

 

 

Above: 16x16 array of single pixel circuits used to form a 16x16 focal plane array section.

 

The Indie chip design process:

Now I can summarize the process I use to design a new image sensor chip:

Specification: Typically I would hand draw a few critical items in my notebook. This may be the schematic diagram for individual pixel circuits or related subcircuits. This would also include a specification of the interface, such as how I want the digital signals provided to the chip to control the chip, and the nature of the output (analog, digital, etc.)

Sketching and Research: Next I would sketch out a cell hierarchy for the chip, including initial hand-drawn schematic sketches for the most critical cells and how they interact. I would also look through existing designs and libraries for cells that I can reuse and/or modify.

Design the chip, cell by cell: Next I would go through the process of designing the cells that will make up the chip design. I would start out with the basic cells, construct both layout and corresponding schematic and symbols, and do any verification. Generally I would both create and verify a given cell before moving up the hierarchy.

Redesign: Sometimes it just happens that through the process of designing it you realize that something may not work or fit. In this case you just have to go back and change some aspect of the design.

Padframe: The padframe is a cell that contains all the “pads” which are the electrical contacts between the chip and the outside world.

Top level cell: I would then assemble and verify the top level cell of the chip.

Tape-out and Fab: The term “tape-out” is the chip design equivalent to making Gerber files for a PCB. I think this is an archaic term that comes from a time when the layout files were literally written to magnetic tape that was then mailed out to the fab company. Nowadays of course you just create the layout file and email it in.

Dicing and Packaging: The chips come back in wafers (see this previous post). We send them out to a company to dice them e.g. cut them up into individual dies. Packaging refers to the process of connecting the individual dies to some sort of package that allows you to solder them to a board. You can’t solder directly to the chip (the pads are between 60 and 100 microns wide!) so typically one uses a wire bonding machine to connect the chip to a package with 1-mil thick gold wire. We own a wire bonding machine so we just wire bond the chips directly to a test PC board, in a process described here. Once this is done we can then test the chip to verify it works.

Cost? For a single chip design I’ve spent anywhere from $980 to $58k to get multiple (between 4 and 40) copies of a single chip design made. For wafers I’ve spent anywhere from about $18k to just under $100k to get multiple wafers containing multiple chip designs made, generally yielding four to eight thousand chips. (Note that for a fine-scale digital process used to make current GPUs or CPUs, you can probably spend millions.) As you make more the price drops further. The economies of scale are drastic. I will comment on that in another post.

Time? You can get PCBs made the same day if you really need it. For chips I wait anywhere from 6 weeks to 4 months. Yes, the long wait can make one nervous…

 

Simplicity and avoiding feature creep

A final thought on the chip design process as I experience it- Simplicity rules! The final part of verifying a chip design is stressful since you really can’t fully verify the chip design, including how the individual cells interact, until you actually fabricate the chip. (Actually for digital circuits the behavior is generally predictable if you use the right practices, but analog circuits are more complicated.) The best I can do until then is to rely on circuit simulations of a limited set of scenarios, along with double, triple, and quadruple checking, and hope that the resulting design works.

So as a result of this, I’ve found that the best habit to have is to be very choosy about what features to include and keep all aspects of the chip (interface, layout, topology, etc.) as simple as possible. The simpler the chip, the easier the layout and the verification, and the less opportunity you have to screw things up! The 80/20 principle is key here- Only include what is necessary. This can be a challenge because we engineers are notorious for saying “hey we can add this feature, and while we’re at it add that one and this other one too”.

In my next post, I'll discuss issues the real issues I face when trying to "open" up chip designs, and how these may be addressed.

by Geoffrey L. Barrows at August 25, 2011 12:39 AM

August 22, 2011

Video Circuits

Richard's Video Synth Jam mk2

 Yesterday I visited Richard's house (one of the few video synth guys in the UK) to see his system again, test some stuff and talk about building my own system based on his designs for more info on his system see here ---> synth-punk

We captured some low quality video from my capture device that I'm sure will find it's way online at sompoint on his blog but for now here are some even lower-quality snaps from my archaic antediluvian mobile phone. Sorry about the quality :(

we also played with some feedback using Richard's genlockable CCTV camera
his system is fantastic fun to play with!







by Chris (noreply@blogger.com) at August 22, 2011 03:07 AM

August 19, 2011

Zedstar

The Clashing Rocks

This project is about using embedded Linux devices to detect, record and react to seismic events. The idea is to use accelerometers to detect shaking and then communicate this event to all other devices connected to the same broadcast group. We are developing the technology using OpenWrt which allows us to use a range of hardware including routers and pocket computing devices. We really like the idea of exploring emerging low-powered, low-bandwidth mesh networks in developing countries. In this video you can see some early work using a network of Ben NanoNote computers fitted with WPAN hardware. Three devices are connected to a Spread daemon running on a co-ordinating device. Because our current hardware lacks accelerometers we run a program on one device to send fake accelerometer data onto the network. Each device should then pick up this data across our wireless network. We are currently able to get some basic support for IP networking using a hack by Werner Almesberger who also developed the WPAN hardware.  In the video you can see the devices display a bar graph indicating it received data. Only one bar is registered as only one device is transmitting. This bar graph could act as a finger print for deciding the scale of seismic activity in a larger network. We intend to add some more intelligence to this part by building a some kind of knowledge system. Currently the project is at a very early stage with some basic infrastructure developed in C. The aim is to extend this infrastructure by embedding GNU Guile. This will allow us to dynamically control how we communicate, store and process the structured data shared amongst devices. Part of this system will involve trying to minimise the quantity of structured data exchanged on the network by serialising to bit-level using Packedobjects.

Further details of the project can be found at The Clashing Rocks wiki.

by john at August 19, 2011 11:22 PM

August 10, 2011

Geoffrey L. Barrows - DIY Drones

New Image Sensor Chips for Robotics and Embedded Vision

I just got back some new silicon! These are the latest image sensor chips I designed specifically for robotics and embedded vision applications. The pictures above show a full wafer followed by a close-up of the wafer from an angle. There are four chips in each reticle- if you look closely you can see them packed into a rectangle (about 8.8mm by 7.0mm). Shortly after that picture was taken, we had the wafer diced up into individual chips and started playing with them!

One of the chips is named “Stonyman” and is a 112 x 112 image sensor with logarithmic-response pixels and in-pixel binning. You can short together MxN blocks (M and N independently selected from 1, 2, 4, or 8) of pixels to implement bigger pixels and quickly read out the image at a lower resolution if desired. The interface is extremely simple- there are five digital lines that you pulse in the proper sequence to configure and operate the chip, and a single analog output holding the pixel value. With two power lines (GND and VDD) only eight connections are necessary to use this chip.

Another chip is named “Hawksbill” and is a 136 x 136 image sensor, also with logarithmic response pixels (but no binning) and the same interface as Stonyman. What is different about Hawksbill is that the pixels are arranged in a hexagonal format, rather than a square format like Stonyman and 99% of other image sensors out there. Hexagonal sampling is not conventional, but it is actually mathematically superior to square sampling, and with recent advances in signal processing one can perform many image processing operations more efficiently in a hexagonal array than a square one.

(Above: 8x8 hex pixel layout from CAD tools, Stonyman chip wire bonded to test board- pardon the dust!)

We plan to release the chips in the near future, with a datasheet, sample Arduino script, and (yes!) a schematic diagram of the chip innards. (If anyone *really* wants one now, I can make an arrangement…)

We are also working on a new generation ArduEye sensor shield with these chips. The shield will be matched to an Arduino Mini for small size, and use a 120MIPS ARM for intermediary processing. The design will be “open”, of course. (Note- anyone who purchased an original ArduEye will get a credit towards the purchase of the new version when it comes out.)

(The thrill of getting new chips back is much like that for circuit boards. You designed it, so in theory you know how it works. But you are never 100% sure and there is no datasheet for you to consult other than your own notes or CAD drawings. You are always slightly afraid of getting a puff of smoke when you first power it. No smoke… the circuit breaker didn’t trigger… so all is good. Then you probe it, verify that different portions work as expected, tweak various settings, and finally get it working. The experience is just like that for a PCB except the stakes are higher.)

by Geoffrey L. Barrows at August 10, 2011 01:56 AM

August 08, 2011

Qi Hardware

Copyleft Hardware News 2011-08-08

Qi News
RSS Twitter

ME 382 LockedUpTechnology2.gif

Copying is an act of love. Please copy & share.
Mimi and Eunice by Nina Paley

Buy

Join the new era of computing, slow fidelity on the freedom channel, and buy the world's best copyleft hardware

Product Starting At Shipping
Ben NanoNote 99 USD/EUR Tuxbrain for Europe
Sharism for US/Japan/others
atben-atusb Combo 59 EUR Tuxbrain
Elphel 353 880 USD Elphel
Elphel Eyesis 24,000 USD Elphel

Projects

Homebrew CMOS and MEMS foundry

The Nyan Cat head at 100x zoom. The entire cat is around 600 microns long and 360 microns high.
The Nyan Cat head at 400x zoom. Pixels are 20 microns square.
The Nyan Cat in the Toped IC layout editor.

Milkymist

  • Xiangfu Liu made recordings of four Milkymist One patches.
Philpraxis-Eight bit starfield.fnp.ogv
Starfield
[57 s, 6.5 MB, download]
Illusion & Che - The Piper.fnp.ogv
The Piper
[1:10 min, 12.42 MB, download]
Telek - Slow Shift Matrix (bb4.5).fnp.ogv
Slow Shift Matrix
[1:8 min, 15.28 MB, download]
Unchained - A Matter Of Taste (Remix).fnp.ogv
A Matter of Taste
[1:10 min, 22.53 MB, download]
  • Lars-Peter Clausen and Michael Walle improved Linux 3.0 on Milkymist One. [1]
  • Lars-Peter Clausen ported an OpenWrt userland to Milkymist One, with static linking and uClibc. [2]
  • Xiangfu Liu setup daily builds of OpenWrt for Milkymist One. [3]
  • Lattice Semiconductor released version 3.8 of the Mico32 core, which among small fixes comes with a major cleanup of the licensing header at the top of every source file.
    Earlier licensing headers were hard to understand and got some people to doubt the openess of the core. The new headers make the Mico32 core indisputably open source and GPL compatible. Lattice Download Comparison of old and new licensing header
  • Christopher Adams designed a new Milkymist logo and selected the free Orbitron font for logo and branding.
    roh from Raumfahrtagentur engraved a mirror version of the new logo on the inside of the top acrylic for the upcoming RC3 run.
Milkymist One logo on acrylic.
  • Yi Zhang finished the Milkymist One box design and sent it off to the box makers.
PDF file sent to the printshop, prepared from a Scribus original.
Printed and die-cut box.
Thirteen wires in and out of Milkymist One during production testing.
  • Wolfson Microelectronics' WM9707 audio codec helped reduce audio noise on the Milkymist One RC3 video synthesizer by 90%, from about 500 mV to about 50 mV.
    Earlier runs used a National Semiconductor LM4550B codec. [4]
  • Cristian Paul ported the Namuru GPS correlator to the Milkymist SoC (thanks to Fabrizio Tapper and Peter Mumford for their support).
    This core will allow speedup of the correlation process for getting a fix and tracking GPS satellites. Work continues on the OpenSourceGPS receiver which will provide the high level software interface to process the navigation data tracked by Namuru. Namuru port to Milkymist, Namuru datasheet, OpenSourceGPS code repository, OpenSourceGPS documentation
  • David Kühling helped port the SoftGNSS matlab code to GNU Octave.
    This will allow offline analysis of raw data for a variety of GPS front-ends. SoftGNSS repo
  • Jon Phillips gave a talk about Milkymist One at FISL 12 in Porto Alegre, Brazil (slides of talk below). [5] [6]
Fisl12 rejon milkymist 20110702.ogv
Jon Phillips at FISL 12 (July 2, 2011, Porto Alegre, Brazil).
[46:17 min, 78 MB, download]

atben/atusb

  • Werner finished designing the ben-wpan boards, a set of IEEE 802.15.4 wireless dongles. [7]
Range of ben-wpan boards measured at Werner's apartment in Buenos Aires (dimensions in cm).
  • Werner wrote documentation and tools for the production and testing process of ben-wpan 802.15.4 boards.
    A total of five pages, overview page and four detail pages. Announcement Overview
Production and testing process flowchart.
Atusb-programming.jpg
David depanelizing PCBs
atben
atusb

Copyleft Hardware Explained

  • Werner Almesberger published a two part comparison of Free scripted CAD tools - Part 1, Part2.
OpenCSG, showing artefacts
OpenSCAD, modeling artefact (internal structure)
OpenSCAD, modeling artefact (reversed face)
  • The names of component packages are often confusing and vary among manufacturers. This is Werner's first step (for small logic gates) towards a packageology.
  • Some data sheets don't contain all the information necessary to make Copyleft Hardware. Here is Werner's anatomy of a datasheet.

NanoNote

  • Jadon Dutra made two nice Ben NanoNote tutorial videos. [8]
Jadon NanoNote Hello world tutorial scaledown.ogv
Tutorial: Hello World program on Ben NanoNote.
[5:43 min, download 11 MB/52 MB]
Jadon NanoNote USB booting scaledown.ogv
Tutorial: How to boot Ben NanoNote into USB mode.
[2:23 min, download 5 MB/38 MB]
Ben NanoNote test point map, SoC mappings here
  • sujan and zedstar took some NanoNotes on a trip to Nepal. We don't really know what happened, but got this nice picture back...
Ben NanoNote in Nepal

OpenLase

Openlase.ogv
OpenLase laser projector.
[2:17 min, 20 MB, download]
OpenLase prototype used in making the video.
Detail of galvo (Galvanometer).

Presentations, Slides, Brochures

Jon,Werner and Sebastien talked about our projects, here's an opportunity to catch up and browse through slide decks, presentations, and a brochure.


Jon's slide deck on Milkymist One

(announcement, video)

Qi-hardware-milkymist-converted.svg

Jon's slide deck on Copyleft Hardware

(announcement)

Qi-hardware-basics-outlines.svg

Werner's talk at FISL 12 in Porto Alegre about Copyleft Hardware

(source FISL 12 in Porto Alegre, Brazil)

Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf
Fisl12.pdf


Sebastien's talk at THSF 2011 in Toulouse about Milkymist One

(source THSF 2011 Toulouse Hacker Space Factory, May 28, 2011)

Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf
Mm thsf.pdf


Sebastien's Milkymist One brochure

(source [10])

M1 brochure v2 100dpi.pdf
M1 brochure v2 100dpi.pdf
M1 brochure v2 100dpi.pdf
M1 brochure v2 100dpi.pdf

A happy continued summer everyone (winter for Werner). Cheers.

--Qi team 08:00, 8 August 2011 (CET)

by Qi team at August 08, 2011 08:00 AM

August 02, 2011

GNU Radio Blog

Gqrx on Mac OS X (almost)

Few weeks ago, or maybe a month or two – I don't remember, I spent an afternoon trying to build gnuradio-core and gr-audio on Mac OS X without using any macports. It was a casual an undocumented attempt that resulted in a compilation failure. I wasn't surprised because I made several mistakes along the way, so I just left it an moved on.

Now with the alpha release of gqrx it was time to make another attempt, and this time I tried to do it right I have also documented the whole process. It took me few hours to get through the whole process of compiling the dependencies then GNU Radio, but to my great surprise I actually ended up with a working GNU Radio installation!

I even managed to build and run gqrx as you can see on this twitpic. Since that tweet I even found out that I can simply use the descriptive names as device names, i.e. "FUNcube Dongle V1.0" for the Funcube Dongle. Unfortunately, the OS X audio source seems to have issues with sample rates above 44.1 kHz which makes the gqrx/fcd combination useless for now. The issue is known and has actually been known since 2009.

I hope somebody will be able to fix it because I really don't know anything about OS X audio programming and looking at the source code for the OS X audio source doesn't make me want to learn it either.

by oz9aec@gmail.com (Alexandru Csete) at August 02, 2011 09:35 PM

July 22, 2011

Freetronics

Half way to 1000: our 500th retail order ships

 Earlier today we received our 500th retail order, which came in from Daniel in Tennessee, USA. Daniel ordered an EtherTen and a 5-pack of the ProtoShield Basic, and because we ship every 100th retail order free it's all shipped out to him at no charge! Congratulations Daniel. We'd love to hear what you build with your new toys.

500 retail orders shipped is a milestone for us so we're really excited about it.

by Jonathan Oxer at July 22, 2011 03:33 AM

July 19, 2011

Freetronics

New version of the Receiver Shield arrives

The new v3 revision of the 433MHz Receiver Shield from Practical Arduino has arrived! The first couple of versions of the shield were surprisingly popular but there were some things about the design that annoyed me, so this version totally rearranges the receiver module and supporting parts to leave more of the prototyping area clear and allow the shield to be stackable.


It includes an antenna and comes fully assembled except for the headers, which are supplied in the package so you can solder them in place. We supply stackable headers but you can use regular male break-away headers if you prefer.

But wait, there's more. We now have it available in two different frequency versions so you can choose the model that suits your requirements. There's still the 433MHz version, but now you can get a 315MHz version as well. In future we're hoping to add a 915MHz version when the receiver modules become available.

Oh yes, and we even dropped the price. We're producing hardware in such large quantities now that we're getting good economies of scale, so the new Receiver Shield is just AUD$29.95 inc GST! Check it out:

by Jonathan Oxer at July 19, 2011 05:53 AM

July 10, 2011

Chitlesh Goorah

Swiss wine tasting

Got the opportunity to taste the following Swiss wines :

  • Aigle, Vieux coucou, Grand Cru, 2010
  • Aigle, Peau Rouge, Grand Cru, 2010
  • Aigle, Gamaret, Evionnaz,2010
  • Aigle, Pinor noir de Chamoson, 2008
  • Yvorne, Le Florin, sélection Terravin
  • Chablais, Malvoisie
  • Chablais, Oeil-de-Perdrix
  • Ollon, Pinot Noir
  • Ollon, Rosé de Pinot Noir

by Chitlesh at July 10, 2011 07:06 PM

July 03, 2011

Chitlesh Goorah

the missing -ldl

export CFLAGS="%{optflags} -ldl -lpthread"

to fix

/usr/bin/ld: dynload.o: undefined reference to symbol  'dlsym@@GLIBC_2.2.5'
/usr/bin/ld: note: 'dlsym@@GLIBC_2.2.5' is defined in DSO
/lib64/libdl.so.2 so try adding it to the linker command line
/lib64/libdl.so.2: could not read symbols: Invalid operation
collect2: ld returned 1 exit status


by Chitlesh at July 03, 2011 01:09 PM

July 01, 2011

Free Electrons

uClibc 0.9.32 released, with NPTL support

A little bit more than one year after 0.9.31, the uClibc project has recently released a new version of the famous C library, uClibc 0.9.32. For the record, uClibc is an alternative standard C library for embedded Linux systems, which features a smaller size than the usual glibc or eglibc, a high-level of configurability and support for non-MMU architectures. uClibc usage is mandatory on non-MMU architectures running a Linux kernel since the traditional glibc or eglibc do not support non-MMU architectures. On architectures with MMU, uClibc may also be interesting for its reduced size, and has been used in a large number of systems over the last years.

The 0.9.32 release brings one major new feature : the support of the Native Posix Threads Library for the most common architectures (ARM, MIPS, PowerPC, x86, x86_64, SuperH and SuperH 64). NPTL is a different way of implementing the pthread userspace API than the one previously used in Linux, called LinuxThreads. The kernel mechanisms needed to implement NPTL have been added in 2.6 and support in glibc has been added a long time ago. uClibc was lagging behind in this area, and the new release fills this gap. This feature does not bring any visible API change, but completely changes the internal implementation of the threading mechanism, with better performance and a behavior that is more similar to the one we have on glibc based hosts. For more details about the differences about NPTL and LinuxThreads, one can check Ulrich Drepper and Ingo Molnar’s paper on this topic: NPTL Design paper.

Another new feature of the 0.9.32 release is support for the C6x architecture, which is a DSP architecture from Texas Instruments, capable of running a Linux kernel (see http://linux-c6x.org). Having upstream support in uClibc allows this architecture to benefit from a nice standard C library.

by Thomas Petazzoni at July 01, 2011 04:18 AM

June 30, 2011

Free Electrons

Buildroot 2011.05 released

Buildroot logoAs expected with the time-based releases, Buildroot 2011.05 has been released just a few days ago. We have already published many blog posts about Buildroot, but to summarize for our new readers, Buildroot is a tool that automates and simplifies the process of building an embedded Linux system. You define your system configuration and components in a menuconfig/xconfig interface similar to the one the kernel uses, then hit make, wait a bit, and you have your embedded Linux system ready to run on your device. At Free Electrons, we appreciate the simplicity of Buildroot, and many of our customers also appreciate it for the same reason. Of course, we also contribute significantly to Buildroot and we have started a commercial support offering on Buildroot.

The 2011.05 release

The 2011.05 release cycle was a little bit more quiet than usual, so the number of new features or major changes is not as large as it was for past releases. Amongst the interesting things:

  • Until now, Buildroot was only capable of building systems using a static /dev, in which device files are statically listed in a device table and created at system build time. The 2011.05 has added a configuration option to select how the /dev directory on the target should be handled. It can be handled in four different ways:
    • with a static /dev, just as before
    • with just devtmpfs. It allows to have a dynamic /dev without any other userspace components, which is really nice.
    • with devtmpfs and mdev. In addition to having a dynamic /dev, it allows allows to execute arbitrary scripts when device are added/removed and to customize the owner, group and permissions for the device files.
    • with devtmpfs and udev. This is the full solution, as used in desktop distributions.
  • There has been an internal infrastructure change on support for external toolchains, and this change will make those toolchains slightly easier to use. In Buildroot terminology, an external toolchain is a toolchain that hasn’t been built by Buildroot, but which Buildroot uses to compile code for the target platform. It allows to re-use existing toolchains such as the CodeSourcery toolchains, or toolchains generated externally with Crosstool-NG. To support those toolchains, we rely on the sysroot mechanism that the GCC compiler provides since the 4.x era. This mechanism allows Buildroot to make a complete copy of the C library binaries, C library headers and kernel headers into a staging directory, and then tell the toolchain utility (compiler, linker, etc.) to use this new directory as their sysroot. This means that a --sysroot option needs to be passed at every invocation of those tools. As this was not very convenient, especially to use the Buildroot toolchain as a SDK to build applications not packaged in Buildroot, the 2011.05 has added wrappers for the toolchain tools, which makes this completely transparent. So one can now just use $(O)/host/usr/bin/arm-linux-gcc as usual, and it will do the right thing.
  • A few new packages have been added: bonnie++ (a block device benchmark), can-utils (userspace utilities for the famous industrial CAN bus), gdisk (a sort of fdisk program, but for the new GPT partition table format), htop (a nice top alternative to watch the activity of processes), input-event-daemon (a simple daemon that executes arbitrary command in reaction to input events), libexif (a library to read the contents of EXIF tags in pictures), libraw (a library to decode pictures in various RAW formats), libv4l (the library to interact with Video4Linux devices), ngircd (an IRC server).
  • Many packages have been upgraded: the Gtk stack, the U-Boot and Barebox bootloaders and the internal toolchain components (gcc and uClibc), with experimental gcc 4.6 support.

Buildroot in the Linux Journal

Linux Journal 206 CoverThe Linux Journal has published an issue, numbered 206, dedicated to Embedded Linux. This issue has several articles around Embedded Linux related topics:

  • Hexapod, a Linux powered robot
  • Debugging Embedded Linux platforms with Python and GDB
  • Breaking free the Gumstix DSP
  • Speech I/O for Embedded Applications
  • CyanogenMod 7.0, Gingerbread in the house
  • Tiny Core Linux
  • Roll your own Embedded Linux System with Buildroot, written by Alexander Sirotkin, which gives a good introduction to what Buildroot is and how to use it.

It is great to see articles about Buildroot in a such widely read magazine, and it should definitely help increasing the awareness about this build system.

Linux Journal 206 Table of ContentsLinux Journal 206 Buildroot

Buildroot used by Fabrice Bellard in jslinux

In May, the famous developer Fabrice Bellard (known as the initial author of ffmpeg, qemu, but also for his records for the computation of pi) has released an impressive new project: an x86 emulator completely written in Javascript, which runs in a Web browser. This emulator is sufficiently capable and powerful to boot a Linux system. And the good news is that the Linux system that Fabrice Bellard is using for the demonstration was generated with Buildroot, as Bellard says in his technical notes about the project.

by Thomas Petazzoni at June 30, 2011 08:37 PM

June 29, 2011

Free Electrons

Embedded Linux training: switch to the IGEPv2 board

Since early 2009, our training sessions have been using the USB-A9263 from Calao Systems as the hardware platform for the practical labs. However, this AT91-based platform was getting older, and we therefore started the process of switching our training sessions to a new hardware platform, the IGEPv2 board from ISEE.

IGEPv2 board

IGEPv2 board


The IGEPv2 platform is very similar to the popular BeagleBoard and BeagleBoard-XM platforms, and has the following technical characteristics :

  • TI DM3730, which is the latest OMAP3 processor from Texas Instruments, clocked at 1 Ghz, and including a DSP for signal processing, an IVA block for audio/video decoding and the PowerVR SGX for 3D/OpenGL. This processor offers far more possibilities than the AT91 one, especially for multimedia applications.
  • 512 MB of RAM and 512 MB of OneNAND flash.
  • Integrated Ethernet connector, Wifi and Bluetooth connectivity.
  • One USB OTG port and one USB host port.
  • A microSD connector.
  • A DVI-D connector (HDMI), stereo input and ouput
  • RS232 connector
  • Multiple expansion ports to access LCD, camera, I2C, SPI, JTAG, etc. signals

Compared to the BeagleBoard-XM, this board has the following advantages:

  • it has a OneNAND Flash device, which allows us to demonstrate and practice the usage of MTD and Linux flash-specific filesystems such as JFFS2 and UBIFS in our training sessions. Even though block-based storage such as SD and eMMC is more and more popular in consumer-electronic devices, usage of raw NAND flash is still very common in industrial applications, and we therefore wanted to keep presenting those devices and their usage in embedded Linux
  • ISEE, the company manufacturing the IGEPv2, is located in Spain, which makes it easier for us to regularly order boards from them, since we are also located in Europe
  • the board provides Bluetooth and Wifi connectivity, which is nice

We have already given two sessions of our Embedded Linux system development training with the IGEPv2, and all our future sessions of this training will use this hardware platform, so the participants will benefit from a more modern platform, with far more capabilities than our previous AT91-based training hardware. This is also the board we are now giving to the participants to our public training sessions, so those participants come back home with a very nice and powerful platform which allows countless experiments around embedded Linux. Note that we also intend to port our Embedded Linux kernel and driver development training session to the IGEPv2 platform in the near future.

by Thomas Petazzoni at June 29, 2011 02:07 PM

June 19, 2011

Chitlesh Goorah

Restoring Electronics-menu in Gnome3

With Gnome 3 shipped with Fedora 15, the menu “electronics” is no longer available on Fedora 15′s gnome-menu.

It was rather annoying for me, as this custom “Electronics” menu remained the first thing that non-linux users would look at if they want to embrace Free(Fedora) Electronic Lab.

Finally, I found how to fix it. It seems that the directory /etc/xdg/menus/application-merged became /etc/xdg/menus/application-gnome-merged.

$ mkdir  /etc/xdg/menus/applications-gnome-merged
$ ln -s /etc/xdg/menus/applications-merged/electronics.menu /etc/xdg/menus/applications-gnome-merged/electronics.menu

The “electronics-menu” package will soon be updated to reflect this fix on Fedora 15.


by Chitlesh at June 19, 2011 11:01 AM

June 16, 2011

Village Telco

SPUD – Simple Unified Dashboard for mesh networks

IT46 have been hard at work and have just made the first public release of SPUD (Simple Unified Dashboard), a wireless mesh network visualisation tool for BATMAN mesh networks and its users.

SPUD is a PHP based dashboard that communicates with the BATMAN visualization server and displays real time wireless link status. The software is written in CakePHP (a PHP-based MVC framework) and uses Google Maps API 1.3 for visualization.

SPUD is designed to be as simple as possible to use, and to enable teams, that have installed large amount of mesh nodes, to visualize their networks quickly.

Some of the core features of SPUD are:

  • Client management: Bulk import of clients from CSV file, Edit client position with Google Maps, Tracking of new clients
  • Link monitoring: Easy overview of active wireless links, Mesh quality in each direction of a wireless link
  • Customization: Colours and threshold values for link quality

See above and below for screenshots that shows some of the functionality of SPUD.  The source code is available via SVN at

svn co http://dev.villagetelco.org/svn/villagetelco/spud/trunk/

and the default configuration will monitor our demo site in Bo Kaap (Cape Town)

Detailed installation instructions are available at

http://spud.it46.se/spud/install (user: vt-admin pass: ouagadougou) or http://dev.villagetelco.org/trac/wiki/spud_install

We have set up a demo site of SPUD that visualizes the Bo Kaap network. The demo is available at: http://spud.it46.se/spud . Please feel free to play with it, and provide us your feedback!

by aep at June 16, 2011 08:41 PM

June 15, 2011

Dan Reetz

How To Start A Truck With A Can Opener

Or, “The utter uselessness of car alarms”.

Sequence of events:
1. Key fob for my car alarm dies, I am about 1 mile from home, in Richmond, CA, in the Iron Triangle.
2. I walk to RadioShack (also 1-2 miles away) and buy battery replacement.
3. Replacement battery does not work. Can’t open door without setting off alarm.
4. I walk home and make 12V battery pack. Fob works, door opens, once. Stops working. Can’t start truck.
5. Determine key fob is borked. No spare, because my keys were stolen a week ago. RICHMOND!!!
6. Open door and set off car alarm.
7. Get angry. Convert anger to cool ruthlessness. Open hood and disconnect battery with Leatherman. Cut wires to obnoxious speaker.
8. Disassemble dash with Leatherman.
9. Cut wire ties supporting car alarm. Remove wires from car alarm.
10. Reconnect battery.
11. Pull off white and red/white striped wires (labeled “starter”&”starter motor”).
12. Connect wires with can opener.
13. Depress clutch (clutch has starter switch)
14. Truck starts.
15. Buy small “adapter” that connects two wires. Connect wires.
16. VICTORY!!!!!!!!!!!!!!!!!!!!!! Thanks, little can opener:

These can openers have quite a history of being used in interesting ways. My Dad gave me one when I was just a little kid – explained its usage and let me put it on my keychain (which mostly contained useless old keys). Over the next 20 years or so I found it useful all over the place. I’ve used it to remove screws, open cans, cut tape, start fires, and now, to hotwire my truck. Thanks, Dad! Too bad the one you gave me was stolen with all my other keys AND my spare fob. But lucky that I’d purchased a dozen more for gifts.

A few lessons here.
1. Car alarms are useless. Now that I’ve done this, I could disable most aftermarket car alarms and start many cars in a matter of minutes.
2. Having only one key fob is the same as having no key fob.
3. Having a multitool in your pocket at all times is not paranoia, it is good policy.
4. The P38 can opener is a profoundly useful thing.

EDIT: While driving to buy some bolt cutters, I realized that the connection I made with the can opener is the correct place to put a kill switch in for the starter. I might also put in a fuel pump kill switch somewhere.

by danreetz at June 15, 2011 08:39 PM

June 11, 2011

Dan Strother

Complete "Cones" disparity map generated by dlsc_stereobm reference algorithm

The first version of my open-source OpenCV-compatible FPGA Stereo Correspondence Core is now available! (have a look at my previous FPGA Stereo Vision Project post for some more context) It’s written purely in synthesizable Verilog, and uses device-agnostic inference for … Continue reading

by Dan at June 11, 2011 06:26 AM

June 09, 2011

Capn's Tech

Playpause 2: Making PCBs at home

For a long time, I've wanted to make PCBs at home.


In the past, I used to make my own electronics project using stripboard and perfboard. This is reliable, if not slow. But a stripboard design doesn't really lend itself to being constructed by others.

In the past year I've started working with surface mounted devices. SMD doesn't work very well on stripboard, so it becomes not just desirable but necessary to make PCBs. I have put off learning how to do it for a long time, but a month or so ago, I finally got the time to give it a go. This article covers what I currently do, and I'm writing about it here in the hope it will help others.

There are three main ways of making circuit boards at home. The first is via the “toner transfer” method. I have tried that in the past, but never been able to reliably make a circuit board greater than about a square inch: I've always had a lot of trouble getting the toner 100% fused to the PCB without cracking or smudging.

The second is by using a CNC mill to mill away undesired copper, leaving copper tracks. With the imminent completion of the CNC mill at our hackerspace, or if I one day build a CNC mill using components salvaged from old DVD drives, that might be a possibility. However for the moment I don't have access to a CNC mill, so I can't use that method.

The third is the photographic method. With this method, a special copper-clad PCB is covered by a film of UV-sensitive dye. Exposing the dye to ultraviolet light through artwork printed on transparent paper will leave some regions of dye exposed, and some regions unexposed. A developer chemical will remove the exposed areas, leaving the dye in the form of green tracks on the board. Then the board is etched in a chemical etchant, which removes the copper which is not protected by the dye. Finally, the dye is removed, leaving copper tracks.

In this article I'll show how to use the photographic method, although I might try the toner transfer and CNC methods again in the future.

The UV-sensitive PCB stock I'm using is sold by Kinsten, and is available in single- and doubled-sided variants. Here is the Kinsten PCB, plus the developer (Kinsten DP-50), etchant (ammonium persulphate), and a scrubbing pad:

Kinsten, etchant, developer and scrubber

In order to generate the UV light, I made an exposer box using nearly 100 UV LEDs. For an enclosure, I cut up and resized a cardboard box. The box is lined with aluminium foil to reflect light towards the board I'm exposing, and the light has to travel through two diffusers of transparent paper.

Here's a picture of the LED array:

Exposer's UV array, LED side


And here's a picture of how I wired up the LEDs:

Exposer's UV array, wiring side

(The two halves are wired differently because the second board is somewhat smaller than the first board, and wouldn't allow the straight-forward row-and-column arrangement I used on the first board).

The specifications for the LEDs say the forward voltage is about 3V. The wiring of the boards configures the LEDs into many parallel strings of four LEDs. I power the exposer with a 12V power supply. I have adjusted the trimpot on the power supply to get a voltage that gives me a current of 25mA through each LED. The LEDs do get quite warm after running for a while. Here's a picture of the exposer working:

Exposer powered up showing UV


NOTE: The LEDs produce a bluish-purple light, but this is not ultraviolet, it's a consequence of the spectrum from the LEDs being spread out somewhat. Our eyes cannot perceive ultraviolet light, yet it is harmful to our eyes. If you are working with ultraviolet light, try to limit how much UV gets into your eyes, or you may have to bear gritty and sore eyes for a few days. UV filtering sunglasses might be a good idea.

I print the artwork for the board on tracing paper I bought from the newsagent. I print it with a laser printer, and in the printer settings dialog I set the density to be as dark as possible. I usually print right-way-around on normal paper to verify that all the parts fit the board, then I print on the transparency in reverse. If I used a normal printout, there'd be a layer of transparency between the toner and the dye. This can cause blurring, as the UV light can diffuse to under the artwork. Mirroring the image means the toner can be right up against the dye.

Tracing paper with artwork


A few weeks ago when I first started this exercise, I didn't know how long to do the UV exposure for. I made some board artwork of ten TQFP-32 footprints in a row, with some lines of different thicknesses. I put the artwork and the PCB on the exposer with a piece of cardboard. Every fifteen seconds I slid the cardboard across by one TQFP, so that by the time two minutes and thirty seconds had elapsed, I had a row of footprints that had been exposed for various times, from 0:15 to 2:30. When I later developed the exposed PCB, what I found was that for my exposer, no pattern emerged until an exposure time of 2:00, and by 2:30 the pattern had developed very nicely. I have since made PCBs with exposure times of 3:00 to 3:30, and they have turned out very nicely.

Some people I've spoken to said I wouldn't be able to reliably make the 0.016” tracks I was hoping for. The good news is that tracks down to 0.010” come out just perfectly, and tracks down to 0.008” (0.2mm) appear very achievable. I think the biggest limiting factor is the quality of the artwork: I can trace small irregularities in the finished PCB to slight imperfections in the artwork, either because of dust or because there is a small hole in the toner. It seems that the toner binds to some places on the transparency better than others.

When doing the exposure, you need some way to keep the artwork flat against the PCB. I use a glass-topped coffee table. I tape the exposer to the bottom side of the coffee table, and put the artwork and PCB on top, held down by a heavy book. I always clean the glass with glass cleaner before doing the exposure.

The dye on the Kinsten PCB is protected by a white plastic film. Just before exposing, I peel off the film, revealing the blue-green dye. I do the exposing well away from the window, as otherwise ultraviolet from the sun may spoil the exposure.

I don't have a picture of a PCB being exposed, because when I'm doing the exposure, I have my hands full with holding the exposer and watching the exposure time.

At the end of the exposure time, I cover the PCB to prevent stray UV light from damaging the exposure. If you look carefully, you should be able to see the pattern of tracks as a very faint yellow hue on the blue-green dye. If you can't see it, it might indicate an exposure problem.

Here I'm developing the board in developer solution:

Developing Playpause boards in developer solution


This is 15g of Kinsten DP-50 developer, in 250ml of water. The developer doesn't have to be hot or warm, but having it warm speeds things up a little. While exposing the boards, I rock the container from side to side. As the exposed dye comes off, it makes patterns in the water like smoke.

Here are the boards after they have been developed. I wash them in water, then dry them, being careful not to scratch the ink.

Developed boards


Now it's time to etch the boards. There are three main chemicals hobbyists use to etch boards. In order of how often they're used, they are ferric chloride, ammonium persulphate, and a mixture of hydrochloric acid and peroxide bleach. Each method has advantages and disadvantages:

Method Advantages Disadvantages
Ferric chloride Etches at room temperature. Horrid yellowy-brown colour stains everything it comes in contact with. Best done outside using things you'll never use again.
Ammonium persulphate Does not stain. Easy to tell how much copper the solution contains, and therefore whether the solution is still ok. Only etches at 60-70ºC and above. Can be a bit fiddly to get the right concentration.
HCl/H2O2 Can be recharged by bubbling air through it with an aquarium pump, which means less chemicals to buy, and less to dispose of. Two rather nasty corrosive chemicals, so care must be taken.


There is a lot of information about making circuit boards on the Internet. For example, here's an interesting article about using just a tablespoon of ferric chloride per board. There is also lots of information on the various techniques here.

I have been using ammonium persulphate, which needs to be kept hot in order for it to work. I put the etchant in a foam ice-cream container, and heat it in the microwave until I can just see vapour. (You don't want to do this too long, as you probably don't want a film of ammonium persulphate eating away the metal parts of your microwave). The foam of the container helps keep the etchant hotter for longer, although it will probably not stay hot enough for the 5-10 minutes needed to etch the board. So, bad boy that I am, I admit to re-heating the etchant in the microwave, even with the PCB in the etchant. I haven't heard any of the arcing that usually happens if you microwave a dish that accidentally has a bit of aluminium foil in it.

Anyway, here's a pic of the etch in progress:

Etching boards. Blue is copper ions


I etch the boards for long enough that large blank areas of the board have completely lost their copper, but not so long that the etchant has had time to start undercutting the tracks of my circuit. After etching, I wash the boards in cold water.

When you are finished, you will have a container of etchant. If you are a cheapskate hobbyist like me, you can save the etchant in a bottle for next time. The etchant is generally good for a couple of boards, depending on how much etchant there is, and the size of the boards you've etched. But there will come a time (for ammonium sulphate, this is when the solution has become such a dark blue that you don't think it could become any bluer) when you have to dispose of the etchant. The problem is that copper ions are an environmental toxin. Apart from taking the etchant to your local waste disposal centre, one idea is to use a paintbrush to paint the etchant onto newspaper, and let the newspaper dry. Then you can dispose of this newspaper in your garbage.

Obviously, the purpose of the etchant is to eat away metals. The problem is that any etchant that gets splashed onto metal (for example, if you're working near a sink, or if you are foolish enough to tip the etchant down the drain) will keep etching. I'm told a drop of etchant will create pinholes in your sink faster than you'd think. So it's probably best to keep the etchant well away from sinks and drains. I do my etching outside, and have a plastic bucket of cold water to do my rinsing in.

After the board is etched, the areas where you want copper are still covered in the dye. This dye can be removed with acetone, or scrubbed off with a scouring pad (don't use steel wool, as the iron may react with the copper over time). The problem is that this leaves the copper exposed to the air, which will then quickly tarnish. There are several ways to treat this. One way is to spray the board with special solder-through lacquer. Another way is to use a special compound to “tin” the board with a metal that doesn't corrode as quickly as copper. I use Cool-amp silver plating powder from ultrakeet.com.au. I haven't yet worked out how to get a great, easy result with this product, but it's better than nothing.  An alternative to Cool-amp is Liquid Tin, (and in .au, here), which I haven't used.  Expensive, but I know folks who swear by it, and say it lasts years.  Sounds worth it to me.

Here are the etched and tinned boards:

Etched and tinned playpause boards


After tinning the boards, I cut them up using an abrasive wheel in my Dremel tool:

Etched, tinned and cut playpause boards, with artwork


Then I file the edges of the boards, and give them a bevel. The boards are then ready for use.

So there you have it: PCBs from artwork to finished. I hope this is interesting and useful. Special thanks to Ross McK, who showed me how to do it. Ross is a great guy and a fine engineer, and he has taught me a lot.

Coming next: Playpause assembly and programming

by Mitch Davis (noreply@blogger.com) at June 09, 2011 10:50 PM

Playpause 3: Assembly and programming

So far in this series we have discussed the Playpause concept and design, and how to make PCBs, using Playpause as an example. Now I want to show how to assemble a Playpause, and how to load the software using a bed-of-nails jig.

Surface mount technology is within reach of everyone. There's no special technology being used here. The iron is a normal 25W soldering iron, it's just normal electronics solder, and the soldering in the photos is being done by my 11-yo son, who has barely soldered before. Thanks Tim!

The first thing to start with is the ATtiny85 microcontroller. When I was a lad, we were told to add the semiconductors to our project last, because of the danger of damage from static. The reason I'm putting the microcontroller on first is because we need to program the chip, and the other components can interfere with programming.

Here's a pic of the chip perched on the board. I've lined up the pins with the PCB pads. Since we will first solder just one pad, it's not critical that all pads are lined up, just the corner pad that gets soldered first:

Chip perched on board
Unless the chip is held in position, it is likely to be moved out of place when touched by the soldering iron. A totally excellent way of holding the chip in place during soldering is to use one tine of a small gardening fork, as described by Jonathan Oxer:
Pressure applied with mini garden fork
Next up, soldering the first pin:
Soldering the first pin
The aim is for the soldering iron to touch both the pad and the pin, so both get heated, for about a second. Then lightly feed a little solder onto the joint (not onto the iron) until the solder flows between the pad and pin. Then remove the iron, and allow the molten solder to solidfy. Make sure the joint is not moved until the solder is set. Surface mount components are very small, and don't take well to being heated for long periods, so try to minimise the amount of time they are in contact with the iron.
After the first pin is soldered, you can gently rotate the chip to get all the pins aligned.

One pin soldered, the chip can be aligned
After the pins are aligned, the rest of the pins can be soldered:
Soldering the rest of the pins
Don't worry if you bridge pins with too much solder. In fact, one good way of soldering fine pitch chips is to deliberately use too much solder, then remove the excess with desoldering braid:
Fixing solder bridges with soldering braid
Now that the microcontroller is soldered on, we can program in the firmware. I am using Tom Long's fantastic USBTiny mkII programmer. Also in this picture is a SparkFun AVRStick, which was my original inspiration for both the USB Doodad and Playpause projects. Thanks SparkFun for the AVRStick, and thanks Objective Development for V-USB!
AVRStick and programmer
To program the Playpause, I'm using a “bed-of-nails” made of “pogo pins” to connect the 6 wires of the ISP header to the micro. You can find out more about pogo pins and making bed-of-nails jigs at this SparkFun tutorial.

To line up the pins with the pads on the circuit board, I made a sleeve out of three pieces of cardboard, glued together as a sandwich. Holes drilled in the top piece of cardboard line up with the pads on the PCB. I slide the PCB into the sleeve, then using one hand, I can hold the bed of nails and the sleeve together. With the other hand, I can press Enter on my computer to run the command to copy the firmware to the micro, and set the right fuses (for example, the fuse which turns on the clock PLL that I mentioned earlier).

Playpause with bed of nails.  The PCB in this pic doesn't have a chip, but of course for programming it would need to have one.

 Programming:


FIXME

The PCB traces at one end of the board are just the right shape to work as a USB connector. But the copper isn't very thin, and if used often, the other part of the connector (the part in your PC) will wear away the copper. To avoid this, you can tin the USB tracks with solder:

Tinning USB connector traces
After the controller is programmed, and the USB traces are tinned, we can add the other components as per this chart:



You can use the gardening fork on all the components except for the diodes, if the diodes are cylindrical. For the diodes, you can ask a friend to hold the diode in position with a small screwdriver.

And now a small admission: When I was copying and pasting the layout to make ten boards, I accidentally deleted a track. That track was omitted on all ten boards I made. So here a small wire is being soldered on to act as the missing track. All the other components have already been soldered.

All passives soldered, doing the switch (extra wire)
When I was developing Playpause, I made a few mistakes in the firmware, which meant I needed to correct and update the firmware. But because I'd already loaded all the components onto the PCB, I couldn't put the PCB back into the programming sleeve. So as an alternative, I direct-wired a 6-pin ISP header to the PCB.

Note that having additional components can interfere with the programmer, but in this case, it seems to work:

Playpause hot-wired to programmer
I made ten of these Playpause boards and took five of them to a friend's place for a craft-and-chat day. Most of the soldering on these boards was done by people who had never done any kind of soldering before, thus proving that surface mount soldering doesn't require any particular skill or dexterity, but just some instruction and guidance.

Five completed playpauses


So, I now have a Playpause to use at work when I'm listening to music, and I can now apply my knowledge of making PCBs and doing bed-of-nails programming to the USB Doodad. Maybe you can too. If you have any questions, or want help making a Playpause or PCBs, ask me.

by Mitch Davis (noreply@blogger.com) at June 09, 2011 12:16 PM

Playpause 1: Design

Ever needed to quickly pause the music or movie that's playing on your computer? Maybe someone is calling you, or you're trying to listen to something else. Hunting around for the pause button with a mouse takes several seconds. What if you could instantly pause with a single button press?
When a USB Doodad gets shipped to someone, it will have a presoldered AVR chip. Somehow I need to get the bootloader into the AVR chip without soldering anything else to the board. The natural way of doing this is via a bed of nails, as I mentioned in Doodad 4.

I have been messing around with bed-of-nails recently, via a little subproject I've been working on called "Playpause":

On top is the Playpause board.
Below is the board for doing bed-of-nails testing.

While the USB Doodad is designed to be a general purpose reprogrammable device, Playpause just does one job: It is a tiny USB device which pretends to be a HID keyboard. But unlike most keyboards, playpause only knows how to send one keycode: The play/pause keycode you'll get from pressing the play/pause button on a multimedia keyboard. Thus with one of these plugged in, you can play and pause your music or movie player without having to get busy with the mouse.  It's small, inexpensive, and easy to build.

(You can find the source code and the KiCad design files here.  TODO: I'm currently working out how to do git submodules so I can park the V-USB code inside playpause, because that's how V-USB likes to be used).

Because it sends a standard USB HID Keyboard keycode, PlayPause will work with any operating system, and doesn't need to have drivers installed. (Although at present it doesn't work with the Mac. I wish I knew why).

Playpause uses the V-USB software USB stack. This is a good choice for AVR projects that you want to be USB-capable, even if the AVR micro you're using doesn't have support for USB in hardware. But there's a catch: V-USB implements USB by using software, which means that when processing USB traffic, the micro can't do anything else.  In practice, this is fine if the task you want your micro to do isn't timing or latency critical, and for this V-USB works very nicely.

Playpause uses surface mount soldering, and the micro I'm using is the 8-pin ATtiny85 in a SOIC-8 package . The pitch on these pins is less than half of an ATtiny85 in PDIP format, which is why Playpause can be made so conveniently small.

While the USB port provides 5V for your device to run on, the USB signalling is done at 3.3V.  This means that every USB project needs to handle this difference somehow.  There are two basic ways of doing this.  The first is to regulate the 5V down to 3.3V, then feed your micro on 3.3V.  This can be done with a linear regulator, or by using the voltage drop across two ordinary diodes.  The second is to run your micro at 5V, but clamp the USB signals to 3.3V.  This can be done with two 3.6V zener diodes, or I've seen some designs (for example the SparkFun AVRStick) that use the forward voltage drop of blue LEDs.  The reason why 3.6V zener diodes are used instead of 3.3V, is that at the frequencies USB runs at, and given the capacitance of a zener diode, the 3.6V zener effectively clamps at 3.3V.  For Playpause, I'm taking the second approach, as shown in “solution B” on the V-USB hardware design page.

Playpause has no external crystal or resonator.  Instead, the clock for the AVR chip is generated onboard using the ATtiny85's RC oscillator.  This presents two problems.  The first is that the RC oscillator is uncalibrated, and may not produce the accurate or stable frequency needed to bit-bang USB packets.  The second problem is that the minimum frequency at which the controller can run V-USB is 12MHz, which is above the nominal 8MHz of the RC oscillator.  How is this situation resolved?

The first problem can be solved by noting that certain parts of the USB protocol take a precise amount of time.  The V-USB software in Playpause can count how many CPU cycles this known time period takes, then from this calculate a calibration value for the RC oscillator. That calibration value then makes sure the RC oscillator produces an exact frequency.

The solution to the second problem lies in the ATtiny85's built-in digital PLL. This circuit has a multiply-by-8 function, so that an input of 8.25MHz from the RC oscillator (8MHz but tweaked up a bit via calibration) gets boosted by the PLL to 66MHz. This frequency is then fed through the clock prescaler, which divides it by 4, to give 16.5MHz, which a frequency supported by V-USB. Curiously, only certain Atmel chips have a PLL, including the ATtinyx5, but excluding the ATmegax8 range. Very useful indeed!

Things to do


Macs


For some reason, Playpause currently doesn't work with Mac computers. My Mac-using friends tell me that the Playpause is able to identify itself correctly, but for some reason MacOS doesn't believe it has a driver to handle the multimedia keypresses Playpause is sending. To try to solve this problem, my plan is to plug in a commercial multimedia keyboard, and sniff the codes it sends when the pause button is sent. That's what I originally did when developing the software, but perhaps there's something I missed, particularly in how multimedia keyboards identify themselves. Either way, it seems that only a software change would be needed to fix the problem.

Suspend


The USB standard says that when the computer suspends, USB devices should put themselves into a low power mode. I'm not currently doing that, so my board is using more power than is strictly necessary. To fix this, I'd set up the processor to sleep until a USB interrupt is received, and if it's not the wakeup condition, go back to sleep.

Code cleanup


The code that's in Git is a direct offshoot of my work on the USB Doodad. As such, it's cluttered with a bunch of things which are not relevant to Playpause. Some janitorial work here would be good.

Coming next: Making PCBs at home

by Mitch Davis (noreply@blogger.com) at June 09, 2011 12:43 AM

June 01, 2011

Qi Hardware

Copyleft Hardware News 2011-06-01

ME 367 CopingStrategies.png

Copying is an act of love. Please copy & share.
Mimi and Eunice by Nina Paley

Milkymist

  • We decided to market Milkymist One as a video synthesizer, not interactive VJ station as planned before. Almost everybody on the project felt that video synthesizer would get more people to understand quicker what the product does, and lead them in the right direction with their second question, whereas interactive VJ station would send them in all sorts of different directions.
  • Yi Zhang took a series of Milkymist One product shots at the Mayray photo studio in Shanghai.
M1 studio shot.jpg
M1 in hand.jpg
M1 vga.jpg
M1 video in.jpg
M1 buttons.jpg
M1 dmx.jpg
One of many new features and improvements in Milkymist One.
Milkymist One at labSurlab in Medellín, Colombia, April 7, 2011
  • Xiangfu Liu added a screenshot feature to Milkymist One, here's a collection of screenshots.
Pshroomery.png
8bitstarfield.png
Pyramids.png
Drunkenboat.png
M1 screenshot cam3.png
Madness2.png
Burningdisc2.png
Balkacid.png
Kalei.png
Interwoven.png
M1 screenshot cam1.png
Ssmatrix.png
Aqualung.png
Burningdisc.png
Mm1.3.png
Torridtales3.png
  • Real-time video synthesis is an exciting feature of Milkymist One. There are still few recordings of performances, because nobody has a VGA grabber, and real-time encoding and streaming into formats such as Ogg Theora or WebM is possible but will require substantial work. Kristian Paul has recorded a small segment with a second video camera... (another one from Sebastien)
Kpaul m1 video-in sample.ogv
Video-in with Milkymist One. [0:27 min, 19.6 MB]
  • Xiangfu Liu demonstrated Open Sound Control ("OSC") with his Milkymist One. OSC is another promising way to control Milkymist One, with nice clients on popular smartphones and tablets.
TouchOSC-control-m1-performence.ogv
Controlling Milkymist One from an Android phone over OSC (Note: video without sound). [0:57 min, 6.5 MB]
  • Slashdot carried a post about our soon-to-be launched open CPU - Milkymist. [11]
  • Sebastien started writing a nice Wikipedia article about the Milkymist project. [12]
  • Sebastien managed to get a clarification from Google that they are not planning to release open and free sources for their WebM hardware codec. [13]
  • Two threads on the mailing list discussed plans about adding a MMU to the Milkymist SoC. [14], [15]
  • Hong Kong based Sharism Ltd, manufacturer of the Milkymist One, sold out its batch of Milkymist One RC2 units. A big THANKS! to all supportive buyers who believed in this product at such an early stage. RC3 will be available soon...
  • Adam Wang reported on the latest Milkymist One RC3 production status. [16]

NanoNote

Ben UBB VGA.ogv
Ben NanoNote and external VGA display. [0:27 min, 4.8 MB]
Ubb-vga-schem.png
Ubb-vga-pub-plugged-medium.jpg
Ubb-vga-pub-v2-medium.jpg
Vga01-ubb-vga-screenshot.jpg
Vga05-ubb-vga2-tstimg.jpg
Vga06-ubb-ccube-jlime.jpg
Vga07-ubb-vga2-ppm.jpg
Vga16-ubb-vga-hsync-noisy.jpg
Vga18-hsync-noisy.png
Vga17-ubb-vga-hsync-clean.jpg
Vga19-hsync-clean.png
Vga08-ubb-vga-800x600.jpg
Vga09-ubb-vga-1024x768-33Hz.jpg
Vga10-ubb-vga-1024x768-36Hz.jpg
Vga11-ubb-dma-tstimg.jpg
Vga20-vga-ben-front.png
Vga21-vga-ben-back.png
Vga22-prod-assembly-draft.png
Vga23-800px-Flower bouquet20091225.JPG
Vga24-ubb-vga-bouquet-dither222.jpg
Vga14-ubb-vga-dual-screen.jpg
Vga13-ubb-dma-web.jpg
Wpan-ipv4.ogg
Ben and Ben talking. [3:30 min, 14.9 MB]
(background info: the video was cut using the command-line melt utility from the MTL framework, sound track P97 made with Korg Kaossilator, scripts)
  • Tuxbrain continued with ben-wpan production, PCBs have been made (see picture), component mounting date (SMT) is scheduled for next week.
Tuxbrain's ben-wpan PCBs.
  • kyak proposed a Russian keyboard layout for the NanoNote, Jane took it one step further and hacked her keyboard into a Colemak layout! [19]
Russian keyboard layout proposed by kyak.
Fabric paint as adhesive.
Jane's finished Colemak keyboard layout.
  • viric has been (for a while already) maintaining nanonixos, a Nix package manager based distribution for the Ben NanoNote. [20]
  • Mark Tuson reported running Debian Wheezy on his NanoNote. [21]
  • David Kuehling added hardware acceleration to the MPlayer video player, which can now play most files in Ogg Theora and WebM formats up to 320x240 and 30fps, and most audio except for surround-sound. Smaller video files are automatically played back full-screen by using the CPU's hardware-scaler. [22]
Big Buck Bunny from the Blender Foundation running on Ben NanoNote.
  • Hans Bezemer released 4tH v3.61.1 for the Ben Nanonote. Changelog
4tH on Ben, thanks to Hans Bezemer
Ben NanoNote OpenWrt 2011-05-28 image after bootup.


--Qi team 03:00, 1 June 2011 (CET)

by Qi team at June 01, 2011 03:00 AM

May 26, 2011

Freetronics

New product: ProtoShield Short

Our new ProtoShield Short is designed to solve a specific problem that's annoyed me for a really long time. Ethernet Shields (and our forthcoming EtherTen) all have a huge RJ45 jack mounted on one end, which means that even though they usually have stackable headers it's really hard to put another shield on top. You need to either insulate the RJ45 jack with tape and jam the shield on top at an angle, or use an extra set of stackable headers to give it more height.

So my solution is the new ProtoShield Short:


Perfect!

by Jonathan Oxer at May 26, 2011 04:32 PM

Our 300th retail order ships. Free, of course

There was a flurry of retail orders yesterday, quickly pushing us up to our 300th retail order shipped - so, in accordance with tradition, Phil from Daglish in Western Australia will receive his order absolutely free!

www.freetronics.com/every-100th-free

Our 100th order shipped 2010-09-17, the 200th was 118 days later on 2011-01-12, and the third was 98 days after that on 2011-04-19. That gives us three data points so we should be able to start guesstimating when the 400th order will be placed: my prediction is July 9th, 2011. Any other predictions? Perhaps we should run a competition!

by Jonathan Oxer at May 26, 2011 04:32 PM

May 25, 2011

Ignacio Garcia, dingux.com

New Gemei X760+

In the comments of the previous post Neno provided the following link:

http://www.it.com.cn/audio/mp4/news/2010/03/10/09/757299_1.html

So I asked ChinaChip. That is the upcoming Gemei X760+ (yes, same name than the old x760+, fun!), and the specs in the linked page are wrong. It's due out by the end of May according to ChinaChip.

It's CC1800 based, same SoC than in the Gemei A330. LCD is 4.3" 480x272. I like the wealth of controls in the lower side.

Unfortunately work on the CC1800 has been slow. It's no fun to write code based on other code with no comments and no programmer's manual, plus I recently got sponsoring for porting dingux to a JZ4755 based device (can't say much about that at the moment), which will be eating up absolutely all of my spare time for the next couple of months. As I already said, I'm not happy being the bottleneck here, so I asked ChinaChip to let me disclose the information they provided on the CC1800 but got no reply, so for now I must honor my promise of keeping the information closed.

by booboo (noreply@blogger.com) at May 25, 2011 04:15 PM

May 19, 2011

Capn's Tech

Rumours of this blog's death are premature

Wow, has it really been three months since I last blogged? Hard to believe. I have been so busy hacking on cool stuff. Previously my blog posts have been to demonstrate something, which is all well and good when one has something to demonstrate. I think I might do more blog posts which are stream-of-consciousness.

In particular, the USB Doodad project is not dead. I have been working on it constantly, just not writing about it.

Anyway, expect to see a rash of new articles soon.

by Mitch Davis (noreply@blogger.com) at May 19, 2011 10:08 AM

May 17, 2011

Village Telco

AfrikaBurns Again for a Village Telco

The following is a guest post from Scarborough Mesh pioneer David Carman who set up a Mesh Potato telephone network for the second year at AfrikaBurn.

David Carman installing Mesh Potato phone booth We headed for Tankwa Town with a full load and empty wallet and flashed & configured the Mesh Potatoes (MPs) in the desert using the good ol’ 192.168 range. The booths were different to last year: they had production MPs, new sleeves and no lighting. I set each node with a different Virtual Access Point (VAP) SSID based on the phone number because I found that using an identical VAP SSID caused SSH to die. This will be ideal in the future, when each MP owner has a WPA key on their router and both cabled and VAP connections are linked to the same account. So any device that wants to roam must either switch between VAPs or run batman itself.

Steve came up for 2 days to help set up and bring some much-needed supplies. I discovered that an Olmeca tequila bottle is not as sturdy as it looks. It broke in the trailer and softened up the Tetrapak milk until most of the cartons ruptured too. So a Nano, a few phones and other gear were swamped. Thanks for the rescue, Steve.

We set up the booths easily this year – far less wiring and better ground pegs. We put phones in the organiser’s caravan, medics and the gate, with a Nano to cover the 5km distance to the gate. However this year they had moved the gate to the end of the airstrip, so it was only 1km away.

I had brought a netbook with broken screen to act as gateway, redirecting all port 80 traffic to a phpbb3 bulletin board with the appropriate DirtyBoard2.0 skin – see http://swug.za.net/phpbb/. I also redirected port 53 to dnsmasq that spoofed the DNS of  Top Level Domains (TLDs) to the gateway IP too. These are the kinds of things that naughty people do, but I think it works well for our application. I set each router’s dns as 8.8.8.8 and SIP registration to villagetelco.org. When a mesh is connected to the Internet, DNS & SIP will work fine (once VT has a SIP server). If there is no Internet access, DNS/SIP/HTTP can be fielded by an offline gateway server. It does look a bit odd, but it works.

The spoof gateway was running fine for devices connected to the LAN but was not accessible from the WAN. In fact, no other device connected to a different MP could be seen except for the MP’s LAN address itself. This suggested that there was an issue with the dummy gateway setting on the LAN, required to allow Asterisk to run as per David & Elektra’s discussion

I was 4 days into the trip by then and it was time to party, so I left the gateway for another day – and Internet access. It was most helpful though in checking the booths. Instead of plugging in a netbook, one could just pick a nearby cosy camp, settle down and connect wirelessly. DHCP, LAN bridging, batman routing, Asterisk were all working fine.

Solar operation

This year I invested in a 90W monocrystalline solar panel and regulator for the camp – 90 watts when the sun is shining for the next 25-50 years. It will be part of my home solar office in a few weeks. I had 4 105AH tractor batteries from last year and connected the gateway netbook and the fixed one (20-40W each), plus about 20W of lighting and didn’t have a power problem for the whole week.

We used the 10W flexible solar panels and 12AH batteries on the booths as with last year, but this time there was no lighting in the booths. 10W kept the booth MPs up throughout the week, but the batteries drained progressively. I put this down to the number of phone calls being made – nearly all the time, day & night. One booth’s phone was left off-hook providing dialtone for a few hours. I disconnected it for a charge back at camp and it was sorted. Perhaps a dialtone hangup can be written into Asterisk for such events on battery-powered phones.

I also installed a phone in a friend’s art car, connected to the cigarette lighter adapter. It was great to be able to phone the art car from anywhere and ask for a pick-up. However next year, I’ll bring along some battery clips so that the phone stays on when the car is off – see whether the MP can “survive the crank”.

Conclusion

Mesh Potato Phone Booth at Afrikaburn This year was tougher with just Steve and I setting up, but easier because of the work we could build on from last year. The most promising result from this year were that the phones worked and worked hard. It gave me some time to work towards the 4093-node, no-NAT VAP firmware I long for. Although the VAP was not feeding into the gateway, every person with a wifi-enabled laptop or phone saw hotspots – so hopefully they’ll be better prepared next time too. Comments from participants were different this year too. Last year the phones were a novelty; this year people were more interested in and supportive of the technology behind the phones.

This year I met some important people for next year. Adriaan Wessels is the technical chap on the organising committee. For next year, we’ll be able to plan carefully regarding gate link and possibly organiser car links. Organiser confidence in the network will mean that they will be able to pre-announce a “Tankwanet” and its services so that participants can be better prepared to take advantage. There are a lot of IT geeks at Afrikaburn. Perhaps some of them could be persuaded to offer services on the network.

Rod Bracher runs the Tankwa Town post office, Burning Mail. They have some old rotary-dialling phones that they connect with carrier but without dialling. I tried to coordinate with him to hook his phones up to the network, but ran out of time. We had a chat about doing so at this burn, so pulse-dialling is definitely on for next year.

The streaming services company antfarm.co.za were at AfrikaBurn this year. I couldn’t spot their VSAT dish, but made brief contact. They were streaming the burns live, which led me to figure a rule at AfrikaBurn: the isolation is an important part of the event, but the isolation need only exist one way – incoming. So theoretically, participants should be able to send SMSs, update their twitter accounts and post on a forum on the Internet – as long as they don’t see any response from outside the burn. Antfarm’s ISP only allows Internet connection on port 80, so a little port jiggling and a helpful Internet server should squeeze whatever we need through, except for multiport SIP.

Lastly and simply, Isigidimi was at AB2011. The continuity will help us attract more participants next year, and perhaps more of the VT-dev community. You can set up an Asterisk service, website, jabberd, tinker with pulse-dialling, or just sip on the Kool Aid and be inspired ;^)

Here are some more images from Afrikaburn 2011

by dcarman at May 17, 2011 04:15 PM

April 27, 2011

Ignacio Garcia, dingux.com

A320 back to production

It could be infered from the fact that support for a new LCD type was implemented, but I just got confirmation from ChinaChip.

by booboo (noreply@blogger.com) at April 27, 2011 12:32 PM

April 25, 2011

Village Telco

Small Enterprise – Campus Network (SECN)

Terry GillettMeet Terry Gillett. Terry joined the Village Telco community early this year and purchased a couple of Mesh Potatoes.  He immediately saw the opportunity that Mesh Potatoes might have for smaller networks such as a campus or small firm.  However, the existing firmware for Mesh Potato was very focused on voice communication in a structured Village Telco environment.  Of course it is possible to configure Mesh Potatoes in a 100 different ways but those alternative configurations can be somewhat arcane and a real barrier to alternative uses of the Mesh Potato.

Setting “smart defaults” is a key to masking complexity and lowering the barrier to uptake.  Think of Google’s search minimalism after Altavista et al or Apple’s simplification of so many applications that were filled with twiddly knobs, checkboxes, and radio buttons in other operating systems that shall remain nameless.    Wordpress is another great example of an application that is capable of impressive sophistication for “blogging software” yet pretty much “just works” after completely a bare minimum of setup information. Terry has taken us one giant step closer towards WordPress-like usability with his Small Enterprise – Campus Network (SECN) setup for Mesh Potatoes.

His goal to be able to serve a local network of modest size offering seamless voice and data.  He wanted any Mesh Potato to pick up Internet connectivity via the ethernet port, if it could find it, and for each Mesh Potato to offer a local WiFi access point.  After experimenting a little bit, he chose to install the BATMAN-ADV mesh protocol instead of BATMAN protocol we currently use.  The big difference between the two protocols is that BATMAN-ADV runs at Layer 2 and BATMAN at Layer 3 of the OSI layer model.  What does that mean?  Well the simplest explanation is that BATMAN-ADV makes Mesh Potatoes behave as if they were all part of one big network switch which means that IP addressing and routing for the network is dramatically simplified as each Mesh Potato is effectively transparent to the IP network.  This effectively removes the hassle of figuring out network addressing and Network Address Translation for Mesh Potatoes.  Everything is just one flat network which means that devices can easily communicate with each other on the network.  The flip side of this is that you have to be careful about what you put on the network because a poorly configured or worse infected computer can generate a lot of local network traffic.  This is something we’re exploring but for a small network, BATMAN-ADV seems to work exceedingly well.

With Terry’s modifications, an SECN configured Mesh Potato network will now:

  • offer an encrypted, WPA-enabled, wireless access point as well as a peer-to-peer wireless connection on each mesh Potato.  This is done by creating a Virtual Access Point (VAP) on the same radio interface as the mesh.  Initially we chose not to enable this by default on the core Mesh Potato distribution because we were concerned about network data load have an impact on voice quality but Terry’s work makes me think that this was a mistake.  Much better to encourage use and solve the problem of over-use rather than ensure a functional but underused network;
  • pick up a network connection from any DHCP-enabled Internet-connected device it is connected to the ethernet port on the Mesh Potato;
  • transparently carry DHCP requests over the network to devices connected to Mesh Potatoes whether by ethernet or WiFi; and,
  • offer simple on-network and also VoIP service provider configurable phone calling.  Local phones can be dialed simply by entering the last 3 digits of the IP address of the Mesh Potato you want to call or the Mesh Potatoes can be registered with any VoIP service provider.

The long and short of this is that if you plug in a bunch of SECN-configured Mesh Potatoes and make sure at least one is connected to something simple like a DHCP-enabled ADSL router, then you have a transparent, highly-adaptable technology for creating a robust local telephone and data network with no wires.

example diagram of an SECN network setupSo, did Terry do this all by himself?  Without Terry’s interest and hard work at testing, reconfiguring, debugging the SECN version might never have happened but one of the great things about Open Source is that one is rarely starting from scratch.  He was able to build on the configuration that Elektra built for the Mesh Potato which in turn built on great Open Source initiatives like OpenWRT, Asterisk, and others.  And at least a dozen people in the Village Telco community were there to help him solve problems and answer questions.  Better still his work inspired others to try out new configurations with the Mesh Potato and Elektra was inspired to take the set of instructions that he had developed and embed them in a new Mesh Potato firmware distribution that people can use to set up smaller Village Telco networks to serve both voice and data.

If you’re interested in trying this out yourself, you’ll need a few Mesh Potatoes to start and then you’ll want to download the latest SECN firmware and flash the Mesh Potatoes with this new firmware.  Terry has been developing the documentation for the SECN, the latest version of which is here.  Because this is still at an early stage, that URL may change.  Best to check in with the Village Telco google group to find the latest version.

by steve at April 25, 2011 11:10 AM

April 23, 2011

Gerard Braad

Simple Bugzilla client

At the moment I work as an IT Consultant on a QA-related project in Beijing at an outsourced partner. As you might know, the Internet connectivity in China is not optimal and this caused some issues on our end. Since we have to do a lot of cross-checking, we needed a way to keep track of remotely reported bugs and store these in a local instance of a previously in-house developed cross-check tracker. I started to develop a simple client to pull information from the remote Bugzilla instance which is then stored locally. This solved most of the issues we encountered with the latency and improved the productivity of our team.

XML-RPC client
The local tracker is built in PHP, so at first a small prototype was built to see if it was possible to call Bugzilla's XML-RPC interface. To ease the development I chose to use the standard ZendFramework library and the XML-RPC client they offer, Zend_XmlRpc_Client. The biggest issue I encountered was the way authentication was implemented on the remote side, but the actual client was simple and very easy to implement. The prototype was first done in a very sequential way... and eventually after a little bit of refactoring this is what remained:

// Add the AutoLoader
require_once('Zend/Loader/Autoloader.php');
Zend_Loader_Autoloader::getInstance();

class BugzillaClient
{
// Initialize the client
protected $rpcClient = null;
protected $basUrl = null;

public function __construct($baseUrl, $username, $password)
{
$this->baseUrl = $baseUrl; // Store internal for later use
$this->rpcClient = new Zend_XmlRpc_Client($baseUrl . "/xmlrpc.cgi");

$httpClient = $this->rpcClient->getHttpClient();
$httpClient->setCookieJar(); // Needed to retain user cookie
$httpClient->setAuth($username, $password, Zend_Http_Client::AUTH_BASIC);

// Login request (XMLRPC)
$response = $this->rpcClient->call('User.login', array(array(
'login' => $username,
'password' => $password,
'remember' => 1
)));
}

public function __destruct()
{
// Logout request (XMLRPC)
$response = $this->rpcClient->call('User.logout', array());
}

public function Get($id)
{
$returnValue = array();

// Get request (XMLRPC)
$response = $this->rpcClient->call('Bug.get', array(array('ids' => $id)));
$index = 0; // Only retrieving one bug, so don't bother with index now

$returnValue['id'] = $id;
// Construct a remote URL
$returnValue['url'] = $this->baseUrl . "/show_bug.cgi?id=" . $id;
// Collect some basic information about the bug
$returnValue['summary'] = $response['bugs'][$index]['summary'];
$returnValue['status'] = $response['bugs'][$index]['status'];
$returnValue['resolution'] = $response['bugs'][$index]['resolution'];

// Comments request (XMLRPC)
$response = $this->rpcClient->call('Bug.comments', array(array('ids' => $id)));
// Extract the first comment from the bug and store as description
$returnValue['description'] = $response['bugs'][$id]['comments'][0]['text'];

return $returnValue;
}
}

This code provides a constructor which does the login and a 'Get' function to query the remote instance.

Example
To use this client you just need to include this module and create a new BugzillaClient instance.
require_once('config.php');          // Contains the baseUrl and credentials
require_once('BugzillaClient.php'); // This is the client code

$bzClient = new BugzillaClient($bzBaseUrl, $bzUsername, $bzPassword);
$bug = $bzClient->Get($id);

echo $bug['summary']);
After this the summary will be printed.

Future work
The last time I did some actual development with PHP was during PHP 3 and the move to PHP 4. At that moment I was not so happy with the Object Orientation model that the language offered. Luckily this improved a lot and hope this code testifies of that... as I have seen some horrific spaghetti code during these several days.

Using this solution does not provide a complete up-to-date picture of the bug, but this is not a problem to us. Besides, triggering a script which iterates over all local bugs and queries the remote state solved this issue. Some more features will be implemented, like searching for bugs and pushing comments back. This basic implementation code has been posted to public git repositories, so fork it and start pushing your improvements.

Repositories

by gbraad (noreply@blogger.com) at April 23, 2011 02:12 PM

April 21, 2011

Ignacio Garcia, dingux.com

Support added for new LCD type (ILI9338)

A couple of maintenance releases, which basically boild down to the addition of support for a new LCD type, ILI9338. The support was implemented and tested by ChinaChip, I just prepared the dual boot installer and added the new zImage to the old system package.

Check out the google code downloads page here.

by booboo (noreply@blogger.com) at April 21, 2011 08:38 PM

April 14, 2011

Capn's Tech

USB Doodad 6: Bootloader

Now that we know USB is working, it's time to get the bootloader working.  The bootloader is called "bootloadHID", and can be found here:

  http://www.obdev.at/products/vusb/bootloadhid.html

I downloaded bootloadHID and extracted it:

[mjd@onza src]$ wget -q http://www.obdev.at/downloads/vusb/bootloadHID.2010-07-29.tar.gz
[mjd@onza src]$ tar -xzf bootloadHID.2010-07-29.tar.gz
[mjd@onza src]$

I have made some changes to the bootloader source and config:
  • We're using different pins for the USB.
  • I want the LEDs to blink to show something's happening.  The blinking is different depending on whether the bootloader is in program mode, or has handed control to the application.
  • Our bootloader program mode switch is connected to an analog input rather than a digital input.  Therefore I had to add code to read an analog value. 
  • Once the bootloader is in program mode, I want it to stay in program mode after the button is released.  (In the stock code, you have to hold down the button constantly in order to program the MCU).
  •  I've changed the MCU type, the fuses, the execution start address and the right command to run avrdude for my USB programmer:

--- bootloadHID.2010-07-29.orig/firmware/bootloaderconfig.h
+++ bootloadHID.2010-07-29/firmware/bootloaderconfig.h
@@ -43,7 +43,7 @@
 /* This is the port where the USB bus is connected. When you configure it to
  * "B", the registers PORTB, PINB and DDRB will be used.
  */
-#define USB_CFG_DMINUS_BIT      0
+#define USB_CFG_DMINUS_BIT      3
 /* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
  * This may be any bit in the port.
  */
@@ -106,6 +106,7 @@
 #ifndef __ASSEMBLER__   /* assembler cannot parse function definitions */
 #include <util/delay.h>

+#if 0
 static inline void  bootLoaderInit(void)
 {
     PORTD = 1 << 3; /* activate pull-up for key */
@@ -113,6 +114,7 @@
 }

 #define bootLoaderCondition()   ((PIND & (1 << 3)) == 0)   /* True if jumper is set */
+#endif

 #endif

--- bootloadHID.2010-07-29.orig/firmware/main.c
+++ bootloadHID.2010-07-29/firmware/main.c
@@ -81,8 +81,15 @@

 static void (*nullVector)(void) __attribute__((__noreturn__));

+static inline void setLed(const int i)
+{
+    PORTC &= ~(_BV(PC0) | _BV(PC1) | _BV(PC2) | _BV(PC3));
+    PORTC |= i & (_BV(PC0) | _BV(PC1) | _BV(PC2) | _BV(PC3));
+}
+
 static void leaveBootloader()
 {
+    setLed(15);
     DBG1(0x01, 0, 0);
     cli();
     boot_rww_enable();
@@ -215,9 +222,68 @@
     sei();
 }

+#define ADC_CHANNEL                    6
+#define ADC_ENABLED                     (1 << ADEN)
+#define ADC_SINGLE_CONVERSION           (0 << ADATE)
+#define ADC_CONV_COMPLETE_INTR_OFF      (0 << ADIE)
+#define ADC_PRESCALE_128                ((1 << ADPS2) | (1 << ADPS1) | (1 << ADPS0))
+#define ADC_REFERENCE_AVCC              (0 << REFS1 | 1 << REFS0)
+#define ADC_RIGHT_ADJUSTED              (0 << ADLAR)
+#define ADC_START_CONV                  (1 << ADSC)
+#define ADC_CONV_IN_PROGRESS            (1 << ADSC)
+#define ADC_CONV_INTFLAG                (1 << ADIF)
+
+static inline void ADC_Init()
+{
+    // Write 0 to power up ADC, 1 to power down
+    PRR &= ~PRADC;
+
+    ADCSRA = ADC_ENABLED | ADC_SINGLE_CONVERSION | ADC_CONV_COMPLETE_INTR_OFF | ADC_PRESCALE_128;
+
+    ADMUX = ADC_REFERENCE_AVCC | ADC_RIGHT_ADJUSTED | ADC_CHANNEL;
+
+    _delay_us(10);  /* wait for levels to stabilize */
+}
+
+static inline uint16_t ADC_Read()
+{
+    // TODO: Start conversion with ADSC=1
+    ADCSRA |= ADC_START_CONV;
+
+    // Wait for the conversion to complete
+    while (ADCSRA & ADC_CONV_IN_PROGRESS)
+        ;
+
+    ADCSRA |= ADC_CONV_INTFLAG;
+
+    return ADC;
+}
+
+static inline void ADC_StopReading()
+{
+    // ADEN in ADSRA enables ADC
+    ADCSRA &= ~ADEN;
+}
+
+static inline void  bootLoaderInit(void)
+{
+    ADC_Init();
+}
+
+static inline char bootLoaderCondition()
+{
+    uint16_t v = ADC_Read();
+
+    ADC_StopReading();
+
+    return v < 512;
+}
+
 int __attribute__((noreturn)) main(void)
 {
     /* initialize hardware */
+    DDRC |= _BV(PC0) | _BV(PC1) | _BV(PC2) | _BV(PC3) | _BV(PC4) | _BV(PC5);
+    PORTC = _BV(5);
     bootLoaderInit();
     odDebugInit();
     DBG1(0x00, 0, 0);
@@ -229,7 +295,14 @@
         GICR = (1 << IVSEL); /* move interrupts to boot flash section */
 #endif
         initForUsbConnectivity();
+        unsigned int a = 0;
+        unsigned int b = 0;
         do{ /* main event loop */
+            if (++a == 32)
+            {
+                a = 0;
+                setLed(++b >> 11);
+            }
             wdt_reset();
             usbPoll();
 #if BOOTLOADER_CAN_EXIT
@@ -243,7 +316,7 @@
                 }
             }
 #endif
-        }while(bootLoaderCondition());
+        } while(1);
     }
     leaveBootloader();
 }
--- bootloadHID.2010-07-29.orig/firmware/Makefile
+++ bootloadHID.2010-07-29/firmware/Makefile
@@ -14,11 +14,11 @@
 #     make flash   # to load the boot loader into flash
 #     make lock    # to protect the boot loader from overwriting

-DEVICE = atmega8
-BOOTLOADER_ADDRESS = 1800
-F_CPU = 12000000
-FUSEH = 0xc0
-FUSEL = 0x9f
+DEVICE = atmega328p
+BOOTLOADER_ADDRESS = 7800
+F_CPU = 16000000
+FUSEH = 0xda
+FUSEL = 0xff
 # Fuse high byte:
 # 0xc0 = 1 1 0 0   0 0 0 0 <-- BOOTRST (boot reset vector at 0x1800)
 #        ^ ^ ^ ^   ^ ^ ^------ BOOTSZ0
@@ -38,7 +38,7 @@

 ###############################################################################

-AVRDUDE = avrdude -c stk500v2 -P avrdoper -p $(DEVICE)
+AVRDUDE = avrdude -c avrisp2 -P usb -p $(DEVICE)

 LDFLAGS += -Wl,--relax,--gc-sections -Wl,--section-start=.text=$(BOOTLOADER_ADDRESS)

A note about the changes to the Makefile:

"BOOTLOADER_ADDRESS = 7800": This is the start address of the bootloader.  There's 2k (0x800) bytes of program space allocated for the bootloader and the '328 has 32k (0x8000) bytes of program flash.  So the start of the bootloader is at 0x8000 - 0x800 = 0x7800.

"FUSEH = 0xda": For the blinkenled and the mouse demo, the high fuse was set to the '328's default of 0xd9.  With this fuse setting, execution will start at address 0.  In order to jump to the bootloader, we want to enable (=0) the BOOTRST fuse, and set the size of the bootloader to be 2048 bytes = 1024 words, and the start address to be 0x3C00 words = 0x7800 bytes.  (This use of words and bytes is quite confusing.  In the AVR and gcc world, some values are given in bytes and some are given in words.  I've had several puzzling moments getting all this straightened out...)

Once again I looked up the fuse calculator:

  http://frank.circleofcurrent.com/fusecalc/

Making these changes gives a high fuse value of 0xda.

Ok, back to the patch:

[mjd@onza src]$ cd bootloadHID.2010-07-29
[mjd@onza bootloadHID.2010-07-29]$ patch -p1 < ../bootloadHID.2010-07-29.diff
patching file firmware/bootloaderconfig.h
patching file firmware/main.c
patching file firmware/Makefile
[mjd@onza bootloadHID.2010-07-29]$

Then I compiled the software:

[mjd@onza bootloadHID.2010-07-29]$ cd firmware
[mjd@onza firmware]$ make
avr-gcc -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -Iusbdrv -I. -mmcu=atmega328p -DF_CPU=16000000 -DDEBUG_LEVEL=0  -x assembler-with-cpp -c usbdrv/usbdrvasm.S -o usbdrv/usbdrvasm.o
avr-gcc -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -Iusbdrv -I. -mmcu=atmega328p -DF_CPU=16000000 -DDEBUG_LEVEL=0  -c usbdrv/oddebug.c -o usbdrv/oddebug.o
avr-gcc -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -Iusbdrv -I. -mmcu=atmega328p -DF_CPU=16000000 -DDEBUG_LEVEL=0  -c main.c -o main.o
usbdrv/usbdrv.h:213: warning: 'usbFunctionDescriptor' used but never defined
usbdrv/usbdrv.h:220: warning: 'usbSetInterrupt' declared 'static' but never defined
avr-gcc -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -Iusbdrv -I. -mmcu=atmega328p -DF_CPU=16000000 -DDEBUG_LEVEL=0  -o main.bin usbdrv/usbdrvasm.o usbdrv/oddebug.o main.o -Wl,--relax,--gc-sections -Wl,--section-start=.text=7800
rm -f main.hex main.eep.hex
avr-objcopy -j .text -j .data -O ihex main.bin main.hex
avr-size main.hex
   text       data        bss        dec        hex    filename
      0       1926          0       1926        786    main.hex
[mjd@onza firmware]$

The warnings don't seem to matter, and I have ignored them.

Now I can program the Doodad:

[mjd@onza firmware]$ su
Password:
[root@onza firmware]# make flash
avrdude -c avrisp2 -P usb -p atmega328p -U flash:w:main.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "main.hex"
avrdude: writing flash (32646 bytes):

Writing | ################################################## | 100% 0.60s

avrdude: 32646 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex contains 32646 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 8.67s

avrdude: verifying ...
avrdude: 32646 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

[root@onza firmware]# make fuse
avrdude -c avrisp2 -P usb -p atmega328p -U hfuse:w:0xda:m -U lfuse:w:0xff:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: reading input file "0xda"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xda:
avrdude: load data hfuse data from input file 0xda:
avrdude: input file 0xda contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xff"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xff:
avrdude: load data lfuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

[root@onza firmware]#

Let me explain my strategy regarding the LEDs.  My changes mean that the bootloader lights up the last LED, and the mouse demo lights up the second last LED.  Both programs also run a binary counter on the next four LEDs.  
If the last LED is on, it means that the bootloader has run.  If the second last LED is on, it means the mouse demo has run.  After programming the Doodad as above, the bootloader LED is on, but the mouse demo LED isn't.  That makes sense because programming the bootloader erases all memory.  Note also the four LEDs before the mouse demo LED are all on.  That tells me the bootloader tried to jump to the mouse demo.

Also, when I run the lsusb command, I can't see any USB devices corresponding to the Doodad.

Next, pull out the Doodad and insert it with the button held down.  The bootloader LED is on, the mouse demo LED is on, and the next four LEDs are running a binary counter.  That tells me the bootloader is in program mode.  lsusb also shows this:


Bus 003 Device 010: ID 16c0:05df VOTI

Later on I'll show how to program an application such as the mouse demo over USB, but for the moment I want to prove that I can load the mouse demo and the bootloader into memory at the same time, and that the bootloader will fall through to the mouse demo if the bootloader button isn't pressed when the Doodad first starts.

So far, whenever avrdude has programmed the '328 program flash, that memory has first been erased.  The problem with this is that it erases any existing program.

In order to get both the bootloader and the mouse demo in flash at the same time, we need to program the bootloader with a flash erase, then program the mouse demo without erasing the flash.  (Note, the only time you can load a program with the programmer without doing an erase is if you're loading into memory which has already been erased).

  • Erase the flash
--- vusb-20100715-orig/examples/hid-mouse/firmware/Makefile
+++ vusb-20100715/examples/hid-mouse/firmware/Makefile
@@ -11,7 +11,7 @@
 F_CPU   = 16000000 # in Hz
 FUSE_L  = 0xff# see below for fuse values for particular devices
 FUSE_H  = 0xda
-AVRDUDE = avrdude -c avrisp2 -P usb -p $(DEVICE) # edit this line for your programmer
+AVRDUDE = avrdude -c avrisp2 -P usb -p $(DEVICE) -D # edit this line for your programmer

 CFLAGS  = -Iusbdrv -I. -DDEBUG_LEVEL=0
 OBJECTS = usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o main.o


  And if that wasn't impressive enough, After I plugged it into my computer's USB port, the mouse cursor started moving around in a large circle, and the LEDs are counting!
Here's what lsusb shows:

[root@onza mjd]# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 1a40:0101 TERMINUS TECHNOLOGY INC.
Bus 001 Device 003: ID 0951:1607 Kingston Technology Data Traveler 2.0
Bus 001 Device 004: ID 0951:1607 Kingston Technology Data Traveler 2.0
Bus 001 Device 005: ID 0951:1607 Kingston Technology Data Traveler 2.0
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 16c0:03e8 VOTI free for internal lab use 1000

The mouse is the "VOTI" entry. The USB vendor ID and product ID can be set in the software.

Now to see the details:

[root@onza mjd]# lsusb -v

Bus 003 Device 002: ID 16c0:03e8 VOTI free for internal lab use 1000
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x16c0 VOTI
  idProduct          0x03e8 free for internal lab use 1000
  bcdDevice            1.00
  iManufacturer           1 obdev.at
  iProduct                2 Mouse
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              400mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.01
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      52
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             100
Device Status:     0x0000
  (Bus Powered)

[root@onza mjd]#

I'm not sure why it says the report descriptors are unavailable.  But at least it works.

Now I'll start working on the bootloader.  If I can get the bootloader working, I can take the three pins we're currently using for ISP, and make them LED outputs.

To be covered in the next article:

  • How to use the bootloader to program new apps to the Doodad without using an ISP.
  • How to use fuses to protect the bootloader.

by mjd (noreply@blogger.com) at April 14, 2011 04:22 PM

April 12, 2011

Capn's Tech

USB Doodad 4: Blinkenleds

Progress on the USB Doodad has been going well with several successes.
After soldering on the processor, I added the reset pullup resistor, and rigged up a 6-pin programming header on the end of the board.

(Note this is a prototype at a later stage)

There's no permanent position for a programming header on the board.  This is because once the board has a bootloader, loading software on the Doodad will be done over USB.  Our plan is to use pogo pins to make a "bed of nails" that we can temporarily sit the Doodad board on to get the bootloader into it.

I plugged the Doodad into my programmer, and plugged the programmer into my PC.  There was no smoke (!), and the avrdude program could recognise the '328!  That's always a good sign.

[root@onza mjd]# /usr/bin/avrdude -c avrisp2 -P usb -p m328p -q

avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x1e950f

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

[root@onza mjd]#

I then soldered a LED and a dropper resistor onto the pin for bit 5 of port C, searched for a simple "blinkenled" program on the 'net, and compiled it for the '328:

[mjd@onza 328hello]$ cat hello.c
#include <avr/io.h>
#include <util/delay.h>

int main()
{
    // Set bit 5 of port C to be an output
    DDRC |= _BV(PC5);

    while (1)
    {
        // Invert the value of pin 5 on port C
        PORTC ^= _BV(PC5);
        _delay_ms(500);
    }
}

[mjd@onza 328hello]$ avr-gcc -Os -DF_CPU=8000000 -mmcu=atmega328p -o hello.o -c hello.c
[mjd@onza 328hello]$ avr-gcc -Os -DF_CPU=8000000 -mmcu=atmega328p -o hello.elf hello.o
[mjd@onza 328hello]$ avr-objcopy -O ihex hello.elf hello.hex
[mjd@onza 328hello]$ ls -l hello.hex
-rw-rw-r--. 1 mjd mjd 582 2010-11-21 14:52 hello.hex
[mjd@onza 328hello]$

I then programmed it into the '328:

[root@onza 328hello]# /usr/bin/avrdude -c avrisp2 -P usb -p m328p -U flash:w:hello.hex
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "hello.hex"
avrdude: input file hello.hex auto detected as Intel Hex
avrdude: writing flash (200 bytes):

Writing | ################################################## | 100% 0.08s

avrdude: 200 bytes of flash written
avrdude: verifying flash memory against hello.hex:
avrdude: load data flash data from input file hello.hex:
avrdude: input file hello.hex auto detected as Intel Hex
avrdude: input file hello.hex contains 200 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.06s

avrdude: verifying ...
avrdude: 200 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

[root@onza 328hello]#

Yay, the LED blinks!  But there's a slight problem: The LED should blink once a second, but I found it was actually blinking once every eight seconds.  This is because by default, there's a fuse in the '328 which divides the clock by 8.

AVR chips have a few bytes of persistent memory called "fuses".  The bits in these fuses control things such as what source the chip uses for clock, and what areas of memory are protected.  The name for the fuse that's dividing the clock by 8 is called CKDIV8.

Here's how I retrieved the fuse values:

[root@onza 328hello]# /usr/bin/avrdude -c avrisp2 -P usb -p m328p -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude> dump lfuse
0000  62                                               |.               |

avrdude> dump hfuse
0000  d9                                                |.               |

avrdude> dump efuse
0000  07                                                |.               |

avrdude> quit

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

[root@onza 328hello]#

I then looked up an AVR fuse calculator:

  http://frank.circleofcurrent.com/fusecalc/

Turning off the CKDIV8 fuse means the "low fuse" value changes from 0x62 to 0xE2.  The fuse calculator also helpfully shows the avrdude parameters to make this change:

[root@onza 328hello]# /usr/bin/avrdude -c avrisp2 -P usb -p m328p -U lfuse:w:0xE2:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: reading input file "0xE2"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xE2:
avrdude: load data lfuse data from input file 0xE2:
avrdude: input file 0xE2 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

I can then check that the fuse programming has worked:

[root@onza 328hello]# /usr/bin/avrdude -c avrisp2 -P usb -p m328p -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude> dump lfuse
0000  e2                                                |.               |

avrdude> quit
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

[root@onza 328hello]#

After doing this, the LED flashes once per second.

At this point, the '328's clock is being provided from an internal oscillator.  The internals oscillator is convenient if you want to keep the number of parts on the board to a minimum, but the frequency can drift with temperature, so it's not a great choice for a USB device.  So my next step was to solder on a quartz crystal and the two associated capacitors.

Back in the fuse calculator, I used the pull-down menu in the "low fuse presets" to choose "Ext. Crystal Osc.; Frequency 8.0- MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms; [CKSEL=1111 SUT=11]".  That makes the low fuse value 0xFF.  So I programmed that in using avrdude as above:

[root@onza 328hello]# /usr/bin/avrdude -c avrisp2 -P usb -p m328p -U lfuse:w:0xff:m





avrdude done.  Thank you.

The LED is now flashing, but it's twice as fast as it should be.  This is because when I compiled the code, I said the clock frequency was 8MHz, to match the internal oscillator.  That's not going to work very well with a 16MHz external crystal.  So I recompiled the code:

[mjd@onza 328hello]$ avr-gcc -Os -DF_CPU=16000000 -mmcu=atmega328p -o hello.o -c hello.c

I won't show the linking and .hex file creation steps as they're the same as above, but after reprogramming the '328, the LED now blinks at 1Hz.

So, I have a board on which I can run software, and the means to program it.  Winnage!

by mjd (noreply@blogger.com) at April 12, 2011 09:31 PM

March 18, 2011

Andrew Zonenberg, Silicon Exposed

Wet etching process

My preferred method for delayering chips is wet etching in dilute hydrofluoric acid (HF), commonly available in grocery stores as Whink brand rust remover:

~2% technical grade HF from Price Chopper
As the MSDS makes quite clear, this stuff is not something you want to splash on your hands (or skin in general). While it's extremely dilute compared to the 45% concentrated solution used in some laboratories, I've been through the HF safety talk at my school's cleanroom enough times that I'd rather not take chances.

I have a pair of Norfoil (Silver Shield) gloves around that I use for this kind of work. They're rather stiff so a common practice to improve dexterity is to double-glove with an XL nitrile glove over the Norfoil. When combined with a lab coat, splash goggles, and a face shield there's little chance of anything getting through.

 
Nitrile outer glove (blue) over Norfoil glove (silver), tucked into sleeve of Tyvek lab coat (white)

My standard lab PPE

Before getting dressed I placed a 10 ml beaker of distilled water on my hot plate and preheated it to a warm but not boiling temperature (exact temp isn't critical).

The next step is to pour a bit under 1 ml of the HF solution into a plastic test tube. HF will eat glass so using glass labware with it isn't a good idea!

HF solution in the test tube
Drop the die into the tube, cap it, and place it in the water bath. Etch rate depends on temperature, strength of the acid (Whink's strength isn't precisely controlled and I often will re-use the acid several times) and a few other factors so it's difficult to accurately predict. I usually will etch for 30 seconds at a time on modern planarized processes and 60-90 seconds on a large non-planarized chip.
Sample etching in the water bath

When the time is up, remove the tube from the heat and suction the HF with a pipette. The acid can usually be re-used for many etches, though it does get weaker over time. Drop the die into a beaker of acetone to remove any acid residue.

Remove the sample from the acetone using solvent-resistant plastic tweezers. (Many common plastics, such as polycarbonate, will dissolve into the acetone and contaminate your sample. Metal tweezers have a nasty habit of chipping edges of dies.)

Rapidly blow-dry the sample, holding it down with tweezers so it doesn't go flying. I used a can of R-134 duster spray. (If you let the solvent evaporate slowly large crystals can form from dissolved materials.)

Drying the sample
Image the die under a microscope to see if you've etched far enough. (The die I used in this demonstration was actually a bit over-etched as I paid more attention to camera angles than etch timing!)

The other main delayering method I plan to explore is CMP with colloidal silica. At the moment MTI is sold out, but when a new shipment arrives expect a post on CMP!







by Andrew Zonenberg (noreply@blogger.com) at March 18, 2011 08:08 PM

March 12, 2011

Ignacio Garcia, dingux.com

Running code on the GA330

Check out usbtool here:

http://github.com/iggarpe/cc1800

The CC1800 has 16KB of SRAM located at 0x0010000, and also mapped at 0x00000000 if certain bit of a special register is set. At boot time this bit is clear and ROM is mapped at 0x00000000.

The A330 can be made to boot from SD card by pressing DOWN during power up. In this mode the ROM code will load sectors 2-17 into SRAM at address 0x00100000 and execute. The code in rom.bin will then in turn execute the USB boot code, and from then on you can use the usbtool above to upload and execute your code through USB. Much more convenient that moving an SD card around.

Note however that since the USB boot code is not executed from ROM but from SRAM, the same SRAM you will be uploading to (at least until the SDRAM controller has been initialized), some restrictions apply: the USB boot code code in rom.bin is loaded at 0x00100000, and first thing it seems to do is move itself to 0x00102000, that is, to the second half of the 16KB of available SRAM. This means you can use only the first 8KB for your code AND the stack.

by booboo (noreply@blogger.com) at March 12, 2011 11:07 PM

GA330 unbricking tool

http://www.mediafire.com/?ed998x4zj86c1a2

Mind you, I haven't been able to make it work. I managed to brick one of the two GA330 that ChinaChip kindly provided, but haven't been able to restore the firmware. Not that I care much anyway since I don't really need the native firmware running for porting the linux kernel.

Note that the USB boot mode is not used in any of the CC1800 based machines that I know of, due to a ROM problem, so actually you will be using SD card boot to run a fixed USB boot code.

To prepare the boot SD card in windows use the ChinaChipSDBurnTools.exe utility. First argument is the drive letter, second argument is rom.bin file. Example:

ChinaChipSDBurnTools.exe I: rom.bin

This will just write the rom.bin file to sectors 2-17 in the SD card, so it will probably destroy the contents of the card. From linux you can use the dd command. Assuming the SD card drive is /dev/sdi, then:

dd if=rom.bin of=/dev/sdi bs=512 seek=2

You can actually make a boot SD card which is also usable for storage: just make it so that the first (and possibly only) partition starts somewhere beyond sector 17. How to do that is beyond the scope of this post.

Insert the card and plug the USB cable while you press DOWN. The GA330 should be now in USB boot mode.

From there on you need to use the Burning_tool(CC1800 V1.14)_W35.exe tool. The first big button will install the USB driver (at least it will copy the files in C:\Windows\System32\ChinaChipUSB, you might need to point windows to that directory when new hardware is found). The second big button starts the burn process, which you can only do after selecting the IPL, DL and HXF firmware files.

If you succeed unbricking your GA330 with this tool, please report in the comments.

EDIT: if you happen do have your serial console connected, please log and send me the output during the unbricking (57600 8N1, the code in the SD card that implements the USB boot mode will output a few lines 115200 8N1, so you'll see some garbage).

by booboo (noreply@blogger.com) at March 12, 2011 08:35 PM

March 03, 2011

Andrew Zonenberg, Silicon Exposed

Microchip PIC12F683 teardown

I'm going to kick off the meat of this blog with a teardown of a chip that has a special place in my memories - the first microcontroller I ever worked with, the Microchip PIC12F683. It's an 8-bit RISC microcontroller made on what looks like a 350nm 3-metal process, with 14 bit wide instructions and a fairly nice set of peripherals:
  • 2K words program Flash
  • 128 bytes SRAM
  • 256 bytes data EEPROM
  • Two 8-bit and one 16-bit timer
  • Four-channel multiplexed 10 bit A/D converter
  • Comparator
I decapped one of these a few months ago and imaged it at 400x magnification. Pin 1 is at the top left. (At the time I was still experimenting with panorama stitching techniques so there are a few alignment glitches.)

PIC12F683 metal 3 with passivation, magnified 400x

The glass layer (reddish) was quite annoying and made it hard to resolve traces so I decided to remove it using my standard wet-etch procedure (heating in 3% HF). I'll be writing about this process in more detail over the weekend.
PIC12F683 metal 3 after wet etching, magnified 400x
We now have enough information to create a floor plan of the chip:
  • The large block at bottom center (surrounded by power rails with 14 white capacitors at the bottom) is the program flash. Each capacitor is part of a charge pump used to generate high voltage for erasing one bit of flash.
  • Immediately to the left is the RAM.
  • Above the RAM is the EEPROM. As with the flash, there is one capacitor per bit of memory for high voltage generation.
  • Above the flash, and slightly to the right, are the configuration fuses. Each of the small red plates is part of a single configuration bit.
  • Analog peripherals are in an L-shape along the top and right sides
Top portion of PIC12F683 configuration fuse array (metal 3 after etching off glass)
The configuration fuses are single cells of EEPROM-style memory storing data such as the clock oscillator source and code / data protection bits. As with most other PICs, when the protection bit is in the "1" state the chip operates as normal; in the "0" state attempts to read firmware or EEPROM respectively via ICSP return all zeros. Configuration fuses can always be read.

EEPROM is typically susceptible to erasure (all bits set to 1) by strong UV light and the configuration fuses are no exception. If we can expose just the fuses (and not the flash or EEPROM, whose data we presumably want intact) to UV, the code protection can be removed and the firmware reverse-engineered using standard software RE tools. Note that PICs are thus a slightly easier target than Atmel chips. Atmel fuses in the "1" state indicates the chip is in the locked state (i.e. UV will set rather than clear the fuse).

Enough talking, time to try pwning the chip! As of this writing my decapping lab is offline, but Brooke Hill from Jimnson Research was kind enough to decap a few samples I sent him.
Decapped PIC12F683, magnified 10x. Rotated 90 degrees counterclockwise from other photos.
The first step was to plug the chip into a breadboard and verify it still worked. (Although decapping is normally a fairly low-risk procedure, bond wires do occasionally work loose during the rinse or cleaning steps.) The test firmware I used was a short piece of assembly that blinked an LED on GP2, and had the code-protection bit set.

I then laid down a mask over the memory areas I wanted to protect. I used the old classic, black nail polish applied with a lint-free swab under a stereo microscope. The brand of polish I purchased turned out to be very thick and gooey; in the future I intend to thin it with acetone for a more even coating.

Halfway through applying the mask
At this point the difficult work was over. I placed the chip inside my homemade UV erasure box, powered by two germicidal fluorescent bulbs.
UV exposure system
Two hours later the PIC was removed from UV and put back in the breadboard. I attempted to verify memory integrity with my PICKit 2.
Success! Program memory and EEPROM are undamaged (and unprotected) while configuration fuses read as all 1s.

Although the code protection on the PIC12F683 is clearly broken I am not finished with it; as an educational subject has not outlived its usefulness. Stay tuned for a future post with gate- and transistor-level analysis of interesting areas!

by Andrew Zonenberg (noreply@blogger.com) at March 03, 2011 10:46 AM

Welcome

Hello readers, and welcome to my virtual laboratory!

I am an undergraduate computer science student at Rensselaer Polytechnic Institute (beginning my PhD this the fall) with a wide variety of technical interests. The focus of this blog is my research into integrated circuit reverse engineering.

While many hardware reverse engineering blogs (such as that of Tarnovsky) are primarily focused with defeating configuration fuses and anti-tamper circuitry, I hope to cover a wide range of topics including these as well as general CMOS logic and sample preparation techniques.

For the skeptics among you, the right to reverse engineer ICs is protected by United States copyright law (17 USC 906), which states that it is not an infringement of a mask right for "a person to reproduce the mask work solely for the purpose of teaching, analyzing, or evaluating the concepts or techniques embodied in the mask work or the circuitry, logic flow, or organization of components used in the mask work".

by Andrew Zonenberg (noreply@blogger.com) at March 03, 2011 05:06 AM

March 01, 2011

Geoffrey L. Barrows - DIY Drones

ArduEye: Brutally minimalist (but quite fast) vision sensor using an Arduino

We are finally having manufactured a "shield" board for the Arduino platform that interfaces a Centeye image sensor with an Arduino to form a true (if simple) "smart sensor". This particular version is about a simple as you can make it:

Shield Board: The board itself is a simple 2-layer board, and can be connected to either a full-size Arduino board (we've so far tried the Duemilanove and the Pro), or a mini-sized version (we've tried Sparkfun's Pro Mini). You need a 5V board to power the image sensor.

If one doesn't want to use the board with an Arduino, it is of course possible to just use it as a breakout board for the image sensor chip. The board design is open source.

Image Sensor: The shield board is compatible with any of Centeye's current image sensor chips, but for the above version we are using the Tam series- These are very simple image sensor chips requiring only five lines- Ground, Power, Clock, Reset, and AnalogOut. When you pulse Reset, a counter on the chip points to the first row, first column pixel, which is output as an analog value. Pulsing the Clock line advances the counter to the next pixel row-wise. That is it. The chips are available in two resolutions- Tam2 at 16x16 and Tam4 at 4x32, the latter with rectangular shaped pixels. I've also taken a leap of faith and decided to publish the schematic of the chip! We've released the analog portion down to the transistor level, and the digital portion down to the gate level.

Right now we have about 200-250 each of the Tam2 and Tam4 chips in stock, in bare die form.

Optics: The sensor will be shipped with a micro lens (about 1.6mm)- we can ship the board with the lens mounted or unmounted. In the latter case the Tam4 chip will be open and exposed, which is appropriate for people who want to use their own lens.

Sample code: I've also written a sample Arduino sketch that illustrates acquiring an image, obtaining a fixed pattern noise mask, and computing one dimensional optical flow from the 4x32 Tam4 chip. By cutting out the serial monitor and acquiring/computing optical flow on just one 32-element row, we obtained more than 200 frames per second- I think more is possible with further optimization. The source code is "open" and is intended to be a starting point for developing your own application.

Uses: I didn't design this board for any specific application, but it should be able to do some things of interest to robotics. I've come to appreciate that it can be difficult if not impossible to make a "one size fits all" sensor, even if supporting just one mode (like optical flow). This is because there are many parameters that must be adjusted for each application. Thus for this board we are taking a different approach- rather than try to hide the optical flow computation from the user, we want the user to be fully aware of what is going on. In order to really use this sensor, you'll have to do some hacking of the code to tailor it to your application. I'll be honest- this is not for those who are afraid to hack a bit.  But I think the Arduino environment makes it very easy to hack, play around, and try different things. I'd appreciate your feedback on this approach.

As for what I think the board will ultimately support (with some hacking)- in the context of robotics and drones I think that things like wall following or basic terrain following should be doable (if on a forward moving platform). Several sensors should support some basic obstacle avoidance against large obstacles. Fulfilling the role of an downward optical flow sensor for a quad might be doable, but would require some careful optimization and algorithm tuning. I don't think impossible though- If the classic 1980's video game Defender could run, with rendering, on a 2MHz processor, then I would imagine adequate optical flow for a quad could be done with 16MHz. Please note though that I haven't tried any of these things yet with this board.

Just so that you know megapixels aren't needed- here are a few facts to consider:

1) Most flying insects have from several hundred to several thousand pixels. They have at most "kilopixels"! 2) We demonstrated altitude hold in 2001-2002 with 16 to 88 pixels, and obstacle avoidance in 2003 with 264 pixels total. 3) We also controlled the yaw angle of a helicopter with 8 (eight) pixels.

For the released files (including the Tam chip schematic), please visit this posting at Embedded Eye. For other details including purchasing, please visit this page at Centeye. Current asking price is $100 per board plus $9 shipping/handling for US customers. We hope we can lower this price in the future as we learn to automate working with bare die and the lenses in the current manner we use.

Please feel free to ask questions.

by Geoffrey L. Barrows at March 01, 2011 05:13 AM

February 19, 2011

Ignacio Garcia, dingux.com

GA330 native firmware SDK

This might very well be old news, but just in case.

You can find the native firmware SDK for the A330 here:

http://code.google.com/p/mp4sdk/downloads/detail?name=A330-SDK-Setup-20101106.exe&can=2&q=

It's an "unofficial" release.

by booboo (noreply@blogger.com) at February 19, 2011 02:10 AM

February 17, 2011

Village Telco

In a Village Telco Minute

Over the last couple of years we have struggled to communicate the message of the Village Telco simply and succinctly.  Thanks to the creative folk at BlinkTower, we think we’ve finally succeeded.

Comments welcome.

by steve at February 17, 2011 11:12 AM

February 15, 2011

Ignacio Garcia, dingux.com

Booting the GA330

Just a few tech comments I left out in the previous post due to lack of time... but after a quick clarification about ChinaChip:

They have a lot of open fronts in a very competitive market and a limited set of resources, I assume that if the project has been put on hold is because they had no choice. Note however that they're still providing information and support, but with some limitations.

As I said, I have schematics, docs (which suck but are just what they have) and BSP code. I'm now working on the tools to boot code on the GA330 through the USB port, and as soon as I get it working and a kernel booting with a serial console, I'll publish it all (but I still believe it will be of little use to other developers without the docs and BSP). I don't like to be the bottleneck, but that's how things are now.

Now for the tech details:

The CC1800, like the JZ4732 and other SoCs alike, has several boot modes implemented in the internal ROM. The code checks the state a of a few pins and then proceeds to boot from NAND, NOR, SD or USB. Actually, USB boot means the ROM code sets up the USB port in device mode and waits for instructions. You can get CPU info, upload code to SRAM, and execute it, that's pretty much all.

Note that I wrote SRAM, not SDRAM. That's why you usually need a two stage process to boot code via USB: upload and execute a tiny piece of code to SRAM which configures and initializes the SDRAM controller (and some other peripherals) so that memory is accessible, and then upload and execute the large piece of code, the kernel, to SDRAM.

Surprisingly, in the two CC1800 based machines I have, the GA330 and an HD8900, the bootsel[2] pin is tied to 3.3V. This means you can't enter USB boot mode. The bootsel[1] pin is connected to the down input of the d-pad, which means that switching the GA330 on while keeping down pressed you enter SD boot mode. In this mode the CC1800 loads the content of sectors 2-17 (a total of 16 sectors, 8KB) from the SD card to SRAM and executes it.

It turns out that due to some errors in the CC1800 design (not sure if it's the silicon or the ROM code) the USB0 port being used wasn't stable. Since the ROM code can't be changed, the hardware designers were forced to use some other alternate boot mode, and went with SD. Now, if you put in the SD a modified version of the USB boot code in ROM which uses USB1 instead of USB0, you're back on track and can complete the flash burn process through the USB1 port.

(note that in SoC of this complexity it is very usual to have tens or even hundreds of errors which are generally described by the manufacturer together with workarounds in the corresponding errata sheets, see the LM3S9B96 from Texas Instruments for instance)

Needing to have an SD card inserted to enter USB boot mode is a small inconvenience for the manufacturer, but can be a blessing for final users, because:

  1. It makes a dual boot unnecessary. You will be able to boot dingux from the SD card without any modifications to the GA330.
  2. Even if a dual boot is necessary, the install method would require only an SD card (no more USB driver madness).

For us developers it's an insignificant inconvenience. We need USB boot because it makes compiling and testing code very easy, and we just happen to need an SD card inserted all the time. Note that the partition table in sector 0 of the SD card is not affected, so you can set the first partition to start anywhere beyond sector 17 and have an usable data partition while still keeping the boot code in sectors 2-17.

by booboo (noreply@blogger.com) at February 15, 2011 11:49 AM

February 12, 2011

Ignacio Garcia, dingux.com

Update on dingux for the GA330

It's been way too long since the last entry. First I delayed it a bit just to have something actually substantial to write, and then then stretched it a bit longer, and well, here we are.

After coming back from China I had a list of tasks I had agreed with the ChinaChip management and engineers to get dingux up and running on the A330 in the near term. There was also the possibility of they sponsoring the development. To make a long story short, I was willing to anything between working on my spare time for free and being hired full time, and I was expecting something in between: I'm way too expensive for full time dedication (plus it's probably too soon for that) and while I'd be happy to work in my spare time, that would of course come with no commitment to any schedule or even to completion.

Since then, there's been some kind of priority rearrangement in ChinaChip and the "dingux on the A330" project as been put on hold. That means that the engineers that would do their part (mostly adapting their firmware to allow comfortable dingux installation in the internal flash) aren't available at the moment to work on it. And delivery of the required information to get a kernel port to the CC1800 running has been... well... slow. I got the most important part a couple of weeks ago. And no sponsoring. So I'll do my best but again, don't hold your breath, since as of now my job and my family allow only for a very limited amount of spare time.

The partial CC1800 programmer's manual I've got is 38 pages long. And consists of a couple of paragraphs describing each peripheral and tables of registers. Only the names of the registers and the bit fields. All in Chinese. The Texas Instruments OMAP3503 programmer's manual is +3000 pages. Go figure.

Not that I'm really complaining, since I truly believe that's what they have from the people that actually designed the CC1800. The cheese is in the BSP, which is code, which means if something is not properly done or downright broken you can't fix it, since you don't have a reference programmer's manual.

I wanted to end this post with some tech details about the A330 boot process and memory map, but I have to leave now, so it'll go in the next post.

by booboo (noreply@blogger.com) at February 12, 2011 12:30 PM

February 01, 2011

Village Telco

Bo-kaap Village Telco – Part 1

While David Rowe and Lemi Soares have been busy building a Village Telco in Dili, the capitol of East Timor, we’ve also been hard at work in Cape Town building a Village Telco within the Bo-kaap community.  The Bo-kaap is a largely muslim community in the heart of Cape Town.  Many of the residents go back several generations and have fascinating stories to tell.  It is a mix of wealthy and poor and also has a sprinkling of “immigrants” mostly white, artistic types (film-makers, photographers, architects) who have been attracted by the Bo-kaap’s unique character.

In terms of a place to pilot a Village Telco, it sits above the demographic we intended the Village Telco for but it seemed a good choice for a number of reasons:

  1. There is a really strong community.  There are strong social bonds linking everyone in the Bo-kaap and strong social bonds means a strong desire to communicate locally.  This was the strongest motivator for choosing the Bo-kaap
  2. We’re still learning and don’t want to create a dependency on something that is still evolving. The fact that Bo-kaap community is a little wealthier on average than our target community means that although they may value the Village Telco, they won’t be completely stuffed up if something goes wrong as we perfect the network.
  3. It’s convenient.  Tempting as it is to set up a rural Village Telco right away, the Bo-kaap is not many minutes away for me so easy to get to and work on.

At the right you can see a screenshot from the Afrimesh software that we use to monitor the mesh.  Right now we’re up to about 50 nodes in the mesh and the increasing density continues to make things easier and easier.  In the beginning we had to be very careful about long links and used some Ubiquity Nanostation IIs to make some of the long shots.  We also had to be very careful about getting the Mesh Potatoes into a strategic position to pick-up other Mesh Potatoes.  Now, once I get up on someone’s roof, I can usually see a Mesh Potato in some direction so installation is as simple as finding something to attach the Mesh Potato to.  TV antenna’s have proven to be very convenient in this regard.

The installation process for the Bo-kaap has been slow, partly because it took a long time to get production Mesh Potatoes into our hand but also because the Bo-kaap is an old community and the houses in it have evolved more than they have been planned.  Each house is a little exercise in complexity in terms of getting to the roof, finding a cable path down from the roof, finding power near the desire location of the phone, etc.  I’ve got it down to a routine now though.  Having the right tools like a long concrete drill bit for going through walls are simple things that make life a lot easier.

We’re learning a lot as we install the Bo-kaap Village Telco.  We decided to offer 100 Mesh Potatoes to the community in exchange for user feedback on the Village Telco.  In order to build the most useful network possible, we built connections by following social ties, a bit like snowball sampling in research.  We started with a family that ran a cafe and followed their social ties, brothers, sisters, friends, neighbours.  Each new person is at liberty to suggest others.  By following existing strong social ties, the Village Telco immediately begins to delivery high-value connections.  An older mother-in-law that wants to stay in touch with her family who are only a few doors away but it is hard for her to get around.  A mother who recently became a grandmother wants to stay in touch with her daughter.  In each of these cases, they could use a mobile phone to call but like the majority of people in South Africa they are conscious of what time spent on the phone costs them.  A local Village Telco call is free.

Mesh Potatoes can be gateway-ed to other telecom networks and can also offer Internet services but for the time being we are just offering local voice because the devices do that on their own at no additional cost.  Once the community is ready to take over the network themselves and manage external voice and Internet charges, we’ll enable those other features.  Stand by for more from the Bo-kaap Village Telco.

by steve at February 01, 2011 07:59 PM

January 31, 2011

Marcan's Abort, Retry, Hack?

OpenLase hardware and simulator

I apologize for taking this long to post this! I’ve been busy non-stop since 27c3 and never got a chance to get around to it. Finally, though, here it is: the description of the Mark 1 laser projector that I use with OpenLase.

But wait, there’s more! If you don’t have the hardware and don’t want to build it, or you want to try out OpenLase, or you want to be able to mess around with it on the go, you can now do that. There’s a new OpenGL-based simulator in the OpenLase tree. It works off of the JACK data (so you still need JACK) and it tries to simulate the dynamics of my laser scanner, including brightness effects and some of the physical limitations of the galvos. Here’s a comparison of the simulator vs. the real thing:


I’m aware that documentation on the software is still sorely lacking. Please bear with me while I get my act together and write that up :)

by marcan at January 31, 2011 07:48 PM

January 30, 2011

Dieter Spaar

GPRS Air Interface

To get a better understanding of how GPRS looks like at the air interface, I implemented some first experimental code in Airprobe (this is not yet ready to be released). The output of this code are the RLC/MAC blocks on the downlink (no uplink yet). As far as I am aware, WireShark cannot decode RLC/MAC yet.

The GPRS air interface is not that different than "standard" GSM (signalling or voice). The PDCH (Packet Data Channel) uses its own multiframe structure with a length of 52 frames, the biggest difference are four coding schemes (CS-1 to CS-4, CS-1 and CS-2 use puncturing) which are chosen depending on the quality of the radio link. If the link quality is good, a coding scheme with less forward error correction and more information bits is used which results in a higher data rate. As a side note, you can test how good your receiver really is if CS-4 is used (very good radio link quality, no forward error correction at all), you should have nearly no bit errors in the decoded data (the phone also receives error free data, otherwise CS-4 would not be used).

I have not yet implemented decoding EDGE, besides other coding schemes EDGE can also use a different modulation (8-PSK instead of GMSK).

Please note that being able to decrypt the A5 encryption does not help with GPRS, it does not use A5 encryption at all, it uses its own encryption algorithm (GEA) at a higher level. If you want to experiment with GPRS encryption, the easiest to start with is probably using a GPRS setup with OpenBSC plus the nanoBTS and look at the traces to the SGSN with WireShark (you have to implement a GPRS encryption algorithm in osmo-SGSN first, the specification of GEA3 is publicly available).

January 30, 2011 01:00 AM

January 25, 2011

Dan Strother

System modeling/verification diagram

As alluded to in a few of my other posts, I’m working on developing an open-source FPGA-accelerated vision platform. This post is a detailed overview of the project’s architecture and general development methodology. Future (and past) posts will elaborate on … Continue reading

by Dan at January 25, 2011 05:28 AM

Dieter Spaar

TETRA Air Interface

If you are interested in how the air interface and the lower levels of TETRA work, you should have a look at the http://tetra.osmocom.org/ website.

My contribution so far was to search for a suitable demodulator (TETRA uses PI/4-DQPSK) which I found at the OP25 project (the author of the demodulator is KA1RBI).

I also implemented some "proof of concept" code which allows decoding speech traffic and converting it to raw audio using the TETRA reference codec. Please note that this cannot be used to listen to encrypted TETRA traffic, it only works if no encryption is used.

January 25, 2011 01:00 AM

January 20, 2011

Geoffrey L. Barrows - DIY Drones

Kicking off two open source optical flow / vision sensor projects (Finally!)

I would like to "formally" announce two open source projects related to optical flow / programmable vision sensors. These are based on some of the optical flow techniques developed at Centeye, but in the spirit of "open source" are meant to be hacked/modified/copied any way a user deems fit. In both cases, the source code has been opened up under a modified FreeBSD license, while the board design has been released under a Creative Commons Attribution-ShareAlike license, the same license that applies to the Arduino boards.

The first project is the CYE8 sensor, an optical flow sensor based on an Atmel ATmega644 (possibly to be replaced by an ATmega1284) 8-bit processor, and using a Faraya64plus sensor head. (A "sensor head" is a vision chip wire bonded to a 9mm x 9mm PCB with a board to board connector on the other side.) We fabricated our first two iterations last year (the first one described here), and are now readying the third iteration this month.

The hardware of the second project was introduced in a recent blog post and is based on the Sparkfun Arduino Pro Mini platform (which uses a similar but smaller Atmel microcontroller) and comprises a simple shield board that interfaces the Arduino with a sensor head. Currently we have used only a FarayaSmall sensor head, but this board will support other chips as well.

At the current time, these projects are hosted on another open Ning network Embedded Eye, since we are trying to capture a broad set of applications beyond drones. If these projects take off, we can set up Huddle spaces accessible across both Ning networks, or move the project elsewhere. (I'll take suggestions- I'm still learning about how to do projects like this.) The CYE8 project is located here and the Arduino-based project is located here. These forum pages include initial board designs and source codes.

Based on interest, we will likely also launch projects built around an Atmel AVR32 processor (faster than the AVR8's) and/or an XMOS quad-core processor (if you have real need for speed).

One common theme of these two projects (which has strengths and weaknesses) is that they utilize vision / image sensor chips designed by Centeye. (This is not a requirement of the license- it is just how they were designed.) The strengths are that since we designed the vision chips, we can probably reveal as many details of the inner workings of these chips as we want. We all have heard complaints of chip manufacturers being too vague about what is inside, so I hope that this is a welcome change. The weakness is that we basically have to burn new wafers every time we want more sensors, so they are not as available as, say, a part from Digikey.

We are actually going to start a new run of silicon soon with the intent of increasing manufacturing quantity. It is tempting to use this as an opportunity to explore semi-open chips designs. I'd be happy to share a (virtual/real) beer with anyone interested in discussing (whether here, at EE, or directly) the various issues associated with the design and manufacture of chips of this type.

I look forward to speaking with everyone soon!

Geof

by Geoffrey L. Barrows at January 20, 2011 01:00 AM

January 12, 2011

Geoffrey L. Barrows - DIY Drones

Make your own plastic mini lens, part 2

In a recent post I described some simple acrylic lenses I made using a simple press-molding technique. The methods were crude, but the results weren't too bad. Also, I had designed an assembly containing four minor variations of these lenses and submitted that for fabrication over the holidays. The injection molding step was a bit of an experiment- rather than using a full optic-grade firm, which would have cost us well into the five figures to try, we used U.S. based Protomold, who was able to create this mold in two weeks and make 100 assemblies (400 lenses) for a bit more than $2k. I again selected acrylic as the resin material for these lenses.

The picture above shows the parts as they came back (top and bottom side). Below shows a close-up of two lenses cut out from the above assembly.

 

The real test, of course, is that image quality. I mounted these lenses onto some of our image sensor chips using the same methods as that discussed in the above-quoted recent post, painted on an iris, and sealed the chip up. Below is a picture of me waving at the camera in 32x32 resolution.

 

I also took another picture of my backyard with a different chip and a different setup at 90x90 resolution. The field of view was roughly between 70 and 80 degrees, thus the pixel pitch was less than one degree. The image quality in this latter picture was not as good. Two factors probably contributed to this- First the finer pixel pitch could have exceeded the limits of the optics, second my method for removing fixed pattern noise was less accurate in this setup. Right now I do not know which of these two factors dominate.

One comment- There was in fact some shrinkage in the lens, on the flat bottom part that gets placed onto the chip. However this was small and easily filled in with the optical adhesive, which has almost the same index of refraction as acrylic.

One lesson learned regarding the injection mold design: There are four slightly different lenses in the above assembly. The difference is in the total thickness, with sequential lenses different by 25 microns. (It turned out this difference was moot compared to the varying thickness due to the amount of adhesive used.) This was to allow me to experiment with variations to compensate factors such as shrinkage and enlarging of the mold through polishing. However I made the mold family perfectly symmetrical (other than the small variations in lens thickness)! When I got the parts back, it was hard to find out which lens was which! Fortunately I found the sprue (where the plastic charge gets injected into the mold) and with careful eyeballing under a microscope, identified the lenses. But the lesson learned is that I should have added a slight marking or asymmetry to help me identify right from left.

Overall I am pleased with the results. For pixel pitches of about two degrees per pixel and up, this technique is adequate. Two degrees per pixel may not sound like much, but many flying insects have this type of resolution and do quite well. It may be that with the right iris and better fixed pattern noise cancellation, I could get the sharpness down to one degree or pixel, but this will have to wait.

Here again is the link to a zip folder containing the Alibre files for the mold: CYE_LensMold_Untested.zip

by Geoffrey L. Barrows at January 12, 2011 01:45 AM

January 10, 2011

Geoffrey L. Barrows - DIY Drones

Arduino Pro Mini optical flow sensor

This is a follow-on to an earlier post about an Arduino-based optical flow sensor prototype. Here I actually constructed a complete sensor that could actually be integrated into a robotic platform. To achieve a smaller size, I used an Arduino Pro Mini board from Sparkfun, and added a "shield" to interface that with a Centeye image sensor and optics. The breakout of parts is shown above- The complete sensor is shown next to a US Quarter. You can also see the individual blue Arduino board and the green "shield" board. On the right are individual "sensor heads" which are basically small PCBs holding the image sensor chip (here the "FireflySmall"), optional optics, and two capacitors. The sensor head plugs into the green shield board via a Hirose DF30 board to board connector. Three sensor heads are shown- on top is a sensor head with optics, in the middle the board-to-board connector side, and on the bottom the image sensor chip side.

 

I wrote a simple Arduino script to grab pixels from the vision chip (configuring it to grab rectangular pixels), compute 1D optical flow using a variation of Srinivasan's "image interpolation algorithm", and dump a display of the optical flow to the serial monitor. (Some of you may know Professor Mandyam Srinivasan as the Australian biologist who has studied honey bee navigation, in particular how honey bees use optical flow to close control loops using simple but elegant heuristics.) A simple video of the sensor is shown below. I've also attached the Arduino script code, in case anyone is interested.

 

 

PIO12Firefly_ProMini_LinearOF.pde

by Geoffrey L. Barrows at January 10, 2011 02:32 PM

January 09, 2011

Methril

Sumarizing 2010

After being so "silent" in my Open Source world, i need to sumarize the last year.

It could look that i leave the FOSS world, but nothing further from the truth. I've been FOSS advocate at my actual company, improving our FOSS ecosystem.
I had to fight in some fronts of the Computer Science that i never had contact with before:

  • I had a combat with binutils/gcc/newlib for ColdFire v1 devices, and i win (we get a multi platform toolchain ready to work), both Windows and Linux builds are working fine.

  • I also deal with other compiler: SDCC. It was hard, but it's our official PIC compiler :D

  • Configure and make an application with RTAI and comedi to measure quality and some important parameters of our physical final products (it was a working proof of concept, we need to improve it a little bit, but it's working). In the while i have to evaluate the use of Scicoslab, RTAI-Lab, Scicos-Hil, Scilab, Xenomai, RT-PREEMPT patch and robotics frameworks like Orocos.

  • I get hands dirty with LTSP, as sys-admin, and i configured some servers and services.

  • And some other propietary stuff or internal work.


Unfortunately, i didn't found time to work with Efika-MX, Ben-NanoNote and carry on hacking my Neo Freerunner (between all my hw toys), neither post some words about my advances. But, at the end of the day i did nice FOSS development, and i also touch the Linux kernel, in a personal way.
So... 2010 was not a bad year :)

by Methril (noreply@blogger.com) at January 09, 2011 02:53 PM

January 06, 2011

Zedstar

Searchable USB flash drives

Recently I was revisiting a powerful open source search engine technology on a Ben NanoNote to see how well it performed. Bearing in mind the NanoNote is only equipped with 32MB of RAM and a 336MHz MIPS processor it performed admirably. As a proof of concept I took the PDF lecture slides from three MIT OpenCoureWare undergraduate modules and indexed them on the device. This part of the process is time consuming but only needs to take place once. As you can see from the following video (OGG format), searching the PDFs is rapid and there should be no problem scaling to thousands of documents.

One nice feature of connecting the NanoNote to your PC is that you are able to access the search engine through your PC’s web browser. This becomes close to something I have thought about for a while – a copyleft designed USB flash drive with embedded web server and search engine. This would allow you to take your documents with you and view them using a familiar g**gle style search on any PC you get access to (in theory) without relying on the host OS to do the work.

by john at January 06, 2011 09:35 PM

December 22, 2010

Geoffrey L. Barrows - DIY Drones

Make your own plastic mini lens

One of my side projects has been to develop an open-source visual motion / optical flow sensor that may be usable in all sorts of devices, whether robotic related or not. I've found though that one of the most difficult parts of developing tiny vision sensors is finding the right optics. Ideally we want something that is cheap, easy to mount, has a decent field of view, and yet creates a reasonable image. For higher resolution images (hundreds of pixels across or more) and image sensors four or more millimeters wide, there are many excellent lens assemblies available from companies like Sunex. (We've used and still use their products in higher resolution sensor designs, always with success.) However there is really nothing available for image sensors a millimeter wide. Printed pinholes do work, but don't let through as much light. This post highlights a little project to design a decent lens for the Faraya64 image sensor, whose focal plane measures about 1.1mm across.

 

The basic concept (shown below) is to make a simple "plano convex" lens, with the curved surface (e.g. "bump") facing outward and the flat section resting on an image sensor. I decided on acrylic as an optical material, since it is light, easily formed, and for our purposes is as good as glass. An opaque "stop", perhaps made of paint or a piece of black plastic, would fit over over the lens and allow light to reach the image sensor through only the center of the front bump.

 

For the front surface I decided to use a spherical shape- this is a pretty traditional shape for 99% of all lenses out there. I used the ray tracing and optimizing capabilities of Zemax, a commercial optics design software package, to find an optimal shape. I found that to provide the 1.1mm image sensor chip with a 60 degree field of view, the dimensions shown above were optimal: The front bump would be a sphere with a radius of 0.61mm, while the total thickness would be 1.6mm. I also allowed the optimizer to try aspherical conic shapes (e.g. parabolas, hyberbolas, ellipses) but found that I did not gain much performance over that of a sphere and so decided to keep it simple.

 

The two figures below show two plots generated by Zemax. First is the lens layout, showing the 0, 10, 20, and 30 degree off-axis rays. Second is the spot diagram showing how the image would be blurred from ideal, for red, green, and blue rays! The pitch between pixels on the Faraya64 image sensor is about 17.1 microns, so the RMS blurring shown here was not quite optimal but was good enough for me to go on.

 

I decided next to first try forming a lens by hand by stamping it. This technique won't match the precision from the Zemax simualtion, but I thought it would be fun. Using Alibre, I designed a simple stamp that would produce a lens of the above shape. I had this stamp CNC machined from aluminum by the company FirstCut.

The stamp came back, but it needed more finishing. Basically the part of the mold that forms the spherical lens bump needed to be polished to "optical quality". I didn't really know what I was doing, but I did manage to find a way to polish this area! I used a Dremel tool, a toothpick, and some polish (Simichrome Polish by Gesswein), put a dab of polish in the hold, and used the Dremel tool to spin the toothpick. After about 5-10 minutes of spinning and moving the toothpick around, I managed to get the spherical surface polished to a decent quality, as shown below. I also cut channels to let the plastic escape as the stamp was being pressed down. The result is shown below.

 

Now comes the fun part- the pressing! I don't have any photos from this step, but I'll try to describe the technique that worked best. I placed a pyrex dish on a hot plate, and set the heat to low-medium. After a few minutes I then placed a piece of aluminum foil on the hot plate, and a tiny piece of acrylic onto the aluminum foil. A few minutes later the acrylic piece got soft, and I pressed down onto it with the stamp. I lifted the stamp out, and the pressed acrylic piece (and the aluminum foil) came up with it. The picture below shows the business end of the stamp, the pressed piece of acrylic, and a U.S. Quarter for size comparison. If you look carefully, you can see the spherical bump in the middle of the piece of acrylic. You can also see extra plastic around the outer side of the lens- I cut that away with a utility knife.

 

I'd say that about 40% of the lenses I pressed turned out OK. Below and at the very top of this post are front and back pictures of some of the final lenses produced.


The next step is to mount the lens on a chip. Basically I used a UV curable optical adhesive (Norland 63) to glue the lens directly onto the chip. Then I used black modeling paint to form the "opaque enclosure". Finally I added more optical adhesive to encapsulate everything (except for the lens bump). The result is shown below- you'll see the lens mounted onto a Firefly chip (similar to the Faraya) and that mounted on a small 9mm x 9mm PCB. If you look closely you can also see the wire bonds that connect the chip to the PCB.

 

How was the image quality? Actually much better than I expected, especially since the flat side of the lens was not perfect. The optical adhesive's index of refraction is similar to that of acrylic, so I think together they helped smooth out some of the imperfections. Below is a screen shot- the quality is certainly good enough for 32x32 images, and I think with refining can be further improved.

 

So now the final step is to automate this process. Rather than press molding by hand, injection molding is the way to go for quantity. Below is a family mold with four slightly different variations of the same lens. This is currently being fabricated by Protomold. I should get parts back in the second week of January. I'll report back on this in a few weeks!

 

by Geoffrey L. Barrows at December 22, 2010 12:09 PM

December 18, 2010

Antitronics

I’ve published my remaining knitting machine files

I had published my floppy drive emulator for the brother knitting machine, and some other information, using the wiki here at antitronics. This was sub-optimal from the beginning, and since Lady Ada published some of that in her git repo here: https://github.com/adafruit/knitting_machine, I’ve been intending to get more of my files out there. Limor’s repo seemed like the best place to put them, and she’s graciously allowed me to add them. What documentation I’ve created about the brother data format is in there, as well as all the hacked-up tools I used to help with the reverse engineering. There’s nothing there for anyone wanting easily usable end-user applications, sorry about that.

As usual, I’d love to hear from anyone who finds these to be useful.

Steve

by sconklin at December 18, 2010 07:57 PM

December 13, 2010

Zedstar

A dynamic data encoder for embedded systems

I personally view Scheme as a good extension language. Something that can be embedded into C code to ease the pain of doing everything in C. I am interested in exploiting this concept on embedded systems where there is a lot of fooling about to make a binary. I still intend to produce binaries and reuse the large amount of existing C code out there. However, I want to script the network communication and in particular the structure of the network packets. I have periodically been working on a tool that attempts to support this. This summer I intend to get rid of the old C code in this project and rewrite it entirely in Scheme apart from the low-level encoder/decoder which will remain in C. In this white paper I attempt to describe the work.

**update**

This white paper has now be superseded by the paper “Everything counts in small amounts“.

by john at December 13, 2010 06:58 PM

December 04, 2010

Ignacio Garcia, dingux.com

Clarifications on previous post

I'm not sure I've explained myself properly, since I totally agree with the comment posted by Xeatheran, but he failed to notice.

Using his words, people buying the A320 and similar devices want an emulator priced around $100. Any feature that significantly increases the price would make it have to compete with the other more expensive linux based consoles (Wiz/Caanoo come to mind) or with the godzillas of the market (NDS, PSP).

So, any wished feature must be such that doesn't increase the price significantly:
  • Better processor: by next year, the CC1800 will be obsolete and underpowered compared to other competitors in the PMP market. The CC2000 will be a bit more expensive, but here they have no choice but to move on or lag behind. Note that the CC2000 has a powerful GPU. More details upon the official anouncement.
  • 256MB: this was already planned before I suggested it. Note that the CC2000 processor uses DDR RAM, whose widespread usage makes it cheaper than the SDRAM used by the JZ4732 and CC1800. This means 256MB in the next generation consoles may probably cost the same or less than 64MB in the current generation consoles.
  • A 480x272 4.3" LCD screen is not much more expensive than the A320 LCD, and it would make a big difference, at least for me. I find the A320 and GA330 screens too small. Problem here is that if you need a multiple of 320x240, you'd have to go for an 800x480 4.3", which I believe will be not just a little but much more expensive.
  • It should be obvious: either powered host USB type A or SDIO. Not both. My choice here is host USB, because dongles are way cheaper and more accessible than SDIO cards. But they pointed out that it may be impossible to fit such a bulky connector in the design. Maybe the PCB cutout would solve this. Anyway, it would increase cost just a little bit (mostly due to the USB power DC-DC converter), but you are also saving by removing the 2.4GHz radio from the design, which also as I pointed out, may be a big advantage when (if) time comes to pass CE/UL certification.
  • Analog nubs: if they are aiming, besides emulation, to get software studios to develop games for this console, it is a must. A GPU capable of, for example, running FPS games, would make no sense without analog nubs.
The rest of features I mentioned are essentially free (except licensing Doom, Duke, etc).

So: a CC2000 SoC (800MHz, GPU), 256MB DDR RAM, 4.3" LCD, analog nubs and powered host USB type A port. This would make a killer emulation console and stay in the same price range where the A320/GA330 are.

Camera, touchscreen, WiFi, etc, are nonsense. If you want too shoot crappy photos (most integrated cameras are crap) or browse the internet, use your phone or buy a tablet.

by booboo (noreply@blogger.com) at December 04, 2010 10:50 AM

Capn's Tech

USB Doodad 5: Working USB

Now that I know the processor on the Doodad is working, I want to try out USB.  As we'll be using a software USB library, it's important that we test this out as soon as possible, in case we need to make circuit changes, or it's unreliable, or it just doesn't work at all.

The software USB stack we want to use is called V-USB:

  http://www.obdev.at/products/vusb

I downloaded V-USB and extracted it:

[mjd@onza src]$ wget http://www.obdev.at/downloads/vusb/vusb-20100715.tar.gz
 --2010-11-23 18:17:39--  http://www.obdev.at/downloads/vusb/vusb-20100715.tar.gz
Resolving www.obdev.at... 78.46.114.187
Connecting to www.obdev.at|78.46.114.187|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.obdev.at/ftp/pub/Products/vusb/vusb-20100715.tar.gz [following]
--2010-11-23 18:17:40--  http://www.obdev.at/ftp/pub/Products/vusb/vusb-20100715.tar.gz
Reusing existing connection to www.obdev.at:80.
HTTP request sent, awaiting response... 200 OK
Length: 417848 (408K) [application/x-gzip]
Saving to: “vusb-20100715.tar.gz”

100%[======================================>] 417,848     94.8K/s   in 4.3s  

2010-11-23 18:17:45 (94.8 KB/s) - “vusb-20100715.tar.gz” saved [417848/417848]
[mjd@onza src]$ tar -xzf vusb-20100715.tar.gz
[mjd@onza src]$

V-USB comes with several demos.  I chose the mouse demo because it doesn't require any extra hardware such as switches or chips.

I have made some changes to the mouse demo source to reflect that we're using different pins for the USB, and also to make the LEDs blink.  I've also changed the MCU type, the fuses, and the right command to run avrdude for my USB programmer:

--- vusb-20100715-orig/examples/hid-mouse/firmware/main.c
+++ vusb-20100715/examples/hid-mouse/firmware/main.c
@@ -124,9 +124,19 @@

 /* ------------------------------------------------------------------------- */

+static const unsigned char portCMask = _BV(PC0) | _BV(PC1) | _BV(PC2) | _BV(PC3);
+
+static void setLED(const unsigned char v)
+{
+    PORTC &= ~portCMask;
+    PORTC |= (v & portCMask);
+}
+
 int __attribute__((noreturn)) main(void)
 {
-uchar   i;
+    uchar   i;
+    DDRC |= _BV(PC0) | _BV(PC1) | _BV(PC2) | _BV(PC3) | _BV(PC4) | _BV(PC5);
+    PORTC |= _BV(4);

     wdt_enable(WDTO_1S);
     /* Even if you don't use the watchdog, turn it off here. On newer devices,
@@ -148,12 +158,16 @@
     usbDeviceConnect();
     sei();
     DBG1(0x01, 0, 0);       /* debug output: main loop starts */
+    unsigned char a = 0;
     for(;;){                /* main event loop */
         DBG1(0x02, 0, 0);   /* debug output: main loop iterates */
         wdt_reset();
         usbPoll();
         if(usbInterruptIsReady()){
             /* called after every poll of the interrupt endpoint */
+            ++a;
+            a &= 0b111111;
+            setLED(a >> 2);
             advanceCircleByFixedAngle();
             DBG1(0x03, 0, 0);   /* debug output: interrupt report prepared */
             usbSetInterrupt((void *)&reportBuffer, sizeof(reportBuffer));
--- vusb-20100715-orig/examples/hid-mouse/firmware/Makefile+++ vusb-20100715/examples/hid-mouse/firmware/Makefile
@@ -7,11 +7,11 @@
 # License: GNU GPL v2 (see License.txt), GNU GPL v3 or proprietary (CommercialLicense.txt)
 # This Revision: $Id: Makefile 692 2008-11-07 15:07:40Z cs $

-DEVICE  = atmega168
-F_CPU   = 16000000    # in Hz
-FUSE_L  = # see below for fuse values for particular devices
-FUSE_H  =
-AVRDUDE = avrdude -c usbasp -p $(DEVICE) # edit this line for your programmer
+DEVICE  = atmega328p
+F_CPU   = 16000000 # in Hz
+FUSE_L  = 0xff# see below for fuse values for particular devices
+FUSE_H  = 0xd9
+AVRDUDE = avrdude -c avrisp2 -P usb -p $(DEVICE) # edit this line for your programmer

 CFLAGS  = -Iusbdrv -I. -DDEBUG_LEVEL=0
 OBJECTS = usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o main.o
@@ -125,6 +125,8 @@
 clean:
     rm -f main.hex main.lst main.obj main.cof main.list main.map main.eep.hex main.elf *.o usbdrv/*.o main.s usbdrv/oddebug.s usbdrv/usbdrv.s

+main.o: main.c usbconfig.h
+
 # Generic rule for compiling C files:
 .c.o:
     $(COMPILE) -c $< -o $@
diff -x usbdrv -X lufa-dontdiff.txt -u -r vusb-20100715-orig/examples/hid-mouse/firmware/usbconfig.h vusb-20100715/examples/hid-mouse/firmware/usbconfig.h
--- vusb-20100715-orig/examples/hid-mouse/firmware/usbconfig.h    2010-07-16 02:43:47.000000000 +1000
+++ vusb-20100715/examples/hid-mouse/firmware/usbconfig.h    2010-11-22 09:07:33.000000000 +1100
@@ -27,7 +27,7 @@
 /* This is the port where the USB bus is connected. When you configure it to
  * "B", the registers PORTB, PINB and DDRB will be used.
  */
-#define USB_CFG_DMINUS_BIT      4
+#define USB_CFG_DMINUS_BIT      3
 /* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
  * This may be any bit in the port.
  */
@@ -116,7 +116,7 @@
 /* Define this to 1 if the device has its own power supply. Set it to 0 if the
  * device is powered from the USB bus.
  */
-#define USB_CFG_MAX_BUS_POWER           20
+#define USB_CFG_MAX_BUS_POWER           400
 /* Set this variable to the maximum USB bus power consumption of your device.
  * The value is in milliamperes. [It will be divided by two since USB
  * communicates power requirements in units of 2 mA.]

I applied this patch:

[mjd@onza src]$ cd vusb-20100715
[mjd@onza vusb-20100715]$ patch -p1 < ../vusb-20100715-mjd-1.diff
patching file examples/hid-mouse/firmware/main.c
patching file examples/hid-mouse/firmware/Makefile
patching file examples/hid-mouse/firmware/usbconfig.h
[mjd@onza vusb-20100715]$

Then compiled the software:
[mjd@onza vusb-20100715]$ cd examples/hid-mouse/firmware
[mjd@onza firmware]$ make hex
cp -r ../../../usbdrv .
avr-gcc -Wall -Os -DF_CPU=16000000  -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=atmega328p -c usbdrv/usbdrv.c -o usbdrv/usbdrv.o
avr-gcc -Wall -Os -DF_CPU=16000000  -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=atmega328p -x assembler-with-cpp -c usbdrv/usbdrvasm.S -o usbdrv/usbdrvasm.o
avr-gcc -Wall -Os -DF_CPU=16000000  -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=atmega328p -c usbdrv/oddebug.c -o usbdrv/oddebug.o
avr-gcc -Wall -Os -DF_CPU=16000000  -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=atmega328p -c main.c -o main.o
avr-gcc -Wall -Os -DF_CPU=16000000  -Iusbdrv -I. -DDEBUG_LEVEL=0 -mmcu=atmega328p -o main.elf usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o main.o
rm -f main.hex main.eep.hex
avr-objcopy -j .text -j .data -O ihex main.elf main.hex
avr-size main.hex
   text       data        bss        dec        hex    filename
      0       1872          0       1872        750    main.hex

And now I can program the Doodad:

[mjd@onza firmware]$ su
Password:
[root@onza firmware]# make flash
avrdude -c avrisp2 -P usb -p atmega328p  -U flash:w:main.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "main.hex"
avrdude: writing flash (1872 bytes):

Writing | ################################################## | 100% 0.65s

avrdude: 1872 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex contains 1872 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.52s

avrdude: verifying ...
avrdude: 1872 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

[root@onza firmware]# make fuse
avrdude -c avrisp2 -P usb -p atmega328p  -U hfuse:w:0xd9:m -U lfuse:w:0xff:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: reading input file "0xd9"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xd9:
avrdude: load data hfuse data from input file 0xd9:
avrdude: input file 0xd9 contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xff"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xff:
avrdude: load data lfuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

[root@onza firmware]#

As a prelude to trying it I also filed away the end of the board so it can fit into a USB port.

Well after that, I power cycled the Doodad, and the second last LED is lit.  And if that wasn't impressive enough, After I plugged it into my computer's USB port, the mouse cursor started moving around in a large circle, and the LEDs are counting!

Here's what lsusb shows:

[root@onza mjd]# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 1a40:0101 TERMINUS TECHNOLOGY INC.
Bus 001 Device 003: ID 0951:1607 Kingston Technology Data Traveler 2.0
Bus 001 Device 004: ID 0951:1607 Kingston Technology Data Traveler 2.0
Bus 001 Device 005: ID 0951:1607 Kingston Technology Data Traveler 2.0
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 16c0:03e8 VOTI free for internal lab use 1000

The mouse is the "VOTI" entry. The USB vendor ID and product ID can be set in the software.

Now to see the details:

[root@onza mjd]# lsusb -v

Bus 003 Device 002: ID 16c0:03e8 VOTI free for internal lab use 1000
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x16c0 VOTI
  idProduct          0x03e8 free for internal lab use 1000
  bcdDevice            1.00
  iManufacturer           1 obdev.at
  iProduct                2 Mouse
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              400mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.01
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      52
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             100
Device Status:     0x0000
  (Bus Powered)

[root@onza mjd]#

I'm not sure why it says the report descriptors are unavailable.  But at least it works.

Now I'll start working on the bootloader.  If I can get the bootloader working, I can take the three pins we're currently using for ISP, and make them LED outputs.

The success continues!

by mjd (noreply@blogger.com) at December 04, 2010 10:43 AM

December 02, 2010

Ignacio Garcia, dingux.com

Suggestions for the next generation consoles

While I was with the CC folks I discussed with them a few suggestions I had for what I though would be the killer console, just in case some could be implemented in their next generation. They're eager to listen to users. That's invaluable IMHO.

Mind you, these are my own suggestions and that means some of them may be pointless since as you may already know I'm not a gamer. So, I'll really appreciate all kinds of comments.

I also collected suggestions from the people at #dingoonity IRC channel during one of the sleepless nights.

These are my suggestions:
  • At least 256MB RAM (this is already confirmed).
  • 4.3" or larger LCD (larger would probably hinder portability).
  • Powered USB OTG port (GA330 is OTG but not powered).
  • Host USB type A connector on the top side. Would allow easy use of WiFi or bluetooth dongles to add wireless capabilitites (internet, multiplayer, etc). Proably the only way to place such a connector without making the console too think would be to use a PCB cutout, such that the connector, instead of being on the PCB, is "into" the PCB (i.e. center of connector aligned with PCB).
  • One microSD slow and one SD/MMC slot with SDIO capability, which would allow use of wireless SDIO cards. Note that the host USB type A connector mentioned above would probably be a much better solution, since there are many more USB dongles to choose from and they're much cheaper than SDIO cards (you can buy a tiny bluetooth dongle for less than $6 shipped).
  • Allowing external wireless through either host USB type A or SDIO has some nice advantages over the internal 2.4GHz module currently used in the GA330:
  1. You can connect to another GA330, your mobile phone, home network, and whatnot. With the internal 2.4GHz module you can only connect to another GA330.
  2. Brings down the price of the console for users that don't need wireless anyway. For those that want it, it's dead easy to add it (mostly in the case of the hust USB type A connector). They could even sell a "wireless edition" pack including the dongle.
  3. Lack of wireless in the base console eases CE/UL certification (in case they ever want to comply).
  • Hardware color space conversion and scaling (already in the CC1800 VPU, and of course in the CC2000 which has a GPU).
  • Good subtitle support. Their high end PMP HD8900 already does support subtitles, buy they lack the black outline which is fundamental to ensure readability independent of image, and fails miserably (and silently) to load some subtitle files (I was able to solve this by rewriting then in strict UTF8 encoding, but this should not be necessary).
These are from #dingoonity:
  • Include Dingux plus a bundle of GPL games in each A320/GA330, and advertise it on the box as a selling point. Community will be happly to prepare such a bundle. In order to comply with the GPL the source code could be supplied in a separate subdirectory with a README stating that it can be safely deleted to reclaim some disk space.
  • License the full version of some famous OSS games like Doom, Duke Nukem 3D, etc, and include them in the bundle above.
  • Use the third connection of the headphone jack as a mic or line input, as it's used in many handsfree headphone kits. Usage of such a feature would be certainly minoritary, but it's essentially free (they're already using a three pin headphone jack in the A320 and I bet the codec they use in the GA330 already has MIC bias and MIC input pins).
  • Analog joypad. This would be great for games, but notice that this would provide the necessary pointing device for a web browser, for example.
  • Route all the unused GPIO pins to test pads on one clear area of the most accessible side of the PCB (both in the A320 and GA330 this would be the opposite side to where the LCD is connected, that is, the side you can access right after opening the case). Would be great if among those pins there was a I2C or SPI bus. This would be great for diehard hardware hackers, and is essentially free since doesn't increase manufacturing costs.

by booboo (noreply@blogger.com) at December 02, 2010 02:36 PM

November 30, 2010

Ignacio Garcia, dingux.com

GA330 serial console

I just added a serial console port to one of my GA330. The pictures below detail the TX and RX pins location and the final result.


Green wire is TX, orange is RX, white is GND (you can probably connect to GND more easily anywhere on the other side of the PCB).



For the curious, here's the boot output (57600 8N1):

ChinaChip IPL V1.04
Data : Jun 08 2010 Time : 17:31:33

SDRAM CAPACITY IS: 04000000
89D7943E
000084FF
Total Size = 0x00047D60

!!! Ecc Correct Error !!!
!!! Ecc Correct Error !!!
.!!! Ecc Correct Error !!!
.Loader Size = 0x00037D60

ChinaChip SPL V1.14
Data : Aug 06 2010 Time : 16:02:01

loader is normal mode...
loader_burning = 0
Battery Voltage = 3746.
g_poweron_vol = 3550
ccpmp_config Ver : 1.08 !!!
LCD Set Init !!!!
LCD Set Init Over !!!!
ccpmp_config.firmware_name = A330.HXF ...
ccpmp_config.update_key = 0x81 ...
ccpmp_config.lcm_name = LCM_TB_TD030WHEA1_320_240 ...
LCD Init Begin.

CN2009P_CFG.DL Data : Aug 25 2010 Time : 17:38:37

****** Enter LCD Init ******
wHCLKDIV = 1, wLCLKDIV = 0
num = 0, flag = 0
num = 1, flag = 0
num = 2, flag = 0
num = 3, flag = 0
wHCLKDIV = 1, wLCLKDIV = 0
num = 1, flag = 1
update key bDevMode = 0
ccpmp_config.load_mode = 0
ret = 0x00102878
usb_mode = 1
NAND ID:
89D7943E
00008400
A0FFFFFF
0000FFFF
A0FFFFFF
0000FFFF
80FFFFFF
0000FFFF
A0FFFFFF
0000FFFF
Nand manufacturer 0: inter
Nand type 0: 4GB
Nand manufacturer 1: Unknown
Nand type 1: Unknown
Nand manufacturer 2: Unknown
Nand type 2: Unknown
Nand manufacturer 3: Unknown
Nand type 3: Unknown
Nand manufacturer 4: Unknown
Nand type 4: Unknown
Nand manufacturer 5: Unknown
Nand type 5: Unknown
Nand manufacturer 6: Unknown
Nand type 6: Unknown
Nand manufacturer 7: Unknown
Nand type 7: Unknown
(dev 0)offset = 8192.
(dev 0)size = 131072.
(dev 0)nb_block = 256.
xxx -- nf_bi[0] 8192.
000 -- sta_block = 16, sta_chip = 0, end_chip = 8192.
xxx -- aaa.
001 -- end_block = 272, sta_chip = 0, end_chip = 8192.
xxx -- bbb.
xxx -- 002.
(dev 0)start chip = 0.
(dev 0)start block = 16.
(dev 0)end chip = 0.
(dev 0)end block = 271.
_this->start_chip = 0, _this->end_chip = 0.
nand_scan_blocks -- 000.
nand_scan_blocks -- 001.
block range of partition 16 ~ 272 on chip 0.
Found bbt at block 16, ver:0x0001.
bklight level: 00000004
bk value = 98
update_succ = 0
ccpmp_config.load_mode = 0
hxf_exist = 0
Play Logo on Music !!!
animation total frame = 15.
CC1800 Run OS ....
nandc0 - chip0, ID: 89 d7 94 3e 84 0
nandc1 - chip0, ID: 80 fe ff ff ff ff
nandc1 - chip1, ID: 80 ff ff ff ff ff
nandc1 - chip2, ID: 80 fe ff ff ff ff
nandc1 - chip3, ID: a0 ff ff ff ff ff
gDiskCapacity = 7941120
begin fs_init...
begin cc_ntfs_init ...
cc_ntfs_init ok ...
fs init OK.
s_wLongPressGOHOME -1
SWITCHOFF KEY register -1
RMT 17 )
LCD Set Init !!!!
LCD Set Init Over !!!!
Init UDC
in otg init 3-14
out otg init
OS Heap Information:
Total Size: 0x00e00000
Used Size: 0x00245e24
Free Size: 0x00bba1dc
AP Heap Information:
Total Size: 0x02000000
Used Size: 0x0018ec8c
Free Size: 0x01e71374
OS Heap Information:
Total Size: 0x00e00000
Used Size: 0x00245e90
Free Size: 0x00bba170
AP Heap Information:
Total Size: 0x02000000
Used Size: 0x0018ec8c
Free Size: 0x01e71374
OS Heap Information:
Total Size: 0x00e00000
Used Size: 0x00245e90
Free Size: 0x00bba170
AP Heap Information:
Total Size: 0x02000000
Used Size: 0x001ff61c
Free Size: 0x01e009e4

by booboo (noreply@blogger.com) at November 30, 2010 08:38 PM

Back from China

I'm back in one piece. It's been an exhausting trip and an amazing experience. I'm still in conversations with ChinaChip and will be writing some more updates in the following days. Meanwhile, a quick trip log:

20/11 Sat - Flight from Valencia to Paris, where I have a 6h transfer.

21/11 Sun - Flight from Paris to Hong Kong. The 12h trip is not as bad as expected because I score nothing short of 9h sleeping. They pick me up at the airport and take me to Shenzhen, have dinner, and then go to Dongguan straight to the hotel. I realize I'm gonna have a very hard time getting used to the chinese pronunciation of english.

22/11 Mon - Pick up at the hotel, not too early because I'm seriously jetlagged and wasn't able to sleep much. We go to the ChinaChip main headquarters and factory where I'm introduced to all the department heads and a few engineers. I visit all the facilities including the factory, and later have a meeting to outline the matters we should discuss in the following days. Excellent dinner with ChinaChip's president.

23/11 Tue - I've been able to sleep just a couple of hours from 10:00 to 12:00, and it's now 7:00 and I'm broken. Had arranged pick up at 9:00 but must delay it a few hours in order to try to catch some sleep. End up having lunch before going to ChinaChip's headquarters, where I spend most of the rest of the days in meetings.

24/11 Wed - Was able to sleep a bit more, so we can go early to the headquarters. More meetings in the morning, and then a walk around Dongguan downtown main square, which is amazingly huge. Late in the evening we travel to Shenzhen where we pay a quick visit to the marketing an sales offices and then go to the hotel to leave the baggage. Nice seafood dinner by the hotel and out to a club for a few beers and some fun.

25/11 Thu - Visit to the China Folk Culture Village park in Shenzhen, where you can see scaled down reproductions of the most important chinese landmarks, together with some other cultural information on the many ethnic groups. The park is huge and we spend the whole morning there. Then lunch and visit to Shenzhen's shanzhai market, which is shocking and will require a whole post. I could have very well spent several days in the market, but had to travel to Hong Kong, where we arrive by 21:00 after a tedious trip and several customs inspections. There's not much day left, so I just have a short walk on the Kwoloon shore to admire the island's view.

26/11 Fri - Full day on my own in Hong Kong. So much to see, so many people everywere. This also requires a whole post.

27/11 Sat - Plane takes off at 10:45, 13h flight (I score only 7h sleep in this one), 2.5h transfer in Paris, 1.5h flight and back in Valencia.

I'll also try to quickly summarize, for now, the content of the meetings with the ChinaChip folks:

- They will make changes to their bootloader and internal flash layout so that the dingux kernel and rootfs is installed in the internal flash. Both for the A320 and GA330 consoles. You'll have access to the internal flash from dingux (but the NTFL won't be released). The installation of dingux will be streamlined in the same way native firmware updates are, so no need to fiddle with usb tools any more.

- There will be dingux for the GA330, with full hardware support, and full open source. There's no problem with knockoffs here because it is based in their propietary CC1800 chip not available to third parties (as opposed to the JZ4732 in the A320).

- There is no schedule for the above as of now, since they're yet to decide if and how they'll sponsor it. In other words, one extreme is I work on it on a hobby basis as I've been so far and at zero cost, and the other extreme is they hire me full time. Anything in between is possible.

- The next generation of consoles will be based on the CC2000 and expected to roll out by Q2 next year. The CC2000 will be announced in a month or so, and I've been kindly asked not to reveal the details, but as you can imagine, it's beast compared to the JZ4732 and CC1800.

I'm sure I'm leaving something out, but I'll continue posting as things come up while I review my notes and prepare the reports of the meetings I'll be sending to ChinaChip. I'll also review the huge lot of pictures I took and post some.

Someone at #dingoonity said he needed a replacement speaker for his A320. Got it, but don't remember who he was. Email me, please.

by booboo (noreply@blogger.com) at November 30, 2010 02:29 PM

November 24, 2010

Marcan's Abort, Retry, Hack?

OpenLase: open realtime laser graphics

Update: see this post for hardware info and also a new GL laser simulator for those without hardware.

First of all, as I’m sure everyone knows by now, I’ve been working on hacking the Kinect and writing open drivers for it. There’s a website for the community and a Git repo with the code, and it’s working fairly nicely by now.

With that out of the way, here’s a project that I’ve been working on on-and-off for the past year or so. I’ve been interested in laser scanning and DIY laser projectors, but I couldn’t find any good open source software to drive them. Specifically, I was interested in the realtime aspect: rendering and showing dynamically generated images and responding to events, not just making and preprocessing laser shows. So I set out to write my own set of software to do real-time rendering. This was the result:




DIY laser projectors commonly use sound cards as DACs. This shifts most of the processing over to the PC, but also lets us get very fine control over the realtime aspects of projection, which is what I want. Thus, my laser projector is based on a bog-standard USB soundcard, modified to pass DC. I’ll probably write a detailed article on the hardware later, but suffice it to say that it’s a galvo kit, a hacked chinese laser pointer, my own laser driver and monitoring circuitry, and some other minor parts. Total cost is about €200, if you play your cards right.

Since we’re converting laser images to audio data, why not just treat the laser data as audio in the first place? After all, laser samples are audio-rate data, and 16-bit multichannel 48kHz fits the requirements for laser projection very well. So that is what I did. OpenLase isn’t really a monolithic framework. Instead, it’s a series of stand-alone applications and chunks built on the excellent JACK audio connection kit, which serves to pipe realtime laser data around the different bits.

On a typical setup, you’d have two processes running on top of JACK. On one hand, there’s the output processor, which is responsible for formatting the idealized laser data to suit the peculiarities of the hardware. This includes things like brightness scaling, the obvious X/Y inversion settings, the final output perspective transform (to fit the screen), and minor filters to try to compensate for hardware imperfections. It also generates a 1kHz square wave on one channel – this is a peculiar safety feature of my laser hardware. I have a microcontroller monitoring this signal, such that if the software hangs or crashes for some reason, the laser shuts down immediately (to avoid having a static dot which would be a serious eye hazard). The OpenLase output processor has a simple Qt GUI that lets you tweak these settings on the fly.

On the other hand, you have whatever picture source you want to use. You can have bare JACK applications, such as two examples: ‘circlescope‘, a circular oscilloscope that takes realtime audio data from a media player, and ‘playilda‘, a bare-bones ILDA file player (ILDA / .ild is the standard file format for laser graphics). The circlescope is particularly good for showing off the real-time aspect (note that the input can come from the laser DAC’s line-in with only the small JACK buffering delay):


However, the other big part of OpenLase is libol, a realtime rendering library loosely modeled on OpenGL which lets you produce 2D and 3D graphics on the fly. This is what I used for the LASE demo above. The demo itself isn’t currently open source (and the code is utterly horrid – I wrote half of it at Euskal Encounter and finished it mere minutes before the deadline), but if there’s demand I might open source it too, just please don’t expect pretty code! However, keep in mind that most features used by the demo (text rendering, 3D, “shaders”, ILDA file loading, etc.) were implemented as part of libol, so you aren’t missing out on much. There are two libol-based examples: some rotating cubes, and Pong.

There’s one part of the demo made it into the OpenLase distribution as a separate example: tools/trace.c. This used to be some tracing code that I used for the metaballs and fire effects (I kind of cheated there, as those are rendered as bitmaps and then traced in realtime into laser vectors). It’s a terribly naive algorithm (check the source out for details), but it worked surprisingly well for certain kinds of video, so I hacked it and tacked on more heuristics in order to attempt to make it work better. It now lives next to tools/playvid.c, which is a simple video player using libavcodec. Here’s what it looks like (improved version (mkv), original YouTube video). More complex videos are hit and miss, but some things turn out surprisingly well for such a silly algorithm.

You can also add filters between the output and the image generator. This is what I did for my Kinect + OpenCV + OpenLase demo, which projects anything projectable by OpenLase onto a moving screen, with a dynamic perspective transform (in this case the perspective transform happens in the filter, not in the output processor). That code currently doesn’t even build with current libfreenect, but again, if someone is interested, drop me a line and I’ll make it work again and publish it.

OpenLase doesn’t have any facilities to patch together these JACK apps. Instead, you should just use existing JACK tools, such as QJackCtl, to connect all the input and output ports together. QJackCtl has a patchbay feature that automagically connects the ports when applications start up, so it’s quite seamless.

Right now there is pretty much no documentation, but I’d like to know if people are interested. If you have (or want to build) this kind of DIY hardware, you run Linux or some other UNIX that can run JACK, and you’re interested in hacking on the code or using it for something, please let me know! Here’s the git repo.

Update: Three more videos, musically themed. A laser visualization of MIDI data (MIDI to laser):

And the other way around, a laser harp (laser to MIDI):



by marcan at November 24, 2010 02:25 AM

November 23, 2010

Zedstar

A minimal OpenWrt image for the Openmoko Freerunner containing GNU Guile

To experiment some more with OpenWrt I dusted out a Freerunner and built a minimal image containing GNU Guile. The image is built with glibc and an IP 192.168.254.101 to match my Nanonote settings.

** UPDATE: GNU Guile now has readline support and root image now contains GLib **

Flash the following:

http://zedstar.org/freerunner/openwrt-s3c24xx-2.6-uImage

http://zedstar.org/freerunner/openwrt-s3c24xx-root.jffs2-128k

Boot the device then:
john@thinkpad:~$ telnet 192.168.254.101
Trying 192.168.254.101…
Connected to 192.168.254.101.
Escape character is ‘^]’.

=== IMPORTANT ============================
Use ‘passwd’ to set your login password
this will disable telnet and enable SSH
——————————————

BusyBox v1.16.1 (2010-05-02 14:45:14 BST) built-in shell (ash)
Enter ‘help’ for a list of built-in commands.

_______ ________ __
| |.—–.—–.—–.| | | |.—-.| |_
| – || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
KAMIKAZE (bleeding edge, r21293) ——————
* 10 oz Vodka Shake well with ice and strain
* 10 oz Triple sec mixture into 10 shot glasses.
* 10 oz lime juice Salute!
—————————————————
root@OpenWrt:/# uname -a
Linux OpenWrt 2.6.30.10 #1 PREEMPT Sun May 2 14:59:31 BST 2010 armv4tl GNU/Linux
root@OpenWrt:/# guile
guile> (string-tokenize “hello world”)
(“hello” “world”)
guile>

by john at November 23, 2010 08:24 PM

November 20, 2010

Ignacio Garcia, dingux.com

Traveling to China

I'm leaving tomorrow to HK/China, where I'll be meeting the ChinaChip people. Will be back in a week, but will try to update as time permits on anything relevant to dingux on the GA330.

UPDATE: Paris CDG airport is da bomb. At least in terminal E where I am as I write this, plenty of places to lay and take a nap, massage chairs, PS3 for entertainment (free). The 5 hours I have to wander here suddenly don't feel so uphill.

They even have 10 minute free wifi. Too bad it's only 10 minutes. Unless you disconnect, clear the browser cookies, change the WiFi interface MAC address, and connect again, of course. You didn't read that here.

sudo ifconfig wlan0 hw ether [your previous MAC + 1]

by booboo (noreply@blogger.com) at November 20, 2010 08:19 PM

November 08, 2010

Ignacio Garcia, dingux.com

DA330 ---> GA330

I'm not sure I understand as of know the relationship between ChinaChip, Dingoo, and Dingoo Technology. It appears that there are two Dingoo companies, one that produces 3D games and another that actually produces the A320. Both belong to ChinaChip group. Then there's Dingoo Technology, which have marketed the A330 which is basically an A320 (JZ4732/JZ4740 SoC) with a different case/LCD, 64MB RAM and stolen firmware. In order to avoid confusion with the later, at some point I decided to refer to it as A330 and to refer to the newer, CC1800 based machine as DA330. But I was mistaken since it is Gemei (another company of the ChinaChip group) who will be marketing it (my two sample machines have both the Gemei logo). So, I figured out I'd rather fix this silly mistake soon. So, from now on, I'll refer to the newer CC1800 based A330 as GA330.

Sorry for any caused confusion. I've edited previous blog entries to reflect this change.

by booboo (noreply@blogger.com) at November 08, 2010 12:42 AM

GA330 specs

I believe there's some confusion on the GA330 specs. As I mentioned in the previous post, I have only preliminary, general, info, but this is what I found out so far (don't take it for granted anyway):
  • CC1800 processor (ARM926 400MHz).
  • 320x240 LCD, slightly larger than the A320 one.
  • 64MB RAM.
  • 2.4 GHz communication module. This is a true radio device and not just a keyboard hack. Enables multiplayer and custom peripherals.
  • USB OTG port, which allows connecting USB devices, but you'll need external +5V power (i.e. a powered hub).
The CC1800 has some nice features: the OMIP seems to be a video decoding coprocessor, and the VPU seems to be some kind of video post processor which can do quick scaling and color conversion before spitting out the data to the LCD.

I would say that the CC1800 CPU core belongs in the same class than the JZ4732 in the A320, however, being an ARM architecture has the advantage of the existing assembly optimized emulation cores. I bet that the VPU will allow a sizeable boost in performance by offloading the color conversion work from the SDL code.

64MB vs. 32MB in the A320 are a big advantage too.

by booboo (noreply@blogger.com) at November 08, 2010 12:39 AM

GA330 guts

It's been some time now since I received the two Gemei A330 sent by ChinaChip (GA330 from now on, to distinguish it from the other A330 out there which is basically an A320 with 64MB RAM). We're still working out the details (NDA, possible trip to China) to acquire the required info on the CC1800 SoC (system-on-chip) in order to port dingux to it, and it might still take a bit longer. Please excuse me if I don't comment more on the matter until everything is settled.

I'm working on the x760+ dingux port. As I said, I have all the required info, but time is limited and I've invested most of it reviewing all my initial work together with recent developments. Please be patient (yes, even more, sorry).

Meanwhile, here you have some electronics pron:





You'll notice that there is no battery in the pictures. The samples were sent without battery due to customs regulations, and though it's not strictly necessary for development, I'll get hold of substitutes soon.

You know I don't use the A320 and GA330 much for gaming (lack of time, you know, bla bla bla), so I can't give you a thorough review of the new GA330. Here are some first impressions. Please bear in mind that I'm not sure to which point the samples I got are definitve production machines, so take it with a pinch of salt:
  • The construction build feels good but not as good as the A320.
  • The LCD is exposed, i.e. there is no plastic protection (which is part of the enclosure) over it, as happens in the A320 and the X760+. This is definitely a no-no.
  • The LCD is a "delta matrix" type. Don't know much about the technology (I'll appreciate links), but it basically means that the color dots are not aligned in an orthogonal matrix but spread in a zig-zag pattern. This is supposed to be better for displaying pictures and video, but I think it's not good for games.
Please let me stress what I already said: these might not be definitive production units and the final product to market may have many of these thingies fixed. Also, note that ChinaChip actively supporting linux on their machines is a huge advance, and a first in the chinese PMP market as far as I know. And more powerful machines will come in the near future.

One final comment on the CC1800: it as a video processing unit (VPU) capable of doing scaling and all kinds of color conversion. The JZ4732 in the A320 has an image processing unit (IPU) which unfortunately is only good for converting YUV to RGB. This is very useful for video playing but useless for gaming. The CC1800's VPU will allow to provide each game with the framebuffer resolution and color space which is best suited, allowing for a significant increase in performance. Being an ARM processor will allow also to use the already existing assembly optimized emulation cores, for another boost in performance.

by booboo (noreply@blogger.com) at November 08, 2010 12:38 AM

November 07, 2010

Ignacio Garcia, dingux.com

hwinit fixed

I just modified hwinit (in the subversion repository) so it works on all A320 out there. These are the changes:
  • Added WP bit clean in CP0 CAUSE register (original idea by BouKiCHi).
  • Added LCD init and logo display as visual feedback of hwinit success (original idea also by BouKiCHi).
  • Code cleanup and removal of unneeded nand code.
Kudos to BouKiCHi for an awesome work of debugging.

The first fix is just weird. CP0 means "coprocessor 0" in MIPS architechture. It's the part that takes care of memory management, exceptions, privilege levels and such. It turns out that some versions of the IPL (Initial Program Loader) ROM code in the JZ4732 set up the WATCH registers in such a way that a watch exception occurs but it deferred (by setting the bit WP in the abovementiones CAUSE register). Then later, when the linux kernel boots, as soon as it sets up the CP0 STATUS register (another special regitser of the same "coprocessor"), the WATCH exception is immediately serviced, caused an unhandled exception panic (that is: for people suffering this problem, hwinit was actually working, but the kernel was panicking way before the LCD was initialized, so they could see nothing at all).

Why some IPL ROM versions behave this way is a mystery, and would be harmless if the kernel MIPS initialization code was careful enough as to clear the WP bit before setting up the CP0 STATUS register (I bet this is fixed in more recent kernels, but I'm too lazy to verify it).

I'm working to provide a native firmware based dual boot installer, so this hwinit issue wasn't really top priority, but it had bugged me for so long that I just had to sort it out before continuing. I'm just like that, like to walk on solid ground and feel very uncomfortable when I leave loose ties behind me.

I won't make a new dual boot installer release with just the fixed hwinit, since by now I guess all those with trouble have eventually been lead to hwinit2. Next release should, in my opinion, include at least:
  • A newer kernel with:
  1. Fixed I/O corruption bug(either Ingenic or OpenDingux based).
  2. with support for newer flash chips in recent A320.
  3. Support for x760+.
  • An updated buildroot and toolchain, with both 32 and 64 bit versions. I had to upgrade my buildroot since the old one didn't compile in my Ubuntu 10.04 x64 box.

by booboo (noreply@blogger.com) at November 07, 2010 09:52 PM

Open Electrons

Milkymist: pushing further the limits of electronics openness

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

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

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

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

freedomstack

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

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

socblock1

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

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

small_mm1_rc1_parts_on_pcb_usb_side_view

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

For more information, visit www.milkymist.org.

by Chitlesh Goorah (Free Electronic Lab) at November 07, 2010 01:07 PM

November 04, 2010

Ignacio Garcia, dingux.com

x760+ key mappings

I know I asked this before, but it was loooong ago, and I'd like some more input on the topic. The x760+ has only UP/DOWN/LEFT/RIGHT/A/B/X/Y keys, which means START, SELECT, LSHOUDLER, RSHOULDER and HOLD are missing and they'll have to be emulated or I guess some dingux apps out there will not be usable.

The funny thing is that the schematic shows actual HOLD, START and SELECT keys. Incidentally, it also has LSHOULDER and RSHOULDER, but those are available only as test pads (which means someone with enough time could theoretically add them).

So I've though this simple approach:
  • POWER + UP = LSHOULDER
  • POWER + DOWN = SELECT
  • POWER + Y (triangle) = RSHOULDER
  • POWER + B = START
None of those combinations will be comfortable to use, but it's better than nothing. I just chose the combinations so they reflect the spatial locations of the corresponding keys in the A320. Will have to increase the reboot/poweroff time when POWER is pressed, otherwise it might be accidentally triggered when using the combos.

Comments welcome.

by booboo (noreply@blogger.com) at November 04, 2010 07:23 PM

Gerard Braad

How-to setup dual-booting MeeGo 1.1 on the N900

The current image of MeeGo is for development purpose. Do NOT try to use it for daily use. You can make a phonecall or send a message, but I already had some issues with not being able to pick up phonecalls which I receive. It should be used as a means for developers to get familiar to the MeeGo environment for use on a handset. Also see the note at the end of this article.

For this how-to I use Fedora 13, but tmost of the steps also apply to any other Linux distribution. Be sure you have downloaded the correct MeeGo images before you begin and that you have a MicroSD card of 2G or more. I used a 4G MicroSD card from SanDisk.

The kernel root filesystem you download have to download from: http://repo.meego.com/MeeGo/releases/1.1/handset/images/meego-handset-armv7l-n900/

You need the following two files:
meego-handset-armv7l-n900-1.1-mmcblk0p.raw.bz2 (521M)
meego-handset-armv7l-n900-1.1-vmlinuz-2.6.35.3-10.3-n900 (1.5M)

N900
Enable the extras-devel repo on your device and install from app-manager: uboot-pr13
or from the terminal with:

# root
$ apt-get install uboot-pr13

Be sure you have upgraded to PR1.3 before doing this. This is all that's needed on the mobile handset.

Workstation
On Fedora you have to install the uboot-tools to create a bootable kernel image. For writing the disk image I also included pv to have some progress indication. Install these tools with:

$ yum install uboot-tools pv cfdisk

Connect your N900 in Mass Storage mode with the MicroSD card inserted or use a multicard reader. As mentioned before, use a 2G or more MicroSD card to dump the raw image to. You have to find the correct device to use from e.g. the dmesg, replace sdX with the correct device. The command for this is:

$ bzcat meego-handset-armv7l-n900-1.1-mmcblk0p.raw.bz2 | pv | sudo dd bs=4096 of=/dev/sdX

Note: This may take some time, especially on the class of SD card you are using. I used just a class 2 4GB from SanDisk. Also be sure it is not mounted during this action. Some distributions use auto-mounting for Removable Media.

To make the MicroSD card usable for dual-booting you have to add a third partition. This might be a little more tricky if you haven't done this often. That is why you can use cfdisk.

$ cfdisk /dev/sdX

And add a new partition in the last freespace you see. The first is only 1.3MB, which is TOO small to contain the kernel image. Define it as a primary partition of 4MB (or full size). Take note of the device name. It should be sdX3.

Now create a FAT filesystem on the newly created partition. This is where your kernel needs to be placed.
$ mkfs.vfat /dev/sdX3

Now you need to prepare the kernel image for use on the SD card.
$ mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008000 -n meego-handset-armv7l-n900-1.1-vmlinuz-2.6.35.3-10.3-n900 -d meego-handset-armv7l-n900-1.1-vmlinuz-2.6.35.3-10.3-n900 uImage

You would now have a file called uImage which you need to place in the FAT filesystem on /dev/sdX3. If you have difficulty creating the file, you can download it from here. Be sure you rename it to uImage. Temporarily mount it or reinsert the SD card so auto-mount can deal with it. Copy the uImage file to the root and unmount.

Now you could use this MicroSD to boot MeeGo 1.1. Try it out by powering off your N900 phone, remove the backcover and place the SD card. Be sure you have placed the backcover before you power on the device. If you don't do so, the root filesystem can not be mounted and the device will show a kernel panic.


External links

Note
I do not take any responsibility in you damaging your device or loosing data during the process. As I had mentioned, it is intended for development use and therefore I hope you have some basic understanding of what you are doing. If you have any question, please post them in the MeeGo Handset forum.

by gbraad (noreply@blogger.com) at November 04, 2010 05:39 AM

Capn's Tech

USB Doodad: An SMT exercise project

Surface mount soldering doesn't have to be scary!

Way back in the distant past when I learned electronics, components were "through hole". That means that components such as resistors had a wire out each end, and these wires were bent and passed through holes in a circuit board, then soldered.

An example through-hole board.

These days, through hole technology is on the decline. It's becoming harder to get the newer integrated circuits in through-hole form. In its place, more and more people are using "surface mount" technology to build circuits. With SMT, components are often in the form of a tiny block, which is placed on a circuit board, directly in contact with the circuit board tracks, then soldered into place.

An example SMT board.
Many people I've spoken to think that using SMT is harder than through-hole. Sure, many SMT components are very tiny, but it's quite easy to buy larger sized SMT components.

As a project at our hackerspace, Connected Community Hackerspace, Ross McKenzie and I have been working on a project which shows people that doing SMT assembly is not as hard as people think.  We have deliberately used the largest size of SMT components to make assembly as easy as possible.

The board has a USB connector at one end, a small expansion connector at the other, and a row of 16 software controlled LEDs in the middle.

The primary purpose of the board is to act as a practical exercise in surface mount assembly.  The secondary purpose is to show how to use the V-USB software USB stack to make a USB device.  The third purpose is to give the Doodad some post-tutorial value, in a number of intentionally frivolous ways:
  • Persistence-of-vision toy. Wave it around or put it on the wheels of your bike. Enjoy making groovy flowing messages in the dark.
  • Secure password keystore.
  • Log-data-to-serial-flash data logger, where samples could be retrieved over USB at some later time.
  • “Messages waiting” / “processor load” / “build progress” indicator.
  • Multimedia keys (if your keyboard doesn’t have them).
  • Novelty breathalyser.
  • Countdown timer for car parking reminder.
Our estimate for the cost of this board is about AUD30, so it's well within hobbyist reach.

We plan to release the design for this project under an open licence, possibly the TAPR OHL, which means that others can copy this design.

The project has been designed to use a single sided PCB.  Although this makes the job of designing and routing the board traces much more difficult, being single sided means people can make this board at home.

For applications which require the doodad to operate independently of a PC, we plan to add a small Li-Ion battery and management chip to the reverse of the board.

More information about the project can be found in the USB Doodad Google doc.

Ross and I are making rapid progress, and I'll post more project updates here soon.

by mjd (noreply@blogger.com) at November 04, 2010 01:21 AM

USB Doodad 3: Hot-air soldering of TQFP-32 chips

The processor we're using in the USB Doodad is an AVR ATmega328P.  This very capable processor is at the heart of the popular Arduino educational microcontroller platform.

The two most common packages for the ATmega328P are the PDIP-28 and the TQFP-32.

  <Good place to insert picture of PDIP vs TQFP>

Because the whole purpose of the USB Doodad is to use surface mount components, we want to use the TQFP-32 package.

Image courtesy of SparkFun.


Armed with a USB Doodad prototype board that Ross etched, I thought it was time to try soldering this chip.

There are several ways to solder SMT ICs.  A good guide is in this SparkFun SMT tutorial.  The method I used was using solder paste and hot air.

In order to do hot air soldering, I use a "hot air rework station" which I bought for about $80 in China.  I found another one at Ameritronics which looks very nice, nicer than mine.

Ideally, I'd use a syringe of solder paste, but I don't have one.  Instead I used the paste I covered previously.

I applied my solder paste with a jeweller's screwdriver.  Not a very precise way of doing it, but it did the job.  I applied one thin line of solder paste along the line of IC pads, then squished the chip pins into the paste.  Then I ran some liquid flux along the pins on all four sides of the chip.

Next, I used the hot air to melt the solder on each corner of the chip.  That was to fix the chip into place.  Finally, I ran the hot air along each side of the chip in turn.  The combination of pins, solder paste and flux means that when the solder paste melted, it blobbed around each pin.  I didn't get any bridges between pins, but if I had, I'm confident I could have fixed it with some desoldering braid.

My success makes me think that beginners could solder it too, if they had the right equipment (a hot air rework station).  And if we had a board with a solder mask (as we'll surely have for Doodad a little further down the track), I think beginners could do it with a regular iron too, if they had a video to watch showing how it's done.

Well, that's how I soldered a TQFN-32!

by mjd (noreply@blogger.com) at November 04, 2010 01:20 AM

USB Doodad 2: Board design and layout

Some time ago, Ross and I discussed and agreed on what we'd like this board to do (and perhaps just as importantly, what we don't need it to do).  How do we get from this stage to something people can assemble?  One way is by making a prototype.

A prototype lets us:
  • Try out the circuit and different variations,
  • Try out the PCB layout and variations,
  • Try out the software and variations, and
  • Try out different assembly ideas.
Ross started off by finding a project in Elektor, a famous English-language electronics magazine produced in the Netherlands.  What it has in common with the Doodad is that it uses an ATmega328P microcontroller, and uses V-USB to do software USB.

Using that project as proof of what is possible, Ross designed the circuit to our requirements, and did a PCB layout.  Because we may use the underside of the board for other purposes later, Ross faced the additional constraint of having to make the board single-sided.  He and I discussed and improved the circuit and the layout several times, and Ross reworked the circuit and layout to match.

In particular, if we use the same pins as the Elektor project, we'd only have 14 pins free for driving LEDs.  Ideally however, we'd like 16 LEDs.  We think by reassigning some pins, doing away with some features (for example, a bootloader exit button, and a reset button), and being creative with some circuit ideas (for example, using a resistor network to run a number of switches off some otherwise-unused ADC pins), we believe we can recover enough pins to give us 16 LEDs.  We'd also like to be able to use the SDA and SCK pins on the expansion port so we can easily attach I2C devices such as sensors and storage ICs.

In order to do this pin experimentation, the board currently has a number of solder pads we can link to reroute various signals.  Here's the current layout:
USB Doodad PCB artwork (v15)
On the left is the expansion port (+, - and two data pins).  On the right is the USB finger port.  Along the bottom is where the LEDs and dropper resistors will go.  In the top right are the USB analog components.  In the middle is the microcontroller, and to each side are the power supply and clock components.  The switches go in the top left.

While this board may not do everything we want it to, it will let us answer a lot of the questions we need to answer before we can produce a final board ready for sending to a manufacturing house.

I want to say that Ross has done a top job: The single-sided layout constraint is pretty fierce, and the quality of the prototype board is easily as good as a bought one.  I am learning a lot working with him.

by mjd (noreply@blogger.com) at November 04, 2010 01:19 AM

November 03, 2010

Capn's Tech

Making PCBs using the toner transfer method

Last year the folk at CCHS, my local hackerspace, did some work on producing PCBs using the photo resist method.

Because I don't have a UV box, and because I'd rather not keep buying UV sensitised PCB, I have been looking at the "toner transfer" method.

  http://www.riccibitti.com/pcb/pcb.htm

Most people use glossy magazine paper, or glossy inkjet paper.  I have been looking at other transfer materials.

Last year, I was using the slippery backing paper from sheets of labels.  This didn't transfer too badly, but I did have somewhat of a problem of small sections of track flaking away from the backing paper before I could do the transfer.  Also, I don't have much of the backing paper.

Last night I got to thinking of other transfer materials.  Something I can print on, but would be willing to give up the toner when it's heated.  I decided to try aluminium foil.

I've done some searching this morning, and it seems I'm not the first to think of using foil:

  http://hackaday.com/2006/05/27/pcb-fuser-for-toner-transfer-etching/

Well, I did several experiments last night, what I can report is that the tracks on the aluminium foil transfer very nicely to the copper.  If the heat is right, there's absolutely no toner left on the aluminium, and the foil can be quickly and cleanly peeled back to leave the tracks of toner on the PCB.


The artwork I'm using has SMT ICs of 0.6mm pitch, which means the tracks have to be really precise.  I haven't yet got one that's of sufficient quality to etch, but I think I'm very close.  Some of my attempts have had great tracks in the middle, but lost some tracks at the edge.  Some of the attempts have had 100% transfer to the copper, but are a little smudged.  I don't think this problem is because I'm using foil as a transfer medium.  Rather, I think it's a problem with the way I'm doing the ironing to transfer the image.  If I can refine the heating process, I think I can produce very high quality boards.  I'd expect to be able to do thinner than the 0.6mm our group can get with the photo resist process.

I think I'll look into getting a laminating machine.  More results to follow.

by mjd (noreply@blogger.com) at November 03, 2010 03:44 PM

November 02, 2010

Ignacio Garcia, dingux.com

Electronica 2010

Next week I'm going to electrodisneyla... er... I mean electronica 2010, in Munich. Since there are only direct flights from Valencia on tuesday and saturday, I'll be staying there for more days than I really need to visit the trade fair, so I'll have some spare time. Please let me take the liberty to use this otherwise technical blog to kindly ask for advice on what to do in Munich (besides beers and flash job interviews :-)

Thanks.

by booboo (noreply@blogger.com) at November 02, 2010 04:11 PM

Antitronics

Knitting machines – Lady Ada takes the Baton!

There’s a great tutorial up by Lady Ada and Becky Stern which is based on some reverse engineering I did of a Brother Knitting machine. This is great, and makes me want to get that machine off the shelf.

It’s so great to find that something you threw out to the public is useful to someone.

by sconklin at November 02, 2010 01:20 PM

Geoffrey L. Barrows - DIY Drones

Arduino optical flow sensor (fun breadboard prototype)




I'm learning to love things open source! To see what the fuss was about, I obtained an Arudino Duemilanove board from Sparkfun and decided to play around with it. It didn't take very long for me to assemble a (very) simple optical flow sensor using this board and one of my 16x16 Tam vision chips.

The circuit is very simple- the only electronic components were the Arduino board, a 16x16 Tam vision chip I developed at Centeye, and a single bypass capacitor. The vision chip and the bypass capacitor reside on a one inch (25.4mm) square breakout board. This particular Tam chip is pretty simple to operate- aside from the power signals, it requires two digital inputs, clock and reset counter, and generates one analog pixel output. A counter on the chip determines which pixel is to be output (by row/column) at the output analog line. Every time the clock is pulsed, the counter increments and the next pixel is selected. Pixels are read out one row at a time. The pixel circuits themselves operate in continuous time and are always generating a voltage in response to light. The counter merely determines which pixel voltage is sent to a voltage buffer before being sent off-chip.

A simple Arduino program reads out the pixel signals, digitizes them with the Arduino/Atmel's ADC, and computes a simple one-dimensional optical flow measurement. For the optical flow algorithm, I chose a variation of the Hassenstein Reichardt algorithm, an venerable algorithm from the 1950's that was one of the first proposed neural models for visual motion sensing. The Arduino program then dumps the simple running graph of the optical flow onto the serial dump terminal.

The optical flow algorithm is very simple. Let pA and pB be the signals output by pixels A and B respectively. Let lp( ) be a simple low-pass filter function, which can be implemented as a running average. The optical flow estimated from pixels A and B is merely lp(pA*lp(pB)-pB*lp(pA)), with the outer low pass filter having a longer time constant than the inner low pass filters. If we have an array of pixels A, B, C, D, and so on, then we compute this algorithm once for pA and pB, then again for pB and pC, and again for pC and pD, and so on, and average the results. This certainly isn't the best algorithm one could use, but it was very simple to throw together and I was actually curious to see how it would work.

For this implementation, I'm only reading in the middle 8x8 block of pixels and row-averaging them to form an eight-pixel line image. Thus the optical flow output you see is really from eight pixels worth of image data, or seven individual optical flow measurements averaged together as described in the last paragraph.

The first video above shows the response when the 16x16 Tam chip is exposed to light and a moving card casts a moving shadow across the chip. The second video shows the response when a lens is placed over the chip, so that the image of my moving hand is tracked. The pictures below show the two complete sensor setups, with and without lens, and a close-up of the Tam chip on it's breakout board.

The purpose of this experiment was to see how easy it would be to throw together a simple optical flow sensor using an Arduino board and a simple image sensor chip. The results are certainly crude, but the concept works. I think with some more work a decent Arduino-based sensor can be made, and it could be as easy to hack as pretty much any other Arduino project. (Arduino rocks!)

For those that are curious, I have another post on another forum that shows simple ASCII images taken from the image sensor, and discusses the operation of the chip in greater detail.

(Note: The "Tam" chip here is similar to but not the same as the "Tamalpais" chip used in the recent post on the 125mg sensor. Both are 16x16, but the Tam has larger pixels and is simpler to operate while the Tamalpais is smaller and has better on-board amplification. There is a story behind both names...)




by Geoffrey L. Barrows at November 02, 2010 02:05 PM

November 01, 2010

Geoffrey L. Barrows - DIY Drones

125 milligram optical flow sensor "TinyTam"







As an exercise in size reduction, we have prototyped a complete optical flow sensor in a 125 milligram and 7mm x 7mm package. This mass includes optics, image sensing, and all processing. Below is a video and two close-up photographs. In the video, note the green vector indicating measured optical flow as a result of image motion.

Image sensor: Centeye Tamalpais 16x16 pixel image sensor (only an 8x8 block is being used), 1.3mm x 4.1mm, focal plane about 0.3mm x 0.3mm.

Optics: Proprietary printed pinhole, about 25 microns wide

Processor: Atmel ATtiny84

Optical flow algorithm: Modified "Image Interplation" algorithm, originally developed by Prof. Mandyam Srinivasan (well known for his research on honey bee vision and navigation).

Frame rate: About 20Hz.

This work is being performed as part of Centeye's participation in the Harvard University Robobees project, an NSF-funded project to build a robotic bee. The final target mass for the complete vision system (including processing) will be on the order of between 10mg to 25mg, and will include omnidirectional sensing as well as algorithms to detect flowers. Obviously we still have some more work to do!

We documented the construction of this sensor, with lots of photographs, in case anyone is interested.


by Geoffrey L. Barrows at November 01, 2010 07:30 PM

October 29, 2010

Zedstar

SlowFi protocols on copyleft hardware

Recently I have been working on Packedobjects which included redesigning the API and replacing a lot of C code in Scheme. I will try and formalize the whole encoding process which I have called Integer Encoding Rules. I also began work on a manual which includes some examples. My aim is to support the tool on OpenWrt which also involves maintaining the GNU Guile build.

I built and tested the software on my Ben Nanonote. The ipk is available: http://zedstar.org/ipk/packedobjects_0.4_xburst.ipk

After improving the documentation I intend to use the tool in a networking course at work. I think it is important for students to gain some experience of designing and structuring binary network protocols.  We will be getting a bunch of Nanonotes to compliment the Openmoko Freerunners we have. This will provide some nice hands on experience packing some data and communicating it across different kinds of hardware.

Long term, I am interested in designing some funky SlowFi protocols on copyleft hardware.

by john at October 29, 2010 08:40 PM

October 23, 2010

Capn's Tech

Open letter to seek.com.au: Suggestions for improvement

From time to time I jump on seek.com.au to see what jobs are out there.  They currently have a boring-as-all-getup survey to gauge how Seek users find the website.  Buried in the survey is a text field which says "in what ways could the site be improved?".

Since I couldn't fit my suggestions in their text field, I'm posting them here, and I'll send Seek a link to here instead.



Goodness, where do I start???

Suggestion 0: Don't ask people "Please provide as much information as possible" then give them a 6-line text field to write it in.

I can list 20 more ways to improve your website.  Please keep in mind that lots of my comments below are about how to make reviewing a large amount of data as simple and as speedy as possible.

I am an experienced Software Engineer in Melbourne.  Naturally I look for jobs in the ICT classification, in the Melbourne area.

Job searching


Because I'm experienced, I could do jobs in several of the ICT sub-classifications.  Not to mention that many jobs are misclassified.  However your website only allows selection of one sub-classification at a time.

Suggestion 1: In the advanced search, allow users to select multiple subclassifications instead of just one.

Since your site doesn't let me do that, I'm forced to use "Any sub-classification".  That means I have to trawl through a LOT of jobs, most of which won't be relevant to me.  So it's vital that I can do that trawling as efficiently as possible. 
While I understand many people just browse on your site, I'm the kind of guy who wants to be sure he's read every ad.  So it's important to me to know where I got up to on my last visit.  At the moment I start from the top and keep reading until yesterday's or last week's ads start appearing.  But this is something the Seek website could do for me.

Suggestion 2: Have something like a bookmark, or a filter that says something like "show me only ads listed since I last visited".

Computers are very good at managing large amounts of data, and finding trends and correlations in that data.  For example, one of the little known purposes of your supermarket's loyalty card is so that the supermarket can use "market basket analysis" to identify correlated buying patterns.


If you want an example, head to the Jango music site.  Enter an artist.  Jango starts playing music, and you can say whether or not you like that song.  Your input, plus the listening patterns of Jango's other users, is used to start feeding you music from other artists.  Jango very quickly starts playing you only the music you like, and through this I have discovered many really cool music acts.  Go try it!

Suggestion 3: Use market basket analysis and other data mining techniques to say to a user "you liked that ad, you'd probably also like this ad".  Then show them those ads.

Suggestion 4: Take this idea further, and play "20 questions" with the user.  Show them two ads.  Ask them which they prefer.  Use their selection and some "affinity analysis" to find two more ads.  Or show an ad and ask the user to rate it "hot or not".  Twenty answers can whittle a million choices down to one.  Twenty questions, and Seek can then say "based on that, here are the jobs we think you'll love".  Implemented well, Seek could use this in a marketing campaign as "simply the fastest way to find the job that's right for you".

Presentation


Trawling means I scan a whole page of jobs, then go to the next page.  I use space or PgDn.  But when I get to the end of the page, I need to take my hands off the keyboard, point with the mouse and click Next.  That takes time I don't want to spend.  (I’ll cover the major reason I use the keyboard later on).

Suggestion 5: Provide keyboard shortcuts so one can go to the next page without using the mouse.

Since I have to look at every single ICT job in Melbourne, there's a lot of noise I have to trawl through.  Let's assume the user has a "hot list" and a "not list" of words.

Suggestion 6: Given the "hot list", highlight any of those words that appear in that ad.

Note, these keywords are not definitive enough to warrant me searching on them.  Plenty of great jobs in a certain area don't use meaningful keywords.  Keywords are hints, not search keys.
Conversely, there are a bunch of technologies out there that I have no experience or interest in.  If a term for that technology appears in an ad, it's a pretty fair bet that the job’s not for me.  So I really don’t want to put any brain power into that job.

Suggestion 7: Given the "not list", grey out the whole ad if any of these words appear.  It still appears in the jobs listing, but greyed out.

Now let’s look at how you’re using screen real-estate.  I have an LCD monitor that’s 22” from corner to corner.  That’s by no means uncommon; you can buy one from MSY for under $180.  22” corner to corner is 19” side to side.  Let’s look at how that space is used, left to right:

  • 2.5” absolutely blank space
  • 2.5” refine your results (only top 5% of column used)
  • 1” job selection checkbox
  • 2.5+” location, and maybe salary
  • 5.5” the text of the ad
  • 2.5” some “helper” icons (only top 10% of column used)
  • 2.5” absolutely blank space

You are spending 5” in absolutely blank space!  And you are spending 5” on tools and search refinement that could live at the top/bottom of the page.  You’ve reduced my nice 19” monitor to a 9” monitor, smaller than my first 12" monitor in 1989!

You might say “well, ads (and web pages in general) look bad if they’re too wide so we have that space to burn any way".  But what happens if I want to use the left half of my screen to look at Seek ads, and the right half to compose a cover letter?  Or if I have a smaller screen?  Or I’m looking at it on a smart phone?

Fortunately, the whitespace on the sides disappears when I resize the window smaller.  But everything else stays the same.  But I do end up having to sideways scroll the page to get the ads centred.

Suggestion 8: Put the 2.5” of “refine your results” stuff, and the 2.5” of “helper” icons at the top/bottom of your page, and make sure your page doesn’t need sideways scrolling on smaller screens.

As mentioned, I do a lot of scrolling through ads.  I rely on words of interest passing by and catching my eye.  You have a pink box that highlights an ad as the mouse goes over it.  I’m sure you thought that was a great idea.  But the flashing of that pink box as ads go under my mouse is INCREDIBLY distracting when I’m looking for keywords. And it makes your site look like someone’s CSS homework.  Just because it’s possible doesn’t mean it’s a good idea.

Suggestion 9: Please, lose the pink highlight.  Please?

One thing that really bugs me about Seek’s website is that once an advertiser retires an ad, Seek loses all memory of it.  For example, let’s say there’s an ad for a good job.  I bookmark the ad, and apply for it online.  Then the advertiser gets enough interest that they retire the ad, because they really don’t need any more candidates.  Next I get a call for an interview.  So I go back to the bookmarked ad to review what the advertiser wanted, and GRRR, it’s not there any more!  How can I prepare for the interview?

Suggestion 10: Except in the case of an ad that was offensive or illegal, if someone has the URL, show them the ad, even if it’s been removed from the public listing.

So, in order to cope with the above, I have to print out all the ads I’m interested in.  Means I can’t use your tools to manage my applications, but at least I've still got the ad after it's retired.  But what about if I want to go back to the online version?

Let’s say I was after job number 18393608.  What I have to end up retyping is:

  http://www.seek.com.au/job/c-engineer-adelaide-based-satellite-communications-next-g/melbourne/18393608/28/1/

That’s a lot of annoying typing, and if I made a mistake in typing it or copying it down, a great job could get away from me.

Suggestion 11: Rewrite your single job pages as (to use the above as an example): http://www.seek.com.au/job?18393608 or similar.  Note, short URLs are no easier for unscrupulous companies scraping your website for jobs, than long ones, so there's no reason to have long ones.  Long ones just make life difficult for schmucks like me.

Data quality


Remember I’m in Melbourne? I have a family and I’m not interested in moving or working outside of Melbourne, so in the advanced search, I always choose Melbourne.  So I’m baffled that I keep seeing ads that aren’t for Melbourne, like the example ad from above.  Please, why does this ad show up if I searched for Melbourne?

This is not a one-off: I’d estimate about 5% of your ads are similarly (and like the Adelaide Next-G ad above, I’d certainly say deliberately) misfiled.

Suggestion 12: Give people a way of reporting such ads (but see below).

Another extremely annoying thing is when recruitment companies put in ads for themselves.  In other words, there’s no job, just a company putting in an ad because they want to get you on their books.  Really, this isn’t why I visit Seek.

Suggestion 13: Ban ads for recruitment companies.  An ad without a job behind it just undermines the quality of Seek’s database.

What’s also annoying is speling misteaks in job ads.  I’m one of those people who notices every single spelling mistake, and when I’m reading ads, it’s like mental speed bumps.  Don’t advertisers know how poorly it reflects on them? 

Suggestion 14: When an advertiser places an ad, run it through a spell checker, and if there are typos, give the advertiser the chance to fix them.  Since ads contain many acronyms and company names, give advertisers the chance to tell the spell checker that words it highlighted are actually correct, for next time.

All that raises another question: What are you doing to engage your users, Web 2.0-style?

Suggestion 15: Give users a score, called a “reputation”.  If they correctly flag ads with incorrect location, no underlying job, or typos, their score goes up.  Users with scores higher than a certain amount have proven themselves and are trusted, and their reports are acted upon immediately, rather than needing moderation by Seek staff or other high score users.  This would be in place of the current “Something fishy?”

Suggestion 16: Give advertisers a publicly visible reputation.  If they keep posting ads that raise the ire of your users, don't take ads from them.  Do you really want their business?  If you do, what does it say about your business?

What you get out of all this is improved data quality, which makes it more attractive for people to seek on Seek. 

Another part of Web 2.0 is inviting your users to produce content.  At the moment, the Seek model is “all push”: You produce content (ads) and Seek users passively consume it.  But Web 2.0 is a two-way street.

Suggestion 17: Do as eBay does: Let users give feedback, and allow them to ask questions of advertisers.

Suggestion 18: Consider the idea of web forums where job seekers can hang out, talk about their experiences, and create a community and buzz around the Seek name.

Suggestion 19: Implement an online suggestion box, and invite your users to tell you what you can do better.  Don’t bury it in the middle of a boring survey!

I’m in the position where I have to use your site, as it has great jobs.  Yet the user experience is pretty dated and frustrating.  In order to make my job-hunting life bearable, I’ve fixed as many of these suggestions as I can on my end, using a Firefox plugin called “GreaseMonkey”.  It lets me change web pages to be how I wish they’d be, and when I sit down to look for jobs, it’s as if you’ve done suggestions 2, 6, 7, 8, 9, 11, and 14.  So I have road-tested these particular enhancements.  (The other suggestions would need changes on your end of the deal, so I can’t use GreaseMonkey to fix them).  But when I go to look at jobs on another computer, I’m back in “lame Seek” land, and the pain comes back.

I’ve now spent about two hours of my time writing 2000+ words to you.  I hope you guys actually read it, and even better, implement some of them!

Suggestion 20: Call me.  Seriously.  If you’re not sure what I mean, I’d be happy to further explain some of these suggestions.  Or if you’ve implemented some of them, and want someone to road test them, I’m happy to do that too.  Just make your site a bit less painful, please?

by mjd (noreply@blogger.com) at October 23, 2010 06:48 PM

October 10, 2010

Ignacio Garcia, dingux.com

GPIO tables updated

ChinaChip provided the A320 schematic, so after studying it I've completed the A320 GPIO table here:

http://code.google.com/p/dingoo-linux/wiki/GPIO?ts=1286716650&updated=GPIO

Some interesting updates:
  • PD3 and PD4 are unused GPIO but connected to test pads. Could be used for hardware mods (but first those pads would have to be located on the PCB). I'll open one of the A320 this evening and have a look.
  • PD22 is connected to the HOLD key (0=pressed, already pointed out in the comments by BouKiCHi).
  • PB30 confirmed to be battery charge status input.
  • PD20 is the battery charge control output (1=charge enabled). Actually, this turns on a NMOS which shunts a resistor to ground. This resistor is used to set the charge control, so in theory a PWM output could be used to achieve lower charge current. However, this pin's alternate function is SSI data output, so PWM might be achieved by spitting out continuously the appropriate data.
Not related to GPIO, but also interesting:
  • The FM chip audio output is (as expected) connected to the LINE_IN inputs of the JZ4732.
  • As I had guessed, the LCD read signal is not connected, and thus it is not possible to identify the LCD type or synchronize the GRAM refresh to the VSYNC.
As I mentioned earlier, I also have the x760+ schematics and I'm making the GPIO tables, soon to be published.

by booboo (noreply@blogger.com) at October 10, 2010 04:41 PM

October 09, 2010

Capn's Tech

Replacing DS touchscreens (part II): When it starts to go right but something else goes wrong

Last article in this series, I replaced a Nintendo DS touchscreen, but in doing so, broke the touchscreen connector (whoops).  I ordered a new connector from GoldenBridge, but surprisingly enough, they didn't ship it until two weeks after I placed the order!  So including the shipping time, the connector ended up taking nearly a month to get here.  GoldenBridge, no cookie for you!

Well, the connector finally arrived, and I took the DS and the connector to our weekly hackerspace meeting.

I don't have any pictures at present, but the good news is that I was able to desolder the connector from the board, and resolder on the new connector.  Took me a few goes, and use of flux and desolder wick and magnification, but I did it.

Only problem is, when I was reassembling the board, I broke the slider off the power switch.  Ouch!

I ordered a new power switch from DealExtreme, and when it arrived, I replaced the power switch.  Put it all back together and now I have a working Nintendo DS again.  I'm now out of danger of being disowned by the kids!

by mjd (noreply@blogger.com) at October 09, 2010 04:08 PM

October 01, 2010

Ignacio Garcia, dingux.com

A personal note

When I sat to write the previous post didn't initially intend to get into the personal side. However, I felt I sort of owed you some explanation on my sudden disappearance, and besides that, I thought that remembering and summarizing the last year of frantic work would help venting a bit. Now that I read it again I have the feeling that I may have painted a gloomy picture on my job status and short-term future, but that would be a bit untrue, and I don't want anyone to worry about it. So, just to clarify: I'm not worried. If things end up well here where I'm now, fine. If they don't, I'm pretty sure I'll be able to find a new job, and in such case I'd really want it to be in another country (so does my wife), so moving abroad is actually an appealing possibility (and to some extent and foreseeing where this country is heading for, I even feel I owe it to my two daughters). And even if it's not that easy to find another job, I have no debt and savings to live on in the meantime.

by booboo (noreply@blogger.com) at October 01, 2010 09:31 PM

September 30, 2010

Ignacio Garcia, dingux.com

Back

Hi all,

Yes, I'm alive. I'll develop later a bit on what's happened for the last year, but first I'd like to apologize to all those disappointed by the sudden stop in A320/x760+ development. I was certainly forced by the circumstances, but that doesn't change the fact that some of you donated money and you probably feel it's not been put to good use. If you want your donation back, please email me.

Now for the blast:

  1. I have now sometime to work again on dingux.
  2. Someone from ChinaChip, from the team that developed the A320, contacted me.
  3. They want to support dingux development for the A330.
  4. They will provide hardware info on the A320.
  5. They will provide hardware info on the A330.
  6. They will provide couple of A330 machines.
  7. They already provided schematics and some source code for the x760+.
  8. They will try to provide a second x760+.

Bam.

The A320 is legacy and is no longer being manufactured (plus there seem to be quite a bunch of knock-offs), so they want to focus on the A330. The A330 is based on an ARM SoC (CC1800) for which, as far as I know, there's not already a linux port (as opposed to the Ingenic SoCs)... so this might be a bit off my skills. We'll see. The x760+ is no longer produced so it might not be possible to get another one (remember, I already have one purchased with donations), which would be helpful because there are two x760+ LCD types.

Having the schematics and example source code for the x760+ should make it much easier to get dingux up and running on it.

Hate to say this, but don't hold your breath. Now I have some time and I'm very motivated (the ChinaChip support is a blast), but my personal situation might change at any time and the job that pays the bills will always be the topmost priority.


And on the personal side (feel free to stop reading here): what's happened in the last year?.

By the time I was forced to put dingux on hold my company was struggling to survive, and downsizing like mad, up to the point that the I was the entire development department. Soon I became also the administrative, customer relations, manufacturing, and installation/repair department. Really. My gmail inbox just collapsed and at a certain point I just gave up trying to reply messages. I'm really sorry if some people felt ignored.

I was working on the hardware and OS of an OMAP3530 based facial biometrics access control system which was itself a quite complex project and wasn't expected to yield some income in the short term, so future looked grim. Then, all of a sudden, two customers (the local government of two small villages) contacted us regarding an outdoor wireless mesh PA system we used to develop and sell. There was an special stimulus plan from the spanish government which would provide financing for those two installations. This was unexpected, since the local governments are literally struggling to pay wages and as a contractor, you're lucky if you get paid six months after invoicing, but the stimulus plan changed the whole thing. It was evident that this was a one-time chance to get good, immediate revenue with a nice profit margin (not really, but we would be using stock that would otherwise have zero value), so I sort of finished the biometrics thingie as fast and as good as I could and jumped on to it.

That was about april.

To make things more fun, there were two choices: either use the v1 system, which had some problems, or finish the design of the v2 system, which would work much better, be easier to maintain, and allow to use all the existing equipment stock. So, I don't fucking know why, I went with the second, and from april to june (remember, at that time I was pretty much the whole company):

  1. Designed a new 200W class D weathertight amplifier. S/PDIF over RS422 and streaming over ethernet inputs. It has two microcontrollers inside, a PIC24 and a LPC1768, and I had never worked before with the later, though had some exprience with the luminary cortex-M3 parts.
  2. Built 20 units of the above, together with another 20 units of a specially modified wireless mesh node. I mean I literally built them. Ordered all the parts, soldered each and every component on the PCBs, machined the 20 cases and assembled it all. Well, actually my wife helped a lot by soldering most of the 0603 caps and resistors.
  3. Loaded my car with all the equipment and went on to install it. Climbing on top of a crane to put it on the top of the 14m poles and on roofs. Fortunately I'm not afraid of heights.
  4. Bought the two computers for the control centers, installed the OS, control application and configured it.
In retrospective, I just don't know how I could do it all myself. One man band working 16 hours a day. I guess it was a combination of good engineering and luck, lots of luck (never ever had a first prototype errorless and straight to production). The installations were finished on time and are being used now to do all the public announcements. Now that I think about it, in between all that, I had also to do some repairs on another old installation and fix some issues in the biometrics thingie. What a madness.

I spent july doing some adjustments to the wireless mesh nets. The customers paid promptly (nice special requirement of the stimulus plan, they must pay you before they get paid by the central government, otherwise... you know... six months to one year), which means we would be able to close the year in the green.

So I needed some rest and time with my family and went on vacation for the whole month on august. The last month I've been working a bit more on the biometrics stuff and developing an asterisk based voice inbox for the PA system, which is a late special request by one of the customers, but makes a good addition to the feature list of the system (which I'm not sure matters at all because I think we're not selling any more for a long time, at least here in Spain). The outdoor IP amplifier is a good piece of engineering and there's a slight chance that could be sold to another company. We'll see.

As I said, we're on the green up to the end of 2010, but there's no income prospect for 2011. So, while now I have some time to work on dingux, and I intend to take it easy for the next months, I will be looking for a new job, new city, new country, not necessarily in that order :-)

by booboo (noreply@blogger.com) at September 30, 2010 02:46 PM

September 17, 2010

Capn's Tech

Touchscreen update

It's been a very long time since I've posted any articles.  However I've been working slowly but consistently on my touchscreen.  I'll have some more info later, but here's a sneak preview:

New touchscreen, wood case, direct USB.

I know, terrible photo, but that's the best my phone cam can do.  It looks heaps better in real life.  

This is a straight USB device, connected directly to my PC, and with no need of an Arduino.  As far as the PC is concerned, it looks like a USB mouse, except that the coordinates are absolute, not relative.

There's a microcontroller inside the case: A Teensy 2.0 running LUFA.

More details to follow!

by mjd (noreply@blogger.com) at September 17, 2010 10:44 PM

Zedstar

btlogger updated to support OAuth

Twitter pulling the plug on basic authentication meant I had to make changes to btlogger to support OAuth. Fortunately, librest made the code changes trivial. However, I ran into some problems. The clock was out of sync on the PC where btlogger runs. This caused the authenticate process to fail at the token request stage and was not easy to debug. The other issue which has been heavily documented is how to support authentication keys in FOSS. Currently configure.ac requires an edit to supply the key information. In theory I could supply the keys to somebody who wants to build the software from source until I figure out another way to handle this. I think they call this “best effort security”.

btlogger is now running from its own twitter account at: http://twitter.com/bluetoothlogger

by john at September 17, 2010 11:02 AM

September 03, 2010

Village Telco

Mesh Potatoes Go On Sale

Production Mesh PotatoThis is a big moment for the Village Telco.  We have finally arrived at the of the journey that began in June 2008 when I sat down with some very, very bright and innovative people and together we decided not to re-purpose rich world technology for Africa but to boldly design our tech to meet our own requirements.  Don’t get me wrong, if something vaguely similar had already existed we would have jumped at it but at the time no one was manufacturing a mashed up WiFi AP and Analogue Telephony Adaptor.  They still aren’t.

You can see the final design of the Mesh Potato at the right.  Those of you are familiar with the Ubiquiti Nanostation II will know that we borrowed wholesale from their excellent enclosure design.  They say imitation is the sincerest form of flattery.  In this case, it is certainly true.  We love Ubiquiti gear.

What we’ve borrowed from Ubiquiti is the sealed-unit design which makes for a sturdy weather-proof enclosure.  What’s a little bit different is the back mounting which has a slip-on piece that can be screwed to a wall.  Without the screw-on piece there is a similar mounting to the Nanostation for mounting on a pole.

A live Mesh Potato The best news of all is that Mesh Potatoes are now available for purchase by anyone.  Simply click on the Products link above to buy them from our webstore.  The cost of each Mesh Potato is USD 119 but for the next two weeks we’re making them available at the wholesale price of USD 89 per unit.  In order get that price, enter “afinemesh” as a coupon code on the Checkout page after you have selected the number of Mesh Potatoes that you’d like.  Shipping is calculated via DHL from Atcom in China.  Please contact us if you’d like to make other shipping arrangements.  Orders placed now will ship by the end of September.

Finally, I would just like to express ongoing amazement and appreciation of the many, many people who have contributed to making the Mesh Potato a reality in small ways and in big earth-shaking ways.  You know who you are.  You all seriously rock.  Open Software, Open Hardware refreshes the parts that other intellectual property regimes can’t reach.  Thank you.

by steve at September 03, 2010 12:50 PM

August 30, 2010

Village Telco

Dili Village Telco Rolls Out

I’ve just blogged on the latest stage of the Dili Village Telco roll out in Timor Leste. Fascinating what can be learnt from a real world deployment. I find the social and business issues just as fascinating as the technical problems us geeks usually focus on.

Test call by HAFOTI Director

Test call by HAFOTI Director. HAFOTI is an NGO working on Womens issues in Timor Leste

Links

1. More photos of the Dili Village Telco roll out.
2. The Dili Village Telco Wiki.
3. Other blog posts in the Dili Village Telco series.

by drowe at August 30, 2010 09:27 PM

August 10, 2010

Mark Adrian Bell

monitors

Simple system monitor powered by Python and Pygame

I’ve continued working on a simple system monitor application for the Ben Nanonote in Python and Pygame by rewriting the code in a more object-oriented style and adding a CPU and Memory monitor. Eventually I’d like to add disk space monitors, and to write a simple application launcher.

#!/usr/bin/python&lt;/code&gt;

&lt;code&gt;# A simple battery monitor application powered
# Python and Pygame.

#########################################################
# Press CONTROL-q to exit

from pygame import *
from copy import deepcopy
# initialize
init()

########################################################
# colours
white = 255,255,255
black = 0,0,0
red = 255,0,0
green = 0,255,0
yellow = 255,255,0
backcolour = black
solid = 0

########################################################
# background screen
def backgroundScreen(colour):
'''Setup background screen
In: colourTUPLE.
Return: screenOBJ'''
screen = display.set_mode((320,240))
backgrnd = colour
screen.fill(backgrnd)
display.flip()
return screen

# Warning colour
def getWarningColour(powerPercent):
'''Set a colour for the power block and percent text'''
if powerPercent &amp;gt;= 50:
warningColour = green
elif powerPercent &amp;gt;= 25:
warningColour = yellow
else:
warningColour = red
return warningColour

# get file
def getFile(path):
'''Returns a string'''
targetFile = open(path)
contents = targetFile.read()
targetFile.close()
return contents

# Check for keypress
# Exit on control-q
def exitKey():
for e in event.get():
if e.type == KEYDOWN \
and e.key == K_q \
and key.get_mods() &amp;amp; KMOD_CTRL:
return True

######################################################
class Point(object):
'''Point object'''

def __init__(self, x, y=0):
'''Create a point from x,y or (x,y). '''
if type(x) is tuple and y == 0:
self.x = x[0]
self.y = x[1]
elif type(x) is int and type(y) is int:
self.x = x
self.y = y
else:
message = &quot;Point type error: %s, %s&quot; % (x, y)
raise RuntimeError(message)

def __str__(self):
return &quot;(%s, %s)&quot; % (self.x, self.y)

def __add__(self, term):
'''Term can be a Point or a tuple.
Returns a Point.'''
result = Point(0, 0)
if type(term) is tuple and len(term) == 2:
result.x = self.x + term[0]
result.y = self.y + term[1]
return result
elif isinstance(term, Point):
result.x = self.x + term.x
result.y = self.y + term.y
return result
else:
message = &quot;Point type error: %s&quot; % (term)
raise RuntimeError(message)
def tuple(self):
return (self.x, self.y)

######################################
class Txt(object):

def __init__(self, message,
size = 16, fontName = None):

# self.message is used by Txt.write()
self.message = message
# font object
self.fontObj = font.Font(fontName, size)

def write(self, position, forecolour = white):
'''Render font object'''
if isinstance(position, Point):
position = position.tuple()
antialias = True
self.textObj = self.fontObj.render(self.message,
antialias,
forecolour,
backcolour)
# Create a rectangle
self.textRect = self.textObj.get_rect()
self.textRect.topleft = position
draw.rect(screen, backcolour, self.textRect, solid)
# Blit the text
screen.blit(self.textObj, self.textRect)
display.update(self.textRect)

#######################################################
class Header(object):

def __init__(self, text, origin):
self.text=Txt(text, 16)
self.origin = origin

def write(self):
self.text.write(self.origin)
#######################################################
class Monitor(object):

def __init__(self, name, origin):
self.origin = origin
# header text
self.header = Header(name, (origin + (0, 5)))

def draw(self):
self.header.write()

#######################################################
class batteryMonitor(object):
'''Header text, terminal, body'''
def __init__(self, origin):
'''origin is Point object '''

self.origin = origin
# header text
self.header = Header(&quot;Battery&quot;, (origin + (0, 5)))

# percent text
self.percentOrigin = self.origin + (55, 5)

# battery: body + terminal
batteryOrigin = self.origin + (100, 0)
batteryH = 22
batteryW = 12
self.lineWidth = 1

# battery terminal
terminalOrigin = batteryOrigin + (batteryW/4, 0)
terminalW = batteryW / 2
terminalH = int(round(batteryH * .1))
self.terminal = Rect(terminalOrigin.x,
terminalOrigin.y,
terminalW,
terminalH)

# battery body
bodyOrigin = batteryOrigin + (0, terminalH)
bodyW = batteryW
bodyH = batteryH - terminalH
self.body = Rect(bodyOrigin.x, bodyOrigin.y, bodyW, bodyH)

# list of power readings to average
self.powerReadings = []

def draw(self):
'''header, terminal, body'''

self.header.write()

# terminal
draw.rect(screen,
white,
self.terminal,
solid)

# body
draw.rect(screen,
white,
self.body,
self.lineWidth)

# update screen
display.flip()

def getPower(self):
'''Check powerlevel and return average of last 5 readings
reading is a percentage'''

# Check the battery power level
path = &quot;/sys/class/power_supply/battery/capacity&quot;
powerPercent = int(getFile(path))
# powerPercent = 75
# add to list of past readings
self.powerReadings.append(powerPercent)
# limit the list to 3 readings by deleting first item
if len(self.powerReadings) &amp;gt; 3:
self.powerReadings = self.powerReadings[1:]
# average the list of readings
average = float(sum(self.powerReadings)) / len(self.powerReadings)
# round the average to the nearest 5
powerPercent = int(round(average *2, -1) /2)
return powerPercent

def updateBlock(self, powerPercent):
'''Build power block and display with percentage'''

# Set a colour for the power block and percent text
warningColour = getWarningColour(powerPercent)
# Make a block to represent the power level
# Copy from body Rect
self.power = deepcopy(self.body)
# adjust the height of the power block to reflect the power level
self.power.h = int(round(self.power.h * powerPercent / 100))
# move the power block to the bottom of the battery
self.power.bottom = self.body.bottom - self.lineWidth
# blank the body outline
draw.rect(screen, backcolour, self.body, solid)
# draw solid power block
draw.rect(screen, warningColour, self.power, solid)
# redraw the body outline over the power block
draw.rect(screen, white, self.body, self.lineWidth)
display.update([self.body, self.power])

# Print the power percent
label = &quot;%2s %%&quot; % (powerPercent)
percent = Txt(label, 22)
percent.write(
self.percentOrigin,
forecolour = warningColour)

###############################################################
class CPUMonitor(object):
'''Header text, body rectangle'''

def __init__(self, origin):
'''origin is Point object '''
self.origin = origin

# header text
self.header = Header(&quot;CPU&quot;, (self.origin + (0, 5)))

# percent text
self.percentOrigin = self.origin + (55, 5)
self.percentBlank = Rect(self.percentOrigin.x, self.percentOrigin.y, 40, 20)

# cpu monitor body rectangle
bodyOrigin = self.origin + (100, 0)
bodyH = 20
bodyW = 12
self.body = Rect(bodyOrigin.x, bodyOrigin.y, bodyW, bodyH)
self.lineWidth = 1

def draw(self):
'''header, body rectangle'''

# header
self.header.write()

# body
draw.rect(screen,
white,
self.body,
self.lineWidth)
# update screen
display.flip()

def getLevel(self):
'''Check cpu level.
reading is a percentage'''

cpuFile = getFile(&quot;/proc/loadavg&quot;)
# extract first item and convert to percentage
listFromFile = cpuFile.split()
cpuPercent = int(float(listFromFile[0]) * 100)
return cpuPercent

def updateBlock(self, cpuPercent):
'''Build cpu block and display with percentage'''

# Set a colour for the power block and percent text
warningColour = green
# Make a block to represent the cpu level
# Copy from body Rect
self.block = deepcopy(self.body)
# adjust the height of the cpu block to reflect the cpu percent
self.block.h = int(round(self.block.h * cpuPercent / 100))
# move the cpu block to the bottom of the body
self.block.bottom = self.body.bottom - self.lineWidth
# blank the body outline
draw.rect(screen, backcolour, self.body, solid)
# draw solid cpu block
draw.rect(screen, warningColour, self.block, solid)
# redraw the body outline over the cpu block
draw.rect(screen, white, self.body, self.lineWidth)
display.update([self.body, self.block, self.percentBlank])

# Print the cpu percent
label = &quot;%2s %%&quot; % (cpuPercent)
percent = Txt(label, 22)
# blank out the old percent text
draw.rect(screen, backcolour, self.percentBlank, solid)
# write percentage
percent.write(
self.percentOrigin,
forecolour = warningColour)

###############################################################
class MemMonitor(object):
'''Header text, body rectangle'''

def __init__(self, origin):
'''origin is Point object '''
self.origin = origin

# header text
self.header = Header(&quot;Mem&quot;, (self.origin + (0, 5)))

# percent text
self.percentOrigin = self.origin + (55, 5)
self.percentBlank = Rect(self.percentOrigin.x, self.percentOrigin.y, 40, 20)

# total and free text
self.freeOrigin = self.origin + (100, 20)
self.freeBlank = Rect(self.freeOrigin.x, self.freeOrigin.y, 100, 20)

# monitor body rectangle
bodyOrigin = self.origin + (100, 0)
bodyH = 10
bodyW = 100
self.body = Rect(bodyOrigin.x, bodyOrigin.y, bodyW, bodyH)
self.lineWidth = 1

def draw(self):
'''header, body rectangle'''

# header
self.header.write()

# body
draw.rect(screen,
white,
self.body,
self.lineWidth)
# update screen
display.flip()

def getLevel(self):
'''Check mem level.
reading is a percentage'''

memFile = getFile(&quot;/proc/meminfo&quot;)
# Convert to list and extract total and free
listFromFile = memFile.split()
memTotal = int(listFromFile[1])
memFree = int(listFromFile[4])
memPercent = int(float(memFree) / memTotal * 100)
return memPercent

def updateBlock(self, memPercent):
'''Build mem block and display with percentage'''

# Set a colour for the power block and percent text
warningColour = getWarningColour(memPercent)
# Make a block to represent the mem level
# Copy from body Rect
self.block = deepcopy(self.body)
# adjust the length of the cpu block to reflect the mem percent
self.block.w = int(round(self.block.w * memPercent / 100))
# blank the body outline
draw.rect(screen, backcolour, self.body, solid)
# draw solid mem block
draw.rect(screen, warningColour, self.block, solid)
# redraw the body outline over the mem block
draw.rect(screen, white, self.body, self.lineWidth)
display.update([self.body, self.block])

# Print the mem percent
label = &quot;%2s %%&quot; % (memPercent)
percent = Txt(label, 22)
# blank out the old percent text
draw.rect(screen, backcolour, self.percentBlank, solid)
# write percentage
percent.write(
self.percentOrigin,
forecolour = warningColour)

###############################################################

# Hide the mouse pointer
mouse.set_visible(0)

# setup screen
screen = backgroundScreen(backcolour)

###############################################################
class TestMonitor(Monitor):

def __init__(self, name, position):
Monitor.__init__(self,name, position)
###############################################################

t = TestMonitor(&quot;header&quot;, Point(10,200) )
# t.draw()
###############################################################

# header, terminal, battery body
batteryMonitorOrigin = Point(10, 10)
battery = batteryMonitor( batteryMonitorOrigin )
battery.draw()

# header, cpu monitor body
cpuMonitorOrigin = Point(10, 50)
cpu = CPUMonitor( cpuMonitorOrigin )
cpu.draw()

# mem monitor
memMonitorOrigin = Point(10,100)
mem = MemMonitor( memMonitorOrigin )
mem.draw()

# The main loop
oldLevel = 100
oldPower = 0
oldMem = 0
done = False
while not done:

cpuPercent = cpu.getLevel()

if cpuPercent != oldLevel:
cpu.updateBlock(cpuPercent)
oldLevel = cpuPercent

powerPercent = battery.getPower()

if powerPercent != oldPower:
battery.updateBlock(powerPercent)
oldPower = powerPercent

memPercent = mem.getLevel()

if memPercent != oldMem:
mem.updateBlock(memPercent)
oldPower = memPercent

done = exitKey()
time.wait(250)


by Mark Adrian Bell at August 10, 2010 10:03 PM

August 06, 2010

Village Telco

V1.3 Antenna Testing

The V1.3 (production) Mesh Potatoes has an etched (PCB) antennas. This post talks about how we tested this antenna and verified the V1.3 design.

Testing at Atcom in June

In June I was visiting Atcom in Shenzhen, China. The first 1.3′s were calibrated and ready for testing so we headed out to a nearby open area with some MP01 V1.2 and V1.3 prototypes.

We taped a V1.2 and a V1.3 back to back on a length of PVC pipe to compare results at roughly the same height. Lead-acid batteries were used for portable power.

MP01 V1.2 and V1.3 back to back

MP01 V1.2 and V1.3 back to back

We did some A-B comparison tests, e.g. a V1.3 to V1.3 call then a V1.3 to V1.2 call and V1.2 to V1.2 call. As well as making calls we measured the rx signal strength using the node_tune.sh script. We wandered about and tested at various ranges.

Edwin and Alen seemed happy that the two antennas (V1.2 omni and V1.3 printed antenna) worked about the same. This is consistent with the tests Jeff and I performed last December.

The node_tune.sh script reports rx signal strengths to a laptop. It’s hard to be precise as the levels bounce around by several dB. Also we must remember the signal strength indicator on a AR2317 SoC is not a calibrated instrument, it’s just a rough estimate. Typical result might be -70 +/- 3 dBm over 10 signal strength samples. As near as we could tell, the results were about the same for the V1.2 and V1.3.

Given it was an inner city site there were other networks on the same channel so ping times bounced about a bit. Despite that the guys managed to make OK phone calls up to about 350m, with the V1.3 only a few metres above the ground. At that height 350m between omni antennas is actually better than I have achieved in Dili or Adelaide. Not bad considering we were in the middle of a city of 12M people.

Time to introduce some of the Atcom guys. From the left we have Nick and HeZhong. Alen (the MP01 hardware engineer) is in the blue shirt, and Edwin is on the far right holding the potato stick.

Atcom Guys

Atcom Guys

It was about 30C and 95% humidity but still nice to be outside. Everyone seemed to enjoy themselves, and it was good training for Atcom in antenna testing. For example when we walked behind a tree the phone call dropped right out, a few steps to one side and the call came back up. I have also used the “potato on a stick” training method with great success in East Timor. Quick and fun education in Wifi propagation.

Testing on the Jetty

By July I was back in Adelaide. Time for some more potato testing. Joel and I repeated the tests on the Jetty with the V1.3. The site and path (400m Line of Site) was the same as the January tests.

The call quality was fine with the MP in any orientation (I rotated it during a call), even kicking it around on the surface of the jetty with my feet. Pretty similar to January’s results with the prototype PCB antennas. The audio would drop out when Joel stepped in front of his MP but seemed to come back up after a few seconds. Perhaps the Wifi bit rate automatically dropped to account for the extra path loss of Joel!

Checking the Antenna Impedance

Next I hooked up my Standing Wave Ratio (SWR) bridge to the MP V1.3 antenna. The SWR bridge is described in this earlier post.

SWR head

SWR head, microwave PCB made with a Dremel tool

The SWR bridge lets me test if an antenna is resonant. If it is resonant the antenna impedance will look like a 50 ohm load at 2.4GHz. The SWR bridge can also be used to compare the V1.3 PCB antenna with other Wifi antennas. As described in the earlier post the SWR bridge produces a DC voltage that indicates the mis-match in the antenna impedance from the desired 50 ohms. A low voltage from the SWR head is a good result. Here are the results:

LoadSWR Bridge Output (VDC)
50 ohm resistive dummy load 0.24
open circuit (no antenna) 0.80
N-type antenna as used on V1.20.36
Off the shelf router antenna 0.35
Prototype 17mm PCB antenna0.30
Prototype 20mm PCB antenna0.40
MP V1.3 PCB antenna 0.22

The MP V1.3 PCB antenna is very close to the “ideal” 50 ohm resistive load. Although with this rough home-made kit a fairer conclusion is that the V1.3 antenna is in the same ball park as the others.

The SWR head & V1.3 antenna was driven from another Mesh potato sending ping floods. A 2.4GHz signal generator would make this testing easier. Using a Wifi transmitter as a signal source means bursty TX signals which makes these measurements tricky. A 2.4GHz sig-gen I could sweep (even manually) would also be great to determine exactly where the antenna is resonant.

Testing the V1.3 Antenna SWR

Testing the V1.3 Antenna SWR


MP01 Antenna Options

The V1.3 has a group of three 0-ohm resistors that can be used to change the antenna configuration. The resistors simply act as shorting links, they could be replaced by blobs of solder:

PCB Antenna and Mode Select Resistors

PCB Antenna and Mode Select Resistors

Close up of Mode Select Resistors and J4

Close up of Mode Select Resistors and J4

The normal configuration is R406 and R404 loaded. This connects the AR2317 SoC to the PCB antenna. To use an external antenna, R406 and R402 is loaded. This connects the AR2317 to J4, where a pigtail can be used to connect J4 to the external antenna.

A third possibility is R402 and R404 loaded. This removes the AR2317 from the circuit, and allows the PCB antenna to be connected to J4 for testing. This is the configuration I used for testing with the SWR bridge in the photo above.

A 2.1km Test between Jetties

On 3 August we made phone calls over a 2.1km path using two V1.3 MP01s with the built in omnidirectional PCB antenna. The phone calls were of excellent quality (no pops or clicks).

Thanks very much to my friend Angelo (a local Electronic Engineer) who helped out on the day. These tests take hours to set and perform and it’s great to have a friend to help.

Angelo on Grange Jetty

Angelo on Grange Jetty

Angelo is an IT Sys Admin by day and loves trouble shooting. During the Wifi test set up we (quite accidentally) stumbled across a previously unknown but serious bug in the Power over telephone Line (PoTL) part of the power supply. Just in time to prevent the bug being repeated 500 times in the first production run! Thanks Angelo for helping us track this bug down.

For the Wifi tests we used two local jetties (Grange and Henley) which extend 500m out to sea. This reduces interference from nearby Wifi networks and gives good height above ground (sea) level.

Below is Grange Jetty as viewed from Henly Jetty. Sorry about the grainy image below. Grange Jetty is so distant it is hard to image with the camera I have. Angelo is the guy with the brown eyes standing just behind the canopy at the end of the jetty.

Grange Jetty viewed from Henley Jetty, 2.1km away

Grange Jetty viewed from Henley Jetty, 2.1km away

Angelo suggested we could have gone much further. I think I agree, as doubling the distance again is a only a further 6dB power loss. But we have run out of convenient jetties for now.

These results, like the earlier results above, show that the V1.3 PCB antenna is working very well. I would like to take this opportunity to thank Jeff Wojtiuk for doing an excellent job in designing this antenna. Thanks Jeff! I would also like to thank Alen Chen from Atcom who has done a fine job on the PCB layout and hardware engineering for the MP01.

Some test data and results, gathered from the Henley end of the link:

  • Height at Grange Jetty was 8m+4m mast
  • Height at Henley Jetty was 8m+2m mast
  • ping -s 1400 -c 100 21% loss 29/42/76 ms
  • ping -c 100 7% loss 3/6/12 ms
  • Batman metric 240-250
  • “iwlist ath0 scan” detected 6 networks, between -81 and -95dBm

I used the node_tune.sh script to measure received signal strength while rotating the Henley end MP01. The signal strength varied between -90 and -86dBm over 360 degrees, with a peak (-86) being reached with the front of the MP01 at 90 degrees to Grange Jetty, i.e. the PCB antenna was edge on. This is an unexpected result.

We tried rotating the MP01 at the Grange end. In this case the maximum signal strength was reached with the MP01 facing Henley jetty. This is the expected result. The difference between the two sites makes me wonder of other factors were involved. For example multipath due to reflections from the sea or nearby metal objects.

Rotating could also have induced a Wifi bit rate rate shift (e.g. from 5.5 to 1 Mbit/s). The AR2317 transmit power varies betwen 15 and 20dBm between 54 and 1 Mbit/s. A rate shift over the link would cause lower lower tx and hence rx power but a higher bit rate. I performed the rotation tests during a regular phone call. Perhaps using broadcast packets would have been a better idea, IIRC they are transmitted at a fixed bit rate and hence fixed power level.

It is important to remember that the AR2317 RSSI indicator is not a calibrated measuring instrument. It is probably not very logarithmic, and no doubt drifts all over the place with temperature and varies from unit to unit. Burst Wifi and interfering signals make power measurements difficult. So we can treat the received signal levels as indicative only. For example I assume an error of +/- 3dB on any RSSI measurements in this system. A much better way to measure RX signal power is to use a spectrum analyser as the receiver.

Using a Wifi calculator I checked the free space path loss and Fresnel zone clearance. The expected power at the receiver is:

Pr = Tx power + Tx antenna gain – path loss + Rx antenna gain

Plugging in the numbers we get:

Pr = 17 + 2 – 106 + 2 = -85dBm

The driver reported the received power as -86dBm, which is a reasonable match if you trust the received power measurement (which I don’t). Still, it’s fair to say we are in the ball park, and that both the antenna and MP01 radio are performing well. Crystal clear VOIP over a 2100m Wifi link with just Omni antennas and 50-100mW is an exceptional result.

I plugged in 17dBm for the tx power above as I was unsure of the bit rate, unfortunately I don’t know how to read the current bit rate of the Wifi driver in ad-hoc mode. The actual tx power could be between 15 and 20dBm, depending on the bit rate.

The 1st Fresnel zone was 8m which we should clear OK with our masts and the jetty height above sea level. However I am not sure what effect the sea has on Wifi. Being slightly conductive it’s probably more reflective than a path over land.

These results show us how important interference and Line of sight (LOS) are to Wifi. In Dili we couldn’t set up a 300m link between MPs equipped with Omni-directional antennas due to massive interference. Even to obtain that range with directional antennas we needed huge, free standing masts (up to 25m) to clear obstacles like trees. However “on the beach” we can achieve an impressive 2.1km with omnidirectional antennas and modest power levels.

Links

Coincidentally a couple of friends sent me this link on PCB antenna design while I was writing this post.

by drowe at August 06, 2010 11:33 PM

August 02, 2010

Gerard Braad

Fedora visits China (Beijing/Shanghai)

A lot of things have happened in China relating to Fedora; our MIPS port gained attention from Loongson and we made Fedora 13 available on our servers. Although it has not been mirrored yet to secondary.fedoraproject.org, you can already try it out. The other thing is about what Kaio and I have been busy with for the last half year, the Chinese Fedora Community!

It seems our efforts have not been unnoticed and the Fedora Community Architecture team sent Mel Chua to China. Yesterday she arrived in Beijing and we immediately started to discuss about our community and future activities and how to gain a more widespread acceptance of Open Source in China.

One of the things we immediately agreed upon was, luckily her explanation was less morbid, to 'Raptor-proof our community'. Our community is fragile when it comes to responsibilities and the load carried upon those shoulders. For this to succeed we would like you to propose people or yourself for a role within the community.

It would be ideal if some of you would step forward and become a regional ambassador who can represent key regions in China, like Shanghai, Hong Kong, etc. The workload for this is low and when we can balance it out it would even be minimal. You would take care of distributing Fedora swag, like t-shirts in your area.

This Raptor issue also troubles our MIPS port. Currently we have three members and of this only the lead role can be performed by someone else. We have a nice group of people around us, but we are always searching for new members. If you want to help with documenting or other activities, just get in touch. No, you don't need to be Chinese :-P. If you have a Yeeloong netbook and got tired or Mandriva, help us test and build third-party packages.

We would really like to know about Open Source activities happening all over China or maybe you have suggestions. If you want to discuss this with us, join #fedora-zh and mailinglist. Mel's agenda for this week is still open, so if you want to meet her in Shanghai, this is your chance.

Thanks to all the members of the Chinese Fedora Community!

by gbraad (noreply@blogger.com) at August 02, 2010 03:54 PM

July 07, 2010

Geoffrey L. Barrows - DIY Drones

User programmable sub-gram optical flow / vision sensor



For a long time I've been wanting to make an ultra minimalist vision / optical flow sensor for the hobbyist and experimentalist community. I've been pursuing this as a small IR&D pet project at Centeye. We're almost there.


The above photo shows one of these sensors next to a millimeter scale. The part count is small- One of our 64x64 custom image sensors, an Atmel ATmega644 processor, several resistors and capacitors, and some lightweight flat optics we developed. Two complete sensors are shown, including with mounted optics (yes it's that thin!). Total mass is about 440mg. The primary interface is via I2C/TWI, which will allow many sensors to be hooked up to a common bus. A secondary connector includes the interface with the ISP for uploading firmware.


We chose to use an ATmega processor since they are loved by hardware hackers and are easy to use. Ideally for a single sensor, one can upload any number of different "application firmwares" to the sensor to make it whatever one wants, limited by just the processor and the base resolution. One firmware will turn it into an optical flow sensor . Another firmware will let it track bright lights. Yet another firmware could turn it into something else. Or someone could write their own firmware, whether by tweaking existing source code (yes I plan to share it) or writing something completely new.


An ATmega644 may not sound like much for image processing- 64kB flash, 4k SRAM, 2k EEPROM, 20MHz max. Neither does a 64x64 array. But the reality is if you are witty you really don't need at lot of resolution or processing power to get some nice results. (We once did an altitude hold demo with just 16 pixels an 1MIPS back in 2001.)


We've already made our first batch of these (about 20) and handed them out to a few close collaborators. Based on feedback we are preparing our second run. The new sensors will be slightly larger and heavier (thicker PCB) but more rigid, and use strictly 0.1" headers for all IO and power (including programming). Mass should still be under a gram.


We also have an even smaller version in the works, shown below with a chip mounted and wire bonded (sorry about the mess). This board uses ATtiny and the 7mm x 8mm board alone weighs about 95mg. I think we can get a whole sensor made for about 120mg, if only I had the time! (Maybe some brave person here would like to take a stab at programming it???)


by Geoffrey L. Barrows at July 07, 2010 03:41 AM

June 22, 2010

Gerard Braad

Installing SELinux on Linode (CentOS profile)

Recently I signed up for a different VPS hosting partner as the one I was using had a dreadful latency when dealing with international connections. The new VPS at Linode I am using has good ping times, the control panel often does correctly what it should do, but the out-of-the-box CentOS profile was in my opinion not what I am used to.

RHEL and Fedora sys-admins know about SELinux and the pains and pleasures it can induce. If you are new to SELinux, be sure to read a little bit of background: SELinux for dummies and Dan Walsh's Blog. Or watch these videos recorded by Scott Dowdle: "SELinux demystified", "Intro to SELinux" Part 1, Part 2.

It seems Linode does not provide SELinux support with their provided kernel. I do not know what their motivation is. Maybe they want to relieve their support of troubling questions (to which I would say: permissive or enforcing=0) or maybe they just don't see the need. However after reading several reports on the web I am sure people want this functionality, but have been troubled by out-of-date resources about recompilation of the kernel to get the needed SELinux support and paravirtualization operations (pv_ops), setting up pv-grub, etc.

Well, things are now much simpler as RHEL/CentOS provides the needed pv_ops kernels. The only missing part is to setup grub and get SELinux going. In several steps I will explain what needs to be done.

Instructions
For these instructions I created a standard CentOS 5.5 (64bit) profile VPS using Linode's Dashboard option 'Deploy a distribution'. Start the node and from the console or ssh perform these steps.

1. Install grub
Grub is not installed on the base system. You will need to install the package, create some symlinks and an empty configuration file which you will need later.

# yum install grub
# mkdir /boot/grub
# cd /boot/grub/
# touch grub.conf
# ln -s ../boot/grub/grub.conf /etc/grub.conf
# ln -s ./grub.conf menu.lst

2. Install kernel with pv_ops
You will need to install a Xen enabled kernel which are provided by CentOS. But for some reason the xennet and xenblk are provided as modules and fail during startup. To solve this issue we create a new initrd which can load these. Be sure to specify your kernel version correctly. You will also need this later for Grub.

# yum install kernel-xen
# mkinitrd -v -f --with=ext3 --with=xennet --with=xenblk /boot/initrd-2.6.18-194.3.1.el5xen-custom.img 2.6.18-194.3.1.el5xen
# echo "devpts /dev/pts devpts defaults 0 0" > /etc/fstab

3. Edit grub.conf
To enable the new kernel, you need to add this to our empty grub.conf. Be sure to verify your version.

# vi /etc/grub.conf

The contents of the grub.conf are:

#boot=/dev/vxda
default=0
timeout=1
hiddenmenu
title CentOS
root (hd0)
kernel /boot/vmlinuz-2.6.18-194.3.1.el5xen ro root=/dev/xvda
initrd /boot/initrd-2.6.18-194.3.1.el5xen-custom.img
title CentOS (enforcing=0)
root (hd0)
kernel /boot/vmlinuz-2.6.18-194.3.1.el5xen ro root=/dev/xvda enforcing=0
initrd /boot/initrd-2.6.18-194.3.1.el5xen-custom.img

The above configuration will automatically boot to the default option which is a pv_ops kernel which has SELinux enabled. The second boot option is handy of you encounter some issues during the next step. If you are uncertain, you can uncomment the following lines, but this means the boot will be interrupted by grub and needs you to select the boot option from the lish console.

#default=0
#timeout=1

4. Install SELinux
Installing SELinux now is a breeze.

# yum install libselinux selinux-policy selinux-policy-targeted
# genhomedircon
# touch /.autorelabel
# shutdown -h now

Now you only need to set your node to use pv-grub to boot from the configuration profile. This is briefly explained in this article on the Linode Library. Boot up your node and allow some time for the relabeling. It might be wise to verify the progress from the lish console. If everything went well, the filesystem should have been been relabeled after a while and the system should operate 'as normal' ;-). You can verify the state of SELinux from ssh using the command sestatus.

There is however still one issue I have not resolved, as soon as the console is handled by mingetty, it seems the lish console does not properly handle this. It might be an issue to use xvc0 instead, but I see this as a minor problem and rather have SELinux enabled.If you have a fix, please let me know so I can improve these instructions.

by gbraad (noreply@blogger.com) at June 22, 2010 08:52 AM

June 09, 2010

Alvaro Lopes, gta02-core-news

Comment moderation

Due to excessive spam in #gta02-core blog (mostly porn links) I'm enabling comment moderation. I'm sure you understand.

Álvaro

by Alvie (noreply@blogger.com) at June 09, 2010 03:49 PM

May 12, 2010

Capn's Tech

Computer assisted Chinese (part VII): Touchscreen 5

Last entry, I had the larger touchscreen working with X, and I worked out how to map the touchscreen data to a rectangular area on-screen.  This time, I will try to get a Nintendo DS touchscreen working with X.

Although my ultimate goal is to make a true USB device, for the moment I'm going to use an Arduino as the microcontroller. 

  http://www.arduino.cc/

The Arduino has an FTDI FT232RL chip on it.  This speaks USB on one side, and TTL-level RS-232 on the other.  On the Arduino board, the FTDI's serial port connects to pins 0 and 1 of the Arduino, which is the microcontroller's UART port.  This lets you send information to and from the microcontroller over USB, and what the PC sees is a USB serial port.

My plan is to make a serial port based touchscreen which emulates one of the existing serial port touchscreens supported by Linux.  Hopefully this means I don't have to write any kernel code.

I looked around in the kernel's drivers/input/touchscreen directory for the serial port touchscreen driver with the simplest protocol.  The most likely candidate seemed to be the driver for the 3M MicroTouch.  It's a five byte protocol, and the driver looks pretty simple.  I'll come back to the protocol later.  For the moment, I want to see if I can read the touchscreen ok.

A touchscreen is a sandwich of two transparent plastic plates.  Each plate is covered with a conductive film, and one plate is printed with tiny plastic bumps to keep the two plates apart when not being touched.  You can find out more about how touchscreens work here.

My touchscreen has four wires.  These wires must be connected to the Arduino board, so I made my own "breakout" board.  I used one of the Sparkfun connectors I bought to fix my Nintendo DS touchscreen.

Soldering the touchscreen connector was "fun".  Remember, there's four conductors in the space of 1.5mm.  I had a lot of problems with solder bridges between the pins.  I eventually solved this problem by using a jig made of polyimide tape with three fingers, which fit between the pins and make a physical barrier to prevent solder getting from one pin to the next.  After completing the soldering, I removed the fingers.

Polyimide tape is a heat-resistant film that is sold by DuPont under the name of Kapton.  Cheap polyimide film can be bought here.

The wire I'm using is wire-wrap wire.  Four of these wires next to each other give exactly the right spacing.

In order to prevent the tiny wires on the connector from breaking, I wanted to put the connector on a board. I didn't want to glue the connector, as there's a risk that glue will get inside. So I made my board out of a small piece of unetched printed circuit board, and soldered the connector to the board. The 4-pin connector has solder pads on the bottom: how to solder it to the board?

Recently I bought myself a small tub of solder paste.  This is a mix of microscopic solder balls, suspended in a liquid to make a paste.  Although it looks a dull grey to the eye, I looked at it under the microscope at our hackerspace, and yes, it's a sea of unbelievably tiny balls.  How cool!

I used a pen to draw the dimensions of the connector onto the end of the PCB, then used a rotary cutting tool to remove the copper where the touchscreen conductors go.  There's still copper underneath the solder pads on the connector, but no copper under the touchscreen wires.

Using a jeweller's screwdriver, I applied a tiny amount of solder paste to the copper of the board where the connector's solder pads will go, and placed the connector.  Holding the connector in place with my finger, I touched the soldering iron to the copper next to the connector.  The copper conducted the heat into the solder paste, and I could see the paste turn from a dull grey to a lovely silver.  I could also see surface tension pull the solder into a nice shape around the solder pads.  Result: One nice strong strain relief for the connector and the wires.  This solder paste worked very well, and I will definitely use it more in the future.  I bought it very cheaply here.

Next, I used 4 header pins to join the wire-wrap wire to the four-conductor flexible ribbon cable, and used 4 right-angle header pins at the other end to make a plug for the Arduino.  To finish off. I used hot glue to lock the ribbon cable in place at both ends.  Here's the result:


The breakout board is a bit rough, but it's a prototype.

(If you have keen eyes, you may note a button attached to the lower Arduino connector.  More about that later)

Well, that's the mechanicals done, now for some software!

by mjd (noreply@blogger.com) at May 12, 2010 11:50 AM

Replacing DS touchscreens (part I): When it all goes wrong

The other day I was talking about the cheapie touchscreens from DealExtreme:

  http://www.dealextreme.com/details.dx/sku.3245

I bought a few for experimenting with, and one for replacing the touchscreen in my sons' Nintendo DS, as that touchscreen has developed problems.

To find out how to replace the touchscreen, I watched these guides:


  http://www.youtube.com/watch?v=5a1AIWYXPmg


  http://www.youtube.com/watch?v=lir1HCupK9Q

They make it look so easy!

Anyway, I successfully opened up that Nintendo DS, and was able to split the old touchscreen from the LCD and replace it with a new one. The problem came when I tried attaching the new touchscreen to the connector on the PCB. That connector has a tiny black plastic lid, and unfortunately for me, one of the legs on the lid broke off.  You can see the connector here:


That connector is tiny as!  To give you an idea of scale, the touchscreen ribbon cable you can see in the lower left is 2.5mm across: Just 1/10th of a inch!

Without the lid, the connector doesn't push down on the touchscreen cable, and the touchscreen doesn't work.  What to do?  Without a working DS, my kids will kill me!

I thought of trying to hot-wire the touchscreen cable to the board, either directly or via four tiny wires, but I couldn't think of a way that wouldn't risk damage to the PCB, so I decided to buy a new connector.

The first place I looked was SparkFun.  I found this connector:





(Click on image to go to the product page)


Although the shape is different, they are only about US$1 each, so I bought a few.  Actually, I bought them from SparkFun's local distributor, Little Bird Electronics.

The connectors arrived in about a week, and when I got them, I noticed something rather unfortunate: The connectors on the Nintendo DS PCB are designed to have the contacts on the touchscreen facing down, whereas the SparkFun connectors are designed to have the contacts facing up.  I don't think that's going to work!

In order to confirm this, I spent more than two hours at our hackerspace, soldering wires onto those four pins under a microscope.  And yes, that connector is the wrong way around and not suitable.

So, I did some more web digging, and found a company called Golden Bridge in Hong Kong.  It seems they're not dissimilar to Deal Extreme, and they have what appear to be the proper DS connectors:




(Click on image to go to the product page)


I ordered a few connectors a week ago, and I'm waiting for them to arrive, which they should do any day now.  Unless they arrive tomorrow, I won't get them in time to solder at hackerspace.  Which is unfortunate, as if my kids don't get their DS back soon, I think I'm going to be buying them a new DS.  Either that or I think I'll have to leave home...

by mjd (noreply@blogger.com) at May 12, 2010 11:50 AM

Computer assisted Chinese (part VI): Touchscreen 4

Last article, I had a working touchscreen where the whole of the touchscreen surface was mapped to the whole of the display.

Skritter is a flash-based web app.  In scritter, there's an area in the middle of the window in which you can use your input device to enter the strokes for the character:


So I have the requirement that I want to map the touchscreen area just into that rectangular area.

Here's another requirement: A 15cm x 9cm touchscreen is designed to fit over a display, not sit on one's desk.


It's too large to comfortably write on, as my wrist hits the surface when writing and throws off the cursor. So I only want to use a small area of it.

And since I eventually want to build this with a cheap nintendo touchscreen, not a full-sized one, I'd like to just use one corner of the large touchscreen.

Further, I want size and aspect ratio of my small corner of the large touchscreen to be roughly the same as for the nintendo touchscreen. Fair enough.

But it gets better: When I finally use the nintendo touchscreen, I want the aspect area of that touchscreen to be the same as Skritter's on-screen drawing area. Since the aspect ratio of the Skritter writing area is slightly different to the nintendo touchscreen area, I will only use about 85% of the nintendo touchscreen area.

So, somehow I have to map a small corner of the large touchscreen, onto this particular on-screen rectangle.

The 11-eGalax.fdi file mentioned in the last article has a line of calibration data:
<merge key="input.x11_options.Calibration" type="string">32 3990 48 3990</merge>
Those four values are the data values one should expect to get from the touchscreen when touching the minimum x, maximum x, minimum y and maximum y positions on the touchscreen. The reason we can provide the numbers is to allow for variations in the properties of each touchscreen, although in general, the values will be around the minimum and maximum values the touchscreen can produce. But what if I fake these values?  Can I use this to trick X into mapping one area onto another?  Let's try...

One thing to note is that from my testing: I've found that the X axis and the Y axis are reasonably independent of each other: Running the stylus along a horizontal or vertical ruler on the touchscreen shows one axis changing a lot but not the other.  Therefore I think the number crunching for the X and Y axes can be done independently.

Mapping an input range of numbers onto an output range of numbers isn't hard. We can visualise the map as a graph, where the X axis shows the input range, and the Y axis shows the output range. The limits of the input and output range correspond to two points on the graph. We can then find the linear equation which describes the line, and once we know that, find the output value for any input value. This should map the touchscreen area to the on-screen area, but also, if we reverse the mapping and feed in the dimensions of the screen, we should be able to find the four calibration values we need to give us the desired mapping.

The first thing I did was work out how much of the touchscreen I want to use. I first considered the case of the nintendo touchscreen.

The pixels on my LCD display are square, so the aspect ratio is 1:1. When the web page is fully maximised, the size of the Skritter writing area on my screen is 347 pixels by 402 pixels. That's an aspect ratio of 0.86. I want to keep the same ratio on my touchscreen.

If I place the nintendo touchscreen with the long axis vertically, the active area is 47.5mm across by 63.5mm high, which is an aspect ratio of 0.75.  Note the two aspect ratios aren't the same.  If I want to keep the aspect ratio the same, I'll have to give up using a small area of the touchscreen.

If I map the width of the touchscreen to the width of the Skritter writing area, the height of the part of the nintendo touchscreen I'll be using is 47.5mm / 0.86 = 55mm. (I can use the remainder for not-on-screen special functions).


Note this picture is not to the same scale as the previous picture.

I then got an index card and cut out a rectangle 47 x 55mm.  I can then place this on top of the larger touchscreen to show me the useable area of the smaller touchscreen:


For comparison, here's the nintendo touchscreen on top of the larger touchscreen:


(The colour difference is because I took the two pictures at different times of the day)

Then I ran the evtest program again,and recorded the touchscreen values for the top left and bottom right corners of the uncovered area on the card.  (The values are backwards because I'm using the touchscreen rotated by 180°).

Tscreen Point X data value Y data value
top left 1940 1850
bottom right 950 203

Skritter Point X data value Y data value
top left 504 285
bottom right 851 687

Screen Point X pixel Y pixel
top left 0 0
bottom right 1680 1050

Now, time for some number crunching.  Treating the X and Y axes separately, we can find the m and c in y=mx+c to map the touchscreen coordinates to screen coordinates.  Then, using x = (y-c)/m, we can feed in the boundaries of the screen, and found out the effective values if the touchscreen was big enough to cover the whole screen, and mapped our touchscreen area onto the Skritter writing area.

I cooked up a spreadsheet to do the number crunching.  I typed in all the coords, and it spits out the four "calibration values" I needed.  You can find the spreadsheet here:

  http://spreadsheets.google.com/ccc?key=0Av3tC4mEgkZPdEl5cl9IR09RdzktUmJvWjEwQURoelE

If I use the data from the tables above, I get the following four values:

Min X 3378
Max X -1415
Min Y 3018
Max Y -1284

Note that two of the four numbers are negative.  That's to be expected.  It just means that with the mapping we have, the lower right corner of the touchscreen is inside the display area.  That's ok for us, because we'll never be sending negative values anyway.  (I'm feeling pretty lucky that whoever wrote the HAL and X stuff didn't disallow negative calibration values....)

So, then I plugged these values into the 11-evdev.fdi file:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- 10-synaptics.fdi is claiming all input.touchpad's as its
own. This file is meant to be loaded afterwards and to undo
any wrong assignments it did.
-->
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.touchpad">
<match key="info.product" contains="eGalax">
<merge key="input.x11_driver" type="string">evdev</merge>
<merge key="input.x11_options.Calibration" type="string">3378 -1415 3018 -1284</merge>
</match>
</match>
</device>
</deviceinfo>


Enough talking, what happened after I restarted HAL and X?  Well, it worked first time!  A light touch to the corners of the restricted touchscreen area goes straight to the corners of my on-screen input area.  I love it when something works first time!  To celebrate, I went and practised Chinese characters for three hours.  So much nicer with a pen rather than a mouse!

What's next?  Well, now that I have the larger touchscreen working, I want to get the cheapy nintendo touchscreen working.  Oh, and practice Chinese more :-)

by mjd (noreply@blogger.com) at May 12, 2010 11:50 AM

Computer assisted Chinese (part V): Touchscreen 3

In the last article, I was getting good sample data from the touchscreen.  But does it work in X? Sadly, it doesn't. Or at least not straight away.

(Note, you'll need to make sure the xorg-x11-drv-evdev package is installed).

When a new USB device (such as that touchscreen) is plugged in, the kernel tells the HAL subsystem. HAL notices the new input device, and tells X about it, and X starts listening to the new device. The beauty of this system is that X can respond correctly as input devices are connected and disconnected from the machine.
The problem is that the standard Fedora kernel treats this kind of touchscreen as an evdev device (good), but HAL makes a mistake about what kind of device it is.  There's a rule in HAL which says "any touchscreen which I don't know about must be a "Synaptics" touchpad". This bad guess gets passed onto X, and X tries to interpret the device as a Synaptics touchpad. Since the device (by the time it gets to X) is really an evdev device, X doesn't know how to handle the touchscreen properly.

So in order to get the touchscreen to work, I had to work out how to convince HAL that the touchscreen was an evdev device, not something else.

This problem has also been experienced by others, and is covered in Fedora bug 473144. To cut a long story short, the most convenient solution is to create a file which tells HAL which kind of input device it really is. Comment 45 of that bug contains a suitable .fdi file:

  https://bugzilla.redhat.com/show_bug.cgi?id=473144#c45
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- 10-synaptics.fdi is claiming all input.touchpad's as its
own. This file is meant to be loaded afterwards and to undo
any wrong assignments it did.
-->
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.touchpad">
<match key="info.product" contains="eGalax">
<merge key="input.x11_driver" type="string">evdev</merge>
<merge key="input.x11_options.Calibration" type="string">32 3990 48 3990</merge>
</match>
</match>
</device>
</deviceinfo>
That bug mentions a file in /etc/hal/fdi/policy called 10-synaptics.fdi. I don't have a file of that name in that directory. Instead, on my machine, it's in /usr/share/hal/fdi/policy/20thirdparty. So I decided to copy the file from that bug report into a file called 11-evdev.fdi in that directory. Then I had to restart HAL in order for it to see the new .fdi file:
  service haldaemon restart
After doing that, I can now see the touchscreen in the output of lshal.

What happens when I restart X? Well, the touch screen works. Sort of.

Note that the maximum X and Y values in that file for the touchscreen axes are 3990. But the evtest utility reported maximum values of 2047. I found that if I use 3990, I can only use the touchscreen for the top left quarter of the screen. Obviously those numbers are wrong for my touchscreen.

When I changed the numbers to 32 2000 32 2000, the touchscreen could point at any location on the X display. Success!

So, what I have now is a working touchscreen, and a setup which maps the whole of the touchscreen to the whole of the display. For reasons I'll go into soon, that's not what I want. But, good progress so far.

by mjd (noreply@blogger.com) at May 12, 2010 11:50 AM

Computer assisted Chinese (part IV): Touchscreen 2

I want to use Skritter with a pen, not a mouse. Commercial products are too expensive for me, so I want to make something using a touchscreen.

While I plan to eventually use a cheap Nintendo touchscreen, I want to start with a touchscreen that I already have, one that used to be in my EeePC. This way, I don't have to deal with as many variables at once.

The interface board for this touchscreen usually speaks to a proprietary kernel module, and proprietary X driver. I would rather not use proprietary software, as proprietary software doesn't let me change things if I need to.

Once upon a time, X was configured with a file called /etc/X11/xorg.conf. This file was a description of all the input and output devices that X had to speak to. You could tell X about a device such as a touchscreen, by having an InputDevice stanza in /etc/X11/xorg.conf, which would cause X to load a driver for that input device. The touchscreen maker provides a proprietary driver for this purpose.

Those days are now gone. In Fedora (and probably in other recent Linux distributions), there's no longer an /etc/X11/xorg.conf file. Instead, it's all done with auto-detection.

The Linux kernel has a subsystem called evdev. It unifies handling of keyboards and pointing devices (and can even "mix" different input devices into one virtual device). The kernel contains drivers for many input devices, which use the services of evdev. One of those drivers is for the touchscreen I have. And for each input device, there'll be a device file in /dev/input.

To start off, I did an ls of /dev/input for files matching event*:
mjd@blackcat [/] ls /dev/input/event*
/dev/input/event0 /dev/input/event2 /dev/input/event4
/dev/input/event1 /dev/input/event3 /dev/input/event5
After I plugged in the touchscreen, I saw this:
mjd@blackcat [/] ls /dev/input/event*
/dev/input/event0 /dev/input/event2 /dev/input/event4 /dev/input/event6
/dev/input/event1 /dev/input/event3 /dev/input/event5
So it appears that /dev/input/event6 is the device file for the touchscreen. I ran evtest on this device: (evtest is in the evtest package)
[root@blackcat /]# evtest /dev/input/event6
Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0xeef product 0x1 version 0x100
Input device name: "eGalax Inc. USB TouchController"
Supported events:
Event type 0 (Sync)
Event type 1 (Key)
Event code 330 (Touch)
Event type 3 (Absolute)
Event code 0 (X)
Value 249
Min 0
Max 2047
Event code 1 (Y)
Value 1397
Min 0
Max 2047
Testing ... (interrupt to exit)
Event: time 1265760809.718325, type 1 (Key), code 330 (Touch), value 1
Event: time 1265760809.718331, type 3 (Absolute), code 0 (X), value 246
Event: time 1265760809.718332, type 3 (Absolute), code 1 (Y), value 1390
Event: time 1265760809.718335, -------------- Report Sync ------------
Event: time 1265760809.770319, type 3 (Absolute), code 1 (Y), value 1389
Event: time 1265760809.770322, -------------- Report Sync ------------
Event: time 1265760809.810320, type 3 (Absolute), code 1 (Y), value 1388
Event: time 1265760809.810325, -------------- Report Sync ------------
Event: time 1265760809.822320, type 3 (Absolute), code 0 (X), value 303
Event: time 1265760809.822322, type 3 (Absolute), code 1 (Y), value 1331
Event: time 1265760809.822326, -------------- Report Sync ------------
Event: time 1265760809.834320, type 3 (Absolute), code 0 (X), value 331
Event: time 1265760809.834322, type 3 (Absolute), code 1 (Y), value 1303
Event: time 1265760809.834326, -------------- Report Sync ------------
Event: time 1265760809.846321, type 3 (Absolute), code 0 (X), value 403
Event: time 1265760809.846323, type 3 (Absolute), code 1 (Y), value 1235
Event: time 1265760809.846326, -------------- Report Sync ------------
Event: time 1265760809.878320, type 1 (Key), code 330 (Touch), value 0
Event: time 1265760809.878326, -------------- Report Sync ------------
^C
[root@blackcat mjd]#
When I touch the touchscreen, I get data! And the data looks sensible, with values for each axis from 0-2047!  Now to get it working with X...

by mjd (noreply@blogger.com) at May 12, 2010 11:50 AM

Computer assisted Chinese (part II): Touchscreen 1

In learning Chinese, I want computers to assist me in two ways. The first is in learning Chinese characters, and the second is as an in-class dictionary/reference.

The first is just a follow-on step from my flashcards and Chutor phone program. But I need to get smarter about how I learn characters. For that reason, I'm using Skritter, a great web service which uses spaced repetition to teach you characters:

  http://www.skritter.com/

To use Skritter, you have to write Chinese characters in an on-screen scribble area.  You can do this with a mouse, but it's fiddly, and I think it's not very good for your wrist, as you're using wrist muscles to try and get the fine motor control you usually get with your fingers on a pen.

A better solution is to use some kind of pen input device.  This is a much more natural way of doing things.  Commercial pen input devices are far too expensive in Australia (at least A$60 for an entry level model).  So I am thinking of using one of these extremely cheap touchscreens, which are intended as replacements for the Nintendo DS:

  http://www.dealextreme.com/details.dx/sku.3245

Eventually I want to read this touchscreen with a small microprocessor, and present this to the computer as a USB touchscreen.  For the moment, I'm going to take a number of half-way steps.

The first half-way step is to start with the larger, commercial touchscreen that used to be inside my EeePC.  The touchscreen size is 15cm by 9cm, which is a lot bigger than I need, but it already has a working controller board.

Once I have that working, I plan to move to one of the smaller replacement touchscreens, and use an Arduino to make it appear as a USB device.

  http://www.arduino.cc/

I think if I can get all this working, I can replace the Arduino with a smaller dedicated micro, put it in a nice, flat case, and make a pen input device for about A$20.

Second project in next post.

by mjd (noreply@blogger.com) at May 12, 2010 11:50 AM

May 08, 2010

Gerard Braad

Chinese Fedora Community and Fedora-MIPS Port

Currently I'm getting ready to move to Beijing (北京), China (中国) in June. While I am still looking for employment I have also been busy with assisting the Chinese Fedora Community (FZUG/中文用户组). As part of some our activities I will give presentations about Fedora and the community at the BeijingLUG. It is a growing community... but we are still looking for new users, ambassadors and contributors. We would also really like to work together with other other user groups in the APAC. If you are Chinese, in China or interested, drop by in our IRC channel #fedora-zh on freenode or get in touch with me (吉拉德, gbraad), Caius Chance (kaio) or Yuan Yijun (袁乙钧, bbbush). We are looking forward to seeing you!

Part of building the Fedora brand, some friends of the Chinese community and I started to port Fedora to the MIPS architecture. MIPS is an architecture that gained a lot of attention recently with the release of the Loongson processor. This processor is Chinese made and ended up in several netbooks and mini-pc's. While they were only available on the Chinese market, they are now being sold in America and Europe, e.g. by the Freedom Included initiative.

Currently we have chosen to target the Loongson 2F, but in time we will also support other MIPS-compatible processors. The primary goal of this project is to provide support for MIPS as a secondary architecture in Fedora. Just like the ARM port, our secondary goal is to enable derivative distributions based on the Fedora package collection and repository that are more suitably optimized for embedded and mobile use-cases. For this we want to work together with the Mini SIG as we can both benefit from this.

We now have a test build available of Fedora 12 (as n32 mipsel) which should be able to run on Qemu or MIPS-based hardware, like the Fuloong. While we are in the process of fixing some remaining build and technical issues and submitting the patches, you are invited to help us test this release. The Fuloong is currently the platform we build and test on ourselves. Be warned, expect to do some DIY especially since no documentation is available yet... and your mileage may vary.

The team currently consists of me (project-lead), FaiWong (technical lead, lazyfai) and XinZhen (co-lead, lonestar). If you want to contribute or donate hardware, please get in touch with us. More information can be found on the Fedora-MIPS wiki page, or just drop by in our IRC channel #fedora-mips on freenode.

by gbraad (noreply@blogger.com) at May 08, 2010 11:29 PM

May 02, 2010

Zedstar

GNU Guile on a Ben NanoNote with command line history (readline support)

I have been hacking at the OpenWrt Makefile and now have command line history working within the REPL.

opkg install http://zedstar.org/guile/libgmp_4.3.1-2_xburst.ipk
opkg install http://zedstar.org/guile/libltdl_1.5.26-1_xburst.ipk
opkg install http://zedstar.org/guile/guile_1.8.7_xburst.ipk

Once installed setup a .guile file:

root@BenNanoNote:~# cat /root/.guile
(use-modules (ice-9 readline))
(activate-readline)

When you run guile now you should be able to use the up and down cursor keys to go through your command history etc.

by john at May 02, 2010 09:20 PM

April 20, 2010

Alvaro Lopes, gta02-core-news

(Kinda) Weekly News for April 20th, 2010

Welcome to this edition (sixth) of #gta02-core news, for April 20, 2010.

Why no posts since October 2009?

My fault, I'd should update this more often, but there were actually several reasons. Some changes on my personal daily life, many projects going on, work, few developments on #gta02-core project, all account for the lack of news.
I hope at least the latter will force me to update this blog, but that will depend on a lot of factors.

So, what are the latest developments ?

Well, let's try to summarize. A lot of background work has been done in fped and other not-so-visible areas of the project. Our beloved mentor (Werner) also had a twist on his life (he moved), and no one actually stepped up for his "job". Most news are actually not so good news, I'll try to explore those as we move along.

Fedora Electronic Lab

The guys at Fedora included support for kicad, fped and openocd on their Fedora-12 release, making development of Electronic Hardware Development a lot easier on their platform.
Thanks!

The pending ECN

A lot of ECN have been worked on: ECN0019 (buzz fix), ECN0024 (GPS ground and layout), ECN0010 (Audio amplifier) [which includes changes to power unit], ECN0015 (Calypso headset), ECN0032 (EMI/ESD protection), ECN0017 (BT to main PCB), and others like
ECN0031, ECN0033, ECN0036, ECN0037, ECN0011 (varistor cleanup), ECN0008 (mistery caps), and ECN0038.

Component status

Trying to understand what components actually Openmoko had in stock started last year (as you can read on this post).
Werner posted a list of the inventory back in January, and the the BOM process we ought to
follow on this post, followed by a list of missing items.

Then, we realised we have another big problem - some components are not easily sourceable, so we need to move to other alternatives.

To focus, or refocus

I did a lenghty post back in February about to focus on current hardware, or instead updating our design to match newest devices, like iPhone and HTC. We'll stick to our
current design.

Cashier needed

We need to figure out how to deal with all donations project is receiving, and perhaps have someone focused on dealing this this issues. If you're interested, please stand up.
There's also an discussion going on with Jon "maddog" Hall about the subject.

Researching component alternatives


Some of our components are hard to source, and there's work to be done to find where we can get those components from. For some of them we need to look up alternatives, if you find something similar and easy to source, please let us know. One late component that was found hard to source is the backlight LCD inductor. Alternatives were using a larger footprint but max. current compliant one, or to use a smaller one and live on the incertainty. We decided for the larger one. Another list of missing components came up, so if you have some time helping us locating those, please do.

Again the backup battery

ECN0040 was revisited recently, since we actually never had a concrete desision on this. We'll probably move to a large capacitor and drop the battery.

Quotes

Whoa ! I should frame this, nail it to the wall, and show it to any
Openmoko veteran who comes visiting ;-)

Werner Almesberger

This news is a great Christmas gift ;)
Patryk "LeadMan" Benderz

Done - wouldn't want anything fishy going on :-)
Dave Ball

by Alvie (noreply@blogger.com) at April 20, 2010 12:39 PM

April 16, 2010

Zhou Yajin, vm-kernel.org

Gdium linux kernel support status

After several days working, the 2.6.34-rc2 kernel is working on gdium expect sound. Of course most of the codes are from mandriva and Philippe's work.

I will make some code clean and make the sound work in the next few days. It seems the sm501 sound driver needs a hardcoded 8051 firmware to work. Damn it. After these works are done, I will send the patches to loongson-dev maillist and merge it to linux-loongson-community and linux-mips mainline at last.

I am keeping moving....... Please wait.

ps: The linux kernel for gdium repository is here.

kill-bill:~# uname -a
Linux kill-bill 2.6.34-rc2 #24 PREEMPT Fri Apr 16 21:01:51 CST 2010 mips64 GNU/Linux
kill-bill:~# cat /proc/cpuinfo
system type : dexxon-gdium-2f-10inches
processor : 0
cpu model : ICT Loongson-2 V0.3 FPU V0.1
BogoMIPS : 598.01
wait instruction : no
microsecond timers : yes
tlb_entries : 64
extra interrupt vector : no
hardware watchpoint : yes, count: 0, address/irw mask: []
ASEs implemented :
shadow register sets : 1
core : 0
VCED exceptions : not available
VCEI exceptions : not available

by yajin at April 16, 2010 01:20 PM

March 27, 2010

Zhou Yajin, vm-kernel.org

Install debian lenny on yeeloong 8089/8101

NOTICE/TIPS:
[For one want to install the debian 6.0, there is a more easy way. See the following link.
http://www.anheng.com.cn/loongson/install/readme.txt (In Chinese).]

Yesterday I installed the debian lenny on yeeloong 8101, the 10.1 inch notebook based on loongson 2F CPU for a friend. Then I find there is less English document describing how to do this. So I write the process down to anyone who is interested in installing debian on yeloong. There are many ways to do it I choose the way of using a debian network installer. Please make sure you have a internet connection first.

1. First download the kernel and initrd to your PC.

wget http://dev.lemote.com/drupal/sites/default/files/kernel-2.6.27-LM8089.tar.gz
wget http://dev.lemote.com/drupal/sites/default/files/initrd_yl_netboot.gz

2. Decompress kernel on your PC.

tar zxvf kernel-2.6.27-LM8089.tar.gz

You will get the kernel vmlinux and the directory named lib. The lib directory contains all the kernel modules.

3. Format your USB disk with ext2 partition and copy vmlinux, directory lib and initrd_yl_netboot.gz to the usb disk.

4. Insert the usb disk to your netbook and boot it

5. Enter the PMON command line.

There are two ways to enter the PMON(the bootloader of yeeloong) command line. One is press DEL when booting. The other way is click C when you see the boot menu.

Use the following commands to load the kernel and initrd, which contains the debian network installer.

load /dev/fs/ext2@usb0/vmlinux
initrd /dev/fs/ext2@usb0/initrd_yl_netboot.gz

Please be patient. The initrd command may need more than 5 miniutes to be finished.

Sometimes the PMON bootloader may hang when you boot with a usb disk inserted. I do not know why. The workaround is booting into the default linux system and inserting the usb disk and then rebooting. Or you can use a tftp method to load the kernel and initrd.

At last use the following command to launch the debian network installer.

g console=tty no_auto_cmd

Then just install the debian as normal.

6. Install debian lenny

After debian configurating the DHCP, it will complain about "no kernel modules were found" and will let you choose "continue the install without loading kernel modules?", just choose Yes(the default answer is No) to continue.

When in the part of Partition disks, it will complain about "The current kernel doesn't support the Logical Volume Manager. You may need to load the lvm-mod modules" and the background becomes red. Do not be scared. Just click continue. :)

Then everything goes as it should be. But at last, debian installer will say "no installable kernel was found in the defined APT sources.... Continue without installing a kernel". Do not click Yes too quickly. We need to copy the kernel and all the modules into new system first. Please make sure that the USB disk is still inserting on the notebook. Use ALT+F2 to active a console. Mount the use disk and copy kernel and libs.

mount /dev/sda1 /target/mnt
cp /mnt/vmlinux /target/boot
cp -rf /mnt/lib/modules /target/lib/

Then click ALT+F1 return to the debian installer. Click Yes to continue installing.

7. Install Desktop environment

You can install LXDE or gnome as your desktop. I prefer LXDE because it is light.

apt-get install lxde

Install the X server driver.

wget http://www.anheng.com.cn/loongson2f/lenny/xorg-server/xserver-xorg-video-siliconmotion_2.2.8-lemote.r04_mipsel.deb
dpkg -i xserver-xorg-video-siliconmotion_2.2.8-lemote.r04_mipsel.deb

Change the xorg.conf according to this link.

8. Trouble shooting

(1) My wifi does not work

You can see "rtl8187: rtl8187_open process failed because radio off" if you use dmesg to see the message. Use FN+F5 to turn on the wifi first. You will see such message "rtl8187: SCI interrupt Methord Will Turn Radio On" on your console.

(2) My sound does not work

Use alsamixer to adjust the volume. But install alsa-utils first.

(3) OOPS, I forget to copy kernel to my new installed system. I can not boot it now. What should I do?

You can load the kernel using tftp method.

by yajin at March 27, 2010 06:28 AM

March 16, 2010

Methril

My 0x1F day

As a bit mask, today is my 0x1F (31) birthday (i´m almost 0x20). But the day is going ok.

A lot of changes happens lately:
  • In my personal life, i moved my house from Spain to Brazil (really big change). One of the best consequence of this movement is the people i met at my new job, really nice people with a nice job.
  • In the job side i´ m working in a open-minded company for the hardwar/embedded path. That gets me happier.

So i´m comfortable and almost fully installed in my new home.

In the Open projects side, i´m improving my knowledge and i´m proud to announce that Wolfgang added me to the qie-hardware planet [1] :)
I´ve been testing the Ben Nanonote. A wonderful and amazing gadget that promise a lot. Wolfgang, with his efforts, is also engaging me to all the projects they are raising. I love the Milkymist project and the SAKC is a good hardware device for approaching the FPGA development. He is also encouraging some open-like hardware projects & putting them (or us) in contact to deal with "open philosophy" together.

Thanks Wolfgang & all the people involved in Qi-hardware. Some of them: Mirko. Xiao. Adam. .... & some old friends Tuxbrain (David & Victor), Ida Systems (Rakshat) I hope to see more people involved & growing this community effort.

See you soon.

[1] http://en.qi-hardware.com/planet/

by Methril (noreply@blogger.com) at March 16, 2010 07:55 PM

March 04, 2010

Capn's Tech

Computer assisted Chinese (part III): Dictionary

The second project stems from my deep unhappiness with the Chinese electronic dictionaries that are out there.  Most of them are aimed at Chinese people learning English, not westerners learning Chinese, and they really suck.  The only thing more awful than the software that's generally on them is the horrid dictionary databases in use.  If there are five ways of saying the same thing, how do we know which one is right for the situation?  And which are current and not archaic?

When I've read English dictionaries for Chinese people, the English seems about 100 years old and quite laughable.  I get the same impression when trying to find words I want in a Chinese-English dictionary:  It's not clear which one I want, and when my Chinese friends see my choice, they just tell me "oh, we don't use that word".  Pah.  And don't get me started about how inflexible the searching is.  I should have the ability to click on a character, break it down into components, then see other words with the same components.  That will help me sort out whether I want 青、晴、清、情,or 请!

When I'm online, I'm constantly using the dictionary at MDBG. It's aimed at Chinese for westerners, and the English descriptions are carefully worded so that in general, it's possible to tell which of the five ways of saying something you actually want. And seeing which HSK level a word is rated at also gives an idea of how common it is.

  http://www.mdbg.net/chindict/
 http://en.wikipedia.org/wiki/HSK_test

This website uses the CC-CEDICT database, which can be downloaded and used for free! Since I like the database so much, I've been dreaming of writing my own Chinese dictionary program which uses that database. And I intend to turn that dream into reality. But in order to do that, I need a platform to run it on.

I have looked around, and I've decided to write it for the Nintendo DS. This is a mature platform, with 4M of RAM, two nice screens, long battery life, a free toolchain, a GUI library, and as much read-only data as you can fit on an SDHC SD card. And cheap too: I picked up a grey market one the other day for A$130.

  http://en.wikipedia.org/wiki/Nintendo_DS_homebrew

As far as a user interface goes, I am thinking of making it work somewhat like this program called Pablo:

  http://ehaton.blogspot.com/2007/02/learning-chinese-pablo-my-personal.html
  http://haton.free.fr/chino/pabloscreenshot.jpg

There are also some free handwriting recognition engines which I plan to try, with a view to giving my dictionary handwriting recognition:

  http://www.tegaki.org/
  http://www.kiang.org/jordan/software/hanzilookup/
  http://hanzirecognizer.sourceforge.net/
  http://zinnia.sourceforge.net/

The DS doesn't come with a UI library, so I would either have to write that myself, or use someone else's.  I am intending to use the "Woopsi" library:

  http://ant.simianzombie.com/?page_id=128

I think my first task will be to port my Chutor program from J2ME to the DS.  As well as being useful in it's own right, it will be a good test of the UI library, and my ability to port Java to C++.

Once that's done, I will move onto doing the dictionary program.  I'm likely to leave the handwriting recognition to last.

by mjd (noreply@blogger.com) at March 04, 2010 09:37 PM

February 26, 2010

Capn's Tech

International Space Station radio link-up

I just had a lovely evening at my kids' primary school.  A group of staff, parents and amateur radio enthusiasts have worked for months to organise a very special event: A radio link-up with the international space station.

To talk to the ISS, some local amateur radio enthusiasts hooked a phone line up to the PA, and this phone line went to Shane Lynd of Glendon, Queensland.  Using his aerial, radio equipment and phone patch, we were able to talk with astronaut Timothy "T. J." Creamer while the ISS was within line-of-sight of Glendon, which was about six or seven minutes.

The link-up was arranged by Tony Hutchison of Kingston SE, South Australia, who coordinates ARISS (Amateur Radio on the International Space Station).  ARISS lets crew members talk with family and schools, and provides backup comms with the station.  There's a nice video about Tony's work here

  http://www.youtube.com/watch?v=2KL8TGTUBTU

The students took turns to say their name, ask their question, and finish with "over".   Here's the list of questions, plus my unreliable recollection of the answer T. J. gave [and some comments by me]:

  1. At what stage in your life did you decide you wanted to be an astronaut?

    He said it wasn't a sudden choice, a lot of things he'd done beforehand prepared him for it and when he had the chance, he said yes.  [His bio is here]

  2. Does living in a zero gravity environment cause long term health problems?

    There are changes to bone density, to the muscles of the heart, and even to the structure of the eye.

  3. How far have astronauts ever been in space?

    To the moon.  Most people don't realise that only 12 people have been to the moon.  Everything else has been done in low Earth orbit.

  4. Who was the youngest astronaut to go into space? How old was she or he?

    T. J. didn't know the answer to this one, but he suggested that the student go to nasa.gov or Google for it.

  5. How do you exercise in space?

    He said he uses a treadmill, with bungees that keep him in place so he doesn't float away.

  6. How did you get into space?

    He said he was launched on a Soyuz rocket from Baikonur Khazakstan.

  7. What if there is a fire? Can you get rescued?

    He said that the space station is designed so that in general, things can't catch fire.  But if there was a fire, they'd cut the power and the fire would likely go out.  They can also use fire extinguishers.  If the fire was too serious, they could come home in the Soyuz capsule that is always docked to the station.

  8. What’s the most interesting thing about space?

    He said floating around, and looking at the Earth.

  9. How do you drink in space because there is no gravity in space?

    He told us about how they drink from fluid pouches.

  10. How do you control the space ship when it is floating in space?

    He said that attitude control is done with gyrodynes [but I think he means control moment gyroscopes, as gyrodynes are a type of aircraft].  If the gyrodynes become saturated, small thruster rockets take over to correct the situation.

  11. Are there aliens in space?

    He said he hadn't seen any, but he'd sure be glad to meet and talk with them.

  12. How do you sleep in the space station?

    He said he zips himself into his sleeping bag, that has straps which stop him floating around.  He said he sleeps very well.

  13. What is your favourite food you eat in the space station?

    Fresh fruit.  He said it was great when the Space Shuttle brought up some fresh fruit.

  14. What do you do on the space station to relax?

    He mentioned that he likes to go into his bedroom and read or use the internet to research things.  [He also likes running]

  15. What happens if you run out of air?

    He said that this is managed pretty closely from the ground, so it's unlikely to happen.

  16. What happens to all the rubbish from the space station?

    All the trash gets put into the Progress resupply vehicle, which is undocked and deorbited.  The vehicle and the trash burns up in the Earth's atmosphere.

  17. How often do you have to do space walks to make repairs to the space station?

    He said that they don't generally go outside to fix things.  He said that he's done spacewalks, but he's not scheduled to do any spacewalks on this expedition.

  18. When you are in space are you ever nervous about anything?

    He said that in general, he's not.

  19. When you swallow your food, does it feel funny in your stomach when in zero gravity?

    [out of range]

Unfortunately the 19th question couldn't be asked, as the station had moved out of range.  I feel sorry for that student.  If I was that student, that would be one of my "life's regrets".  (And I have so few)

In all, well over 200 people enjoyed the evening.  A big thank you to T.J., Tony, Shane, the local amateur radio enthusiasts, and all the others who made this possible.  It was certainly a night I'll never forget!

by mjd (noreply@blogger.com) at February 26, 2010 02:32 PM

Hawkboard

Active discussions

Subscribe to RSS headline updates from:
Powered by FeedBurner

by admin at February 26, 2010 11:32 AM

February 25, 2010

Zedstar

Guile on a Ben NanoNote

Received a Ben NanoNote today. It is a really natty little device with a lot of potential.

My standard test on how hackable a device is involves getting Guile running. Anyway, it was pretty easy to accomplish this despite not using openWrt before.


root@BenNanoNote:~#
root@BenNanoNote:~# guile
guile> (map (lambda (x) (+ x 1)) '(1 2 3 4 5))
(2 3 4 5 6)
guile>

To install get the 3 xburst packages from here.

Happy Scheming!

by john at February 25, 2010 10:58 PM

February 15, 2010

Bearstech Hackable:1

Openmoko devroom at the fosdem

Hello hackable:1 users !

Serdar Dere, from #openmoko-cdevel managed to get a devroom at this year's fosdem for the openmoko community !
First things first, huge thanks to him.

Second, we get the room on Sunday morning and the schedule is here. As you can see, it is full of talks and hackable:1 has a slot.

Meet you there ! Who's coming ?

EDIT: The slides

by David Wagner at February 15, 2010 06:08 PM

February 09, 2010

Capn's Tech

Computer assisted Chinese (part I)

I am learning Chinese.  Since I hate doing things by hand that can be automated (and because it's much more fun to hack with the the computer than do work), I like to use the computer to help me whenever I can.

For me, the hardest thing about Chinese is learning the characters.  Unless you're actively learning and reviewing them every day, you're forgetting.  And the techniques I've seen my classmates use (such as just writing them a few times) doesn't seem to help me.

When I was learning Chinese in 2005, I typed the word list from each chapter of the textbook into my computer.  From this, I could print the lists on labels, and make flash cards.  Each flash card had the Chinese character and the pinyin (pronounciation) on one side, and the English meaning on the other.  It took a lot of time to enter the characters, and a lot of time to make the flash cards, but I found it a very effective way of learning.  I'd stick a bundle about 6cm x 4cm and 3cm high into my pocket, and be all set to learn when I had some free time, such as waiting for a train.

I'd start with all the cards in my hand, and look at each one in turn.  If I knew the card (for example, I could write the character from memory, given the meaning and the pronunciation), I'd remove that card from my hand, and put it on my discard pile.  Otherwise I'd move that card to the back of the pile I was holding.  The cards I knew well would quickly leave my hand, and my time would be spent working on the ones I didn't know.  For reasons I don't fully understand, some characters are easy for me to remember, and others give me such trouble.  It was years before I could remember to write such every-day things as 喜欢 and 意思!  When I'm learning, I might need to see some cards ten times before it will finally sink in.

What I had implemented was a real-world form of a "spaced repetition" learning system, and it worked really well for me:

  http://en.wikipedia.org/wiki/Spaced_repetition

The drawback of this approach, as well as the preparation time, is that I ended up with a bag of some 22 bundles, which is a pile around 60cm high!  That was quite unwieldy to carry around, so I'd have to put some thought into the bundles I wanted to carry, and leave the rest at home.

After a while I got tired of the physical nature of the cards, so I decided to do it with a computer program.  But lugging around a laptop is not really an option!  What could I run the software on?

I eventually decided to write the app as a J2ME Java app, as J2ME programs will run on most phones.  Over the course of 2007, I worked on the program when I had some spare time (mostly on the train).  I finally released the program in 2007 as "Chutor", which is a portmanteau of "Chinese Tutor".

  http://sf.net/projects/chutor
 
It shipped with the word lists from the New Practical Chinese Reader volumes I, II and III, because that was the textbook I was using at the time, but it can be tailored to take any vocab.  When I was in China in 2008, I reworked it to use the vocab of the textbooks were were using there.

Although the program has a number of non-critical bugs, I find it very convenient for reviewing characters when I have a few spare minutes:  waiting for a train, or for a few minutes before going to sleep (and yes, learning characters is very effective at inducing sleep).

The missing feature I'd like most is spaced repetition (although I really want and need it, and adding it wouldn't be hard).  At the moment, if you get a character right, that character gets dropped until you go and select a new set of chapters.  But even so, the program is useful enough.

Give Chutor a try on your phone.  Does it work for you?  Does it help?

by mjd (noreply@blogger.com) at February 09, 2010 03:35 PM

February 08, 2010

Capn's Tech

First post!

Well, hardly surprising as it's my blog :-)

I've created this blog to put tech stuff in that wouldn't appeal to the sort of people who read my other blog. Expect stuff about electronics, creative spaces, Linux and coding.

by mjd (noreply@blogger.com) at February 08, 2010 06:53 PM

January 27, 2010

Geoffrey L. Barrows - DIY Drones

Micro Helicopter Hovering in Place Using Vision Sensing



Find more videos like this on DIY Drones

Find more videos like this on DIY Drones
Some of you may have seen Centeye's old website showing our earlier work flying optical flow sensors on small RC-class aircraft. Much of this work was sponsored by DARPA and the U.S. Air Force. More recently we have been hacking an eFlite Blade mCX, a very stable small 7" contra-rotating coaxial helicopter.

The helicopter is a basic mCX airframe, minus the front canopy, and with the out-of-box green receiver / controller board replaced with one of our own design. Our own board sports an Atmel AVR32 microcontroller and an AT86RF230 wireless chip as well as carbon resistor strips and transistor circuits to implement the swashplate servos and rotor speed controllers. We have also integrated into the board a 6DOF IMU using standard MEMS components.

In front of our controller board is a sensor ring with eight custom designed vision sensors mounted on a flexible circuit board and a processor board having another AVR32. They are stacked vertically via 0.8mm board-to-board connectors- Thank You cell phone industry! The processor board operates the eight vision sensors (which form an nice parallel system), acquires the imagery, computes optical flow, and sends high level control signals to the controller board. The whole sensor ring, including processor, flexible ring, vision sensors, and optics together weigh about 3 grams.

Using a variation of control algorithms developed by Sean Humbert's lab at the University of Maryland at College Park, we were able to have this helicopter "hover in place" for up to six minutes straight. We could even perturb the helicopter slightly by manually moving it, and it would attempt to return to its original position. We have been able to get this demonstration working in a variety of room sizes and illumination levels. For these experiments, we did not use the IMU- the helicopter held its position (including yaw angle) using purely visual information. The man in the videos above is Travis Young, who has been executing the control aspects of this project at Centeye.

Just to make it clear- All sensing, processing, and control is being performed on the helicopter. There is no human in the loop in these videos.

Centeye is participating in the NSF-funded Harvard RoboBees project, led by Harvard EECS professor Rob Wood. As part of this project, we will be building vision sensors weighing on the order of tens of milligrams. If all goes well, we should have our first prototype at this scale by this summer!

The RoboBee project will also let us do something that I personally have been wanting to do for a long time- to develop a portfolio of purely consumer/academic/hobbyist vision sensors that I can get into the hands of people like the members of this community! I'll be starting a thread soon in the "Sensors and IMUs" forum where I'd enjoy discussing this with everyone.

by Geoffrey L. Barrows at January 27, 2010 09:30 PM

January 22, 2010

Zhou Yajin, vm-kernel.org

UNSW Advanced OS about L4

For someone who is interested in OS and micro-kernel especially L4.

Part 1:

Part 2:

Part 3:

Part 4:

Part 5:

Part 6:

Part 7:

Part 8:

by yajin at January 22, 2010 08:18 AM

January 20, 2010

Methril

A lot of time without news

I've been busy with my daily/paid job, and i have not be able to put any update to this blog.
We start a new year and it's time to post some updates of whats going on from my part ;)

First, i'm moving to Brazil. This give me a lot of headaches, as i need to do a lot of paperwork. I'm almost finishing this issue, as i'm going to travel in 9 days!!

I would like to say thank you to my TuxBrain coleages (we get fun together and we work nicely together); i could not forget IdaSystems (that always believe in my hard work); news projects evolving like Genesi-USA (they finally sent me the EfikaMX board!! :D), Qi-hardware, Harald Welte & other hackers that are giving some GSM freedom :D; all OpenEmbedded hackers, that give me one of the better development tools that i never tested; all SHR & Openmoko comunity (they persist on this device and give us some usable software in that piece of hardware - and maybe a little bit more); and all the FOSS developers/hackers & communities that i'm involved :D (i don't have enough space to put all of them here).

I don't know if i'm going to post anything before i move, but.. this is my first 2010 post & i'm really happy with my future plans.

See you soon (from the south hemisphere) :D

by Methril (noreply@blogger.com) at January 20, 2010 09:43 PM

December 22, 2009

Bearstech Hackable:1

New feature for rev5: h1settings

In this article I'm going to describe a new feature which will be available in rev5: h1settings.

h1settings is a library which handles the global settings of the phone. It is a basic wrapper upon some gconf keys and has functions to :
  • read and update key values
  • listen to gconf key changes
Currently, only a few keys are available :

Device states :
  • gprs on/off : /desktop/h1/phone/enable_gprs
  • gsm on/off : /desktop/h1/phone/enable_gsm
  • gps on/off : /desktop/h1/gps/enable_gps
  • wifi on/off : /desktop/h1/phone/enable_wifi
  • bluetooth on/off : /desktop/h1/phone/enable_bluetooth
Power management :
  • power management enabled / disabled
The idea behind this library is to add loose coupling between components. For example the power management key is used by the gsm applet when a call is in progress (to fix this silly bug: http://trac.hackable1.org/trac/ticket/42 ) in order to disable power management (i.e. suspend). The gsm applet does not know how to disable PM but neod knows.

Currently, all the actions related to key states except gsm are handled by neod, the central daemon. It registers itself for these keys changes and sets the state of the devices. For the gsm part, it is handled by the gsm applet because it has already everything needed to switch on/off the antenna.
 
Another advantage is that an independant settings app can be built very easily without any dependencies with the underlying system, and this app already exists : h1settings.
See some screenshots below :

h1settings-1.png
h1settings-2.png


by Jérome Blondon at December 22, 2009 02:30 PM

Running hackable:1 on the ROAD Officer S101

Within my position for the promotion of free, open-source hardware solutions in general (and currently, telephony in particular), I am of course trying to keep in touch with the latest developments in this field. Eventually, I have met the fine people at ROAD, a small company in Berlin developing a phone: the Officer S101.

If you don't know about it already, its form-factor will remind you of the Nokia Communicator: from the outside, it looks like a regular candy-bar phone, but it also reveals a full keyboard and wide-screen display when opened. What interests us here is that its inside is open, too :)

The device is not in production yet, but they have been so kind as to let me borrow a sample for a while, which I demonstrated during my hackable:Device workshops at HAR2009 by the way. This is where I managed to install hackable:1 on the phone.

On the hardware side, it was difficult to let it be easier to test. Let me stress first that this was a pre-production device, and all of this may be subject to changes! So here we are:

  • the phone has an internal flash memory but can also boot on an SD card, which is conveniently replaceable without opening the phone or even removing the battery,
  • the first partition of the SD card must be formatted as a FAT filesystem,
  • I was provided with two second-stage bootloaders: one that boots the phone from flash, and the other which updates it.
Therefore, it was just a matter of copying the correct bootloader on the SD card, along with the root filesystem to flash if desired.

About the software now, this device happens to use the same architecture as the Openmoko Freerunner within Debian, "armel". One only has then to choose the right packages, configure them accordingly and generate a filesystem archive.

First, I have added a generic device definition file in trunk/build/profiles/ROAD-Officer.include:
DEBIAN_ARCH="armel"
STRIP="arm-linux-gnueabi-strip"
The "STRIP" line is necessary because of the way we are currently cross-compiling Debian packages: the native tools are unable to strip the binaries cross-compiled. Therefore, strap:1 is currently doing it instead, while generating the images.
#this device is a phone
. "profiles/generic-phone.include"
#add bluetooth support
. "profiles/generic-bluetooth.include"
#add GPS support
. "profiles/generic-gps.include"
#add touchscreen support
. "profiles/generic-touchscreen.include"
#add wifi support
. "profiles/generic-wifi.include"
This should be self-explanatory :)

#packages
#Debian
PACKAGES="$PACKAGES
[...]
xserver-xorg-core
xserver-xorg-input-kbd
xserver-xorg-input-tslib
xserver-xorg-video-fbdev
zlib1g"

Unlike the Openmoko Freerunner, which has its own dedicated X server, we are using the generic framebuffer-based X server. It just works :)

#specific kernel
#FIXME still needs to be packaged
PACKAGES_BLACKLIST="xserver-xorg-video-all"
In order to gain space, we are blacklisting this meta-package: xserver-xorg-core dependencies are actually satisfied with at least one video driver installed, which is the case here.

Next comes the actual profile definition, in trunk/build/profiles/ROAD-Officer-user.profile:

. "profiles/ROAD-Officer.include"
#blacklist packages to gain space
PACKAGES_BLACKLIST="bash
debconf-i18n"
#additional dependencies adjustments
PACKAGES="$PACKAGES
debconf-english"
CLEAN_DOC=yes
CLEAN_LOCALES=yes
This was directly taken from the Openmoko Neo1973 profile, which has tough space constraints on the flash. Here we do not have such limitations, however it made the testing process slightly faster.

Anyway, after some more tuning in trunk/build/packages, it was time to generate the filesystem archive:

$ ./build.sh VENDOR=ROAD MODEL=Officer PURPOSE=user archive

At this stage, the only missing bit was the kernel. I simply used the one already flashed onto the device, but I still needed some modules. They were of course provided to me in source and binary forms, but I don't think this kernel tree is available publicly at the moment. I am sure it will be as soon as the ROAD developers can manage.

Unfortunately, I could only get this far yet. It boots all the way to the graphical user interface, where the Om2007.2 design does not really fit the rather wide screen. We are currently working hard on the next release, rev5, and focusing on the Openmoko Freerunner first, but I will be resuming this work soon enough!

by Pierre Pronchery at December 22, 2009 02:29 PM

Temporary issues with emdebian's toolchain solved

When cross-compiling hackable:1 packages, we are relying on the stable emdebian toolchain to compile our programs. Apparently, there has been a problem last week, where the toolchain was erroneously recompiled and from then on depending on packages not available on Debian Lenny.

We have coordinated this issue with emdebian's team, and are glad to announce that everything seems to be back in order.

If you have been upgrading your hackable:1 cross-compilation environment during this window, there is a simple way to get it to work again:
# apt-get remove --purge libgcc1-armel-cross
# apt-get install gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi

Then you should be able to cross-compile again!

by Pierre Pronchery at December 22, 2009 02:29 PM

Study boot process to improve boot time

One thing I'll certainly work on in the upcoming weeks is boot time improvement.
So far, booting takes quite a long time. But instead of looking at my clock when powering up my FreeRunner, I installed a tool to go deeper in the boot process and analyse its (non-)performance.

bootchart_small.png This tool is called Bootchart-lite, a clone of the well known Bootchart on desktop systems.
That's a basic rewrite from embedded systems that create similar logs as its big brother bootchart, meaning bootchart can compute them.

If you are interested in working on boot time improvement, you should install it !

Uboot configuration

The bootloader must be configured to add a kernel parameter. Here is the way for Uboot. Adapt it for Qi if you use it.

    # apt-get install fso-utils # from FSO
    # mkdir /tmp/uboot && cd /tmp/uboot
    # dfu-util -a u-boot_env -U env.u-boot
    # uboot-envedit -i env.u-boot -p > env_modified.u-boot.tx

Edit env_modified.u-boot.txt to tell the kernel to use bootchart-lite instead of init as first process.

    boot_menu_timeout=300
    bootargs_base=rootfstype=jffs2 root=/dev/mtdblock6 quiet bootlevel=8 init=/usr/bin/bootchart-lite console=ttySAC2,115200 console=tty0 loglevel=8 regular_boot
    ...

    # uboot-envedit -i env.u-boot -f env_modified.u-boot.txt -o env_modified.u-boot
    # dfu-util -a u-boot_env -D env_modified.u-boot

* Install the packages *

On your FreeRunner running Hackable:1, install bootchart-lite: (As of september, 18, it is packaged for daily builds, and will be packaged for rev5)

    hackable1# apt-get install bootchart-lite
    hackable1# reboot

Get data and render the image

On your computer, install bootchart-view (from the big brother bootchart project), and get the logs.
Then, render the PNG (or SVG) image.

    # apt-get install bootchart-view 
    $ scp -r root@hackable1:/etc/bootchart-lite .
    $ cd bootchart-lite
    $ tar czf bootchart.tgz *.log
    $ bootchart -f png bootchart.tgz

Analysis

That's the most difficult step :) !

I'll have a look on that later, I'm focusing on rev5 for now.

Eh ! There are "beta2" images available on http://build.hackable1.org. Would you give it a try ?

Please let us know how you like it and if bugs remain !

by Sébastien Bocahu at December 22, 2009 02:29 PM

Hackable:1 rev5 is out !

Dear Hackable:1 users,

After rev5rc1, we spent hours and hours debugging this or improving that to finally get the rev5 out today. Yep, that's right: hackable:1 rev5 (Codename: Chuck) is there!


Xbackground.png

First of all, you can grab the different flavours (user for the flash and developer for the SD) here: http://download.hackable1.org/rev5

Changelog

Here are the changes since rev4:

+ End users matters

  • Most of the software stack now runs under the 'hackable1' user, for security purposes.
  • SMS proper implementation
  • The contact list bug has been found and fixed!
  • Power management improvements, suspend works, bluetooth and wifi are no longer turned on by default.
  • An application called 'h1settings' can be used to configure phone features, (enable / disable GSM / Wireless / GPS, power management, ...) as well as time and date.
  • We created a new theme to celebrate this new release!
  • We got a splashscreen! It features a Chuck figure to reflects the rev5 codename: Chuck
  • For those who used to love the games on OM2007.2, we put them back !
  • Boot time seems to have been improved a bit

+ Power users / developers matters
  • This rev5 release has entirely been built from the automatic build system.
  • A Linux kernel is now packaged in hackable:1, in order not to rely on fso-pkg anymore.
    • Debugging has been disabled (boot time improvement)
    • Easier kernel upgrade when using an ext2 partition to store the kernel on µSD cards
    • Separation of kernel modules in three sets: essential (comes with the kernel), common modules and "more modules"
    • You can read a bit on http://zecrazytux.net/Embedded/Hackable1/Custom_Kernel.html
  • CDBS is now used for some packages.
    • the package h1packtools contains a CDBS rule that may suffice for simple programs with the autotools
    • this rule also enables cross-compilation ; it is based on previous works on this subject
  • Git repositories can now be used as sources for remote projects.

Where can I find it? Where can I get it? I didn't understand last time, so I ask again : what is the answer to the ultimate question about life, the universe, and everything?

As ever, you can download hackable:1 on http://download.hackable1.org/rev5.

All the necessary information can be found on http://trac.hackable1.org as ever, that is documentation, installation instructions as well as known issues.

It's obvious that the answer to the aforementioned question is "Chuck".

Who should I thank for all that stuff?

Among the people who worked on this release, the most notorious are (alphabetically):

  • Marcus Bauer (mbauer)
  • Jérome Blondon (jbl2024)
  • Sébastien Bocahu (zecrazytux)
  • Pierre Pronchery (khorben)
  • David Wagner (Deubeuliou)

We'd also like to thank all the testers, among them most notably Bearstech employees, and regular contributors/users of hackable:1, who kept us going forward.

What should I expect next?
Due to a very good number of good reasons, which could all of them be summed up by a minute of one of khorben's rants against libgsmd, we'll switch to Freesmartphone.Org for rev6.
We will also switch from xserver-xglamo to xserver-xorg for the sake of more responsive graphics.
On the developer side, we will of course continue to improve the packaging system and lower the entry barrier.

All in all, more reliable GSM & suspend, and almost all the features one may need. Stay tuned!



The hackable:1 team

by David Wagner at December 22, 2009 01:27 PM

December 14, 2009

Gerard Braad

Migrating from VMware to KVM

A lot of reports on the internet talk about the reduction of costs when you invest in virtualization. This is something I will certainly not deny after many years of experience with VMware Workstation, VMware Fusion, VMware GSX (now VMware Server) and VMware ESX and having implemented several high-availability setups using ESX. Even at home I had several whitebox servers with Virtual Center... until I migrated away to KVM. In this article I will explain the reason of the migration and how to perform it with an example. It is written towards people who currently run VMware GSX or VMware Server on Linux.

Motivation
It is undeniable that virtualization provide you with a lot of benefits; consolidation of servers will save you money. Maintaining your virtualized servers becomes a breeze, since they are all accessible from a single front-end. But implementing your environment on VMware comes at a price... even for the free version VMware Server; maintenance. You will still need to monitor your virtualization servers for performance and distribute your virtual machines among your servers or resource pools according to load. Although there are tools available to assist you, it is not the biggest issue.

VMware Server requires an additional operating system like Linux (or Windows). This introduces an added maintenance dependency; kernel modules which VMware uses need to be recompiled when the kernel gets updated. If a security exploit is found in the kernel, the virtualization host can be compromised and therefore jeopardize the continuity of your business. To prevent this, you update the kernel, but on reboot you notice that VMware does not start properly. On the command line you will need to perform a vmware-config.pl which build the modules. Unfortunately, your kernel headers are newer and either vmmon (virtual machine monitor) or vmnet (network component) does not build properly. Because of this, your whole infrastructure is offline until VMware provides new components or the release of the community patch package 'vmware-any-any'.

Users of VMware ESX will not have this issue, since the operating system and modules are provided in the form of the VMware's vmkernel. If a security update is needed, you only need to install an update. The previously mentioned issue  has happened to me often enough and I I wanted to have the same solution as ESX, but with the convenience of using Un*x/Linux experience for maintenance without the dependency of a third-party product. Since RHEL 5.4 this is provided as an enterprise supported solution; KVM, the Kernel-based Virtual Machine, once developed by Qumranet and now owned by RedHat. And by using CentOS this is available to everyone without too much trouble.

There are some differences between VMware and KVM. KVM is provided as part of the kernel, so any Linux distribution can provide it as part of their offering. KVM supports different formats for a virtual hard disk, while VMware only uses their own VMDK format. VMware can run in a full virtualized mode and is therefore suitable for older hardware. KVM needs a processor that provides VT-x (Intel) or AMD-V (AMD) to operate. VMware can run x86_64 guests on a i686 host, while KVM can not.

Because of this last reason, I had to reinstall CentOS on one of my systems, since it still ran an i686 version of CentOS 5.4 (on a Core2Duo E6600). This provides a good overview of what needs to be done to run KVM on CentOS.

Note: since KVM uses qemu to emulate any hardware you can also choose to use qemu without KVM as the hypervisor, but instead use the kqemu kernel module.

Installation

You will need to download an installation disc of CentOS 5.4. Prefer to use the x86_64 version; CentOS-5.4-x86_64-bin-DVD.iso. During the installation you can keep the default settings and when asked for the 'additional tasks' you will perform, do not select the 'Virtualization' option. After the installation finished, you will need to update the system to the latest updates.

From the reinstall I noticed a minor error in the CentOS 5.4 x86_64 installation. Due to installing openssl.i686 it also installed a lot of other standard i386-arch libraries. You can find out if you also have those packages installed as described in a earlier post. If you also want to remove those packages, perform the following command line option before continuing.

$ rpm -e `rpm -qa --qf '%{name}.%{ARCH}\n' |grep i386` openssl.i686

To update your system:

$ yum update

If your system is up-to-date, continue to install the needed packages for KVM and Virt-Manager.

$ yum install bridge-utils kvm kvm-qemu virt-manager virt-viewer python-virtinst

In later versions of CentOS it might suffice to issue the command "yum groupinstall 'Virtualization'", but currently this installs a Xen enabled kernel. According to the used processor, you can test to load the needed kernel module and start the libvirt daemon.

$ modprobe kvm
$ modprobe kvm-intel (or kvm-amd)
$ service libvirtd start

I normally use a different management workstation. And as an example I use a Fedora 12 installation to connect to the virtualization host (beibei). First from a tunneled connection to the host (with X11 forwarding).

$ ssh -X root@beibei
root@beibei's password: **************
# virt-manager


This will start the Virtual Machine Manager from which you can create new instances. You can of course use a Gnome desktop from the CentOS system to manage your virtual machines, but it pays off to try a seperate management workstation. This will allow you to try additional features, like live migrations between KVM virtualization servers.

This is all it needs to install KVM on a CentOS 5.4 installation. For an earlier version of CentOS, it is best to consult the wiki article about KVM.

Network settings
A default VMware Server installation will bridge the network card you have. You will probably want to have the same configuration for your KVM environment. For this you need standard Linux bridging utilities.

$ yum install bridge-utils

You only need to edit (or create) some network-scripts to make a bridge work.

$ vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
HWADDR=00:1a:2b:3c:4d:5e
ONBOOT=yes
BRIDGE=br0


And create the bridge

$ vi /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge


When you start the network again, you will have a br0 and eth0 device.

$ service network restart

You will now be able to select a bridged network card inside the KVM virtual machine configuration. If you have more network card, create a bridge per network card.

Converting the virtual disk files
For the migration part I choose a virtual machine who once began it's life as a physical machine; forum.survion.net. It is a Linux installation once based on FC3, got migrated to CentOS... and then ran as a VMware virtual machine.

The VMware virtual machine consists of one or more hard disk files, with the extension .vmdk and a description file, with the extension .vmx. A listing of server-forum.vmwarevm looks like:

[root@beibei server-forum.vmwarevm]# ls -al
total 29405144
drwxr-xr-x 2 root users 4096 Dec 12 20:53 .
drwxr-xr-x 21 root root 4096 Dec 9 17:32 ..
-rwxr-xr-x 1 root vmware 8684 Dec 7 21:09 nvram
-rw------- 1 root vmware 0 Jan 3 2009 Red Hat Linux.vmsd
-rwxr-xr-x 1 root vmware 2369 Dec 7 21:09 Red Hat Linux.vmx
-rw-r--r-- 1 root vmware 268 Jan 3 2009 Red Hat Linux.vmxf
-rw-r--r-- 1 root vmware 2147221504 Dec 7 22:22 storage-f001.vmdk
-rw-r--r-- 1 root vmware 2147221504 Dec 7 22:20 storage-f002.vmdk
-rw-r--r-- 1 root vmware 2147221504 Dec 7 22:21 storage-f003.vmdk
-rw-r--r-- 1 root vmware 2147221504 Dec 7 22:20 storage-f004.vmdk
-rw-r--r-- 1 root vmware 2147221504 Dec 7 22:22 storage-f005.vmdk
-rw-r--r-- 1 root vmware 2147221504 Aug 30 14:45 storage-f006.vmdk
-rw-r--r-- 1 root vmware 2147221504 Dec 7 22:22 storage-f007.vmdk
-rw-r--r-- 1 root vmware 2147221504 Oct 25 19:18 storage-f008.vmdk
-rw-r--r-- 1 root vmware 2147221504 Nov 30 04:05 storage-f009.vmdk
-rw-r--r-- 1 root vmware 2147221504 Nov 30 04:04 storage-f010.vmdk
-rw-r--r-- 1 root vmware 2621440 Jul 23 2008 storage-f011.vmdk
-rw-r--r-- 1 root vmware 749 Dec 7 21:11 storage.vmdk
-rw-r--r-- 1 root vmware 2147221504 Dec 7 22:22 system-f001.vmdk
-rw-r--r-- 1 root vmware 2147221504 Dec 7 22:22 system-f002.vmdk
-rw-r--r-- 1 root vmware 2147221504 Dec 7 22:22 system-f003.vmdk
-rw-r--r-- 1 root vmware 2147221504 Dec 7 22:22 system-f004.vmdk
-rw-r--r-- 1 root vmware 17659904 Jul 23 2008 system-f005.vmdk
-rw-r--r-- 1 root vmware 616 Dec 7 21:11 system.vmdk

As you can see, there are two hard disks (system and storage) and several other files. The hard disk as shown here is a fully allocated file which is divided up in seperate 2Gb files (handy for use on a FAT32 filesystem for portability). We have to convert it back into a monolithic file for use on KVM. Luckily KVM understands the monolithic VMDK file format, so we will choose this for interoperability. To convert the file you can use a VMware provided tool called vmware-vdiskmanager (includes with VMware products).

$ vmware-vdiskmanager -r system.vmdk -t 0 forum-system.img
$ vmware-vdiskmanager -r storage.vmdk -t 0 forum-storage.img


After this you will have two files that need to be copied to the in the images folder of libvirt on the virtualization host (/var/lib/libvirt/images/). You can do this using scp, ftp or mount an NFS export. From here we can create a virtual machine to connect these disk files to. Connect to the virtualization host and start the Virtual Machine Manager.

Create the Virtual Machine
Select localhost and create a new virtual machine using the context menu. Give it a unique name that identifies it easily for you, as I did: server-forum. If KVM is installed properly, you can only select "Full virtualized' from the Virtualization Method. Select the CPU architecture that fits your former VMware virtual machine and as the hypervisor: kvm.



On the 'Installation Method' page choose 'Network boot (PXE)' so you don't have to select a installation disk image.



On the 'Storage' page you deselect the 'Allocate entire virtual disk now' since we will not use the create virtual hard disk image. Beware; don't let the size become 0, since this way libvirt will not create the disk file and will fail to create the virtual machine.



On the 'Network' page you will probably want to select the bridged network card. This gives you the same functionality as VMware did as default option. On the 'Memory and CPU Allocation page' you can adjust the settings which are most close to your former virtual machine. After the summary the virtual machine will start automatically. Immediately issue a 'Force Off' as Shut down option. Now select the 'Hardware' tab.



Remove the 'Disk hda' and add new hardware of the type 'Storage' and select the system file from the storage location. If you have selected the file, you will see the correct size. Do the same of the other disks you have.



Be sure to change the boot device in the Boot options of this VM. Else it will try to start using Network (PXE) instead of the virtual hard disk.

Now everything should be ok to start the virtual machine.

Issues you might encounter
The conversion will probably not be without problems. For instance, I had a common issue with the kernel of the virtual machine. Due to a kernel panic it did not start properly. Fortunately tools are available to perform actions of the virtual hard disk files. One of those tools is guestfish. On CentOS and Fedora you can install this tool using:

$ yum install guestfish

For instance, I had to download a newer kernel and try to install this inside the virtual machine. The following commands show what I did:

$ guestfish
fs# add /var/lib/libvirt/images/forum-system.img
fs# run
Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory
fs# mount /dev/sda2 /
fs# mount /dev/sda1 /boot
fs# upload /tmp/downloaded.rpm /tmp/kernel.rpm
fs# command "rpm -ivh /tmp/kernel.rpm"
fs# vi /boot/grub/grub.conf


These commands will add the forum-system.img to a qemu instance. Inside the qemu instance you will then mount the mountpoints, upload the kernel RPM from the local path to the tmp inside the filesystem. From here nothing special... and then it will issue a command inside qemu to install the kernel package. This command will run inside the filesystem as if it performed the command from the commandline. Finally I verify the grub configuration and change it if necessary. From here I was able to start the virtual machine without any errors.

Note: If you convert Windows virtual machines you might encounter more issues. Those conversion steps are outside the scope of this document, but are not impossible to perform.

Fedora 12
The latest release of Fedora includes many improvements which are virtualization related. If you want to try KVM on a workstation, you should definitely try Fedora 12.

Below here you can see virt-manager. The interface has changed a little. As you can see from the screenshot, it is connected to the local machine and two remote hosts. The console is shown from the remote host (using ssh and vnc). For this no additional configuration was needed.



It is easy to monitor the performance of a virtual machine using the Virtual Machine Manager. Here you can see the server-forum instance with an overview of CPU/Memory usage and Disk/Network activity.



Just a few days ago SPICE was released. This is an alternative to vnc to view the console of a virtual machine. It is target towards the use of a Virtual Desktop. More information about this can be found on the SPICE website. A how-to for Fedora 12 is available.

by gbraad (noreply@blogger.com) at December 14, 2009 07:14 PM

December 05, 2009

Zedstar

Scripting with Guile on Openmoko

Having Guile running on an embedded device is very powerful. You can add scripting capabilities to a C program and avoid some of the cross compilation -> deploy cycles by simply editing the script to change some functionality. As an example I have taken the code from the excellent introductory article Scripting with Guile. I packaged the code so that if you install the tarball or the ipk it will install both the binary and script to a suitable place.

Tarball: http://zedstar.org/tarballs/square-0.1.tar.gz

ipk: http://zedstar.org/ipk/square_0.1-r0_armv4t.ipk

After installing Guile do:

root@om-gta02 ~/ipks $ opkg install square_0.1-r0_armv4t.ipk
Installing square (0.1-r0) to root...
Configuring square
root@om-gta02 ~/ipks $ square
result of square is 49
result of square2 is 81

by john at December 05, 2009 01:44 PM

November 23, 2009

Gerard Braad

Maemo 5 SDK on Fedora 12

It is possible to install the Maemo 5 SDK (final) on Fedora 12. It only takes two minor edits to the installer script. You first need to make sure you have installed Xephyr. You can do so with the command:

$ yum install Xephyr

since the installer is not able to do so for other distributions than Ubuntu and debian. You can download the GUI installer script from Forum Nokia: Maemo 5 SDK.

In the file maemo-sdk-install-wizard_5.0.py you can change line 129 to

SB_PATH="/opt/scratchbox"

It is just optional. But to me this location feels more appropriate then '/scratchbox'. On my system it is linked to another location with other hardware and software development tools.

The current version of the script seems to fail on Fedora because of not being able to install scratchbox due to a missing path.

Change line 2311 to:
exec_cmd(sb_installer_fn + opt + "-s " + SB_PATH)

Change line 2351 to:
cmd = "%s -d -m %s -s %s" % (sdk_installer_fn, self.__sdk_inst_m_opt_arg, SB_PATH)

This includes the Scratchbox path during the command invocation. You can then install the SDK by running the script. It will handle the download of PyQT and sip itself.



After the install you can start Xephyr. However you can not use the -kb option:

$ Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac &

The first start of af-sb-init.sh failed for me with a coredump and several segmentation faults. try to close the scratchbox environment and try again.



Note: I haven't tried it with SELinux as enforcing since I currently run my workstation as permissive. Discussion is possible on the Maemo developer's forum posting.

by gbraad (noreply@blogger.com) at November 23, 2009 12:41 AM

November 22, 2009

Gerard Braad

Using Mono 2.4 on coLinux to ease .NET development

Currently I deal a lot with .NET development in my daily work. Most of the development is done on Windows. When you need to develop cross-platform .NET you would like to use Mono. Mono is binary compatible with .NET and allows .NET applications to run on Linux distributions. If you would develop from Visual Studio you want to easily test the binary directly in a mono session on Linux!

To test software both platforms in a convenient way mostly virtualization is chosen. Of course you can use VMware or VirtualBox when you use Windows, but you can also use coLinux. coLinux is a port of the Linux kernel that allows it to run cooperatively alongside another operating system on a single machine. My choice of distribution to use on top of coLinux is the open version of SUSE, both supported by Novell.

This description does expect you to have understanding of a Linux environment and administrative rights on your Windows system.

Installation (Windows side)
First of all you would need to coLinux installer. This file is available from the coLinux website. The downloads section will point you to the latest stable, as of writing v0.7.3. On the website of Henry Nestler you can also find development and daily builds for 0.8.0. This installation is pretty straightforward, just keep the default settings. When the installer asks you 'Hardware installation' you need to press 'Continue anyways', this will allow the TAP network driver to be installed.

To use a desktop environment from coLinux you need to install a X server. The more difficult way would be to use Cygwin/X... this way you will have a complete GNU system running on top of Windows to provide a Linux-like experience. The fastest and easy way is to use a tool like Xming. The installer you need is the Xming or Xming-portablePuTTY (Mesa is not needed). Also, this installation is quite straightforward. After the installation start the X server from the start menu (Programs → Xming → Xming).

In the posting 'openSUSE 11.1 on coLinux' I described a way to make a base installation of openSUSE for use with the coLinux environment. The file 'colinux-opensuse-111.exe' (113Mb) [VIPeers] [dropbox] contains all you need to run the openSUSE environment. As you can see from the size, it contains only a base system. After you have extracted the file, you will still need to perform some additional installations to make the Mono development work.

Before you start the Mono installation inside the coLinux environment, you need to reserve a directory for your development files or some other shared directory. I choose to use 'D:\Development'. In the run.txt file in the openSUSE directory, you can add a line which says:

cofs1="D:\Development"

This will later be mounted inside the Linux environment.

Installation (Linux side)
Now you can start the environment from the 'runonce.bat'. This one time start is needed to finalize the installation (describe in the 'openSUSE on coLinux' posting as the post-install). You will see something similar to:

openSUSE 11.1 started on coLinux 0.7.3

Logon using the credentials: 'root' and the password 'password'. Immediately change the password using


passwd


Enable the network using the command:


for i in 0 1
do
cat > /etc/sysconfig/network/ifcfg-eth$i << END BOOTPROTO='dhcp' STARTMODE='auto' USERCONTROL='no' END done


Add a mount point to your shared directory


mkdir /media/Development
vi /etc/fstab


and add the following line to this file


cofs1 /media/Development cofs defaults 0 0



To enable the shared directory you need to mount it


mount /media/Development



You can now shutdown...


shutdown -hn now



... the system will halt and closes the console. From now on you are able to start the environment using the normal 'run.bat'. Do so and log on using your new password.

Your network should now use eth0 as a serial line and eth1 as a bridged network using the device called 'Local Area Connection'. If your Windows network device is called differently, please change it in the 'run.txt' file. IP addresses are assigned using DHCP. The device eth0 will probably be assigned the address 10.0.2.15/24. For device eth1 this will depend on your local network settings. I will just assume that eth1 is configured and provides the Internet connection.

To allow packages to be installed you would need to add the standard repositories to this installation.


zypper ar http://download.opensuse.org/distribution/11.1/repo/oss/ openSUSE111
zypper ar http://download.opensuse.org/distribution/11.1/repo/non-oss/ openSUSE111_NonOSS
zypper ar http://download.opensuse.org/update/11.1/ openSUSE-11.1-Updates



Enabling the User Interface
You can use a full-blown desktop environment as GNOME, but since coLinux does not provide a framebuffer device it is not advisable at the moment. We will use the Xming as the X server for our desktop. The X protocol is a client/server model for user interfaces. To keep the installation small, we use a very lightweight Desktop Environment on top of X, namely LXDE.

Install the LXDE packages using:


OCICLI http://download.opensuse.org/repositories/home:/swyear/openSUSE_11.1/LXDE-desktop.ymp


This will start the One-Click-Install. You will need to agree to some questions and lean back... this might take some time.

If this finished, you can test if the installation finished correctly. You will need to set the DISPLAY parameter to specify where the X server is running. Now let's start the appearance settings...


export DISPLAY=10.0.2.2:0.0
lxappearance


and choose a theme that suits your current Windows theme.

LX Appearance

This means your desktop environment works.

If you would receive a 'Gtk-WARNING **: cannot open display:' this means your connection might be blocked for some reason. Check your settings or disable a firewall/virus scanner.

Mono installation
Mono will provide a Linux/Unix system with support to run .NET applications. Originally this description was written to use Mono 2.2 which was provided from the openSUSE repository. To install these packages issue a simple


zypper in -t pattern devel_mono


would be sufficient to install a development environment. To start the Monodevelop you can start this using the command:


export DISPLAY=10.0.2.2:0.0
monodevelop &



Monodevelop

Since the 30th of March a newer release of Mono (v2.4) is available. To install you will need to specify the mono repository and upgrade the previous installation.


zypper addrepo http://ftp.novell.com/pub/mono/download-stable/openSUSE_11.1 mono-stable
zypper refresh --repo mono-stable
zypper dist-upgrade --repo mono-stable



You can now start Monodevelop 2.0 and use managed debugging!

That's it for now... In later posts I will automate the startup and show how to do development using this environment.
Have a lot of fun...

Notes
If you think VMware provides a better solution you can make use of the files that the Mono Project provide in their download section. Either download the generated VMware image of the LiveCD.

If you want to use GNOME as your desktop environment you are advised to remove the gnome-screensaver package and it's dependent, since it can cause issues during use. If you want to experiment with the LXDE environment, you are advised to use the lxpanel and pcmanfm. In a later post these will be explained in more detail.

by gbraad (noreply@blogger.com) at November 22, 2009 12:30 AM

November 18, 2009

Gerard Braad

聚集:Fedora 12 正式发布 from LinuxTOY

以技术创新驰名的 Fedora Project 今日发布了代号 Constantine 的 Fedora 12 ,口号 Unite,取意“聚集开源软件智慧”。

新特性
  • 性能优化:在 32 位平台上全部软件包针对 i686 架构重新编译,并对 Intel Atom 处理器进行性能调优。
  • NetworkManager :改善了对于宽带、蓝牙和 IPv6 的连接配置过程。配合 PolicyKit ,网络配置只需要点击鼠标即可轻松完成。
  • 下一代 Theora 编码支持:Fedora 12 集成了最新的开源视频编解码器 Theora 1.1 版本(详情见本站此文)。
  • 更好的显卡支持:针对 Nvidia Nouveau 驱动和 AMD R600/700 系列的 KMS 支持,同时为 Intel 显卡引入 DisplayPort 支持。
  • 虚拟化支持:改善了 KVM 性能,并提供虚拟机磁盘镜像监控工具 guestfish。
  • 自动臭虫汇报系统和 SELinux:新的崩溃收集程序 abrt 只需要点击几下鼠标即可将遇到的软件或 SELinux 提交至 Bugzilla,方便开发者修复。
  • 新的 Dracut initrd 启动系统:并行、以事件为单位的 Dracut 系统进一步加快启动速度。
  • PackageKit 插件:当用户尝试运行一个包含在尚未安装的软件包中的命令时,PackageKit 可以自动提示安装相应软件包。
  • 按需蓝牙服务:蓝牙服务会根据需要自动启动和停止。
  • Moblin 桌面环境:增加了 Moblin 桌面环境软件包组以及Fedora Moblin Spin 。
  • PulseAudio :增添了 UPnP 和 DLNA 支持,可以直接将音频流发送至 PS3 等设备。同时改善了热拔插和蓝牙设备支持。
  • 更加安全:降低了部分系统文件和进程的运行访问权限,避免使用 root 权限访问。同时为 SELinux 增添了沙箱支持。
  • Broadcom 固件:默认包含了 Open Broadcom 固件,对部分 Broadcom 无线网卡提供 out-of-the-box 支持。
  • 混合 Live 镜像:现在只需要使用 dd 即可创建光盘或者 USB Live 镜像,不过还是推荐使用 Livecd-tools 以获得诸如保留空间等功能。
  • 更好的摄像头支持:改善了部分摄像头的成象质量,尤其是很多廉价摄像头。
  • GNOME 2.28:使用 Gnote 替代了 Tomboy 成为默认便签,用 Empathy 替代了 Pidgin 成为默认即时通讯客户端。
  • GNOME-shell 预览:尽管 GNOME 3.0 延期了,但是依然可以在 Fedora 12 中提前体验下 GNOME Shell 的。
  • KDE 4.3:升级版的 Air 主题,可配置的快捷键支持,新的窗口管理器特效以及更好的红外线遥控支持。
  • 开发者:Eclipse Galileo, Perl 6, PHP 5.3, Netbeans 6.7.1
  • 管理员:GFS2 集群 Samba 管理
  • X.org 1.7.1:包含支持多指点设备支持的 XI2。

英文原文及详细贡献者
官方镜像下载
完整功能列表

Thanks 黑日白月, Orginal article

by gbraad (noreply@blogger.com) at November 18, 2009 12:17 AM

November 07, 2009

Gerard Braad

Get to know a Fedora Ambassador or User

Name: Gerard Braad
IRC-Nick: gbraad
IRC-Channels: #fedora-ambassadors, #maemo, #beijinglug on freenode (seldom)
Location: Apeldoorn, NL / Beijing, CHN
Fedora Ambassador: Netherlands
FAS username: gbraad

Gerard Braad

by gbraad (noreply@blogger.com) at November 07, 2009 04:14 PM

October 30, 2009

Zhou Yajin, vm-kernel.org

performance of loongson 2f

Some friends ask me about the performance of loongson2f. They want to know whether the performance of loongson 2f can surpass Marvell Sheeva CPU. Well I can not just say it's better or worse without giving the benchmark data.
Since there is a benchmark result of Marvell Sheeva CPU, we can run the same benchmark program on loongson 2f. The benchmark program is nbench.
Machine: gdium
OS: Debian squeeze
Kernel: Linux

1. gcc-4.3.4
CFLAGS = -s -static -Wall -O3

TEST Iterations/sec. Old Index New Index
    Pentium 90* AMD K6/233*
NUMERIC SORT 358.24. 9.19 3.02
STRING SORT 33.041 14.76 2.29
BITFIELD 5.5164e+07 9.46 1.98
FP EMULATION 47.402 22.75 5.25
FOURIER 4721.1 5.37 3.02
ASSIGNMENT 7.0534 26.84 6.96
IDEA 1597.4 24.43 7.25
HUFFMAN 575.17 15.95 5.09
NEURAL NET 4.2065 6.76 2.84
LU DECOMPOSITION 107.28 5.56 4.01

==========ORIGINAL BYTEMARK RESULTS========
INTEGER INDEX : 16.297
FLOATING-POINT INDEX: 5.864
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==========LINUX DATA BELOW============
CPU                 :
L2 Cache            :
OS                  : Linux 2.6.24-gdium-1
C compiler          : gcc version 4.3.4 (Debian 4.3.4-5)
libc                : libc-2.9.so
MEMORY INDEX        : 3.156
INTEGER INDEX       : 4.918
FLOATING-POINT INDEX: 3.252
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

2. gcc-4.4
CFLAGS = -s -static -Wall -O3 -fomit-frame-pointer -funroll-loops
CFLAGS += -march=loongson2f  -mtune=loongson2f  -mabi=n32

TEST Iterations/sec. Old Index New Index
    Pentium 90* AMD K6/233*
NUMERIC SORT 366.08 9.39 3.08
STRING SORT 46.686 20.86 3.23
BITFIELD 4.764e+07 8.17 1.71
FP EMULATION 90.2 43.28 9.99
FOURIER 5171.9 5.88 3.30
ASSIGNMENT 11.094 42.21 10.95
IDEA 1726.9 26.41 7.84
HUFFMAN 605 16.78 5.36
NEURAL NET 9.761 15.68 6.60
LU DECOMPOSITION 215.64 11.17 8.07

==========ORIGINAL BYTEMARK RESULTS========
INTEGER INDEX       : 20.035
FLOATING-POINT INDEX: 10.100
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==========LINUX DATA BELOW============
CPU                 :
L2 Cache            :
OS                  : Linux 2.6.24-gdium-1
C compiler          : gcc-4.4
libc                : libc-2.9.so
MEMORY INDEX        : 3.922
INTEGER INDEX       : 5.997
FLOATING-POINT INDEX: 5.602
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

by yajin at October 30, 2009 09:11 AM

Gerard Braad

Nokia N900; the geek-device!

Phones should be open to anything
During the Maemo Summit 2009 I was given a Nokia N900 for evaluation and development. For about three weeks now I have been able to use the device and got used to it in such a way that I seldom check the internet on my notebook or desktop. Here you will find my thoughts on using this 'pre-production' model.


Services I often use, like Identi.ca and Twitter, are consolidated using my Google Mail account. Normally I would quickly browse the web to check my mail and check the messages I received while I was offline. During a working day, I tended to use my other Nokia phone for tethering to my N810. This way I was mostly always online (Bluetooth sometimes wouldn't re-establish until a power down of both devices)... I was able to receive VoIP calls (SIP) on both my phone and internet tablet. Most of the time I would still use my notebook to have a full web experience or respond to my emails... and for calendar-keeping? I gave up on that... Symbian's calendar isn't comparable to the Palm calendar (or Agendus!). I have tried to use the N810 as a PDA, but the GPE tools didn't work well for me... I missed a good synchronization and integration: then came the N900.

Near desktop experience
The N900 is very powerful! That needs to be said. It is powered by a Texas Instruments OMAP3430. This processor is comparable to the BeagleBoards OMAP3530. The ARM Cortex-A8 core runs at 600Mhz and has the same PowerVR SGX 530 GPU. Only the DSP core is a little slower with 430MHz (TMS320C64x). The device gives a feeling of having more than enough power. When you start a game, like Bounce, you can still see it being active in the task-switching overview; true multi-tasking.

The OMAP-series processor can provide a full desktop experience, like the BeagleBoard can do with for instance Fedora and Ubuntu. However, this is also where the N900 falls a little short. Instead of providing a mini-HDMI connector it only has a composite out. After some tweaks in the OS you can connect a Bluetooth keyboard and mouse... and using the correct cables even USB. But you can't connect a larger screen... this way it is not a convergence device which could replace a desktop computer. Compare this to the the Creative Zii which I have for development; it provides HDMI-out and can playback a HD video in 1080p (but it can't do the desktop experience at the moment). The composite image quality is in my opinion too blurry. For games it works well, but viewing photos or a video felt a little disappointing.

Battery time and use
Lately I have seen a lot of news about the Motorola Droid. This device is also powered by the OMAP3430 and would be thinner than a iPhone 3GS. I am curious to see how they deal with battery time... since that battery must be small! The N900 is quite large and the capacity of the BL-5J battery is less than the one in the N810. The battery is empty after half a day of extensive use; GPS always on, always online (using 3G or lower depending on the location in NL, WLAN at home), FM transmitter on when I go to work (and back home) while playing music of course.

Luckily you can charge the device using the MicroUSB connector and at work I always have to do so. During this 'extensive' use I seldom made a phonecall! For me the N900 is primarily a mobile computer and a phone second. The GSM functionality provides me with the cellular data service I was missing the N810. Most of my phonecalls were done using VoIP (over 3G) and were short. I did notice the device became VERY HOT during a VoIP (over WLAN) of about 30 minutes.

Internet
If you want the full Internet in a device, the N900 is what you want. It has a Firefox browser which loads pages fast and plays Flash videos from YouTube without any hiccup. Photos you take with the camera can be immediately uploaded to remote services, like Flickr and Ovi. GPS information can be set as a status message for your IM. Maemo uses the telepahy framework for messaging and video/voice calls. Out-of-the-box it provides support for SIP, Jabber/XMPP (and Google Talk, Ovi), Skype and GSM (Voice calls, SMS). What I really like is the way conversations are kept or started. Last messages are all easily viewed from the Conversations application.

All contacts are aggregated from the IM accounts I use. This immediately fills the gap of not having a phonebook service for my SIP accounts. Contacts from different sources can be merged into a single contact entry. If you want to call a contact from the phone application you can easily see if he is online using Google Talk or Skype and even initiate such a call.

You can send a message from either the contacts or conversations (or even desktop shortcut) and it will open a separate window in which you can see the chat. I haven't felt the need to install Pidgin, unlike what I did for the N810. By installing the telepathy-extras package you can also integrate MSN, Yahoo, ICQ, IRC and more.

Closing thoughts
Maemo 5 includes a simple calendar which for the moment works quite well for me. Although you can not sync it to a remote service, it works very intuitive. Notes, calendar entries and your contacts can be synchronized using the Nokia PC Suite or SyncML compatible client.

The camera in the device is 5 mega-pixels and can really make very good quality photos. Just take a look at the Photojourney with N900 from tigert.

As a game device the N900 could be a very good competition against the iPhone. It easily plays games like Quake3. Just connect it to the TV and play using the keyboard and the accelerometer! It is almost like having an embedded Wiimote. While the N810 still had a D-pad, this was dropped on the N900. The cursor keys feel more natural for typing emails... but for gaming it feels like you miss some control. Also the screen does not allow multitouch... so no on-screen joysticks for now.

Although the device has a complete open development model it currently lacks commercial support of big game companies. I have to admit, this is still where the iPod Touch and iPhone excels... it has a lot of available games. This will be addressed in the next release of Maemo (codenamed Harmattan). It allows a security model which will probably attract a lot more commercial development.

Last week Nokia postponed the release of the N900 to allow more feedback from developers and evaluators. It also gives developers more opportunity to get familiar to the N900. As an example, most applications were installed in the / (root) filesystem, while large datafiles should have been installed to the user directory (/home/user). I had suffered from an almost complete device lock-up due to system memory being full. This should not happen to a none experienced (Linux) users. So I really think Nokia does a good thing here... They really want to give new users of Maemo a good experience.

So if you are searching for a game console rather buy a PSP Go or even iPhone. But if you bought a Macbook with the idea of having Un*x under the hood (and a terminal) you should buy a N900. Even the Android falls short in this area. If you want a phone with mobile computer ambitions (being powerful and useful) buy a N97.

For me the iPhone is a good sheep-phone, while the N900 is the real geek-phone (/device)!


Take note, I have been using a 'pre-production' model. The full production model will likely provided a much better experience.

by gbraad (noreply@blogger.com) at October 30, 2009 01:31 AM

October 25, 2009

Gerard Braad

FreeSWITCH packages for CentOS 5.3

Recently I built and packaged the 1.0.4 release of FreeSWITCH for CentOS 5.3 as i386 and x86_64. They are hosted on a temporary location http://files.spotsnel.net/freeswitch/. Eventually they will move to a repository for use with yum.

by gbraad (noreply@blogger.com) at October 25, 2009 08:48 PM

October 22, 2009

Ignacio Garcia, dingux.com

New system/toolchain

Quick post. I just uploaded the latest system files and toolchain.

Changes are:
  • Compiled for MIPS32. Previous toolchain release was wrongly compiled again for MIPS I.
  • The whole system (libraries and executables) have been compiled with -O3.
  • Fixed MP3/OGG integer decoding in SDL_mixer.
Now for something completely different: if you are having trouble getting dingux up and running, try the following as suggested by some users:
  • If you can't get the dual-boot installer to start, that is, you see nothing on the A320 screen after successfully running the two usbtool commands, try to unplug then the USB cable. No idea at all what's the problem and how unplugging the cable fixes it, though (I would need such an A320 and attach a serial console).
  • If, after installing the dual-boot, you cannot get dingux running, try to do a complete FAT32 format of your card (with ot without partition, dingux now supports both), and then copy zImage and rootfs before anything else. There might be some problem in u-boot-1.1.6 preventing it from reading FAT32 files in some circumstances, though I tried to fix it by backporting code from the latest u-boot.

by booboo (noreply@blogger.com) at October 22, 2009 02:03 PM

October 15, 2009

Bearstech Hackable:1

Hackable:1, rev5rc1, at last!

Dear Hackable:1 users,

We are glad to announce that, after long & thorough efforts from the development team, after a bunch of testing hours, after a long time spent on arguing whether we should include this or that feature, we made it: hackable:1 rev5rc1 (Codename: Chuck) is there!


Xbackground.pngHere is a changelog of corrected bugs and added features from rev4.

Changelog


+ End users matters
  • Most of the software stack now runs under the 'hackable1' user, for security purposes.
  • SMS proper implementation
  • The contact list bug has been found and fixed!
  • Power management improvements, suspend works (well almost each & every time, sadly we're still hunting GSM issues for that matter)!
  • An application called 'h1settings' can be used to configure phone features, (enable / disable GSM / Wireless / GPS, power management, ...)
  • We created a new theme to celebrate this new release!
  • We got a splashscreen! It features a Chuck figure to reflects the rev5 codename: Chuck
  • Boot time seems to have been improved a bit

+ Power users / developers matters
  • This RC1 and the upcoming final rev5 release are now built from the automatic build system.
  • A Linux kernel is now packaged in hackable:1, in order not to rely on fso-pkg anymore.
    • Debugging has been disabled (boot time improvement)
    • Easier kernel upgrade when using an ext2 partition to store the kernel on µSD cards
    • Separation of kernel modules in three sets: essential (comes with the kernel), common modules and "more modules"
    • You can read a bit on http://zecrazytux.net/Embedded/Hackable1/Custom_Kernel.html

Where can I find it? Where can I get it? What is the answer to the ultimate question about life, the universe, and everything?

As ever, you can download hackable:1 on http://download.hackable1.org/rev5rc1.
All the necessary information can be found on http://trac.hackable1.org as ever, that is documentation, installation instructions as well as known issues.
It's obvious that the answer to the aforementioned question is "Chuck".

Who should I thank for all that stuff?

Among the people who worked on this release, the most notorious are (alphabetically):

  • Marcus Bauer (mbauer)
  • Jérome Blondon (jbl2024)
  • Sébastien Bocahu (zecrazytux)
  • Pierre Pronchery (khorben)
  • David Wagner (Deubeuliou)

We'd also like to thank all the testers, among them most notably Bearstech employees, and regular contributors/users of hackable:1, who kept us going forward.

What should I expect next?

Due to a very good number of good reasons, which could all of them be summed up by a minute of one of khorben's rants against libgsmd, we'll switch to Freesmartphone.Org for rev6.
All in all, more reliable GSM & suspend, and almost all the features one may need. Stay tuned!



by Julien 'Ainulindalë' Cassignol at October 15, 2009 03:58 PM

Zhou Yajin, vm-kernel.org

qemu mips msub instruction emulation bug

It's really a long time since last post. Now I am working on the android mips porting project. I want to run android on the MIPS emulator.

The problem is that when I run mips-android on qemu, it hangs when executing init program in the initramfs root file-system. Then I use the remote gdb to debug the init and finds out that it it because pa_workspace is not initiated.

Function ashmem_create_region will open /dev/ashmem and return the fd if succeed. However, it returns -1 and the errno is 19 which means NO SUCH DEVICES.

fd = ashmem_create_region("system_properties", size);

The problem is who is responsible for creating /dev/ashmem?

In fact, in android it uses udev mechanism to create devices in /dev when executing function device_init. The full cold patch to create a device is as following:

device_init->coldboot->do_coldboot->write(fd, "add\n", 4)->handle_device_fd->handle_device_event->make_device

In function parse_event, it will parse the uevent msg and then pass uevent to handle_device_event. However, I find that the uevent message is a little weird. I use remote gdb to dump this message.

0x7ff3d250:     "add@/class/tty/console"
0x7ff3d267:     "ACTION=add"
0x7ff3d272:     "DEVPATH=/class/tty/console"
0x7ff3d28d:     "SUBSYSTEM=tty"
0x7ff3d29b:     "MAJOR=+"
0x7ff3d2a3:     "MINOR=/"
0x7ff3d2ab:     "SEQNUM=31+"
0x7ff3d2b6:     ""
0x7ff3d2b7:     ""
0x7ff3d2b8:     ""

You see, in the message the MAJOR is +. It will confuse the parse_event so that the corresponding device won't be created.

It looks the kernel passes wrong uevent message to user space. So the question is who has messed up the uevent message?

Then I recall that when booting linux kernel, there are some weird messages.

Primary instruction cache .kB, VIPT, 2-way, linesize 1* bytes.
Primary data cache .kB, 2-way, VIPT, no aliases, linesize 1* bytes

You see the instruction cache is .kB and linesize is 1* bytes, not a valid number at all.

Then I suspect that something is wrong in kernel when parsing the numbers. So I use the remote gdb to debug the kernel again.

r4k_cache_init->probe_pcache->printk->vprintk->vscnprintf->vsnprintf->number->put_dec->put_dec_trunc

Function put_dec_trunc uses a unsigned int between[0,99999] as input and outputs the number as a string. But I find that when the input is 2, the output is '.', not the expected '2'. So maybe this function is the bad boy.

In the following function I assume q=2.

277 static char* put_dec_trunc(char *buf, unsigned q)
278 {
279         unsigned d3, d2, d1, d0;
280         d1 = (q>>4) & 0xf;            /*d1=0*/
281         d2 = (q>>8) & 0xf;            /*d2=0*/
282         d3 = (q>>12);                 /*d3=0*/
283
284         d0 = 6*(d3 + d2 + d1) + (q & 0xf);  /*d0=2*/
285         q = (d0 * 0xcd) >> 11;              /*q=0*/
286         d0 = d0 - 10*q;                     /*d==2*/
287         *buf++ = d0 + ''; /* least significant digit */
288         d1 = q + 9*d3 + 5*d2 + d1;   /*d1=0*/
289         if (d1 != 0) {               /* it is false so we won't get into here.*/
290                 q = (d1 * 0xcd) >> 11;
291                 d1 = d1 - 10*q;
292                 *buf++ = d1 + ''; /* next digit */
293
294                 d2 = q + 2*d2;
295                 if ((d2 != 0) || (d3 != 0)) {
296                         q = (d2 * 0xd) >> 7;
297                         d2 = d2 - 10*q;
298                         *buf++ = d2 + ''; /* next digit */
299
300                         d3 = q + 4*d3;
301                         if (d3 != 0) {
302                                 q = (d3 * 0xcd) >> 11;
303                                 d3 = d3 - 10*q;
304                                 *buf++ = d3 + '';  /* next digit */
305                                 if (q != 0)
306                                         *buf++ = q + '';  /* most sign. digit */
307                         }
308                 }
309         }    
310         return buf;
311 }

/*  MIPS uses a0/a1 to pass arguments.
 *  a0= address of bu
 *  a1= q = 2
 */
8015a040 <put_dec_trunc>:
8015a040:    00051202     srl    v0,a1,0x8        /* v0= q>>8*/
8015a044:    00053102     srl    a2,a1,0x4        /* a2= q>>4*/
8015a048:    30c6000f     andi    a2,a2,0xf        /* a2= (q>>4) & 0xf = d1 in line 280*/
8015a04c:    3048000f     andi    t0,v0,0xf        /* t0 = (q>>8) & 0xf = d2 in line 281*/
8015a050:    00054b02     srl    t1,a1,0xc        /* t1= (q>>12) = d3 in line 282*/
8015a054:    00c81021     addu    v0,a2,t0        
8015a058:    00491021     addu    v0,v0,t1          /* v0 = d1+d2+d3 in line 284*/
8015a05c:    24030006     li    v1,6
8015a060:    70433802     mul    a3,v0,v1          /*a3= 6*(d3 + d2 + d1)*/
8015a064:    30a5000f     andi    a1,a1,0xf         /*a1= q & 0xf*/
8015a068:    24020009     li    v0,9               /*v0=9*/
8015a06c:    00e56021     addu    t4,a3,a1          /*t4= 6*(d3 + d2 + d1) + (q & 0xf) = d0 in line 284*/
8015a070:    240b00cd     li    t3,205            /*t3= 0xcd*/
8015a074:    71223802     mul    a3,t1,v0          /*a3= 9*d3 in line 288. Apparently gcc has reordered the code.*/   
8015a078:    718b1802     mul    v1,t4,t3          /*v1= (d0*0xcd)*/
8015a07c:    24020005     li    v0,5
8015a080:    00e62821     addu    a1,a3,a2          /*a1= 9*d3 + d1 in line 288*/
8015a084:    71023002     mul    a2,t0,v0          /*a2= 5*d2 in line 288*/
8015a088:    00031ac2     srl    v1,v1,0xb         /*v1= (d0*0xcd)>>11 in line 285*/
8015a08c:    240a000a     li    t2,10             /*t2=10*/
8015a090:    01800013     mtlo    t4                /*put t4->lo. lo=t4= 6*(d3 + d2 + d1) + (q & 0xf) = d0 in line 284 */
8015a094:    706a0004     msub    v1,t2             /*hilo = v1*t2 - hilo = 10*(q) - hilo in line 286*/
8015a098:    00c51021     addu    v0,a2,a1
8015a09c:    00002812     mflo    a1                /*lo->a1*/    
8015a0a0:    00431821     addu    v1,v0,v1
8015a0a4:    24a20030     addiu    v0,a1,48         
8015a0a8:    00803821     move    a3,a0
8015a0ac:    a0820000     sb    v0,0(a0)

We just need to see the instruction in 0x8015a094, it is a msub instruction. The defination of msub is as following:

(HI,LO) = (HI,LO) - (GRP[RS]*GPR[RT])

Then after executing the instruction in 0x8015a094, the HI/LO should be 0/2. But qemu produces the value 0xffffffff/0xfffffffe, which is -2 indeed. Maybe this is the problem.

Then I need to find how qemu emulates msub instruction.

2178     case OPC_MSUB:
2179         {
2180             TCGv r_tmp1 = tcg_temp_new(TCG_TYPE_I64);
2181             TCGv r_tmp2 = tcg_temp_new(TCG_TYPE_I64);
2182             TCGv r_tmp3 = tcg_temp_new(TCG_TYPE_I64);
2183
2184             tcg_gen_ext32s_tl(t0, t0);
2185             tcg_gen_ext32s_tl(t1, t1);
2186             tcg_gen_ext_tl_i64(r_tmp1, t0);
2187             tcg_gen_ext_tl_i64(r_tmp2, t1);
2188             tcg_gen_mul_i64(r_tmp1, r_tmp1, r_tmp2);  /*r_tmp1= gpr[rs]*gpr[rt] */
2189             gen_load_LO(t0, 0);                /*t0 <- lo*/
2190             gen_load_HI(t1, 0);                /*t1 <- hi*/
2191             tcg_gen_extu_tl_i64(r_tmp2, t0);   /*r_tmp2 = 64bit expand of lo*/
2192             tcg_gen_extu_tl_i64(r_tmp3, t1);   /*r_tmp3 = 64bit expand of hi*/
2193             tcg_gen_shli_i64(r_tmp3, r_tmp3, 32);
2194             tcg_gen_or_i64(r_tmp2, r_tmp2, r_tmp3);
2195             tcg_temp_free(r_tmp3);
2196             tcg_gen_sub_i64(r_tmp1, r_tmp1, r_tmp2); /*r_tmp1= r_tmp1 - r_tmp2 = gpr[rs]*gpr[rt] - HI/LO */
2197             tcg_temp_free(r_tmp2);
2198             tcg_gen_trunc_i64_tl(t0, r_tmp1);
2199             tcg_gen_shri_i64(r_tmp1, r_tmp1, 32);
2200             tcg_gen_trunc_i64_tl(t1, r_tmp1);
2201             tcg_temp_free(r_tmp1);
2202             tcg_gen_ext32s_tl(t0, t0);
2203             tcg_gen_ext32s_tl(t1, t1);
2204             gen_store_LO(t0, 0);
2205             gen_store_HI(t1, 0);
2206         }
2207         opn = "msub";
2208         break;

You see, qemu makes an error emulation of msub instruction. It uses gpr[rs]*gpr[rt]-HI/LO and then put the results to HI/LO, which is different from the defination of msub instruction. I patched the qemu code and it works.

BTW: MIPS32 4KTM Processor Core Family Software User’s Manual version MD00016 gives an error operation of msub instruction on papge 253.

Operation:
   temp ← (HI || LO) - (GPR[rs] * GPR[rt])
   HI ← temp63..32
   LO ← temp31..0

Maybe this misleads the qemu developers. The latest qemu version has fixed this bug. We can see this instruction emulation in qemu-svn-20091014.

2195     case OPC_MSUB:
2196         {
2197             TCGv_i64 t2 = tcg_temp_new_i64();
2198             TCGv_i64 t3 = tcg_temp_new_i64();
2199
2200             tcg_gen_ext_tl_i64(t2, t0);
2201             tcg_gen_ext_tl_i64(t3, t1);
2202             tcg_gen_mul_i64(t2, t2, t3);  /*t2=GPR[RS]*GPR[RT] */
2203             tcg_gen_concat_tl_i64(t3, cpu_LO[0], cpu_HI[0]);  /*t3= HI/LO*/
2204             tcg_gen_sub_i64(t2, t3, t2); /*t2= HI/LO - GPR[RS]*GPR[RT] */
2205             tcg_temp_free_i64(t3);
2206             tcg_gen_trunc_i64_tl(t0, t2);
2207             tcg_gen_shri_i64(t2, t2, 32);
2208             tcg_gen_trunc_i64_tl(t1, t2);
2209             tcg_temp_free_i64(t2);
2210             tcg_gen_ext32s_tl(cpu_LO[0], t0);
2211             tcg_gen_ext32s_tl(cpu_HI[0], t1);
2212         }
2213         opn = "msub";
2214         break;

See this link for more information.

So finding this bug is really not easy. I have to dig dig and dig from userland to linux kernel and then to qemu until catching this bad qemu bug. Thanks to the remote gdb and gdb stub in qemu, it makes life easier.

Following is the patch of qemu.

diff --git a/target-mips/translate.c b/target-mips/translate.c
index 3dded6c..0a1b461 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -2193,7 +2193,11 @@ static void gen_muldiv (DisasContext *ctx, uint32_t opc,
             tcg_gen_shli_i64(r_tmp3, r_tmp3, 32);
             tcg_gen_or_i64(r_tmp2, r_tmp2, r_tmp3);
             tcg_temp_free(r_tmp3);
-            tcg_gen_sub_i64(r_tmp1, r_tmp1, r_tmp2);
+            /* msub means HI/LO = HI/LO - GPR[RS]*GPR[RT],
+             * not HI/LO = GPR[RS]*GPR[RT] - HI/LO
+             */
+            //tcg_gen_sub_i64(r_tmp1, r_tmp2, r_tmp2);
+            tcg_gen_sub_i64(r_tmp1, r_tmp2, r_tmp1);
             tcg_temp_free(r_tmp2);
             tcg_gen_trunc_i64_tl(t0, r_tmp1);
             tcg_gen_shri_i64(r_tmp1, r_tmp1, 32);

by yajin at October 15, 2009 05:06 AM

October 04, 2009

Alvaro Lopes, gta02-core-news

Weekly News for October 4th

Welcome to the fourth edition of #gta02-core-news, for October 4, 2009.

Last week news

As you might have noticed, I have not posted any news entry last week. There was so little done and so few messages exchanged on the mailing list I decided to wait for another week to post.

ECN progress

Dave closed some of the pending ECN for EMI filters, SPI degugging and Telit integration. He also noticed some others are still not closed, despite their changes appear on the schematics already. Most of them only need small updates, except for the mistery caps for the GPS RF. Rene gave some ideas, but I have not had the time to properly analyse the problem. Maybe this week. Rask also updated some ECN with new test points.

Backup battery - to be or not to be ?

Rask did us some update regarding the removal of backup battery. There is no conclusion yet about this matter, so unless someone comes up with a good reason to change it, it will be kept as-is.

USP SMT line

Werner posted some more pics of the SMT line at University of São Paulo, Brasil. Very well documented, with references to the individual machines. Definitely worth a look.

Quotes of the Week


(...) I'll be quite busy carting equipment around and doing a gazillion of little administrative things. (The logistics of making phones are ridiculously easy in comparison ;-)
Werner Almesberger

I can most certainly help out with any kernel related issues, and even do some minor board modifications after the fact.
Christopher Friedt

I don't think we've had problems with undefined state on power up. If we manage to power up at all, we can (and do) load our own settings anyway.
Rask Ingemann Lambertsen

by Alvie (noreply@blogger.com) at October 04, 2009 12:23 PM

September 28, 2009

Ignacio Garcia, dingux.com

Progress on x760+ / buildroot published

First and foremost: sorry for being so hard to get in touch with lately. We've been in defcon 1 for the last week at work preparing a demo for the current project (OMAP3530 based) which is crucial to the future of the company, so I had reduced my daily routine to sleep-eat-work-sleep. My inbox is exploding.

Sweetlimre commented on having a writable home directory (see interview). If I recall correctly, I wrote about this already. The main application executed by busybox's init process is responsible for this. At this stage in the boot process no HOME environment variable has been set. I could easily modify busybox's init to set it to "/usr/local/home", but I felt it's better to stick to a vanilla busybox as much as possible. Oh, wait: maybe if (as I recommended) the main menu application is using exec() to launch emus/apps things are not so simple. Need some input from devs here, and if the only solution is to modify busybox's init, so be it.

Regarding the modified buildroot I'm using, as he requested it's now available for download at the google code project page. I hadn't published it before just because I could not find time to fix all the dirty hacks I used, which resulted in a partially manual build. I'll be glad to add anything developers suggest. Just send me the buildroot recipe. I would really like to stay away from OpenEmbedded. I have to use it for the OMAP3530 and IMHO it is way overengineered.

Some good news on the Ingenic front: the Qi-Hardware guys have managed to get Ingenic to release their kernel development trees DAILY. This means immediate access to any useful fix they make. There are 2.6.24.3 and 2.6.27 branches, and I'm working on porting the A320 support code to the later, mostly to see if it helps somehow with the USB/DMA and SD/MMC standing bugs. Note that in the case of embedded devices like the A320 I don't think that newer kernel is necessarily better.

Regarding the Gemei x760+ things are going slower than expected. I dumped the hardware initialization .DL from NAND flash and disassembled it, only to discover I was looking in the wrong place. Let me explain:

When the JZ4740 boots a piece of code called the IPL (Initial Program Loader) is executed from ROM. Depending on the state of some pins this code either enters USB boot mode or boots from NOR or NAND flash. In the A320 we can only choose to enter USB boot mode or boot from NAND. The IPL only supports 512 and 2048 page size NAND, so despite the fact that the NAND chip in the A320 has a 4096 page size it is handled by the IPL as if it was 2048.

The IPL reads the four first pages (8KB total) of NAND into the instruction cache (because the SDRAM is not yet available). This is called the SPL (secondary program loader) and its purpose is to do a basic hardware initialization, most notably making the SDRAM available, and load the system loader from NAND. The A320 SPL also handles the NAND as if it was 2048.

In the original firmware the SDL is stored in the first 8KB of the first NAND block (0x00000-0x3FFFF). It loads the system loader from 0x50000-0xBFFFF. Before loading the operating system the A320 system loader does something interesting: it loads from 0x40000-0x4FFFF a piece of code that I call the hardware initialization DL. It is a dynamic linked object code chunk that does board-specific hardware initialization: GPIO, LCD, etc. This is the interesting stuff. In both the older and newer A320 the LCD initialization code was reverse engineered from this DL.

However, the x760+ LCD initialization seems to be mostly done by the system loader itself. It stil loads the DL and uses it for some GPIO initialization that is also related to the LCD controller, but not much more. The DL does contain a large LCD register initialization code routine, but it is unused (and I lost a lot of time reverse engineering it).

Since the system loader code is much larger (~260KB) than the DL code (~10KB), it's gonna take some time to reverse engineer the LCD handling code. Note also that I had already reverse engineered the A320 DL code and that helped a lot, but the system loader is unexplored territory.

by booboo (noreply@blogger.com) at September 28, 2009 02:53 PM

September 21, 2009

Gerard Braad

Fedora 11 on coLinux (fixes)

Recently HenryN (of coLinux) made some minor changes to the Fedora 11 image for coLinux. The new image is available from the coLinux forum at SourceForge or directly from [FedoraPeople] or [MegaUpload] (70.3 MB).

Thanks!

Note: the original image has been replaced by this fixed image. If needed the original image is available upon request. However it should be considered obsolete.

by gbraad (noreply@blogger.com) at September 21, 2009 04:47 PM

Fedora 11 on coLinux

After some minor issues I managed to install Fedora 11 on coLinux. Normally I would perform a manual installation by creating a basic rpm environment, but with Fedora 11 I encountered problems during the installation; first the version of squashfs was different. This was easily fixed with a dump from Fedora 10... but second, rpm packages were all of a sudden not available halfway a rpm transaction. Since it occurred more than once, I settled for using qemu again.

The file colinux-fedora11.exe (82MB) is published on [fedorapeople], [dropbox] and [files]. It does have some minor issues during startup, but besides this it is operational. The installation was performed as a basic installation; so it does not contain any graphical environment, no additional network servers, no updates, etc. This way the download is small. The only added packages are wget, mc and my kernel modules RPM.



All you need to run it is: coLinux, winpcap and the archive. The file 'run.bat' would start the cooperative environment. Any tweaks you would like to make can be placed in the 'run.txt' file. The user is 'root' without a password. After you start it, do set a password for this user.

Personally I use the environment for Fedora Electronic Lab which coexists with Cygwin. Not all the tools I use for electronics are available on Linux... yet!

Note: I have used version 0.7.3 of coLinux because the current stable release 0.7.4 suffers from a problem with the tap device.

Note 21-09-09: The original image has been replaced by the updated image from HenryN. IF needed the original image is available upon request. It should however be considered as obsolete.

by gbraad (noreply@blogger.com) at September 21, 2009 04:46 PM

September 20, 2009

Alvaro Lopes, gta02-core-news

Weekly News for 20th September

Welcome to the third edition of #gta02-core-news, for September 20th 2009.

Progress

Some good news from USP, Brasil!. Read below for more details. Besides that project is evolving slowly. I hope we can start the layout soon.

Finances again

Werner has posted a lenghty message about the state of project finances, where he states "I'd estimate the total budget of the project that will still need covering, with pooled and individual costs at something like EUR 15'000-25'000", not counting other costs like usage of openmoko infrastructure and the components we'll be "offered".

News from Brasil - USP

Some great news for us all. Werner went to Brasil this week, to USP (University of São Paulo) and was happy to tell us that Prof. Marcelo Knoerich Zuffo of the University of Sao Paulo (USP) has offered gta02-core the use of his SMT facility. As if this wasn't generous enough, all he asks for in return are a few of our prototypes for his team to play with.. There was much rejoice, because this opens way for quicker and cheaper production of the first prototypes. He also took a pic of the SMT facility. Many many thanks to Prof. Marcelo Zuffo, and to Jon "maddog" Hall for his help (although he declines all and any responsability for it :P). There was some discussion on the same thread about PCB manufacturers, their capabilities and cost. We have quite a lot to choose from, you can read all the gory details on the mailing list archives.

Quotes of the week


It did not take a lot of convincing.
Jon "maddog" Hall

IIRC, we still have a hole where the connector for the external GPS antenna used to be.
Rask Ingemann Lambertsen

Heh, the things we do to make it into Alvaro's quotes of the week ;-)
Werner Almesberger

by Alvie (noreply@blogger.com) at September 20, 2009 08:51 AM

September 18, 2009

Ignacio Garcia, dingux.com

Testing new dual-boot installer

I've just released a new dual-boot installer in the hope that it fixes the "flash write error" problem some users have experienced. The error is caused by one or more bad pages in the first block of NAND. This is normal and there is a mechanism that was supposed so handle it but wasn't working. As I don't have bad pages in this first block in my two A320s, I can't test it myself, so, until someone reports that it is working for him, consider it beta.

UPDATE 1: so far three success reports. Yeah, looks like this bug is squashed!.

UPDATE 2: confirmed. No more flash write errors.

by booboo (noreply@blogger.com) at September 18, 2009 10:35 AM

September 13, 2009

Alvaro Lopes, gta02-core-news

Weekly News for 13th September

Welcome to the second edition of #gta02-core-news, for September 13th 2009.

About this blog

Hasn't been easy to write this on Fridays, so I've decided to do it during the weekend, when I have more spare time. Thanks for your understanding :)

Progress

Again this has been a very quiet week. Only a handfull of emails were exchanged on the mailing list, and those only cover a few aspects of the project. I guess most of us are back to work after the big holydays, meaning less time to work on #gta02-core. I expect more people to join us, now that we are moving torwards completion of the first prototypes.

Finances

There's an ongoing discussion on the mailing list about project finances and prototype cost. Werner did an initial estimation of 500-1000€ perprototype (these are prototypes so there is some amount of uncertainity about whether they will fully work, work to some extent, or just draw some smoke when we first power them on).
Getting some funding to help us making the first prototypes has been also on top of the table, but this is very time consuming and sometimes even disappointing. Nathael brought us attention to the fact some of us cannot really afford that prototype cost, but might be interested in donating some smaller amounts of money to the project, and even build some website to capture external donations. Let's see how this idea evolves on the next weeks.

The new GSM modem

As you know we dropped our old GSM modem (TI Calypso) and replaced it with a Telit one. This week Dave Ball decided to have a first stab at schematics, and raised a lengthy discussion about RF, and power issues (glitches, ON/OFF circuitry). One important aspect of the discussion is removal of external GSM antenna circuit. Addition of some more test points was also discussed, these will surely make all those hardware hackers happier for sure.

Quotes of the week


Ah, what's the trouble ? I'm good at fixing fped ;-)

Werner Almesberger, author of fped

By the responses we've had so far, I'm happy to go with the internal antenna only, which should be simple enough even for me! :-)

Dave Ball

by Alvie (noreply@blogger.com) at September 13, 2009 09:43 AM

September 09, 2009

Gerard Braad

Beijing LUG meeting (8th of September 2009)

Last night I attended a meeting of the Beijing Linux User Group. It was for me the first time I could attend it during my time in Beijing and it is certainly something I will do more often. Every 2nd Tuesday of the month they will have a group meeting in which they will have speakers about a subject. I was lucky to listen to Coly Li and Ulrich Drepper.

Ulrich Drepper at BLUGColy Li is a kernel developer who supervised a Google Summer of Code student, YuEr, who ported openSUSE to MIPS. YuEr showed what he had done, the results and the errors still left. He was able to start a X11 session using FVWM on a Gdium (MIPS-based smartbook). For this he had used a cross-platform RPM build environment targeting MIPS and qemu. Amazing results for such a short period he was able to work on it.

Ulrich Drepper gave the same talk as he did at the RedHat Summit in Chicago about 'Acceleration Through Stream Computing'. In this talk he explains how to speed up applications by using vectorization and the vector extensions as provided by SSE. Using templates and partial specialization in C++ it is possible to speed up applications without a lot of changes. The specialized critical code could be altered by experts and just a rebuild would suffice. He explains this for instance with a simple example of a vector scaling and translation... the result speaks for themselves. It was also apparent that Ulrich is not a promoter of CUDA (or even CTM) either. In my opinion they result in vendor-lockin. The alternative to look for is OpenCL...

Overall it was a nice evening. I talked to a talented bunch of 'folklore dancers' wearing T-Shirts. If you ever have the chance to be in Beijing, stop by... you will not regret it.

by gbraad (noreply@blogger.com) at September 09, 2009 05:47 AM

September 05, 2009

Alvaro Lopes, gta02-core-news

Goals and Objective

Hello all,

Although I am not a blogger, I think we need alternative ways to let community know what we are doing at #gta02-core project. So I decided to start this blog and hope it will help community to get in touch with latest news from our project.

For those who do not have a clue about what #gta02-core is about, take a look here

http://wiki.openmoko.org/wiki/Gta02-core

If you still have doubts, please drop me an email and I'll be glad to dissipate those. But there should be enough information there, like mailing list address and archives.

So I'll try to weekly post news about the project here. Very summarized, since I am not someone that speaks or writes too much.

I will try to post here every Friday.

Let the power of Open Design Hardware be with you.

Álvaro

by Alvie (noreply@blogger.com) at September 05, 2009 04:43 AM

Weekly News for 5th September

Welcome to the first edition of #gta02-core-news, for September 5th 2009.

Progress

There has been not much progress this week. Mostly discussion about shielding, debug connector FPC and audio ECN collection. One OT discussion about binary drivers was also very active. And a new schematic - wireless on-board.

Bad news from OpenMoko

Werner brought us some piece of bad news, apparently OpenMoko might not have as many parts in stock as initially thought. We'll have to wait for more information now, but this might put us on a bad position, because some parts are very hard to source.

Shields

Rask has asked a local supplier a quote for custom shields for #gta02-core. I think personally this prices are a bit high, we might have to live with our current shields if possible.

The footprint problems

Werner brought our attention to the fact that several manufacturers have different values for footprint parameters. This will require us to choose some common values ans use them, instead of using some non existent industry standard.

New on-board wlan

Your blogger finished the 1st version of the on-board WLAN module. There's an ECN pending for this module too. Some component names had to be renamed but there will exist a mapping somewhere.

SPI and debug connector

Rask found some inconsistencies in the way we use SPI on the debug connector, which might cause debug connector to interfere with WLAN.

Printed Circuit Board

There has been some discussion on board parameters, like minimum trace widths and vias. Other parameters were also discussed, like surface finishes. We're still trying to find out a good balance between our requirements and total board cost.

Quotes of the week

" At the end, i think we should consider that this will be *only* a prototype and not a usable phone, so we don't need a lot of gimmicks which are not absolutely required. "
Rene Harder

" It really helps then if you don't have to suspect every single solder joint to be a traitor to the cause ;-) "
Werner Almesberger

by Alvie (noreply@blogger.com) at September 05, 2009 04:09 AM

September 02, 2009

Methril

What i've been doing

Hello to all specially to openmokers, as this is my first post that is going to appear at planet.openmoko.org

I'm being a little bit silent lately.
The good news is that i've not been quiet :)
What i've been doing? Well, first of all i'm being too busy with a lot of tuxbrain stuff :)
I put a smile because they are giving me the opportunity to develop/hack a lot of devices and they give e the opportunity to hardware hacking, that is not an easy one :)

  1. I've been doing some buzz fixes [1] [2] [3] [4].

  2. I've been hacking some devices [5] [6].

  3. I've been hacking some OE recipes (Porting some shr recipes from import/shr to org.openembedded.dev), and putting some patches [7].

  4. I've been following new interesting companies [8].


And off course i've been having a lot of fun, a real life, a paid job and a wonderful wife that supports me ;) until one holiday week :)

I put this post because i've one specific blog with some new stuff [9] An i.MX515 [10] development platform that i'm going to start to hack.

I'm reading my mails from the last weeks (now last month), and i'm getting up to date.

.....

Stay tunned to know what i've been doing in next weeks :)

Hope to write here soon.

Greetings

--
The links
[1] http://www.openmoko-spain.org/tiki-view_blog_post.php?blogId=1&postId=10
[2] http://www.tuxbrain.com/en/content/buzz-fix-party-barcelona-movie
[3] http://www.tuxbrain.com/en/content/buzz-fix-party-madridphotos
[4] http://www.tuxbrain.com/en/content/there-and-back-againtuxbrain-debconf09-pics
[5] http://www.compulab.co.il/x270em/html/x270-em-datasheet.htm
[6] http://openinkpot.org/wiki/NetronixEB600
[7] http://article.gmane.org/gmane.comp.handhelds.openembedded/25655
[8] http://www.qi-hardware.com/
[9] http://projects.powerdeveloper.org/project/imx515/752
[10] http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX515

by Methril (noreply@blogger.com) at September 02, 2009 02:23 AM

August 25, 2009

Gerard Braad

Accidently installed i386 packages on x86_64?

If you have a CentOS installation (or Fedora) running as x86_64 architecture, be sure to install your packages with yum using the following command:

$ yum install [packagename].x86_64

This way you will specify the architecture to use. If you do not specify the architecture you might end up installing both the x86_64 and the i386 packages with all it's dependencies.

If you have already done so in error, you can easily query for these packages using the following command:

$ rpm -qa --qf '%{name}.%{ARCH}\n' |grep i386

this command returns all i386 packages. You can pipe it directly into rpm -e or choose to uninstall them by hand.

by gbraad (noreply@blogger.com) at August 25, 2009 11:16 PM

August 19, 2009

Bearstech Hackable:1

Run Ogsmd on Hackable:1

As you may know, we are willing to migrate to FSO. As part of it, we made ogsmd running on H:1 and we will rewrite phone-kit to use libfso-glib instead of libgsmd.

Until we get all the stuff packaged, here are the step to make ogsmd running on a Hackable:1 rev4 installation.

Install the framework

We will use a git version that I know working. On your computer:

git clone git://git.freesmartphone.org/framework.git
cd framework
git checkout 17898fc0f73453c11d1b1e8db57f8e8a0cfbc943 .
cd ..
scp -r framework root@192.168.0.202: # I assume that it is you FR's IP

SSH into your freerunner and:

cd framework
python setup.py install
cd ..

Install the muxer

We will use SHR packages which a copy of them is on our trac.

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/fso-abyss_0.3.5+gitr67+ff68be1581069ca494a559e85f6299246888d3b5-r0_armv4t.ipk"
ar -x fso-abyss_0.3.5+gitr67+ff68be1581069ca494a559e85f6299246888d3b5-r0_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libgsm0710mux0_0.3.5+gitr35+8e3e7533b286d8086bce8fa09bce23bb9f18bb98-r1_armv4t.ipk"
ar -x libgsm0710mux0_0.3.5+gitr35+8e3e7533b286d8086bce8fa09bce23bb9f18bb98-r1_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libgsm0710-0_1.1.1+gitr15+3bb80ba6cc9f86ed3996f88bfa2986cc572489d6-r1_armv4t.ipk"
ar -x libgsm0710-0_1.1.1+gitr15+3bb80ba6cc9f86ed3996f88bfa2986cc572489d6-r1_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libfsotransport0_0.9.3+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk"
ar -x libfsotransport0_0.9.3+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libfsobasics0_0.8.1.0+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk"
ar -x libfsobasics0_0.8.1.0+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk
tar -xvzf data.tar.gz -C /

We will use SHR frameworkd.conf:

wget "http://git.shr-project.org/git/?p=shr-themes.git;a=blob_plain;f=frameworkd/frameworkd-config-shr/om-gta02/frameworkd.conf;hb=HEAD" -O /etc/frameworkd.conf

If the following file doesn't exists, libgsm0710mux segfaults (see http://trac.freesmartphone.org/ticket/467)

cat << __EOF > /etc/abyss.conf
[omuxerd]
autoopen = 1
autoclose = 1
autoexit = 1
[session]
mode = 1
framesize = 98
port = /dev/ttySAC0
speed = 115200

[device]
wakeup_threshold = 6
wakeup_waitms = 200

__EOF

And if this one doesn't exists, fso-abyss claims it doesn't provide any channel

touch /etc/cornucopia.conf

A file may have permissions problem, first check it:

ls -l /usr/lib/dbus-1.0/dbus-daemon-launch-helper

If the group isn't messagebus:

chgrp messagebus /usr/lib/dbus-1.0/dbus-daemon-launch-helper
chmod u+s /usr/lib/dbus-1.0/dbus-daemon-launch-helper # because chgrp removes the SUID

Launch Ogsmd

Let's kill the old stuff...

killall -9 ogsmd
...and launch te framework:
frameworkd -s ogsmd
If no error (Python Traceback) occurs, we can move on:

libfso-glib sample
Install libfso-glib

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/libfso-glib/libfso-glib0_0.2.0-gitrx44+9d292508739452b55b80ec40ec57405a5de2159f-r0_armv4t.ipk"
ar -x libfso-glib0_0.2.0-gitrx44+9d292508739452b55b80ec40ec57405a5de2159f-r0_armv4t.ipk
tar -xvzf data.tar.gz -C /

Install the sample (See the sources)

wget http://trac.hackable1.org/trac/raw-attachment/wiki/libfso-glib/sample-libfso-glib_0.1-1_armel.deb
dpkg -i sample-libfso-glib_0.1-1_armel.deb
sample-w
You will be asked for your PIN (unless you are already authentified) and you will be registered.

Then, it will catch several signals. after that, you can call yourself and see the signals "CallStatus" be matched. These signals are sent whenever the status of a call (which ID is specified, i.e. "1") change. (ie "incoming" or "release"). See FSO doc for further information.

And now what ? You can already, by reading freesmartphone.h, find any interesting function you need and write nice applications.

Any question ?
If you have any question about this manipulation or about Hackable:1, feel free to ask in the comments.

You can fin updates of this tutorial on our trac

by David Wagner at August 19, 2009 09:31 PM

August 17, 2009

Bearstech Hackable:1

hackable:1 makes your device happy

As a lot of you know, at Bearstech, we're very serious with hackable:1 and what we intend to do with it.

If you were to ask to a typical hackable:1 developer, he'd probably say he crafts his code as he would paint an art piece or carve a nice wooden table. All the development is done for your GTA02 pleasure.

As can prove the following pictures, left alone, our GTA02s are not that happy. See how they seem to whine or just how they seem alone, oblivious to the fact that they're with their peers:

boite.jpg

But then, a little bit of H:1 magic, and look at how they seem to shine in happiness, all directed towards the same common objective, united to fight for their common goal:

hackable_1.jpg
There is no spoon more proof needed to say that hackable:1 will make your device happy. Up to you guys !

by Julien 'Ainulindalë' Cassignol at August 17, 2009 02:11 PM

August 13, 2009

Bearstech Hackable:1

Welcome on our new hackable:blog !

Hey everyone,

Long time no see. At last, we decided to setup a blog in order to keep you all in touch with what you need to know about hackable:1, and about the new things we do.

Stay tuned, as we're bounded to put a lot of things here sooner than later!

by Julien 'Ainulindalë' Cassignol at August 13, 2009 05:35 PM

July 15, 2009

Zhou Yajin, vm-kernel.org

qemu internal part 3: memory watchpoint

In qemu there is an amazing feature – memory watchpoint. It can watch all the memory access including memory read, write or both of them. When guest os/application touches the memory region watched by qemu, a registered function will be called and you can do everything as you want in this function. The gdb stub in qemu uses it to implement the memory watch command.

The implemention of memory watchpoint is tricky in qemu. In last article of qemu internal, we know that when emulating memory access, qemu needs to distinguish the normal RAM read/write from memory mapped I/O read/write. If it is a memory mapped I/O address access, qemu will dispatch this access to the registered I/O emulation functions. Qemu use this mechanism to implement the memory watchpoint. When accessing the memory address watched by qemu, qemu will dispatch this access to the registered memory watch functions, even if this address is normal guest RAM address or memory mapped I/O address! Qemu will do all the magic things in these memory watch functions.

In the following, I will use an example to explain the whole process of memory watch implement of qemu.

80103c60 <memcpy>:
80103c60: 00801021 move v0,a0
80103c64 <__copy_user>:
80103c64: 2cca0004 sltiu t2,a2,4
80103c68: 30890003 andi t1,a0,0x3
80103c6c: 15400068 bnez t2,80103e10 <__copy_user+0x1ac>
80103c70: 30a80003 andi t0,a1,0x3
80103c74: 1520003d bnez t1,80103d6c <__copy_user+0x108>
80103c78: 00000000 nop
80103c7c: 15000046 bnez t0,80103d98 <__copy_user+0x134>
80103c80: 00064142 srl t0,a2,0x5
80103c84: 11000017 beqz t0,80103ce4 <__copy_user+0x80>
80103c88: 30d8001f andi t8,a2,0x1f
80103c8c: 00000000 nop
80103c90: 8ca80000 lw t0,0(a1)

These asm lines are objdumped from linux 2.6.30 kernel for mips malta. Assume that I want to watch the memory access of virtual address 0x804cd000(swapper_pg_dir in linux kernel).

First I insert the watchpoint into cpu.

cpu_watchpoint_insert(env, 0x804cd000, 4, BP_GDB | BP_MEM_ACCESS,
NULL);

And then I need to register the vm state changing call back functions.

qemu_add_vm_change_state_handler(spy_vm_state_change, NULL);

If register a1=0x804cd000, guest linux kernel will touch the watched memory region when pc is 0x80103c90, then qemu dispatches this access to the registered memory watch function, even if this access is a noram guest RAM access.The memory watch functions in qemu are in array watch_mem_read/watch_mem_write.

exec.c

2649 static CPUReadMemoryFunc *watch_mem_read[3] = {
2650 watch_mem_readb,
2651 watch_mem_readw,
2652 watch_mem_readl,
2653 };
2654
2655 static CPUWriteMemoryFunc *watch_mem_write[3] = {
2656 watch_mem_writeb,
2657 watch_mem_writew,
2658 watch_mem_writel,
2659 };

In function watch_mem_readl, it will call function check_watchpoint first.

exec.c

2622 static uint32_t watch_mem_readl(void *opaque, target_phys_addr_t addr)
2623 {
2624 check_watchpoint(addr & ~TARGET_PAGE_MASK, ~0x3, BP_MEM_READ);
2625 return ldl_phys(addr);
2626 }

2563 static void check_watchpoint(int offset, int len_mask, int flags)
2564 {
2565 CPUState *env = cpu_single_env;
2566 target_ulong pc, cs_base;
2567 TranslationBlock *tb;
2568 target_ulong vaddr;
2569 CPUWatchpoint *wp;
2570 int cpu_flags;
2571
2572 if (env->watchpoint_hit) {
2573 /* We re-entered the check after replacing the TB. Now raise
2574 * the debug interrupt so that is will trigger after the
2575 * current instruction. */
2576 cpu_interrupt(env, CPU_INTERRUPT_DEBUG);
2577 return;
2578 }
2579 vaddr = (env->mem_io_vaddr & TARGET_PAGE_MASK) + offset;
2580 TAILQ_FOREACH(wp, &env->watchpoints, entry) {
2581 if ((vaddr == (wp->vaddr & len_mask) ||
2582 (vaddr & wp->len_mask) == wp->vaddr) && (wp->flags & flags)) {
2583 wp->flags |= BP_WATCHPOINT_HIT;
2584 if (!env->watchpoint_hit) {
2585 env->watchpoint_hit = wp;
2586 tb = tb_find_pc(env->mem_io_pc);
2587 if (!tb) {
2588 cpu_abort(env, "check_watchpoint: could not find TB for "
2589 "pc=%p", (void *)env->mem_io_pc);
2590 }
2591 cpu_restore_state(tb, env, env->mem_io_pc, NULL);
2592 tb_phys_invalidate(tb, -1);
2593 if (wp->flags & BP_STOP_BEFORE_ACCESS) {
2594 env->exception_index = EXCP_DEBUG;
2595 } else {
2596 cpu_get_tb_cpu_state(env, &pc, &cs_base, &cpu_flags);
2597 tb_gen_code(env, pc, cs_base, cpu_flags, 1);
2598 }
2599 cpu_resume_from_signal(env, NULL);
2600 }
2601 } else {
2602 wp->flags &= ~BP_WATCHPOINT_HIT;
2603 }
2604 }
2605 }

When check_watchpoint is executed in the first time, env->watchpoint_hit is null. Then it will check whether the address is a watched address. If so, set the flag BP_WATCHPOINT_HIT in wp->flags(line 2583) and set env->watchpoint_hit to wp. Then it will find and invalidate the current translation block(line 2586-2592). If the flag BP_STOP_BEFORE_ACCESS in wp is not set, then qemu will translate the code from current pc(line 2596-2597) and resume the guest instruction emulation(line 2599). Function cpu_resume_from_signal will jump to line 256 in cpu-exec.c and rerun the emulation process from the lw instruction(pc=0x80103c90).

cpu-exec.c

255 for(;;) {
256 if (setjmp(env->jmp_env) == 0) {
257 env->current_tb = NULL;
258 /* if an exception is pending, we execute it here */
259 if (env->exception_index >= 0) {
260 if (env->exception_index >= EXCP_INTERRUPT) {
261 /* exit request from the cpu execution loop */
262 ret = env->exception_index;
263 if (ret == EXCP_DEBUG)
264 cpu_handle_debug_exception(env);
265 break;
266 } else {

Why do qemu need to invalidate current translation block and regenerate the code? Because this memory access(pc=0x80103c90) is in the middle of a translation block. If we want to rerun this instruction, we need to regenerate the code from this instruction(pc=0x80103c90). Moreover before invalidating the translation block, qemu needs to sync the cpu state to guest cpu(cpu_restore_state). That’s because the cpu state in the middle of translation block is different from the actual cpu state. Understanding this process needs some knowledge of binary translation. If you find it is hard to understand, just ignore it.

Now qemu rerun the guest os from pc=0x80103c90. Because the memory address is a watched memory address, qemu will call watch_mem_readl->check_watchpoint again. But this time, env->watchpoint_hit is not null(qemu set it in last call), then it will call cpu_interrupt and return from function check_watchpoint. Then in watch_mem_readl it will call ldl_phys to fetch the value from guest RAM. Function cpu_interrupt in check_watchpoint sets the CPU_INTERRUPT_DEBUG to flag to env->interrupt_request.

Then qemu runs normally just like nothing has happened. Because the CPU_INTERRUPT_DEBUG has been set in env->interrupt_request, the main loop of cpu emulation will return.

cpu-exec.c

355 if (interrupt_request & CPU_INTERRUPT_DEBUG) {
356 env->interrupt_request &= ~CPU_INTERRUPT_DEBUG;
357 env->exception_index = EXCP_DEBUG;
358 cpu_loop_exit();
359 }

54 void cpu_loop_exit(void)
55 {
56 /* NOTE: the register at this point must be saved by hand because
57 longjmp restore them */
58 regs_to_env();
59 longjmp(env->jmp_env, 1);
60 }

Function cpu_loop_exit will do longjmp to line 256 in cpu-exec.c. Because env->exception_index is EXCP_DEBUG, it will break from the loop of function cpu_exec. Function cpu_exec returns to main_loop in vl.c.

vl.c

3800 ret = cpu_exec(env);

3850 if (unlikely(ret == EXCP_DEBUG)) {
3851 gdb_set_stop_cpu(cur_cpu);
3852 vm_stop(EXCP_DEBUG);
3853 }

It will call gdb_set_stop_cpu and then vm_stop to stop the qemu. It the virtual state is changed, qemu will the call the callback functions registered by qemu_add_vm_change_state_handler. So the function spy_vm_state_change will be called.

In sum, when accessing the watched memory address, the memory watch functions will be called. It will call function check_watchpoint. Function check_watchpoint will set env->watchpoint_hit to current watchpoint and rerun the guest os/applicaton from current pc. Then memory watched functions will be called again. It will call function check_watchpoint. This time, function check_watchpoint just set the flag in env->interrupt_request and tells cpu to interrupt the emulation process. And then qemu will return to the main_loop and stop the vm. At last it will call the registered vm change state callback functions.

by yajin at July 15, 2009 09:31 AM

July 10, 2009

Zhou Yajin, vm-kernel.org

qemu internal part 2: softmmu

Qemu uses softmmu to accelerate the process of finding the mapping between guest physical address and host virtual address and the mapping between guest I/O region and qemu I/O emulation functions. In this article, I assume the guest page table size is 4K.

1. the two level guest physical page descriptor table

Qemu uses a two level guest physical page descriptor table to maintain the guest memory space and MMIO space. The table is pointed by l1_phys_map. Bits [31:22] is used to index first level entry and bits [21:12] is used to index the second level entry. The entry of the second level table is PhysPageDesc.

exec.c

146 typedef struct PhysPageDesc {
147 /* offset in host memory of the page + io_index in the low bits */
148 ram_addr_t phys_offset;
149 ram_addr_t region_offset;
150 } PhysPageDesc;

If the memory region is RAM, then the bits [31:12] of phys_offset means the offset of this page in emulated physical memory. If the memory region is memory mapped I/O, then the bits of [11:3] of phys_offset means the index in io_mem_write/io_mem_read array. When accessing this memory region, the functions in io_mem_write/io_mem_read of index phys_offset will be called.

2. register the guest physical memory

Function cpu_register_physical_memory is used to register a guest memory region. If phys_offset is IO_MEM_RAM then it means this region is guest RAM space. If the phys_offset >IO_MEM_ROM, then it means this memory region is MMIO space.

898 static inline void cpu_register_physical_memory(target_phys_addr_t start_addr,
899 ram_addr_t size,
900 ram_addr_t phys_offset)
901 {
902 cpu_register_physical_memory_offset(start_addr, size, phys_offset, 0);
903 }

Function cpu_register_physical_memory_offset will first find the PhysPageDesc in table l1_phys_map using the given guest physical address. If finding the entry, qemu will update the entry. If not finding the entry, then qemu creates a new entry and updates its value and insert this entry to the table at last.

In malta emulation, the following is the code to register malta RAM space.

hw/mips_malta.c

811 cpu_register_physical_memory(0, ram_size, IO_MEM_RAM);

3. register the mmio space

Before registering mmio space using cpu_register_physical_memory, qemu uses the function cpu_register_io_memory to register the I/O emulation functions to array io_mem_write/io_mem_read.

exec.c

2851 int cpu_register_io_memory(int io_index,
2852 CPUReadMemoryFunc **mem_read,
2853 CPUWriteMemoryFunc **mem_write,
2854 void *opaque)

This function will return the index in array io_mem_write/io_mem_read and this index will be passed to function cpu_register_physical_memory via parameter phys_offset.

hw/mips_malta.c

malta = cpu_register_io_memory(0, malta_fpga_read,
malta_fpga_write, s);

cpu_register_physical_memory(base, 0x900, malta);

4. softmmu

Given the guest virtual address, how does qemu find the corresponding host virtual address? First qemu needs to translate the guest virtual address to guest physical address. Then qemu needs to find the PhysPageDesc entry in table l1_phys_map and get the phys_offset. At last qemu should add phys_offset to phys_ram_base to get the host virtual address.

Qemu uses a softmmu model to speed up this process. Its main idea is storing the offset of guest virtual address to host virtual address in a TLB table. When translating the guest virtual address to host virtual address, it will search this TLB table firstly. If there is an entry in the table, then qemu can add this offset to guest virtual address to get the host virtual address directly. Otherwise, it needs to search the l1_phys_map table and then fill the corresponding entry to the TLB table. The index of this TLB table is bits [19:12] of guest virtual address and there is no asid field in tlb entry. This means the TLB table needs to be flushed in process switch!

This TLB table idea is just like the most traditional hardware TLB. However, to MIPS cpu, there is another mmu model in qemu. Unlike x86 cpu, MIPS does NOT care about hardware page table. Instead it uses hardware TLB which is NOT transparent to software. Maybe It is another topic I will explain in another article. What we need to understand here is that the softmmu model in this article is not the mmu model of MIPS cpu itself.

Moreover, besides helping speed up the process of translating guest virtual address to host virtual address, this softmmu model can speed up the process of dispatching I/O emulation functions according to guest virtual address too. In this case, the idex of I/O emulation functions in io_mem_write/io_mem_read is stored in iotlb.

The format of TLB entry is as flowing:

cpu-defs.h

176 CPUTLBEntry tlb_table[NB_MMU_MODES][CPU_TLB_SIZE]; \
177 target_phys_addr_t iotlb[NB_MMU_MODES][CPU_TLB_SIZE];

108 typedef struct CPUTLBEntry {
109 /* bit TARGET_LONG_BITS to TARGET_PAGE_BITS : virtual address
110 bit TARGET_PAGE_BITS-1..4 : Nonzero for accesses that should not
111 go directly to ram.
112 bit 3 : indicates that the entry is invalid
113 bit 2..0 : zero
114 */
115 target_ulong addr_read;
116 target_ulong addr_write;
117 target_ulong addr_code;
124 target_phys_addr_t addend;
131 } CPUTLBEntry;

Field addr_read/write/code stores the guest virtual address for TLB entry. It is the tag of this entry. Filed addend is the offset of host virtual address to guest virtual address. We can add this value to guest virtual address to get the host virtual address.

addend = host_virtual_address – guest_virtual_address

host_virtual_address = phys_ram_base(qemu variable) + guest_physical_address – guest_physical_address_base(0 in MIPS)

The iotlb stores the index of I/O emulation function in io_mem_write/io_mem_read.

Function __ldb_mmu/__ldl_mmu/__ldw_mmu is used to translating the guest virtual address to host virtual address or dispatching guest virtual address to I/O emulation functions.

softmmu_template.h

86 DATA_TYPE REGPARM glue(glue(__ld, SUFFIX), MMUSUFFIX)(target_ulong addr,
87 int mmu_idx)
88 {
89 DATA_TYPE res;
90 int index;
91 target_ulong tlb_addr;
92 target_phys_addr_t addend;
93 void *retaddr;
94
95 /* test if there is match for unaligned or IO access */
96 /* XXX: could done more in memory macro in a non portable way */
97 index = (addr >> TARGET_PAGE_BITS) & (CPU_TLB_SIZE - 1);
98 redo:
99 tlb_addr = env->tlb_table[mmu_idx][index].ADDR_READ;
100 if ((addr & TARGET_PAGE_MASK) == (tlb_addr & (TARGET_PAGE_MASK | TLB_INVALID_MASK))) {
101 if (tlb_addr & ~TARGET_PAGE_MASK) {
102 /* IO access */
103 if ((addr & (DATA_SIZE - 1)) != 0)
104 goto do_unaligned_access;
105 retaddr = GETPC();
106 addend = env->iotlb[mmu_idx][index];
107 res = glue(io_read, SUFFIX)(addend, addr, retaddr);
108 } else if (((addr & ~TARGET_PAGE_MASK) + DATA_SIZE - 1) >= TARGET_PAGE_SIZE) {
109 /* slow unaligned access (it spans two pages or IO) */
110 do_unaligned_access:
111 retaddr = GETPC();
112 #ifdef ALIGNED_ONLY
113 do_unaligned_access(addr, READ_ACCESS_TYPE, mmu_idx, retaddr);
114 #endif
115 res = glue(glue(slow_ld, SUFFIX), MMUSUFFIX)(addr,
116 mmu_idx, retaddr);
117 } else {
118 /* unaligned/aligned access in the same page */
119 #ifdef ALIGNED_ONLY
120 if ((addr & (DATA_SIZE - 1)) != 0) {
121 retaddr = GETPC();
122 do_unaligned_access(addr, READ_ACCESS_TYPE, mmu_idx, retaddr);
123 }
124 #endif
125 addend = env->tlb_table[mmu_idx][index].addend;
126 res = glue(glue(ld, USUFFIX), _raw)((uint8_t *)(long)(addr+addend));
127 }
128 } else {
129 /* the page is not in the TLB : fill it */
130 retaddr = GETPC();
131 #ifdef ALIGNED_ONLY
132 if ((addr & (DATA_SIZE - 1)) != 0)
133 do_unaligned_access(addr, READ_ACCESS_TYPE, mmu_idx, retaddr);
134 #endif
135 tlb_fill(addr, READ_ACCESS_TYPE, mmu_idx, retaddr);
136 goto redo;
137 }
138 return res;
139 }

In this function, it will get the index of TLB table and compare the guest virtual address with the address stored in this tlb entry(line 97-100). If these two addresses match, it means this guest virtual address hits the tlb entry. Then qemu will determine this virtual address is a MMIO address or RAM address. If it is a MMIO address, get the index of IO emulation functions from env->iotlb and call these functions(line 103-117). If it is a RAM space, add the guest virtual address to addend to get the host virtual address(line 118-128). If there is no matched tlb entry, then fietch the entry from table l1_phys_map and insert the entry to tlb table(line 135).

5. an example

When fetching code from guest memory, the whole code path is as flowing:

cpu_exec->tb_find_fast->tb_find_slow->get_phys_addr_code->(if tlb not match)ldub_code(softmmu_header.h)->__ldl_mmu(softmmu_template.h)->tlb_fill->cpu_mips_handle_mmu_fault->tlb_set_page->tlb_set_page_exec

by yajin at July 10, 2009 03:14 AM

July 08, 2009

Zhou Yajin, vm-kernel.org

qemu internal part 1: the code path of memory load emulation

In qemu, there are two different meanings of target. The first meaning of ‘target’ means the emulated target machine architecture. For example, when emulating mips machine on x86, the target is mips and host is x86. However, in tcg(tiny code generator), target has a different meaning. It means the generated binary architecture. In the example of emulating mips on x86, in tcg the target means x86 because tcg will generate x86 binary.

This article is based on qemu version 0.10.5 and target machine emulated is little endian mips. I will summarize the code path of mips lw instruction emulation in qemu.

Function decode_opc is used for decoding all the fetched instructions before tcg generating the target binary.

target-mips/translate.c

7566 static void decode_opc (CPUState *env, DisasContext *ctx)

7960 case OPC_LB ... OPC_LWR: /* Load and stores */
7961 case OPC_SB ... OPC_SW:
7962 case OPC_SWR:
7963 case OPC_LL:
7964 case OPC_SC:
7965 gen_ldst(ctx, op, rt, rs, imm);
7966 break;

It will call function gen_ldst which is also in target-mips/translate.c.

target-mips/translate.c

973 static void gen_ldst (DisasContext *ctx, uint32_t opc, int rt,
974 int base, int16_t offset)

1046 case OPC_LW:
1047 op_ldst_lw(t0, ctx);
1048 gen_store_gpr(t0, rt);
1049 opn = "lw";
1050 break;

Function op_ldst_lw will generate the target binary which fetches the value from the emulated guest memory and gen_store_gpr will store this value to the emulated cpu’s general register rt.

Function op_ldst_lw is generated by the macro OP_LD.

target-mips/translate.c

901 #define OP_LD(insn,fname) \
902 static inline void op_ldst_##insn(TCGv t0, DisasContext *ctx) \
903 { \
904 tcg_gen_qemu_##fname(t0, t0, ctx->mem_idx); \
905 }

910 OP_LD(lw,ld32s);

We can find that op_ldst_lw is a function which calls function tcg_gen_qemu_ld32s. It will output the OPC(INDEX_op_qemu_ld32u) and args to gen_opc_ptr.

tcg/tcg-op.h

1793 static inline void tcg_gen_qemu_ld32s(TCGv ret, TCGv addr, int mem_index)
1794 {
1795 #if TARGET_LONG_BITS == 32
1796 tcg_gen_op3i_i32(INDEX_op_qemu_ld32u, ret, addr, mem_index);
1797 #else
1798 tcg_gen_op4i_i32(INDEX_op_qemu_ld32u, TCGV_LOW(ret), TCGV_LOW(addr),
1799 TCGV_HIGH(addr), mem_index);
1800 tcg_gen_sari_i32(TCGV_HIGH(ret), TCGV_LOW(ret), 31);
1801 #endif
1802 }

99 static inline void tcg_gen_op3i_i32(int opc, TCGv_i32 arg1, TCGv_i32 arg2,
100 TCGArg arg3)
101 {
102 *gen_opc_ptr++ = opc;
103 *gen_opparam_ptr++ = GET_TCGV_I32(arg1);
104 *gen_opparam_ptr++ = GET_TCGV_I32(arg2);
105 *gen_opparam_ptr++ = arg3;
106 }

The path of generation of target binary code of tcg is as following.

cpu_gen_code->tcg_gen_code->tcg_gen_code_common->tcg_reg_alloc_op->tcg_out_op

tcg/i386/tcg-target.c

856 static inline void tcg_out_op(TCGContext *s, int opc,
857 const TCGArg *args, const int *const_args)

1041 case INDEX_op_qemu_ld32u:
1042 tcg_out_qemu_ld(s, args, 2);
1043 break;

431 static void tcg_out_qemu_ld(TCGContext *s, const TCGArg *args,
432 int opc)

508 #if TARGET_LONG_BITS == 32
509 tcg_out_movi(s, TCG_TYPE_I32, TCG_REG_EDX, mem_index);
510 #else
511 tcg_out_mov(s, TCG_REG_EDX, addr_reg2);
512 tcg_out_movi(s, TCG_TYPE_I32, TCG_REG_ECX, mem_index);
513 #endif
514 tcg_out8(s, 0xe8);
515 tcg_out32(s, (tcg_target_long)qemu_ld_helpers[s_bits] -
516 (tcg_target_long)s->code_ptr - 4);

In line 514, tcg outputs 0xe8 which means a call instruction in x86. It will call the functions in array qemu_ld_helpers. The args to the functions is passed by registers EAX,EDX and ECX.

tcg/i386/tcg-target.c

413 static void *qemu_ld_helpers[4] = {
414 __ldb_mmu,
415 __ldw_mmu,
416 __ldl_mmu,
417 __ldq_mmu,
418 };

These functions __ldb_mmu/__ldw_mmu are defined in softmmu_template.h.

softmmu_tempate.h

DATA_TYPE REGPARM glue(glue(__ld, SUFFIX), MMUSUFFIX)(target_ulong addr,
int mmu_idx)

In sum, function gen_ldst outputs the OPC(INDEX_op_qemu_ld32u) to gen_opc_ptr and tcg_out_op will generates the target binary according to the OPC. In the lw instruction emulation, it will generate the x86 binary calls the functions in softmmu_template.h.

by yajin at July 08, 2009 06:58 AM

June 14, 2009

Open Electrons

Using Fedora’s Windows cross compilers to extend EDA software distribution

Last week announced the availability of Fedora 11. This new release entails Windows cross-compilers
introduced by Fedora’s MinGW Special Interest Group.

The aim is to eliminate duplication of work for application developers by providing a range of libraries and development tools which have already been ported to the cross-compiler environment. This means that developers will not need to recompile the application stack themselves, but can concentrate just on the changes needed to their own application.

Though this feature will interest a wide range of software developers, I believe EDA vendors will also be very interested. I will demonstrate a quick example of how to use these Windows cross-compilers.

In this demo, I will use gerbv, a gerber viewer and the example “Temperature Collector” developed by Levente Kovacs.

To install gerbv on fedora,

# yum install gerbv


The above screenshot shows gerbv compiled under a normal Linux “configure && make”. Now we will compile the same gerbv for Windows.

1. Download the sources of gerbv.

2. Setup your Fedora 11 Linux

# yum install mingw32-gcc mingw32-gtk2 mingw32-crossreport mingw32-nsiswrapper wine

3. Configure Wine.

4. Extract gerbv sources.

5. Compilation of gerbv for Windows
$ cd gerbv-2.2.0
$ mingw32-configure
$ mingw32-make

The final Windows executable file of gerbv will be stored in src/.libs/ as gerbv.exe together with its DLL file, libgerbv-1.dll.

6. Launch gerbv.exe under wine

$ wine src/.libs/gerbv.exe


7. Test gerbv.exe under windows.

Under windows, extra DLLs are required and these can be downloaded from The GTK+ Project or simply from here.

The gerber files used in this example, my compiled gerbv.exe and libgerbv-1.dll can be downloaded from here.

mingw32-nsiswrapper can later be used for building automated Windows installers for distribution.

I hope this short crash course will help you. For any additional details, please join the Fedora Mingw mailing list or IRC: #fedora-mingw on FreeNode.

References:

by Chitlesh Goorah (Free Electronic Lab) at June 14, 2009 01:38 PM

June 11, 2009

Open Electrons

FEL: Improving collaborative hardware development experience

One of the many faces of digital hardware design entails tracking many files to be fed to multiple EDA tools. The eventual reports or netlists are carefully analysed and logged as part of the sign-off methodology. Each company tracks these project dependent files under a certain directory structure and under a certain revision controlled system of their choice.

The development cycle Fedora Electronic Lab 12 has started. One key feature for the next Fedora 12 release will be improving “collaborative hardware development experience” on Fedora. As a test-case scenario, let’s imagine 4 persons (from 4 different continents) have encountered each other using a particular social networking medium and want to engage into the development of a FPGA project.

While Fedora Electronic Lab already includes the respective simulators for digital design (VHDL/Verilog), waveforms viewers, schematic editors, PCB layout editor and Fedora’s different webserver and security solutions, these 4 persons (test-case scenario) should not have any issue with the latest Fedora 11 release.

For Fedora 12, we want to ensure that these persons have adequate tools to set up a webserver dedicated for hardware design and help them improve their sign-off and code review methodologies. Hardware code review for small inexperienced companies is often misguided and ends up wasting work hours in unnecessary meetings. Designers often have mixed feelings about code reviews. Sometimes when the code review is outsourced to a third party, source codes are sent in the form of tarballs and tracked as tarballs instead of files, which this is no means an efficient way.

We are currently including an efficient and reliable code review solution into the Fedora collection. This free and opensource solution will also help create links and seamless references between bugs, tasks, changesets and files. Project coordinators will have a more realistic the overview of the on-going project and track the progress very easy with respect to different milestones and deadlines.

Coupled with Fedora’s commitment in Virtualization and SELinux, hardware designers will benefit with a free and robust platform which can easily be deployed.

by Chitlesh Goorah (Free Electronic Lab) at June 11, 2009 07:06 PM

June 10, 2009

Zhou Yajin, vm-kernel.org

a little progress on qemu-loongson

Hi guys, it is about one month since posting last blog entry. These days I am really very busy preparing the GRE and Tofel test. Moreover I have to work to support my life. So I have to spend less time on qemu-loongson.

Anyway, there are progress these days.

  • Rewrite the GPIO I2C emulation for gdium. Now it is more clear than before.
  • add st4180 rtc emulation to qemu
  • add stds75 temperature sensor emulation to qemu
  • change a little in uart emulation to satisfy pmon’s uart probing process
  • fix a little bug in pflash_cfi02.c
  • fix gdb stub bug in qemu to support mips64
  • Follow is the uart output of qemu-loongson.

    kill-bill:/home/root/sdd/gdium/qemu-loongson/mips64el-softmmu# ./qemu-system-mips64el -M gdium -pflash gzrom.bin.gdb -nographic -S -s
    Register sst39vf040  size 80000  at offset 08800000 addr 1fc00000 'pflash0' 80
    devfn 70
    unassigned_mem_readl Unassigned mem read 000000001fbffffc
    unassigned_mem_readl Unassigned mem read 000000001fbffffc
    new_sm502_mm_io 7000000 pci_mem _base 10000000
    PMON2000 MIPS Initializing. Standby...
    PRID=00006302
    enable register space of MEMORY
    DDR2 config begin_whd
    DIMM read
    0000008000000008read DIMM number of rows
    read number of cols
    module data width
    DIMM SIZE=20000000
    cols rows:
    04030940DDR2 config end
    DDR2 DLL locked
    00000004
    disable register space of MEMORY
    jlliu : rom speed reg : 0x00000f8c
    Init SDRAM Done!
    Sizing caches...
    Init caches...
    godson2 caches found
    Init caches done, cfg = 00030932
    Copy PMON to execute location...
    copy text section done.
    Copy PMON to execute location done.
    sp=80ffc000...............new_sm502_mm_io 6000000 pci_mem _base 10000000
    cmd 7
    mmio 6000000
    FREQ
    FREI
    DONE
    DEVI
    ENVI
    MAPV
    nvram=bfc00000
    NVRAM is invalid!
    NVRAM@bfc00000
    STDV
    80100000: heap is already above this point
    SBDD
    P12PCIH

by yajin at June 10, 2009 03:15 AM

June 01, 2009

Open Electrons

Hello EDACafe!

It is with great pleasure that today I’ve a featured blog on EDACafe. My name is Chitlesh Goorah. I will be exposing different opensource solutions which will interest both EDA engineers and ASIC designers.

Some of you may know me from my work behind Fedora Electronic Lab. For about three years now, we are proposing an opensource ASIC design and simulation platform, which is fairly well accepted by many universities around the world. We are working closely with many upstream projects such as gEDA, veripool, open circuit design, … in order to ensure interoperability between our solutions.

At the same time, Fedora developers are introducing Windows cross-compilers for the next version. Thereby, EDA vendors can also use Fedora or entreprise-class distribution such as RHEL or CentOS as a development ground for their products.

Later, I will introduce other features such as virtualisation, mass deployment, various design handoff checking facilities, … etc each accompanying with at least an example. Many designers and CAD engineers are already using opensource tools such as Vi, Emacs, svn, … I am looking forward to read your comments on my next posts.

by Chitlesh Goorah (Free Electronic Lab) at June 01, 2009 06:18 PM

May 02, 2009

Gerard Braad

Linux distributions for ARM

Recently there is a lot of attention for the ARM port of Linux. This is of course related to the netbooks and specialized distributions like Maemo for the Nokia Internet Tablets and Android from Google. Earlier I wrote a short post about the Hasty Hippogriff release of the Mojo Project. This Nokia-sponsored project ported Ubuntu's Hardy Heron to the ARM architecture. It allowed a full desktop distribution to be run on hardware like BeagleBoard. Luckily the major distributions also have increased their support for ARM. openSUSE, Debian and Ubuntu officially announced their support for the ARM architecture in their next release. This will allow companies to use a distribution like openSUSE as a thin client solution or for hardware developers to use Debian as their base system.

The distributions I have tried are Fedora 10, Debian 5.0 (Lenny) and Ubuntu 9.04. Debian 5.0 (Lenny) and Ubuntu 9.04 (Jaunty Jackalope) are now released. Debian provides downloads and bootstrap tools in their distro and lots of documentation. Despite the announcement it seems Ubuntu only has a release candidate?! So the release schedule seemed to not apply for the ARM architecture. Fedora however did not official announce any ARM support, but has a wiki page which describe how to use their distribution. openSUSE recently released a testing milestone for their 11.2 release, but I was unable to find the packages necessary to make a base system. I do have to make a note here: the openSUSE Build Service (OBS) provides ARM support for building packages for Fedora 10, Debian 5.0 and Ubuntu 9.04.

Below you can find the images I have created or used to test the distributions and the information I have used. These images are all base systems to get you started. They can serve as a starting point to create a build environment.

Fedora 10
Fedora does not provide official downloads, but all the files are provided on the wiki. To ease the deployment from a Windows system I created a usable root image which you can download from dropbox or vipeers and the kernel (dropbox). The archive can be unpacked using a tool like Winrar.

With the following command will start the qemu environment without networking:

qemu-system-arm.exe -M versatilepb -kernel zImage-versatile-2.6.24-rc7.armv5tel -hda rootfs-f10.img -append "root=/dev/sda"

You can login with username: root, without a password.

Ubuntu 9.04
Canonical only provides a Release Candidate for their ARM port of Jaunty Jackalope. You can find a the downloads from the cdimage server, such as a general image and an image for the NSLU2. I however built a new rootfs using the information provided on the wiki and the build-arm-rootfs script. This script will use debootstrap and qemu to produce a usable tarball or qemu image. I used the script to create a tarball and dumped this in a mounted image (the same as done for the fedora image).

You can download the root image from dropbox or vipeers and the kernel (dropbox).

To start the environment:

qemu-system-arm.exe -M versatilepb -kernel vmlinuz-2.6.28-11-versatile -hda rootfs-jaunty.img -append "root=/dev/sda"

To login use the username: ubuntu and the password: ubuntu.

Debian 5.0
The ARM support for Ubuntu is no miracle, as their base distribution Debian has support for this architecture. The installation guide can be found on the debian website. Using the debootstrap tool you can easily create your own rootfs. On the webpage of Aurélien Jarno (aurel32) you can find a complete article which describe the process of getting debian running on an emulated ARM using qemu on Linux. The root images and kernel he uses can be found here.

To start the environment:

qemu-system-arm.exe -M versatilepb -kernel vmlinuz-2.6.26-2-versatile -hda debian_lenny_arm_small.qcow -append "root=/dev/sda1"

To login using the username: user and password: user. The password for root is root.

Notes
Read the How to use Network if you want to enable networking for the qemu environment on Windows.

by gbraad (noreply@blogger.com) at May 02, 2009 12:09 AM

May 01, 2009

Gerard Braad

Mojo's Hasty distribution for use with qemu.

As part of a test I am doing, I started to use the Mojo distribution. This is a desktop distribution compiled for mobile and embedded devices. Currently they provide a Ubuntu Hardy (8.04) which is known as Hasty. Since the installation can be a little troubling at first, I will provide a full installation of the Mojo distribution I use. Hopefully it will encourage other to also use it.

mojo hasty running firefox

You need the following files:
mojo-hasty.tar.bz2.00 [rapidshare] [dropbox] (100mb)
mojo-hasty.tar.bz2.01 [rapidshare] [dropbox] (100mb)
mojo-hasty.tar.bz2.02 [rapidshare] [dropbox] (100mb)
mojo-hasty.tar.bz2.03 [rapidshare] [dropbox] (32mb)

Mirrors are welcome... please post your locations in the comments of this article. After download you can extract the files using the command
$ cat mojo-hasty.tar.bz2.* | tar -xvj

Included are the scripts to install (will overwrite hasty.img) and to start the emulation environment.

Installed as described at Using the Debian Installer with QEMU
with all the missing bits added:

during the installtion it will ask you to provide a mirror location:
host: repository.handhelds.org
path: /hasty-armv5el

continue without installing the kernel and bootloader. Do not try to install the desktop environment; due to muine being missing it is not possible at the moment to do so. After installation of the base system, I installed xfce4 xfce4-terminal gdm and xserver-xorg with a configured fbdev device.

username: user
password: user
sudo password: user

It will start from the start script as a recovery console. This can be handy if you encounter unforeseen difficulties, else just continue normal boot. If you don't want this behaviour, just remove 'single' from the append command for qemu.

Additional actions I did to make the experience a little bit more enjoyable are:
$ mkdir /lib/modules/2.6.25.10/
$ depmod -a

xfce: changed panel to a fixed position (bottom, size 24)
xfce: changed terminal font to monospace 4
xfce: changed background color rgb(0, 112, 224)
gdm: enabled automatic login, User: user
gdm: changed local theme to 'Happy GNOME'
gdm: changed background color rgb(0, 112, 224)
user, root:
$ rm ~/.bash_history


Tested with the qemu installation as provided by CentOS 5.2, Fedora 9 and Ubuntu 8.04. Any comments are welcome at 'me+mojo-hasty [monkey] gbraad [dot] nl'.

Note:
In the published files I forgot to mention I also installed the xorg meta package. This is needed to install the fonts for the X server.
$ apt-get install xorg

This action does not need to be performed, since GDM starts. But for a reinstall, this is needed to run the X environment.

Links
Mojo Handhelds,
Qemu, processor emulator

by gbraad (noreply@blogger.com) at May 01, 2009 09:40 PM

April 23, 2009

Zhou Yajin, vm-kernel.org

what's the difference between these two definitions

I write this article because some guys are talking about it in CLF. The question is: what is the difference between the two following definitions:

A. const char temp[]="abc";

B. const char *temp="abc";

You may have your own answer already. But wait a moment, let me write some test cases first and you can see whether your answer is right or not. :)

(1) Test case 1

const char temp[]="abc";
int main()
{
temp[0]='c';
printf("temp %s \n",temp);
}
debian:~# gcc -o test test.c
test.c: In function `main':
test.c:8: error: assignment of read-only location `temp[0]'

(2) Test case 2

const char temp[]="abc";
char temp1[]="def";
int main()
{
temp = temp1;
printf("temp %s \n",temp);
}
debian:~# gcc -o test test.c
test.c: In function `main':
test.c:8: error: assignment of read-only variable `temp'

(3) Test case 3

const char* temp="abc";
char temp1[]="def";
int main()
{
temp = temp1;
printf("temp %s \n",temp);
}
debian:~# gcc -o test test.c
debian:~# ./test
temp def

(4) Test case 4

const char* temp="abc";
int main()
{
temp[0] = 'd';
printf("temp %s \n",temp);
}
debian:~# gcc -o test test.c
test.c: In function `main':
test.c:8: error: assignment of read-only location `*temp'

So the definition A means both temp and array is const and you can not change it. Definition B means temp points to a const string, which you can not change its content. But you can change temp itself.

by yajin at April 23, 2009 01:39 AM

April 03, 2009

Gerard Braad

CentOS 5.3 image for coLinux

A few days ago CentOS 5.3 was finally released. Just like what I have done with the previous version, I created a coLinux environment. This installation is a base system performed using the previously described manual method. Updated instructions are included in the published archive.

For now you can find the files here:
colinux-centos53.exe [VIPeers] [dropbox] (98mb)

It is configured to use DHCP on the network connections eth0 (slirp) and eth1 (bridged). The user account is 'root' without a password. After login, you should change the password. During startup you will see some complaints about the kernel modules. To solve this you can install my kernel modules RPM or use the tarball provided by coLinux.

by gbraad (noreply@blogger.com) at April 03, 2009 10:54 PM

openSUSE 11.1 on coLinux

To ease cross-platform .NET development, I have installed openSUSE on coLinux. This allows me to develop from Windows and also test and debug the binary on Linux. Advantages are: No need to dual boot and a much better performance than using VMware or other virtualization solution. In this article you can find the base system and I will describe how I did the base installation.

Take note, these instructions do NOT provide any details about the .NET environment. Those are published on my .NET blog.

Monodevelop

The files to install and run the environment 'colinux-opensuse-11.1.exe' can be found at [VIPeers], [dropbox] (113Mb). This file contains the base system.img, a swap image and start commands. If you don't want to install it yourself, you can at least immediately start to use openSUSE on coLinux. Take note, network has not been configured yet (see notes). The user account is 'root' with the password 'password'.

Preparation
The installation closely follows the instructions I wrote for CentOS. You will need a clean system.img which you can find in the colinux-centos52-base.rar. Copy the Debian businnesscard init ramdisk to install_initrd.gz. And of course you need to download the openSUSE 11.1 DVD from http://www.opensuse.org/. This file will be about 4.25GB in size.

You can perform a RPM installation, but since openSUSE provides an image-based installation I will use this for the base of the coLinux environment. My main purpose was to keep the installation easy to perform (and if possible small in size). Copy the files base-i386.tar.lzma, base-meta-i386.tar.lzma and common-base-i386.tar.lzma from the openSUSE 11.1 DVD. It is located in the directory images. Since the Debian initrd does not contain the lzma binary, so you will need to decompress the archives with a tool like 7-Zip. The resulting files will be standard tape-archives. Place them in a directory called 'images'. The install.bat will map it to cofs1.

Installation
If you have the install files from the opensuse-11.1.exe file, the images, debian's install_initrd.gz and the system.img from the centos52-base.rar, you are ready to go.

Start the install.bat. You will see a debian installation screen... toggle with ALT-F2 to a console and press Enter.

Please press Enter to activate this console.

Please press Enter to activate this console. BusyBox v1.10.2 (Debian 1:1.10.2-2) built-in shell (ash) Enter 'help' for a list of built-in commands.

From here you can perform the following commands. The line which says 'tar -C /mnt/linux -xf $i' will unpack the image to the system.img. Just be sure to have some coffee ready since it might take some time.


mkswap /dev/cobd7
swapon /dev/cobd7

mkdir /mnt/linux
mkdir /mnt/win
mount /dev/cobd0 /mnt/linux
mount -t cofs cofs0 /mnt/win

mkdir /mnt/images
mount -t cofs cofs1 /mnt/images
cd /mnt/images

for i in *.tar
do
tar -C /mnt/linux -xf $i
done

mkdir -p /mnt/linux/media/cdrom
mount /dev/cobd1 /mnt/linux/media/cdrom

chroot /mnt/linux
cd /media/cdrom/suse/i586

rpm -ivh openSUSE-release-[0-9]*.rpm \
openSUSE-release-dvd-[0-9]*.rpm

echo password | passwd - stdin root

cat > /etc/fstab END
/dev/cobd0 / ext3 acl,user_xattr 1 1
/dev/cobd7 swap swap defaults 0 0
proc /proc proc defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
END

exit


After this you can halt the system. And start it for the first time.

Post-install
To finish the installation you need to start it with the coLinux initrd once. The script runonce.bat will take care of that... after you have run it, openSUSE will start properly. Log on and halt again. After this you can start it without a initrd being specified. The script run.bat will start the final system.

openSUSE 11.1 started on coLinux 0.7.3

It might give some startup errors... nothing serious. I didn't configure the network inside the base system. This can be done using yast or perform the following command:


for i in 0 1
do
cat > /etc/sysconfig/network/ifcfg-eth$i END
BOOTPROTO='dhcp'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR=''
MTU=''
NAME=''
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'
END
done


This enables both eth0 and eth1 to use DHCP. Kernel modules can be installed with the same RPM I have provided earlier. Just use the following commands:


zypper in http://gbraad.fedorapeople.org/files/kernel-modules-2.6-co0.7.3.i386.rpm


Alternative installation
If you want to perform a RPM-based installation you will still need to install the base-i386.tar image. I tried without, but ended up with a lot of errors during installation. The can find the installation instructions in the file instructions-rpm.txt which is included in the archive. Eventually I have not further tested this alternative installation...

Notes
I have tried to only use the files provided by openSUSE, but somehow they seem to consume too much time. The common filesystem did not provide all the tools I needed (similar to the stage2.img from redhat). If you know another way to install it, let me know. Qemu can also install it, but it consumes a lot more time in my opinion; install, dd, etc.

For the moment it is not possible to perform an image installation without the openSUSE DVD installation media. I do hope they will provide a single CD image installer or provide the images from their 11.1 download site. If it is possible, please enlighten me?!

If you want to install additional software, you will need to add the openSUSE repositories. This can easily be done using zypper.


zypper ar http://download.opensuse.org/distribution/11.1/repo/oss/ openSUSE111
zypper ar http://download.opensuse.org/distribution/11.1/repo/non-oss/ openSUSE111_NonOSS
zypper ar http://download.opensuse.org/update/11.1/ openSUSE-11.1-Updates


Now you can install Gnome by using a command like:


zypper in -t pattern gnome


More information about installing software can be found on openSUSE Tutorials.

Have a lot of fun...

by gbraad (noreply@blogger.com) at April 03, 2009 09:50 PM

April 02, 2009

Gerard Braad

CentOS 5.2 image for coLinux

Although soon we hope to have the newer 5.3 release of CentOS, I still decided to create a coLinux image of the current release. The problem with this release is that the kernel has issues when run on Qemu as can be seen in this bug report. This issues is known upstream and is solvable by installing 5.1 and then update it beyond the problematic kernel... or you could just wait until CentOS 5.3 is released.

To make CentOS 5.2 usable in coLinux you could install 5.1 in this way using Qemu and update it. I just took a different approach: use RPM. I used a modified initrd image and installed a basic RPM installation (kinda similar to the FC3-CentOS frankenupgrade). More details about how the installation was performed will follow.



For now you can find the files here:
colinux-centos52.exe [VIPeers] [dropbox] (82mb)

The files contain an image with a minimal installation which you can use on coLinux 0.7.3. The startup is not error-free... but you can ignore the failures for now, since I will update the images to reflect the Fedora images. Your suggestions are of course welcome.

It is configured to use DHCP on the network connections eth0 and eth1. The user account is 'root' without a password.

Edit: repacked the archive to be self-extracting and kernel modules (co0.7.3) have been installed by RPM.

by gbraad (noreply@blogger.com) at April 02, 2009 07:50 PM

March 22, 2009

Gerard Braad

Manually installing CentOS 5.2 on coLinux

In the previous post I published a minimal CentOS 5.2 environment for use with coLinux. As I described in the posting, I did a manual installation since I was unable to use Qemu to start the CentOS 5.2 installation process. Although I received a comment that someone else was able to install CentOS, I am still unable to do so... even with the latest build of Qemu (currently 0.9.1) on Windows. Instead of trying to convert a VMware image or using an update process, I wanted to only use coLinux. In this posting I will try to describe what I did.

Requirements
To ease the installation I have created a base which can assist you with installing. It contains the files you need as images (formatted as Ext3). It is available as centos52-base.rar [dropbox] (35kb).

This file contains what is needed to install the CentOS 5.2 image for
use with coLinux:

  • system.img 4Gb system image, formatted as Ext3

  • swap512m.img 512Mb swap location

  • Batch and parameters file needed to start coLinux

    install.bat, install.txt for the installation process (needed once)

    run.bat, run.txt to start the environment after install

  • instructions.txt file containing the commands to perform


Extract the base archive and place the CentOS 5.2 (i386) installation media in the same directory. Mirrors are provided on the download page of CentOS. If you do not want to download the DVD file, you can also choose to only download CD 1of6. For this you need to change the install.txt parameters file. After the initial install, you can then rely on YUM to install all additional packages.

I used a custom init ramdisk to create the images and perform the installation. Since this file is still rough, I suggest you to download this business card iso from debian. The businesscard ISO is about 35Mb.

With a tool like winrar (or mount it using a tool like Daemon Tools), you can extract the file /install.386/initrd.gz. If you prefer to only download the initrd.gz. Save this file as install_initrd.gz in the directory where you extracted this base directory. This ramdisk will be used to start a system to perform commands from which will start the RPM install.

Please choose the language used for the installation process. This language will be the default language for the final system. Choose a language: C - No localization English - English

After installing coLinux to the standard location you can run the install.bat and start the installation process. It will start the start kernel with the install_initrd.gz as ramdisk. The terminal of choice for this process was a NT terminal, since copy-n-paste was easier to perform. When the installation process interface is shown, you should toggle with ALT+F2 to a console.

Please press Enter to activate this console.

Please press Enter to activate this console. BusyBox v1.10.2 (Debian 1:1.10.2-2) built-in shell (ash) Enter 'help' for a list of built-in commands.

When you do so, you will see a BusyBox prompt where you can perform the instructions as shown in the instructions.txt.

Instructions
You will now perform the instructions needed to do the actual install. We will create a basic environment to perform an RPM installation of the base packages. After this you can use YUM to download and/or install additional packages. To create
the basic layout:

mkswap /dev/cobd7
swapon /dev/cobd7
mkdir /mnt/linux
mkdir /mnt/win
mkdir /mnt/stage2
mount /dev/cobd0 /mnt/linux
mkdir -p /mnt/linux/media/cdrom
mount -t cofs cofs0 /mnt/win
mount /dev/cobd1 /mnt/linux/media/cdrom

This will create some swapspace, a mountpoint /mnt/linux which points to the block device cobd0 (system.img), /mnt/win will be used to point to the coLinux program files folder and /mnt/stage2 will later be used to mount the CentOS stage2 image file. Block device cobd1 is used to mount the DVD image to the mountpoint /mnt/linux/media/cdrom. This will later be used to install the base packages from.

The stage2 image file uses the squashfs filesystem. CoLinux provides kernel modules to use this filesystem.

tar xzvf /mnt/win/vmlinux-modules.tar.gz lib/modules/2.6.22.18-co-0.7.3/kernel/fs/squashfs/squashfs.ko
insmod /lib/modules/2.6.22.18-co-0.7.3/kernel/fs/squashfs/squashfs.ko
mount -t squashfs -o loop /mnt/linux/media/cdrom/images/stage2.img /mnt/stage2

The contents then need to be copied to the /mnt/linux to form the basis of our installation process.

cp -a /mnt/stage2/ /mnt/linux
umount /mnt/stage2
mv /mnt/linux/stage2 /mnt/linux/base

This might take some time...

The system needs to have some directories which will form the basis. The following command will create this.

for n in bin dev proc lib usr tmp etc
do
mkdir -p /mnt/linux/$n
done
touch /mnt/linux/etc/fstab /mnt/linux/etc/mtab
mkdir -p /mnt/linux/var/lib/rpm

The location /var/lib/rpm is needed to store the RPM database files.

Pre-installation
RPM will need some libraries to run. These will be copied to the appropriate location using the following commands:

cd /mnt/linux/lib
ln -s ../base/lib/* .
rm /mnt/linux/lib/udev
rm /mnt/linux/lib/bdevid
mkdir /mnt/linux/usr/lib
cp -a /mnt/linux/base/usr/lib/librpm-* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/librpmio-* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/librpmdb-* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/libpopt.* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/libsqlite3.* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/libelf* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/libbeecrypt.* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/libz.* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/libbz2.* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/libstdc++.* /mnt/linux/usr/lib/
cp -a /mnt/linux/base/usr/lib/rpm /mnt/linux/usr/lib/

All necessary libraries are now available to pivot the root to the /mnt/linux location.

chroot /mnt/linux /base/usr/bin/sh
/base/usr/bin/rpm --initdb

This will create a fresh RPM database which the installation process can use.

Installation
You are now ready to perform the installation.

cd /media/cdrom/CentOS
/base/usr/bin/rpm -ivh setup-*.rpm

The following packages need to be installed at once. These will form a base installation of CentOS.

/base/usr/bin/rpm -ivh \
audit-libs-[0-9]*.rpm \
audit-libs-python-[0-9]*.rpm \
authconfig-[0-9]*.rpm \
basesystem-[0-9]*.rpm \
bash-[0-9]*.rpm \
beecrypt-[0-9]*.rpm \
bzip2-libs-[0-9]*.rpm \
centos-release-[0-9]*.rpm \
centos-release-notes-[0-9]*.rpm \
checkpolicy-[0-9]*.rpm \
chkconfig-[0-9]*.rpm \
coreutils-[0-9]*.rpm \
cpio-[0-9]*.rpm \
cracklib-[0-9]*.rpm \
cracklib-dicts-[0-9]*.rpm \
cryptsetup-luks-[0-9]*.rpm \
cyrus-sasl-lib-[0-9]*.rpm \
db4-[0-9]*.rpm \
dbus-[0-9]*.rpm \
dbus-glib-[0-9]*.rpm \
device-mapper-[0-9]*.rpm \
device-mapper-event-[0-9]*.rpm \
device-mapper-multipath-[0-9]*.rpm \
dhclient-[0-9]*.rpm \
dhcpv6-client-[0-9]*.rpm \
diffutils-[0-9]*.rpm \
dmidecode-[0-9]*.rpm \
dmraid-[0-9]*.rpm \
e2fsprogs-[0-9]*.rpm \
e2fsprogs-libs-[0-9]*.rpm \
ecryptfs-utils-[0-9]*.rpm \
ed-[0-9]*.rpm \
elfutils-libelf-[0-9]*.rpm \
ethtool-[0-9]*.rpm \
expat-[0-9]*.rpm \
file-[0-9]*.rpm \
filesystem-[0-9]*.rpm \
findutils-[0-9]*.rpm \
gawk-[0-9]*.rpm \
gdbm-[0-9]*.rpm \
glib2-[0-9]*.rpm \
glibc-[0-9]*.i686.rpm \
glibc-common-[0-9]*.rpm \
gnu-efi-[0-9]*.rpm \
grep-[0-9]*.rpm \
grub-[0-9]*.rpm \
gzip-[0-9]*.rpm \
hal-[0-9]*.rpm \
hdparm-[0-9]*.rpm \
hwdata-[0-9]*.rpm \
info-[0-9]*.rpm \
initscripts-[0-9]*.rpm \
iproute-[0-9]*.rpm \
iptables-[0-9]*.rpm \
iptables-ipv6-[0-9]*.rpm \
iputils-[0-9]*.rpm \
kbd-[0-9]*.rpm \
kernel-[0-9]*.rpm \
keyutils-libs-[0-9]*.rpm \
kpartx-[0-9]*.rpm \
krb5-libs-[0-9]*.rpm \
kudzu-[0-9]*.rpm \
less-[0-9]*.rpm \
libacl-[0-9]*.rpm \
libattr-[0-9]*.rpm \
libcap-[0-9]*.rpm \
libgcc-[0-9]*.rpm \
libgcrypt-[0-9]*.rpm \
libgpg-error-[0-9]*.rpm \
libhugetlbfs-[0-9]*.rpm \
libselinux-[0-9]*.rpm \
libselinux-python-[0-9]*.rpm \
libsemanage-[0-9]*.rpm \
libsepol-[0-9]*.rpm \
libstdc++-[0-9]*.rpm \
libsysfs-[0-9]*.rpm \
libtermcap-[0-9]*.rpm \
libusb-[0-9]*.rpm \
libuser-[0-9]*.rpm \
libvolume_id-[0-9]*.rpm \
libxml2-[0-9]*.rpm \
libxml2-python-[0-9]*.rpm \
lvm2-[0-9]*.rpm \
m2crypto-[0-9]*.rpm \
MAKEDEV-[0-9]*.rpm \
mcstrans-[0-9]*.rpm \
mingetty-[0-9]*.rpm \
mkinitrd-[0-9]*.rpm \
mktemp-[0-9]*.rpm \
module-init-tools-[0-9]*.rpm \
nash-[0-9]*.rpm \
ncurses-[0-9]*.rpm \
net-tools-[0-9]*.rpm \
newt-[0-9]*.rpm \
nspr-[0-9]*.rpm \
nss-[0-9]*.rpm \
openldap-[0-9]*.rpm \
openssh-[0-9]*.rpm \
openssh-clients-[0-9]*.rpm \
openssh-server-[0-9]*.rpm \
openssl-[0-9]*.i686.rpm \
pam-[0-9]*.rpm \
passwd-[0-9]*.rpm \
pciutils-[0-9]*.rpm \
pcre-[0-9]*.rpm \
pm-utils-[0-9]*.rpm \
policycoreutils-[0-9]*.rpm \
popt-[0-9]*.rpm \
prelink-[0-9]*.rpm \
procps-[0-9]*.rpm \
psmisc-[0-9]*.rpm \
python-[0-9]*.rpm \
python-elementtree-[0-9]*.rpm \
python-iniparse-[0-9]*.rpm \
python-sqlite-[0-9]*.rpm \
python-urlgrabber-[0-9]*.rpm \
readline-[0-9]*.rpm \
redhat-logos-[0-9]*.rpm \
rhpl-[0-9]*.rpm \
rootfiles-[0-9]*.rpm \
rpm-[0-9]*.rpm \
rpm-libs-[0-9]*.rpm \
rpm-python-[0-9]*.rpm \
sed-[0-9]*.rpm \
selinux-policy-[0-9]*.rpm \
selinux-policy-targeted-[0-9]*.rpm \
setools-[0-9]*.rpm \
setserial-[0-9]*.rpm \
shadow-utils-[0-9]*.rpm \
slang-[0-9]*.rpm \
sqlite-[0-9]*.rpm \
sysfsutils-[0-9]*.rpm \
sysklogd-[0-9]*.rpm \
system-config-securitylevel-tui-[0-9]*.rpm \
SysVinit-[0-9]*.rpm \
tar-[0-9]*.rpm \
tcl-[0-9]*.rpm \
tcp_wrappers-[0-9]*.rpm \
termcap-[0-9]*.rpm \
tzdata-[0-9]*.rpm \
udev-[0-9]*.rpm \
udftools-[0-9]*.rpm \
usermode-[0-9]*.rpm \
util-linux-[0-9]*.rpm \
vim-minimal-[0-9]*.rpm \
wireless-tools-[0-9]*.rpm \
yum-[0-9]*.rpm \
yum-metadata-parser-[0-9]*.rpm \
zlib-[0-9]*.rpm

If you perform the command, the following will show indicating that the installation process started.
RPM installation process
This will again take some time... and will eventually result in the following.

If no error occurred you can start with the post-installation to make the system usable from coLinux.

Post-installation
We will now perform some post-installation commands to finish the installation. Create the device nodes in the device directory. These will be used by the filesystem table to mount the filesystem. Do not forget to first exit out of the chroot environment.

exit
mknod -m 666 /mnt/linux/dev/null c 1 3
for i in 0 1 2 3 4 5 6 7 8 9 10
do
mknod -m 660 /mnt/linux/dev/cobd${i} b 117 ${i}
done
chown 0:6 /mnt/linux/dev/cobd*

To have the filesystems mounted on startup you need to have the fstab file being created. Just overwrite the current file:

cat > /mnt/linux/etc/fstab END
/dev/cobd0 / ext3 defaults 1 1
/dev/cobd7 swap swap defaults 0 0
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
none /sys sysfs defaults 0 0
END

Write some basic information to the hosts file.

cat > /mnt/linux/etc/hosts END
127.0.0.1 localhost localhost.localdomain
END

The following will create the shared memory and the pseudo terminal devices, turns off the hardware daemon and allows you to give an initial password for the root user.

chroot /mnt/linux /sbin/MAKEDEV con
chroot /mnt/linux /bin/bash -c "/bin/mkdir /dev/{shm,pts}"
chroot /mnt/linux /bin/bash -c "/bin/chmod a+rwxt /dev/shm"
chroot /mnt/linux /sbin/MAKEDEV generic
chroot /mnt/linux /sbin/chkconfig haldaemon off
chroot /mnt/linux /usr/sbin/authconfig --enableshadow --update
chroot /mnt/linux /usr/bin/passwd root

To have the network start, you need to create the following files. This way your system will be configured with a basic hostname and two network devices using DHCP.

cat > /mnt/linux/etc/sysconfig/network END
NETWORKING=yes
HOSTNAME=localhost.localdomain
END


cat > /mnt/linux/etc/sysconfig/network-scripts/ifcfg-eth0 END
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
END


cat > /mnt/linux/etc/sysconfig/network-scripts/ifcfg-eth0 END
DEVICE=eth1
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
END

Cleanup
You can now remove the base directory we had copied from the stage2 image.

rm -rf /mnt/linux/base
halt

After this you can halt the system and start the environment using the run.bat file. If everything went well your system would look like this!

During startup you will notice some minor error which are related to the kernel dependencies file being missing. To solve this, you can extract the kernel modules using the /dev/cofs0 mapping. Although I prefer to use RPMs, since they are easier to cleanup and upgrade when needed.

yum install wget
wget http://gbraad.fedorapeople.org/files/kernel-modules-2.6-co0.7.3.i386.rpm
rpm -ivh kernel-modules-2.6-co0.7.3.i386.rpm

Enjoy using it... If you have suggestions or stories about your use, leave a comment or send me an email.

by gbraad (noreply@blogger.com) at March 22, 2009 07:18 PM

March 03, 2009

Methril

Remember my first OpenSource project

Today I'm in a melancholic mod. And i started to think about my collaborations to the OpenSource world. I did a lot of experiments at home, but i didn't made it public available, because i wasn't so proud of my code, and I feel scared that someone laughs about my style or my syntax.

I remember my first public project: RTL-EtherBootD is an Open Source project which consists of porting the Ethernet card drivers provided in the Etherboot project to RTLinux. It was my graduate work at University. Since that project, i didn't publish any OpenSource code. I worked in some different environments, but unluckily at my country (Spain) they didn't work a lot with Linux.

I started my actual job very enthusiastic, i was going to work developing Linux in Embedded Systems, but it's not what i'm doing right now :( I'm sad about that, i hope to work in Embedded Linux environments one day, but for now i've to work on this at home.

At work, i started my small patches to u-boot project here. Not really big, but a small step to start doing it more frequently (i've code to submit, but i didn't find it good enough to send it).

Personally, with the OpenMoko project, i started to hack the IDA Systems project, and the build system Openembedded. I found some problems with my working environment at home (Ubuntu 8.10 with a Core2Duo MacBookPro), but i'm solving the environment problems sending some patches to OpenEmbedded.

What i'd like to do is have a day to day work with Linux in Embedded environments, but actually i'm frustrated with a 8-bit PIC micro that i've to develop in Linux environments. Some time before, i was working with 16-bit Motorola uC, at R&D department devolping embedded systems from scratch, for ships. A lot of restrictions: hard-real time, fast response, 3 redundancy communication channels, .... I miss the hardware hacks that i've to do with our prototypes, the evaluation boards and all the stuff. It was funny and i miss the friends that still are there.

For now, i've to see to the future and look for another comfortable environment, Linux, and OpenSource development. I like to don't have to wait too much to find that change.

In my most important project, at the moment (the collaboration with IDA Systems), i suffer from the combination of OpenEmbedded and my environment. I hope to solve this soon. I'm going step by step :)

Now that i wrote some words about my senses, i start to feel better and i can afford my day-to-day job.

See you soon.

-- Edited --
My u-boot patch (the first): http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/44824/focus=45183
My OpenEmbedded patch: http://article.gmane.org/gmane.comp.handhelds.openembedded/21425

by Methril (noreply@blogger.com) at March 03, 2009 12:35 PM

February 21, 2009

Methril

Delays in my updates

Lately i'm not being really active in my blog.

This is because i had a lot of changes in my personal life, and in my working environment.

First of all i've to announce (if someone has interest in it) that i changed my relationship status. Now i'm married. This has give me a lot of my responsabilities and a lot of housework.
Well, not all is bad, but i've less time ;)

Other delayed cause is that i've been traveling in my honeymoon. Now i'm back and i'm reading the news, and future developments (a lot of news missed).

In other order of things, i've been fighting with fso & openembedded to build some images. As allways, i see a lot of dependencies missed. And my build hardware is not really fast (i'm going to need an update) but it's hard because is a computer. My only options are upgrade the HDD to bigger 7200 rpm & upgrade the RAM from 2 GB to 4 GB, other upgrades means buy another hardware, and actually it's not possible.

More updates soon.

As everybody said:
"I'm trying to be more active in my development efforts, and post more often".

by Methril (noreply@blogger.com) at February 21, 2009 08:05 PM

First post, "First" device

Hello to everybody,

This is my first english post in that blog. I created this blog in order to have the my hardware development in the OpenSource world up to date to the community.

I'm working with some ARM Hardware devices (soon patches are in the kitchen). And in my spare time i'm getting fun hacking the Compulab EM-X270. I get this device thanks to rakshat http://idasystems.net . The goal is to make Openmoko Linux "distro", that was designed for NeoFreerunnere and Neo1973 hardware phones, to work with this device, and I'm hands on it.

I'll try to keep the blog up to date.

Hope you like.

by Methril (noreply@blogger.com) at February 21, 2009 06:11 PM

Trying poky

Well, some Openembedded distros have "support" for the em-x270, but only poky (http://pokylinux.org) is officially supported into the distro.

As a Openembedded distro, i'll try to compile and get it working with the module.
Here you can see some screenshots:


Poky running into the em-x270. No icons loaded.



A better picture of the main screen:





It's not working properly, but it could be because the nfs server. I'll take a look on it.

I'll get working some distros, then: angstrom (the officially compulab distro), and poky linux.
Next step, use the Openmoko distro rootfs.

by Methril (noreply@blogger.com) at February 21, 2009 06:11 PM

First Openmoko image

It's a long time since my last post., but here I come back to show you new progress.

I'm being bussy trying to make the poky trunk build system work in my company server. But the config of that server, makes it almost impossible. As the Ida Systems Ltd. guys send me the new phone Openmoko Neo Freerunner as a present, i though that was time to get hands on it (but, keeping in mind the em-x270). After some compiling warnings and errors with the OE environment, i'll found one really nice, in mix with the FSO (http://www.freesmartphone.org) framework that is going to be used with openmoko in the near future (i hope). This environment works, because the openemebedded repository used was the official one, plenty of configurations and machines.

This gives us the opportunity to make the FSO-image for other machines that om-gta01 or om-gta02. This is what i get, a working image for em-x270 :)

Take a look of the em-x270 and the Openmoko Neo Frerunner:


Bootin the board.


First Openmoko Look


A deeper look.


Booting the FSO image.


Zhone started. (Take a look that the dbus system is not working)


zhone out of time :) Left: mls2 Right mls3


The Home in action (another icon fix problem).


The bad things are:

  • No dbus properly working (i'd like to help the FSO guys to get more hardware working with the framework)
  • Some of the devices has to be linked with the touchscreen: ln -s /dev/input/touchscreen0 /dev/ts or ln -s /dev/input/touchscreen0 /dev/touchscreen/0 that are the ones that the openmoko uses.


All this stuff is working through NFS, because it's easier to has a dev cross env until everything goes working properly.

Well, it needs some real dev work to get the devices working, but it would be a happy hacking time :)

Some more news soon.

P.D. Ah! I forget to said that the poky system, that has official support to the em-x270 machine, has the icons working properly.

by Methril (noreply@blogger.com) at February 21, 2009 06:11 PM

D-BUS working, but not all services available

Hello to everybody,

well, some progress have been made in the desired port. The DBUS systems is up and more or less working. We'll have he zhone app working properly with DBUS connected into the app. To surf deeply into the API, and the services running, we have some usefull commands, thanks to mdbus app provided by Michael Lauer.

root@em-x270:~# mdbus -s
:1.0
:1.1
:1.2
:1.3
:1.4
:1.5
:1.6
:1.7
org.bluez
org.freedesktop.Avahi
org.freedesktop.DBus
org.freedesktop.Gypsy
org.freesmartphone.frameworkd
org.freesmartphone.odeviced
org.freesmartphone.oeventsd
org.freesmartphone.ogpsd
org.freesmartphone.ogsmd
org.freesmartphone.ophoned
org.freesmartphone.opreferencesd
org.freesmartphone.ousaged


We could see a lot of services, but not all of them are working properly.

Now it's time to write some code to add support for the GSM modem, the WiFI, the bluetooh, the GPS, battery, speakers, ...
A lot of things to test :D

Time to dev a litle bit.

See you soon.

by Methril (noreply@blogger.com) at February 21, 2009 06:10 PM

Conference at LUG - Madrid

I'm proud to announce to the community my first presentation about OpenMoko.For the English speakers, i'm so sorry, but it's in english.

The UC3M LUG and the creator of the FDOM distro (es), David Samblas, give me the opportunity to talk about this amazing project.
The event was the Congreso GUL UC3M 2008. A lot of Spanish people talking about OpenSource projects. (i love it :D)

You could see the presentation in two parts.(in Spanish, sorry):




And the Presentation in OpenOffice format.

by Methril (noreply@blogger.com) at February 21, 2009 06:10 PM

February 15, 2009

Gerard Braad

libvirt for RHEL5/CentOS 5

Just built and packaged the libvirt library version 0.6.0 for use with Red Hat Enterprise Linux 5 and CentOS 5 (or any other EL5 compatible system). This library supports the following virtualization systems: Xen, KVM, Qemu and OpenVZ.

Files are located at http://files.gbraad.nl/packages/el5/.

These packages have been signed with my packaging key, which is available here (mirror). More information about this library can be found on the libvirt homepage.

by gbraad (noreply@blogger.com) at February 15, 2009 08:20 PM

February 01, 2009

Gerard Braad

The Wizard of Yum: Upgrade from FC3 to CentOS 5.2

If you have a production server, you would like to stay on the yellow brick road of upgrades for the operating system and installed software. However, it might happen you forget to support a server... and get 'scared' of performing updates: "If it ain't broken, don't fix it"! This mentality is not always correct, since errors you don't have at the moment, might still be a problem later on. The further away you get from the updates, the more difficult it will become to perform an upgrade to a later version of a distribution.

Why to write about it
The motivation to describe my experience of upgrading is because I hear a lot of people still complain about RPM and the dependency issues. Most of them have never used it and call the apt system the best solution. In my opinion, the key to success for apt is the reliance on a single repository. Debian people seldomly use dpkg -i to install package, since they use apt-get install to resolve dependencies. YUM solves the issue for RPM systems in a similar fashion. Instead of using rpm -i you can install packages using yum install, which resolves necessary dependencies from the configured repositories.

Note: With Ubuntu and Maemo I have noticed that more repositories get introduced which cause the same problems for apt-get. Dependency resolving might not work, since packages and depencies get fragmented and sometimes even unavailable or conflicting. The Red Hat community recently merged several repositories (RPM Fusion and RPM Forge) which does solve a lot of issues.

Setup
I was faced with the upgrade problem with my own personal (web)server for quite some time. I have no idea what I originally installed on it, but it has always been a Red Hat Linux system. It has been upgraded many times until it ran Fedora Core 3. At least the oldest file on the server was from January 2000. Since the server ran FC3, there was a problem. Fedora Core 3 was released in November 2004 it therefore only had updates available until about 2006.

Last year the machine was taken apart and virtualized to run on a newer VMware environment. I did update the system quite often... but never upgrade the distribution again. I had strayed from the yellow brick road and had no clear upgrade path any more. To solve this issue I could do to things:

  1. Install a new server and migrate the files
  2. Upgrade to a new distribution and hope this would start
No matter what option I would choose, I wanted to have similar functionality. Currently it runs:
  • Webserver:
    Apache HTTPd (with various modules) → Zope
  • Mail infrastructure:
    Postfix → Amavisd-new → Cyrus-imapd
  • Database:
    PostgreSQL
I wanted to upgrade (option 2) as I had always done. Because of this, my options for upgrade were kinda limited: Fedora Core 4? Fedora Core had no support either... and the support for Fedora 8 would also expire soon (as it did this week). On the internet I had seen people mention it would be impossible to perform an upgrade from FC3 to a later version, like FC9 or they strongly advice others not to do so...

Hmmm, so instead I copied my 'sites', 'imap', 'zope' and database dumps to an NFS. Did I have to start a new installation?!??? All other servers I installed allready ran CentOS, I would also make this a CentOS installation. Well, considering CentOS is derived from RHEL (RedHat Enterprise Linux) it is in fact a Fedora installation. If you look at the release details:

  • RHEL-4 is based on FC3
  • RHEL-5 is based on FC6
You can upgrade from RHEL-4 to RHEL-5, this would mean like you jump from FC3 to FC6. CentOS 5.2 is a RedHat derivative from RHEL-5.2... So I wanted to upgrade my FC3 to CentOS 5.2. I know this would be difficult, but in my opinion possible. The key to success would be YUM, the chosen applications and the self-contained installs. The structure I had laid out was simple
  • Amavisd-new ran its own Perl installation from /opt/activestate/perl/
  • Zope
    ran from a Python installation from /opt/activestate/python/
    datafiles are in /home/zope/
  • Cyrus was built from source
    installed in /opt/cyrus/
    datafiles are in /home/cyrus/, totalling 7GB.
  • Each website has its own vhost-[domainname].conf for Apache and a separate directory in /home/sites/[domainname]/[hostname]/web/ which contains the files. Several websites, subdomains and databases, totalling 4GB of data.

Description
The following description are the actions I took, but it is NOT a howto for guaranteed success. It might work for you, although you could also end up with a non-booting system. Only perform this installation if you have enough knowledge of a Linux system and have backups available if it goes wrong.

On VMware I made a snapshot of the VM and opened the console, logged in on the 2nd and 3rd console as root. The main installation I would perform from two SSH connections (one as a backup). The tool I would use for the upgrade is YUM. YUM is a tool which resolves dependencies from repositories you have specified.

As root I created a 'frankenstein' directory with the following files from a CentOS mirror.

centos-release-5-2.el5.centos.i386.rpm

beecrypt-4.1.2-10.1.1.i386.rpm
centos-release-notes-5.2-2.i386.rpm
db4-4.3.29-9.fc6.i386.rpm
db4-devel-4.3.29-9.fc6.i386.rpm
db4-utils-4.3.29-9.fc6.i386.rpm
elfutils-0.125-3.el5.i386.rpm
elfutils-libelf-0.125-3.el5.i386.rpm
elfutils-libelf-devel-0.125-3.el5.i386.rpm
elfutils-libelf-devel-static-0.125-3.el5.i386.rpm
elfutils-libs-0.125-3.el5.i386.rpm
glib2-2.12.3-2.fc6.i386.rpm
glib2-devel-2.12.3-2.fc6.i386.rpm
glibc-2.5-24.i386.rpm
glibc-common-2.5-24.i386.rpm
glibc-devel-2.5-24.i386.rpm
glibc-headers-2.5-24.i386.rpm
keyutils-1.2-1.el5.i386.rpm
keyutils-libs-1.2-1.el5.i386.rpm
krb5-devel-1.6.1-25.el5.i386.rpm
krb5-libs-1.6.1-25.el5.i386.rpm
krb5-workstation-1.6.1-25.el5.i386.rpm
libselinux-1.33.4-5.el5.i386.rpm
libselinux-devel-1.33.4-5.el5.i386.rpm
libsepol-1.15.2-1.el5.i386.rpm
libsepol-devel-1.15.2-1.el5.i386.rpm
libxml2-python-2.6.26-2.1.2.1.i386.rpm
m2crypto-0.16-6.el5.2.i386.rpm
mcstrans-0.2.7-1.el5.i386.rpm
openssl-0.9.8b-10.el5.i386.rpm
popt-1.10.2-48.el5.i386.rpm
python-2.4.3-21.el5.i386.rpm
python-devel-2.4.3-21.el5.i386.rpm
python-elementtree-1.2.6-5.i386.rpm
python-ldap-2.2.0-2.1.i386.rpm
python-sqlite-1.1.7-1.2.1.i386.rpm
python-urlgrabber-3.1.0-2.noarch.rpm
readline-5.1-1.1.i386.rpm
readline-devel-5.1-1.1.i386.rpm
rpm-4.4.2-48.el5.i386.rpm
rpm-build-4.4.2-48.el5.i386.rpm
rpm-devel-4.4.2-48.el5.i386.rpm
rpm-libs-4.4.2-48.el5.i386.rpm
rpm-python-4.4.2-48.el5.i386.rpm
sqlite-3.3.6-2.i386.rpm
sqlite-devel-3.3.6-2.i386.rpm
yum-3.2.8-9.el5.centos.1.noarch.rpm
yum-metadata-parser-1.1.2-2.el5.i386.rpm

The centos-release file tell your YUM to which repository it should refer for an upgrade. Your version number may differ, but this would generally give you a working YUM installation from a CentOS system. Install all the packages at once.

$ rpm -Uvh *.rpm --nodeps.

This is what my console showed after the installation. Since the berkely database version has been upgraded, you need to remove the previous RPM database and rebuild it.

$ rm -f /var/lib/rpm/__db.*
$ rpm --rebuilddb

From this moment on, you could upgrade the system. The command

$ yum upgrade

will show you what issues you need to satisfy for the dependencies. These you can install using:

$ yum install [packagename]

Before I upgraded, I disabled several repositories in my /etc/yum.repos.d/ directory. You can do this by adding enabled=0 to a repo definition. Before continuing the upgrade I stopped unnecessary services and disabled SELinux for now. Depending on the use of your installation you may need to also remove some packages. I had to do so.

$ rpm -qa

shows you all the installed packages. For my installation I removed some Novell branded packages for Mono and most of the X11 packages. After this remove the installed kernels. You might to iterate these steps (rpm -qa and rpm -e or yum remove) several times before you can perform the upgrade.

$ yum upgrade

starts the actual upgrade... be careful during the installation, since some services might not function as expected. Do not abort it. This would render your system not usable.

After the yum upgrade has been performed, you need to check if you have a kernel configured in /boot/grub/grub.conf (/etc/grub.conf). I had to install the kernel myself due to architecture conflicts?!

$ rpm -ivh --ignorearch kernel-2.6.18-92.el5.1686.rpm

Even after this installation you would need to check the grub configuration. Reboot the system and when it starts, you would have a CentOS system.

After this you can cleanup your system.

$ rpm -qa > /tmp/rpmlist
$ cat /tmp/rpmlist | grep fc3
$ cat /tmp/rpmlist | grep FC3

Remove any remaining package which refer to your previous installation. Note: it is normal to find references to fc6 packages for your CentOS installation.

After the reboot, I noticed that most of the applications still worked as they should. Most of the time went into getting Apache and Zope running well together. Now a week later, I removed the VMware snapshot, even consolidated two harddisc files into one. Cyrus-impad is now makes use of the official release package (using my own config file) and upgraded amavisd-new to the RPMforge release. Only zope is running the old installation...

Conclusion
Always plan your system for future use. A sever has a lifespan which may exceed your initial thoughts. Try to compose the server as seperate responsibilities (mail, web, etc) as this would make upgrade easier. Try to stay close to the release schedule of patches and updates for your system... try to avoid building from source or compiling your own kernels as this would make management more difficult later on. And when a distribution gets the end-of-life status, try to move away from it immediately.

As you can see, it would still be possible to upgrade to CentOS 5.2 from Fedora Core 3... but this is NOT advised or a common practice. For me it shows how well thought the components and layout were, since this is also the setup I had used for SpotlightMedia and my previous employer.

In my opinion it shows how well the YUM dependency resolving and upgrading works. The wonderful wizard of Yum gave me a working CentOS system!

by gbraad (noreply@blogger.com) at February 01, 2009 02:48 PM

Installation of OpenVZ on CentOS 5.2

OS virtualization allows you to better scale if you need a large amount of similar software installations and you do not want to deploy more than one physical (or even virtual) machine. It creates isolated containers in which your environment run. In a way it is comparable to a jailed environment, but it provides better isolation, security and management. Hardware virtualization, for products as VMware, XEN and KVM, has a different approach in which you run a completely emulated distribution (often paravirualized) on top of your host system. OS and Hardware virtualization can complement each other.

The installation of OpenVZ containers on CentOS (or RHEL5) is very simple. The following steps were performed on a default installation of CentOS 5.2. In my case I use a virtual machine in a VMware environment.

The OpenVZ installation

$ setup

First you need to disable SELinux and the firewall.

$ cd /etc/yum.repos.d
$ wget http://download.openvz.org/openvz.repo
$ rpm --import http://download.openvz.org/RPM-GPG-Key-OpenVZ
$ yum -y install ovzkernel
$ vi /etc/sysctl.conf

In this file change the following lines:

net.ipv4.ip_forward = 1
kernel.sysrq = 1
net.ipv4.conf.default.proxy_arp = 0

In this same file add the following lines:

net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0


Install the OpenVZ service and have it start at boot:

$ yum install vzctl vzquota
$ chkconfig --add vz
$ reboot


Container configuration
After this, you need to create or download an OS template. For keeping this post easy, I use a precreated template:

$ cd /vz/template/cache
$ wget http://mirror.proserve.nl/openvz/contrib/template/precreated/centos-5-i386-default.tar.gz

Now you can create your first OS container from this template. The information we need is an IP address, hostname and nameservers.

$ vzctl create 101 --ostemplate centos-5-i386-default --conf vps.basic --ipadd 10.73.11.150 --hostname c1.survion.net
$ vzctl set 101 --name c1 --nameserver "10.73.11.1 10.73.11.2 10.73.11.3" --diskspace 10G:10G --save
$ vzctl set 101 --userpasswd root:password --save

Each container instance is represented by an CTID. In the previous steps we used id 101 the identify the container. The configured information can now be found in the file /etc/vz/conf/101.conf. Be sure to use your own secret password for the last command.

You can now start this container and list processes

$ vzctl start 101
$ vzctl exec 101 ps ax

You can also issue an enter command:

$ vzctl enter 101

You would then authenticate as root inside the container. On the console you can perform commands as if you would on a normal machine.


That's it! You now have a CentOS container running on top of your CentOS installation.


Links and additional information
Information on how to create a template can be found on http://wiki.openvz.org/OS_template_cache_preparation

OS Templates can be found at:
If you download the minimal template you can not enter the container. This is because the container does not have a console configured. You could still issue commands using the 'vzctl exec' command and be able to configure the console, but YMMV.

You can read more detailed information about the installation on the following websites:


Edit: An interesting experiment performed by Scott Dowdle can be found on his blog called 'How many containers?'.

by gbraad (noreply@blogger.com) at February 01, 2009 02:48 PM



Subscribe To The Planet
  • Atom Feed
  • RSS 2.0 Feed
  • RSS 1.0 Feed
  • FOAF Subscriptions
  • OPML Subscriptions

Planet Reads From

interactive