Copyleft Hardware

Shakthi updated gplcver to fix a crash upon launch.

Dean Glazeski updated openocd to 0.5.0.

 

I’ll be giving a talk at 28c3 this year on December 29 at 6:30PM about a Man in the Middle attack on HDCP that I discretely embodied within the NeTV. The sharp fellows at rootlabs noticed the trick and disclosed the attack in a blog post from September, which was further elaborated by The Register. I will disclose all the naughty bits about the attack’s implementation in my talk this December.

Now that I have departed chumby, I will produce an open-source version of NeTV to support developers & OEMs through my Singapore-registered company, Sutajio Ko-Usagi. Adafruit.com is currently taking pre-orders. Thank you Phil and Limor for taking the time during peak season to get the product up on your website! You guys rock.

Stay tuned for more…

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.

 

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

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.

For those of us isolated from the rest of the world by shark-infested oceans and 10-hour plane trips, seeing all the Open Hardware action in the US and Europe has left us feeling just a little bit jealous. Over the last few years I've looked enviously at pictures of the huge O'Reilly Maker Faire, wishing there was such a thing in Australia.

Now, thanks to the hard work of Paul Szymkowiak (@paulzee to his friends!) and his army of helpers, my dream is coming true!

Within a few hours the venue will be announced (it's all settled, pending some official paperwork) and the call for Makers to exhibit has already gone out.

The Mini Maker Faire Melbourne will take place on Saturday January 14th, 2012 to coincide with the start of linux.conf.au in Ballarat, so if you're coming into town for LCA you can drop in at Mini Maker Faire Melbourne first and then head on to the conference.

More details can be found at www.makerfairemelbourne.com.

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 popular request, I’ve compiled all the wares from the 2011 Name that Ware season and put them into a wall calendar for 2012. This will be available to next year’s winners of Name that Ware as one of the prize choices, or you can buy one yourself at the bunniestudios cafepress shop.

Each month pictures the featured ware from the previous year, annotated with the identity of the ware and the competition winner … with the exception of December, of course, as this month’s competition has yet to conclude!

Watch the fine folks at Tinkerforge explain their modular hardware kit at http://youtu.be/3DwzskCmTgE
They have chosen the CERN Open Hardware License for their designs.

This site has transitioned to an upgraded server. The transition should be transparent, but if anyone notices anything amiss, please comment!

The Ware for December 2011 brings us from 1945 back to the modern day:

Happy holidays!

The Ware for November 2011 is a Westinghouse JAN-CWL-861 vacuum tube. Thanks to Mike Fitzmorris for contributing this wonderfully preserved retro-ware. It was identified in under one hour from posting, which I didn’t expect. Some people definitely know their vacuum tubes!

Here’s a photo of the whole tube for context:

plum33 is the first person to correctly guess the ware, congrats and email me for your prize!

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.

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/

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.

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.

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

4PM DEC 2 2011. Upon invitation from Terrence Curry, Associate Professor at Tsinghua University’s School of Architecture, Naihan Li gave a talk about her crates in front of about 50 students. this event is about the story of her and her mobile furniture crates. you can find more info about her work at google . but here is a small picture can give you a brief idea. she will using her Media Wall while the speech. this Meida Wall is most interesting things for us. since it have DMX-Light, DMX-Laser, Speakers, Big Screen, Projector. since I have no idea about architecture or design stuff, I will just put the entire event video record somewhere later. then people who have interesting can download this video. there about ~50 students in this event, total time is ~1 hour, Milkymist One is keep rendering about ~20 minutes at the Answer Section, students like it since they think it part of the arcwork I will just put some pictures:

Events Presentation
Professor_Curry_Form_follows_function_or_does_it.pdf
Naihanli_Crates_设计的故事.pdf

Events video
Naihanli_Tsinghua_Event_Crates_1
Naihanli_Tsinghua_Event_Crates_2
Naihanli_Tsinghua_Event_Crates_3
Naihanli_Tsinghua_Event_Crates_4

About Naihanli:
http://naihanli.com/
http://en.wikipedia.org/wiki/Naihan_Li
http://www.core77.com/blog/design_festivals/beijing_design_week_2011_crates_by_naihan_li_20686.asp

About Milkymist One:
http://en.qi-hardware.com/wiki/Milkymist_One
https://sharism.cc/shop/product_info.php?products_id=13

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!

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.