copyleft hardware planet

August 30, 2014

Video Circuits

Richard Paul Lohse

Picked up an exhibition catalogue of a Richard Paul Lohse show from 1970. There were some pretty interesting diagrams of the systems he used to construct his images. Similar concerns to early computer art/constructivist type stuff. Different image generation/process control systems are interesting me at the moment. from multi plane cameras, to the scanimate to digital software but somthing about doing things hands on like Lohse is still interesting.

by Chris (noreply@blogger.com) at August 30, 2014 09:14 AM

August 29, 2014

Richard Hughes, ColorHug

Putting PackageKit metadata on the Fedora LiveCD

While working on the preview of GNOME Software for Fedora 20, one problem became very apparent: When you launched the “Software” application for the first time, it went and downloaded metadata and then built the libsolv cache. This could take a few minutes of looking at a spinner, and was a really bad first experience. We tried really hard to mitagate this, in that when we ask PackageKit for data we say we don’t mind the cache being old, but on a LiveCD or on first install there wasn’t any metadata at all.

So, what are we doing for F21? We can’t run packagekitd when constructing the live image as it’s a D-Bus daemon and will be looking at the system root, not the live-cd root. Enter packagekit-direct. This is an admin-only tool (no man page) installed in /usr/libexec that designed to be run when you want to run the PackageKit backend without getting D-Bus involved.

For Fedora 21 we’ll be running something like DESTDIR=$INSTALL_ROOT /usr/libexec/packagekit-direct refresh in fedora-live-workstation.ks. This means that when the Live image is booted we’ve got both the distro metadata to use, and the libsolv files already built. Launching gnome-software then takes 440ms until it’s usable.

by hughsie at August 29, 2014 07:04 PM

Free Electrons

Free Electrons at the Embedded Linux Conference Europe

DüsseldorfThe Embedded Linux Conference Europe will take place on October 13-15 in Düsseldorf, Germany. As usual, a large part of the Free Electrons engineering team will participate to the conference, with no less than 7 engineers: Alexandre Belloni, Boris Brezillon, Grégory Clement, Michael Opdenacker, Thomas Petazzoni, Maxime Ripard and Antoine Ténart.

Several of our talk proposals have been accepted, so we’ll be presenting about the following topics:

In addition to this participation to the Embedded Linux Conference Europe:

  • Many of us will also participate to the Linux Plumbers conference, on October 15-17. It’s another great opportunity to talk about topics around real-time, power management, storage, multimedia, and more.
  • Thomas Petazzoni will participate to the next Buildroot Developers Meeting.

As usual, we’re looking forward to this event! Do not hesitate to get in touch with us if you’re interested in meeting us during these events for specific discussions.

by Thomas Petazzoni at August 29, 2014 09:47 AM

Altus Metrum

bdale's rocket blog: EasyMega v1.0

Keith and I are pleased to announce the immediate availability of EasyMega v1.0!

EasyMega is effectively a TeleMega without the GPS receiver and radio telemetry system. TeleMega and EasyMega both have 6 pyro channels and enough sensors to lock out pyro events based on conditions like tilt-angle from vertical, making both boards ideal solutions for complex projects with air start or multi-stage engine ignition requirements. Choose TeleMega for a complete in-airframe solution including radio telemetry and GPS, or EasyMega if you already have a tracking solution you like and just need intelligent control of multiple pyro events.

EasyMega is 2.25 x 1.25 inches (57.15 x 31.75 mm), which means it can be easily mounted in a 38 mm air frame coupler. The list price for EasyMega is $300, but as an introductory special, you can purchase one now through Labor Day for only $250! This special is only good for in-person purchases at Airfest and orders placed directly through Bdale's web store.

Altus Metrum products are available directly from Bdale's web store, and from these distributors:

All Altus Metrum products are completely open hardware and open source. The hardware design details and all source code are openly available for download, and advanced users are invited to join our developer community and help to enhance and extend the system. You can learn more about Altus Metrum products at http://altusmetrum.org.

August 29, 2014 03:12 AM

August 28, 2014

Free Electrons

Embedded Linux training update: Atmel Xplained, and more!

Atmel SAMA5D3 Xplained boardWe are happy to announce that we have published a significant update of our Embedded Linux training course. As all our training materials, this update is freely available for everyone, under a Creative Commons (CC-BY-SA) license.

This update brings the following major improvements to the training session:

  • The hardware platform used for all the practical labs is the Atmel SAMA5D3 Xplained platform, a popular platform that features the ARMv7 compatible Atmel SAMA5D3 processor on a board with expansion headers compatible with Arduino shields. The fact that the platform is very well supported by the mainline Linux kernel, and the easy access to a wide range of Arduino shields makes it a very useful prototyping platform for many projects. Of course, as usual, participants to our public training sessions keep their board after the end of the course! Note we continue to support the IGEPv2 board from ISEE for customers who prefer this option.
  • The practical labs that consist in Cross-compiling third party libraries and applications and Working with Buildroot now use a USB audio device connected to the Xplained board on the hardware side, and various audio libraries/applications on the software side. This replaces our previous labs which were using DirectFB as an example of a graphical library used in a system emulated under QEMU. We indeed believe that practical labs on real hardware are much more interesting and exciting.
  • Many updates were made to various software components used in the training session: the toolchain components were all updated and we now use a hard float toolchain, more recent U-Boot and Linux kernel versions are used, etc.

The training materials are available as pre-compiled PDF (slides, labs, agenda), but their source code in also available in our Git repository.

If you are interested in this training session, see the dates of our public training sessions, or order one to be held at your location. Do not hesitate to contact us at for further details!

It is worth mentioning that for the purpose of the development of this training session, we did a few contributions to open-source projects:

Thanks a lot to our engineers Maxime Ripard and Alexandre Belloni, who worked on this major update of our training session.

by Thomas Petazzoni at August 28, 2014 05:52 AM

August 27, 2014

Andrew Zonenberg, Silicon Exposed

Updates and pending projects

It's been a while since I've written anything here so here's a bit of a brain-dump on upcoming stuff that will find its way here eventually.

Thesis stuff

This has been eating the bulk of my time lately. I just submitted a paper to ACM Computing Surveys and am working on a conference paper for EDSC that's due in two weeks or so. With any luck the thesis itself will be finished by May and I can graduate.

Lab improvements

I'm in the process of fixing up my lab to solve a bunch of the annoying things that have been bugging me. Most/all of these will be expanded into a full post once it's closer to completion.
  • Racking the FPGA cluster
    The "raised floor" FPGA cluster was a nice idea but the 2D structure doesn't scale. I've filled almost all of it and I really need the desk space for other things.

    I ordered a 3U Eurocard subrack from Digikey and once it arrives will be making laser-cut plastic shims to load all of my small boards into it. The first card made for the subrack is already inbound: a 3U x 4HP 10-port USB hub to replace several of the 4-port hubs I'm using now. It will be hosted by my Beaglebone Black, which will function as a front-end node bridging the USB-UART and USB-JTAG ports out to Ethernet.

    The AC701 board is huge (well over 3U on the shortest dimension) so I may end up moving it into one of the two empty 1U Sun "pizza box" server cases I have lying around. If this happens the Atlys boards may accompany it since they won't fit comfortably in 3U either.
  • Ethernet - JTAG card
    FTDI-based JTAG is simple and easy but the chips are pricey and to run in a networked environment you need a host PC/server. I'm in the early stages of designing an XC6SLX45 based board with a gigabit Ethernet port, IPv6 TCP offload engine, and 16 buffered, level-shifted JTAG ports. It will speak the libjtaghal jtagd protocol directly, without needing a CPU or operating system, for ultra-low latency and near zero jitter.
  • Logo
    I've gone long enough without having a nice logo to put on my boards, enclosures, etc. At some point I should come up with one...

Test equipment

I've gradually grown fed up with current test equipment. Why would I want to fiddle with knobs and squint at a tiny 320x240 LCD when I could view the signal on my 7040x1080 quad-screen setup or, better yet, the triple 4K displays I'm going to buy when prices come down a bit? Why waste bench space on dials and buttons when I could just minimize or close the control application when it's not in use? As someone who spends most of his time sitting in front of a computer I'd much prefer a "glass cockpit" lab with few physical buttons.

I'm now planning to make a suite of test equipment based on the Unix philosophy: do one thing and do it well. Each board will be a 3U Eurocard with a power input on the back and Ethernet + probe/signal connections on the front. They will implement the low-level signal capture/generation, buffering, and trigger logic but then leave all of the analysis and configuration UI to a PC-based application, connected over 1- or 10-gigabit Ethernet depending on the tool. Projects are listed in the approximate order that I plan to build them.
  • 4-channel TDR for testing cat5e cable installs
    This design will be based on the same general concept as a SAR ADC, with the sampling matrix transposed. Instead of gradually refining one sample before proceeding to the next, the entire waveform will be sampled once, then gradually refined over time.

    Each channel of the TDR will consist of a high-speed 100-ohm differential output from a Spartan-6 FPGA to generate a pulse with very fast rise time, AC coupled into one pair of a standard RJ45 jack which will plug into the cable under test.

    On the input stage, the differential signals will be subtracted by an opamp, then the single-ended differential voltage compared against a reference voltage produced by a DAC using a LMH7324SQ or similar ultra-fast comparator. The comparator will have LVDS outputs driving a differential input on the Spartan-6, which can sample DDR LVDS at up to 1 GHz. This will produce a single horizontal slice across a plot of impedance mismatch/reflection intensity vs time/distance.

    By sending multiple pulses in sequence with successively increasing reference voltages from the DAC, it should be possible to reconstruct an entire TDR trace to at least 8 bits of precision for a fraction of the cost of even a single 1 GSa/s ADC.

    Given the 5ns/m nominal propagation delay of cat5 cable (10us/m after round trip delay), the theoretical spatial resolution limit is 10cm although I expect noise and sampling issues to reduce usable positioning accuracy down to 20-50, and the TDR will need to be calibrated with a known length of cable from the same lot if exact propagation delays are needed to compute the precise location of a fault.
  • 10-channel DC power supply

    Offshoot of the PDU. Ten-channel buck converter stepping 24 VDC down to an adjustable output voltage, operating frequency around 1.5 MHz. Digital feedback loop with support for soft-start, state machine based current limiting and overcurrent shutdown, etc.

    More details TBD once I have time to flesh out the concept a bit.
  • Gigabit Ethernet protocol analyzer
    Spartan-6 connected to three 1gbaseT PHYs. Packets coming in port A are sent out port B unchanged, and vice versa. All traffic going either way is buffered in some kind of RAM, then encapsulated inside a TCP stream and sent out port C to an analysis computer which can record stats, write a pcap, etc.

    The capture will be raw layer-1 and include the preamble, FCS, metadata describing link state changes and autonegotiation status, and cycle-accurate timestamps. Error injection may be implemented eventually if needed.

  • 128-channel logic analyzer
    This will be based on RED TIN, my existing FPGA-based ILA, but with more features and an external 4GB DDR3 SODIMM for buffering packet data. A 64-bit data bus at 1066 MT/s should be more than capable of pushing 32 channels at 1 GHz, 64 at 500 MHz, or 128 at 250 MHz. The input standards planned to be supported are LVCMOS from 1.5 to 3.3V, LVDS, SSTL, and possibly 5V LVTTL if the input buffer has sufficient range. I haven't looked into CML yet but may add this as well.

    The FPGA board will connect to the host PC via a 10gbit Ethernet link using SFP+ direct attach cabling. Dumping 4GB (32 Gb) of data over 10gbe should take somewhere around 4 seconds after protocol overhead, or less if the capture depth is set to less than the maximum.

    The FPGA board will connect via matched-impedance 100-ohm parallel cables (perhaps something like DigiKey 670-2626-ND)) to eight active probe cards. Each probe card will have a MICTOR or similar connector to the DUT providing numerous grounds, optional SSTL Vref, 16 digital inputs, and two clock/strobe inputs with optional complement inputs for differential operation. An internal DAC will allow generation of a threshold voltage for single-ended LVCMOS inputs.

    The probe card input stage will consist of the following for each channel:
    • Unity-gain buffer to reduce capacitive load on the DUT
    • Low-speed precision analog mux to select external Vref (for SSTL) or internal Vref (for LVCMOS). This threshold voltage may be shared across several/all channels in the probe card, TBD.
    • High-speed LVDS-output comparator to compare single-ended inputs against the muxed Vref.
    • 2:1 LVDS mux for selecting single-ended or differential inputs. Input A is the LVDS output from the comparator, input B is the buffered differential input from this and the adjacent channel. To reduce bit-to-bit skew all channels will have this mux even though it's redundant for odd-numbered channels.
    The end result will be 16 LVDS data bits and 2 LVDS clock bits, fed over 18 differential pairs to the FPGA board. The remaining lines in the ribbon will be used for shielding grounds, analog power, and an I2C bus to control the DAC and drive an I/O expander for controlling the mux selectors.
LA input stage for two single-ended or one differential channel
  • 4-channel DSO
    This will use the same FPGA + DDR3 + 10gbe back end as the LA, but with the digital input stage replaced by an AFE and two of TI's 1.5 GSa/s dual ADCs with interleaving support.

    This will give me either two channels at 3 GSa/s with a target bandwidth of 500 MHz, or four channels at 1.5 GSa/s with a target bandwidth of 250 MHz. The resulting raw data rate will be 3 GSa/s * 8 bits * 2 channels or 48 Gbps, and should comfortably fit within the capacity of a 64-bit DDR3 1066 interface.

    I have no more details at this point as my mixed-signal-fu is not yet to the point that I can design a suitable AFE. This will be the last project on the list to be done due to both the cost of components and the difficulty.

by Andrew Zonenberg (noreply@blogger.com) at August 27, 2014 12:46 AM

August 25, 2014

Zedstar

NibbleKiosk: controlling chromium through sound

The idea of NibbleKiosk is to turn old monitors into interactive displays using simple hardware such as a Raspberry Pi with a microphone. The sounds received by the microphone are turned into URLs and sent to Chromium browser. The software comes with 3 programs:

  • one to create the sound files based on the URLs to be used by the client
  • one to create a database of URLs
  • the main program which does the signal processing and controlling of Chromium

You first need to create a database of URLs:

nibbledb -u http://www.raspberrypi.org -d test.db

which outputs:

test.db: key 1B95FB47 set to http://www.raspberrypi.org

You can then create a sound file to use to trigger the URL:

nibblewav 1B95FB47

This will output a wav file with the same hex code in lowercase to your /tmp directory

aplay /tmp/1b95fb47.wav

and you should hear what it sounds like.

You can now start the main program on the receiver. You should first start Chromium listening on port 9222

chromium-browser --remote-debugging-port=9222&

You are now ready to start the main program with the database you created earlier:

nibblekiosk -d test.db

This should now listen continually for the right sounds to trigger URLs on Chromium. You can build your own clients with the wav files you generate.

There are number of variables to get a functioning system. I have had good performance from the microphone on an old USB webcam.

If you are feeling brave and want to try I have made some packages for Ubuntu (14.04) and Raspbian:

http://nibble.io/testing/deb/

The only dependencies are OpenAL and Berkeley DB.

by john at August 25, 2014 06:21 PM

Free Electrons

Linux 3.16 released, Free Electrons 7th contributing company

Linus Torvalds has released the 3.16 kernel a few weeks ago. Unfortunately, the KernelNewbies LinuxChanges page has not been updated, but LWN.net summaries of the merge window (part 1, part 2 and final part) give a good summary of the important changes available in Linux 3.16.

On Free Electrons’ side, 3.16 has been our most active kernel cycle ever: we have merged 388 patches in this cycle, making Free Electrons the 7th company contributing to the Linux kernel by number of patches according to the statistics. Free Electrons is ranked right after Texas Instruments, and before Novell, Renesas or Google. (Note that the statistics rank Free Electrons as 9th, but this includes the “Unknown” and “Hobbyists” categories which are not companies). This strong participation clearly shows Free Electrons’ ability to get code merged in the mainline Linux kernel, as we’ve progressively done since kernel 3.6 over the last two years.

We are therefore available to help companies willing to add support for their hardware (processor, system-on-chip, module, or board) to the mainline Linux kernel. Do not hesitate to contact to get the discussion started.

Our major contributions have again been focused on the support of various ARM processor families:

  • On the Atmel SoC family
    • Conversion of the SAM9RL processor to the Device Tree. Done by Alexandre Belloni.
    • Huge cleanup of ADC/touchscreen handling: improvements in the IIO at91_adc driver to support more SoC families, and conversions of several Atmel platforms to use this driver, and then finally removal of the old atmel_tsadcc driver. Done by Alexandre Belloni.
    • Numerous fixes to the clock handling on various SoCs, following their conversion to the Common Clock Framework. Done by Alexandre Belloni.
    • Conversion of the SAM9RL, SAM9x5 and SAM9n12 SoCs to the Common Clock Framework. Done by Boris Brezillon.
    • Boris Brezillon is now one of the official maintainers for AT91 clock support.
  • On the Allwinner SoC family
    • Addition of PWM support to sun4i and sun7i. Done by Alexandre Belloni.
    • Addition of SMBus support to the regmap subsystem. This was needed to support the P2WI bus of Allwinner A31. Done by Boris Brezillon.
    • New I2C driver for the P2WI bus of Allwinner A31, used to communicate with the PMIC. Done by Boris Brezillon.
    • Improvements to the Allwinner pinctrl driver needed to support the P2WI bus. Done by Boris Brezillon.
    • Addition of a driver for the PRCM (Power, Reset and Clock Management) unit of the Allwinner A31. Done by Boris Brezillon.
    • Numerous cleanups of the pinctrl driver for Allwinner. Done by Maxime Ripard.
    • Addition of the ARM PMU description in the Device Tree of Allwinner platforms. Done by Maxime Ripard.
    • Add USB support for Allwinner A31. Done by Maxime Ripard, with some help from Boris Brezillon.
    • Various improvements to Allwinner clock drivers. Done by Maxime Ripard.
  • On the Marvell Berlin SoC family
    • Addition of basic Device Tree descriptions for several Marvell Berlin processors and boards. Done by Antoine Ténart.
    • Addition of clock drivers and DT clock descriptions of the Marvell Berlin processors. Done by Alexandre Belloni.
    • Addition of the pinctrl drivers for the Marvell Berlin processors. Done by Antoine Ténart.
    • Enabling of SDHCI and GPIO support on Marvell Berlin. Done by Antoine Ténart.
  • On the Marvell EBU SoC family
    • Addition of watchdog support for Armada 375 and Armada 38x, which required some changes to the existing watchdog driver. Done by Ezequiel Garcia.
    • Addition of thermal support for Armada 375 and Armada 38x, which required some changes in the existing armada_thermal driver. Done by Ezequiel Garcia.
    • Improvements of the pxa3xx_nand driver used for NAND support on Armada 370/375/38x/XP to use the newly introduced ECC strength and step size Device Tree bindings, which allows from the Device Tree to override the ECC constraints described by ONFI, when needed to match the bootloader constraints. Done by Ezequiel Garcia.
    • Addition of a generic software TSO (TCP Segmentation Offload) layer, and the corresponding changes to enable this feature in the mv643xx_eth and mvneta network drivers. This gives a huge performance boost in transmit operations! Done by Ezequiel Garcia.
    • SMP support for Armada 375 and Armada 38x has been added. Done by Grégory Clement.
    • cpuidle support for Armada XP has been added. Done by Grégory Clement.
    • USB support (USB2 and USB3) for Armada 375 and Armada 38x has been added. Done by Grégory Clement.
    • Hardware I/O coherency support for Armada 375 and Armada 38x. Done by Thomas Petazzoni.
    • Enabling of the SDHCI and AHCI interfaces on Armada 38x. Done by Thomas Petazzoni.
    • Major clean-up of Marvell Orion5x support. This is an older ARMv5 family of processors from Marvell, having a lot of similarities with Kirkwood and more recent Armada. This cleanup include many Device Tree conversions, up to the point where a few Marvell Orion5x platforms can now be fully described using a Device Tree, with no board file. Done by Thomas Petazzoni.
    • Addition of a new Device Tree binding for fixed network links, i.e links that do not use a MDIO-controlled PHY. This involved both some generic PHY layer improvements, and corresponding changes in the Marvell-specific mvneta network driver. Done by Thomas Petazzoni.
    • Addition of a work-around for a relatively complex PCIe/L2 errata affecting Armada 375/38x, which fixes heavy PCIe traffic when the system is running with hardware I/O coherency enabled. Done by Thomas Petazzoni.

Here is the complete list of patches from Free Electrons merged into the 3.16 kernel:

by Thomas Petazzoni at August 25, 2014 02:33 PM

August 24, 2014

ZeptoBARS

Atmel AT90USB162 : weekend die-shot

Atmel AT90USB162 is an 8-bit microcontroller with hardware USB, 16KiB flash and 512B of SRAM/EEPROM.


August 24, 2014 09:41 PM

August 22, 2014

GNSS-SDR

A bit of advertising

This year a book “GPS, GLONASS, Galileo, and BeiDou for Mobile Devices: From Instant to Precise Positioning” by author Dr Ivan G. Petrovski was published. It contains link of my article. More details about book are available through the link

book.jpg

August 22, 2014 10:13 AM

GLONASS: step towards CDMA

This summer almost unnoticed event has happened. In june GLONASS-M (№755) satellite with L3-band equipment was launched. Since beginning of august this satellite was included in GLONASS constellation. This means that at this moment there are two satellites capable of transmitting CDMA signals in L3 band...These events has become a reason for experiments with receiving signals in L3 band from two satellites simultaneously. Another reason is possibility to use SDR-receiver USRP B200 for these experiments. So the time when both satellites were visible had been chosen and the record was made. Pilot-component of the signal was chosen for processing. During experiments the fact that GLONASS-M transmits only pilot-component while GLONASS-K transmits both pilot and data-components of the signal was revealed. Results of signal processing are of the figures below.

acquisition.png

GLONASS-M.png

GLONASS-K.png

August 22, 2014 10:10 AM

August 17, 2014

ZeptoBARS

Ti CC1100 (formerly Chipcon) : weekend die-shot

Ti CC1100 is a radio transceiver for 300-348 MHz, 400-464 MHz and 800-928 MHz ranges.



Apparently there are 30 initials of the people, involved in the design of this chip mentioned at the lower right corner. Although this chip was designed after Ti acquisition of Chipcon (that happened in January 2006), it is still marked as Chipcon.

August 17, 2014 11:04 PM

August 15, 2014

Village Telco

SECN 2.0 Final Released

SECN 2.0It’s been a while coming but we’re happy to announce the general release of the SECN 2.0 firmware.  This firmware is available for the Mesh Potato 2.0 and a range of TP-Link and Ubiquiti devices.  We posted details in the RC1 release of the software but here is a comprehensive list of features:

  • OpenWrt Attitude Adjustment:  SECN 2.0 is based on the final release of OpenWrt Attitude Adjustment.  We will continue to tie SECN releases as closely as possible to OpenWrt releases in order to maximise device compatibility.
  • Batman-adv:  The SECN firmware now runs the 2013.4 release of batman-adv which includes essential features such as Bridge Loop Avoidance.
  • WAN Support:  SECN 2.0 now offers WAN features that allow the device to configure an upstream connection via WiFi, USB Modem or Mesh
  • Configurable Ethernet:  Ethernet ports can be individually configured for WAN or LAN function.
  • Timezone setting
  • WiFi Country Code setting
  • Web page for Firmware Upgrade

The SECN 2.0 firmware can be downloaded at http://download.villagetelco.org/firmware/secn/stable/  Please check all downloaded files against their MD5 sums prior to flashing your device.  If you have any questions about upgrading your firmware, please don’t hesitate to ask questions in the development community.

Also available very soon will be an SECN 2.0 firmware for the MP1 which will allow full compatibility among first generation Mesh Potatoes and all current generation devices including the MP2 Basic, MP2 Phone, and TP-Link/Ubiquiti devices.

This final release of the 2.0 SECN firmware wouldn’t have been possible without countless hours of tweaking, testing and innovation by Terry Gillett.  Thanks too to Keith Williamson and Elektra for invaluable support.

Upcoming Firmware

SECN 2.1
Firmware for the MP2 Phone is currently in alpha development.  The 2.1 release of the SECN firmware will be the first release to fully support the MP2 Phone.
SECN 2.x
Successive point releases of the 2.0 firmware will include support for:
  • a softphone directory web page which will allow for local registration and management of SIP-enabled devices to a master Mesh Potato allowing for small-scale local directory management and services for VoIP
  • local instant messaging support via XMPP through the integration of the Prosody jabber server
  • integration of a Twitter Bootstrap based UI which will make for faster and more intuitive configuration interface.
SECN 3.0
The 3.0 release of the SECN firmware will be coordinated with the release of the Barrier Breaker of OpenWrt.  It will also include the most recent updates to the Batman-adv mesh protocol.

by steve at August 15, 2014 03:14 PM

August 14, 2014

Video Circuits

Bristol Video Workshop

So Alex and I will be teaching a beginners workshop in analogue video techniques as part of Encounters Festival at the Arnolfini Gallery on Saturday the 20th of September. The whole reason and drive behind the workshop is as  part of Mclaren 2014 a celebration of Norman McLaren's work and  life. Joseph who is the force behind Seeing Sound festival asked if I would put together a workshop exploring some analogue video techniques. The Arnolfini is one of my favourite venues down south, I recently caught a screening of Jordan Belson's work on film which absolutely blew me away and they seem to have a regular program of interesting audio visual and electronic performance stuff. Alex and I have prepared a simple starter in to the world of electronic video with some basic experiments to try and a little background history.

ARNOLFINI
Chris J King and Alexander Peverett
10:00 – 13:00
£25 
Mclaren for event page
Media Artists Chris J King and Alexander Peverett will present a workshop on hands on video techniques influenced by McLaren. The themes in McLaren’s work of drawn sound and visual music were expanded by later artists using electronic video and video synthesis. The workshop will include an introduction to both the historical and technical aspects of electronic video work as well as the construction of a simple circuit and experimentation with video feedback. Be prepared for vivid colours, frenetic sounds and dancing shapes! The cost includes all the parts to make your circuit to take away and play with as well as mirrors to manipulate video feedback and a small publication containing all the information covered in the workshop.

http://encounters-festival.org.uk/news/events/analog-video-workshop/
http://www.seeingsound.co.uk/

by Chris (noreply@blogger.com) at August 14, 2014 05:37 AM

August 13, 2014

Bunnie Studios

Dangerous Prototypes’ Hacker Camp SZ, 2nd Edition

My buddies at Dangerous Prototypes are hosting another Shenzhen hacker camp at the end of September. If you missed the last hacker camp or are just curious about Shenzhen, check it out — the slots are filling up fast!

Come to the world’s electronics capital and experience Shenzhen like a local hacker. Tour the famous Huaqiangbei electronics markets with people who live in the neighborhood, figure out what to eat and how to get around, and of course – learn how to reball BGA chips from a soldering master with noth’n but hand tools.

  • Optional: Tuesday 23 – early arrival dinner at Japanese Secret Location
  • Optional: Wednesday 24 – tour of Dongmen market & sign street, copy mall
  • Thursday 25 – talks: how to survive Shenzhen, Huaqianbei tour
  • Friday 26 – talks: how to use Shenzhen to the fullest, BGA reballing day 1
  • Saturday 27 – BGA reballing day 2, hacker BBQ
  • That’s just an overview. See the full Hacker Camp Shenzhen schedule here. You can expect nightly dinners and parties all week. If you want to come really early, we’re hacking Phuket from the 15th to the 19th.

    by bunnie at August 13, 2014 12:56 PM

    August 10, 2014

    Andrew Zonenberg, Silicon Exposed

    Microchip PIC32MZ process vs PIC32MX

    Those of you keeping an eye on the MIPS microcontroller world have probably heard of Microchip's PIC32 series parts: MIPS32 CPU cores licensed from MIPS Technologies (bought by Imagination Technologies recently) paired with peripherals designed in-house by Microchip.
    Although they're sold under the PIC brand name they have very little in common with the 8/16 bit PIC MCUs. They're fully pipelined processors with quite a bit of horsepower.

    The PIC32MX family was the first to be introduced, back in 2009 or so. They're a MIPS M4K core at up to 80 MHz and max out at 128 KB of SRAM and 512 KB of NOR flash plus a fairly standard set of peripherals.

    PIC32MX microcontroller

    Somewhat disappointingly, the PIC32MX MMU is fixed mapping and there is no external bus interface. Although there is support for user/kernel privilege separation, all userspace code shares one address space. Another minor annoyance is that all PIC32MX parts run from a fixed 1.8V on-die LDO which normally cannot (the 300 series is an exception) be disabled or bypassed to run from an external supply.

    The PIC32MZ series is just coming out now. They're so new, in fact that they show as "future product" on Microchip's website and you can only buy them on dev boards, although I'm told by around Q3-Q4 of this year they'll be reaching distributors. They fix a lot of the complaints I have with PIC32MX and add a hefty dose of speed: 200 MHz max CPU clock and an on-die L1 cache.

    PIC32MZ microcontroller

    On-chip memory in the PIC32MZ is increased to up to 512 KB of SRAM and a whopping 2 MB of flash in the largest part. The new CPU core has a fully programmable MMU and support for an external bus interface capable of addressing up to 16MB of off-chip address space.

    I'm a hacker at heart, not just a developer, so I knew the minute I got one of these things I'd have to tear it down and see what made it tick. I looked around for a bit, found a $25 processor module on Digikey, and picked it up.

    The board was pretty spartan, which was fine by me as I only wanted the chip.

    PIC32MZ processor module
    Less than an hour after the package had arrived, I had the chip desoldered and simmering away in a beaker of sulfuric acid. I had done a PIC32MX340F512H a few days previously to provide comparison shots.

    Without further ado, here's the top metal shots:

    PIC32MX340F512H
    PIC32MZ2048ECH
    These photos aren't to scale, the MZ is huge (about 31.9 mm2). By comparison the MX is around 20.

    From an initial impression, we can see that although both run at the same core voltage (1.8V) the MZ is definitely a new, significantly smaller fab process. While the top layer of the MX is fine-pitch signal routing, the top layer of the MZ is (except in a few blocks which appear to contain analog circuitry) completely filled with power distribution routing.

    Top layer closeups of MZ (left), MX (right), same scale

    Thick power distribution wiring on the top layer is a hallmark of deep-submicron processes, 130 nm and below. Most 180 nm or larger devices have at least some signal routing on the top layer.

    Looking at the mask revision markings gives a good hint as to the layer count and stack-up.

    Mask rev markings on MZ (left), MX (right), same scale
    The MZ appears to be one thick aluminum layer and five thin copper layers for a total of six, while the MX is four layers and probably all aluminum.

    Enough with the top layer... time to get down! Both samples were etched with HF until all metal and poly was removed.

    The first area of interest was the flash.

    NOR flash on MZ (left), MX (right), different scales
    Both arrays appear to be the same standard NOR structure, although the MZ's array is quite a bit denser: the bit cell pitch is 643 x 270 nm (0.173 μm2/bit) while the MX's is 1015 x 676 nm (0.686 μm2/bit). The 3.96x density increase suggests a roughly 2x process shrink.

    The white cylinders littering the MX die are via plugs, most likely tungsten, left over after the HF etch. The MZ appears to use a copper damascene process without via plugs, although since no cross section was performed details of layer thicknesses etc are unavailable.

    The next target was the SRAM.

    6T SRAM on MZ (left), MX (right), different scales
    Here we start to see significant differences. The MX uses a fairly textbook 6T "doughnut + H" SRAM structure while the MZ uses a more modern lithography-optimized pattern made of all straight lines with no angles, which is easier to etch. This kind of bit cell is common in leading-edge processes but this is the first time I've seen it in a commodity MCU.

    Cell pitch for the MZ is 1345 x 747 nm (1.00 μm2/bit) while the MX is 1895 x 2550 nm (4.83 μm2/bit). This is a 4.83x increase in density.

    The last area of interest was the standard cell array for the CPU.

    Closeup of standard cells on MZ (left), MX (right), different scales
    Channel length was measured at 125-130 nm for the MZ and 250-260 nm for the MX.

    Both devices also had a significant number of dummy cells in the gate array, suggesting that the designs were routing-constrained.

    Dummy cells in MZ
    Dummy cells in MX

    In conclusion, the PIC32MZ is a significantly more powerful 130 nm upgrade to the slower 250 nm PIC32MX family. If Microchip fixes most of the silicon bugs before they launch I'll definitely pick up a few and build some stuff with them.

    I wasn't able to positively identify the fab either device was made on however the fill patterns and power distribution structure on the MZ are very similar of the TI AM1707 which is fabricated by TSMC so they're my first guess.

    For more info and die pics check out the SiliconPr0n pages for the two chips:

    by Andrew Zonenberg (noreply@blogger.com) at August 10, 2014 08:30 AM

    August 05, 2014

    Bunnie Studios

    Introducing lowRISC

    There’s a new, open-to-the-RTL CPU project called lowRISC.

    lowRISC is producing fully open hardware systems. From the processor core to the development board, our goal is to create a completely open computing eco-system.

    Our open-source SoC (System-on-a-Chip) designs will be based on the 64-bit RISC-V instruction set architecture. Volume silicon manufacture is planned as is a low-cost development board.

    lowRISC is a not-for-profit organisation working closely with the University of Cambridge and the open-source community.

    This is a positive development for the open source hardware community and I’m excited and honored to be included on their technical advisory board. Can’t wait to play with it!

    by bunnie at August 05, 2014 02:37 PM

    Video Circuits

    South Kiosk Summer Screen #2 - Oscillate Wildly

    South Kiosk have turned their gallery into a screening space, for a series of one-off events taking place over the course of latter summer months.

    For the second installment of their Summer Screen programme, South Kiosk will work with a number of artists, musicians and technologists to construct an immersive installation of flickering CRT surfaces. The various works will offer up a series of experiments in visual mutation through analogue processes, and the degradation of video signal and the VHS tape format. These different approaches offer perspective on a particular branch of filmmaking, and sonic experimentation.

    Featuring work by: James Alec Hardy, Phil Baljeu, Will Cenci, Greg Zifcak, Dan Sandin!

    by Chris (noreply@blogger.com) at August 05, 2014 02:45 AM

    August 03, 2014

    ZeptoBARS

    Fairchild NC7SZ57 - universal 2-input gate : weekend die-shot

    Fairchild NC7SZ57 (and 58) - are universal 2-input shmitt gates, which let us implement various 2-input logic functions by wiring pins in different ways.

    Die size 416x362 µm, which is the smallest among microchips we've seen.

    Comparing to 1-gate NAND2 Ti SN74AHC1G00 - die area here is 1/3 smaller because area below pads is not wasted and used for IO transistors and wiring. It is unclear though how they achieved decent yields (as things there might get damaged during wire bonding) - we can only tell that insulation before last metal is much thicker than usual.

    Drop us a message if you have experience or knowledge on getting high-yield logic under pads - this is something we would be interested to have in our own product.


    August 03, 2014 11:17 PM

    July 30, 2014

    Bunnie Studios

    Name that Ware July 2014

    The Ware for July 2014 is shown below.

    Sorry that posts and updates have been infrequent the past few months — been really busy!

    by bunnie at July 30, 2014 09:07 AM

    Winner, Name that Ware June 2014

    The Ware for June 2014 is a Lantronix SLC RS232 I/O server. I’ll declare Jacob Creedon as the winner for being very close with his first response and providing some in-depth analysis to back up his guesses! Congrats, email me for your prize.

    by bunnie at July 30, 2014 09:07 AM

    July 29, 2014

    ZeptoBARS

    NXP PCA9570 - 4-bit IO expander : weekend die-shot

    NXP PCA9570 is an I²C 4-bit IO expander, although there are 4 unused pads on the die: probably 8-bit version uses the same die. 800nm technology.

    Die size 589x600 µm.



    After (terrible) metal etch - we see IO transistors right under pads:

    July 29, 2014 04:39 AM

    July 27, 2014

    ZeptoBARS

    KILAR KV1084 5A linear regulator : weekend die-shot

    Remember good old times when you could feed CPU from single linear regulator? KILAR KV1084 came from this time.

    Comparing to LM2940L or LM1117 there are more bonding pads per signal and obviously larger output transistors. Chip was soldered on copper heat spreader to help dissipate 10W+.

    Die size 3075x3026 µm.


    July 27, 2014 11:35 AM

    July 26, 2014

    Elphel

    Lens testing at Elphel

    We were measuring lens performance since we’ve got involved in the optical issues of the camera design. There are several blog posts about it starting with "Elphel Eyesis camera optics and lens focus adjustment". Since then we improved methods of measuring Point Spread Function (PSF) of the lenses over the full field of view using the target pattern modified from the standard checkerboard type have better spatial frequency coverage. Now we use a large (3m x 7m) pattern for the lens testing, sensor front end (SFE) alignment, camera distortion calibration and aberration measurement/correction for Eyesis series cameras.

    Fig.1 PSF measured over the sensor FOV

    Fig.1 PSF measured over the sensor FOV – composite image of the individual 32×32 pixel kernels

    So far lens testing was performed for just two purposes – select the best quality lenses (we use approximately half of the lenses we receive) and to precisely adjust the sensor position and tilt to achieve the best resolution over the full field of view. It was sufficient for our purposes, but as we are now involved in the custom lens design it became more important to process the raw PSF data and convert it to lens parameters that we can compare against the simulated achieved during the lens design process. Such technology will also help us to fine-tune the new lens design requirements and optimization goals.

    The starting point was the set of the PSF arrays calculated using images acquired from the the pattern while scanning over the range of distances from the lens to the sensor in small increments as illustrated on the animated GIF image Fig.1. The sensor surface was not aligned to be perpendicular to the optical axis of the lens before the measurement -each lens and even sensor chip has slight variations of the tilt and it is dealt with during processing of the data (and during the final alignment of the sensor during production, of course). The PSF measurement based on the repetitive pattern gives sub-pixel resolution (1.1μm in our case with 2.2μm Bayer mosaic pixel period – 4:1 up-sampled for red and blue in each direction), but there is a limit on the PSF width that the particular setup can handle. Too far out-of-focus and the pattern can not be reliably detected. That causes some artifacts on the animations made of the raw data, these PSF samples are filtered during further processing. In the end we are interested in lens performance when it is almost in perfect focus, so scanning too far away does not provide much of the practical value anyway.

    Acquiring PSF arrays

    Fig. 2 Pattern Grid

    Fig. 2 Pattern grid image

    Each acquired image of the calibration pattern is split into color channels (Fig.2 shows the pattern raw image – if you open the full version and zoom in you can see that there is 2×2 pixel periodic structure) and each channel is processed separately, colors are combined back on the images only for illustrative purposes. Of the full image the set of 40 samples (per color) is processed, each corresponding to 256×256 pixels of the original image.

    Fig. 3 shows these sample areas with windowing functions applied (this reduces artifacts during converting data to frequency domain). Each area is up-sampled to 512×512 pixels. For red and blue channels only one in 4×4=16 pixels is real, for green – two of 16. Such reconstruction is possible as multiple periods of the pattern are acquired (more description is available in the earlier blog post). The size of the samples is determined by a balance of the sub-pixel resolution (the larger the area – the better) and resolution of the PSF measurements over the FOV. It is also difficult to process large areas in the case of higher lens distortions, because the calculated “ideal” grid used for deconvolution had to be curved to precisely match to the acquired image – errors would widen the calculated PSF.

    Fig. 3 Pattern image split into 40 regions for PSF sampling

    Fig. 3 Pattern image split into 40 regions for PSF sampling

    The model pattern is built by first correlating each pattern grid node (twisted corner of the checkerboard pattern) over smaller area that still provides sub-pixel resolution, and then calculating the second degree polynomial transformation of the orthogonal grid to match these grid nodes. The calculated transformation is applied to the ideal pattern and result is used in deconvolution with the measured data producing the PSF kernels as 32×32 pixel (or 35μm x 35μm) arrays. These arrays are stored as 32-bit multi-page TIFF images arranged similarly to the animated GIF on Fig.1 making it easier to handle them manually. The full PSF data can be used to generate MTF graphs (and it is used during camera aberration correction) but for the purpose of the described lens testing each PSF sample is converted to just 3 numbers describing ellipse approximating PSF full width half maximum (FWHM). These 3 numbers are reduced to just two when the lens center is known – sagittal (along the radius) and tangential (perpendicular to the radius) projections. The lens center is determined either from finding the lens radial distortion center using our camera calibration software, or it can be found as a pair of variable parameters during the overall fitting process.

    Data we collected in earlier procedure

    In our previous lens testing/adjustment procedures we adjusted tilt of the sensor (it is driven by 3 motors providing both focal distance and image plane tilt control) by balancing vertical to horizontal PSF FWHM difference in both X and Y directions and then finding the focal distance providing the best “averaged” resolution. As we need good resolution over the full FOV, not just in the center, we are interested in maximizing the worst resolution over the FOV. As a compromise we currently use a higher (fourth) power of the individual PSF components width (horizontal and vertical) over all FOV samples, average the results and extract the fourth root. Then mix results for individual colors with 0.7:1.0:0.4 weights and consider it as a single quality parameter value of the lens (among the samples of the same lens model). There are different aberration types that widen the PSF of the lens-sensor combination, but they all result in degradation of the result image “sharpness”. For example the lens lateral chromatic aberration combined with the spectral bandwidth of the sensor color filter array reduces lateral resolution of the peripheral areas compared to the monochromatic performance presented on the MTF graphs.

    Automatic tilt correction procedure worked good in most cases, but it depended on a particular lens type characteristics and even sometimes failed for the known lenses because of the individual variations between lens samples. Luckily it was not a production problem as this happened only for lenses that differed significantly from the average and they also failed the quality test anyway.

    Measuring more lens parameters

    To improve the robustness of the automatic lens tilt/distance adjustment of the different lenses, and for comparing lenses – actual ones, not just the theoretical Zemax or OSLO simulation plots we needed more processing of the raw PSF data. While building cameras and evaluating different lenses we noticed that it is not so easy to find the real lens data. Very few of the small format lens manufacturers post calculated (usually Zemax) graphs for their products online, some other provide them by request, but I’ve never seen the measured performance data of such lenses so far. So far we measured small number of lenses – just to make sure the software works (the results are posted below) and we plan to test more of the lenses we have and post the results hoping they can be useful for others too.

    The data we planned to extract from the raw PSF measurements includes Petzval curvature of the image surface including astigmatism (difference between sagittal and tangential surfaces) and resolution (also sagittal and tangential) as a function of the image radius for each of the 3 color components, measured at different distances from the lens (to illustrate the optimal sensor position). Resolution is measured as spot size (FWHM), on the final plots it is expressed as MTF50 in lp/mm – the relation is valid for Gaussian spots, so for real ones it is only an approximation: MTF50≈2*ln2π*PSFFWHM. Reported results are not purely lens properties as they depend on the spectral characteristics of the sensor, but on the other hand, most lens users attach them to some color sensor with the same or similar spectral characteristics of the RGB micro-filter array as we used for this testing.

    Consolidating PSF measurements

    We planned to express PSF size dependence (individually for 2 directions and 3 color channels) on the distance from the sensor as some functions determined by several parameters, allow these parameters to vary with the radius (distance from the lens axis to the image point) and then use Levenberg-Marquardt algorithm (LMA) to find the values of the parameters. Reasonable model for such function would be a hyperbola:

    (1) f(z)=(a*(z-z0))2+r02

    where z0 stands for the “best” focal distance for that sample point/component, a defines asymptotes (it is related to the lens numeric aperture) and r0 defines the minimal spot size. To match shift and asymmetry of the measured curves two extra terms were added:

    (2) f(z)=(a*(z-z0))2+(r0-s)2 +s+t*a*(z-z0)

    New parameter s adjusts the asymptotes crossing point above zero and t “tilts” the function together with the asymptotes. To make the parameters less dependent on each other the whole function was shifted in both directions so varying tilt t does not change position and value of the minimum:

    (3) f(z)=(a*(z-z0-zcorr))2+(r0-s)2 +s+t*a*(z-z0-zcorr)-fcorr

    where (solved by equating the first derivative to zero:dfdz=0):

    (4) zcorr=(r0-s)*ta*1-t2

    and

    (5) fcorr=(a*zcorr)2+(r0-s)2-t*a*zcorr-(r0-s)

    Finally I used logarithms of a, r0, s and arctan(t) to avoid obtaining invalid parameter values from the LMA steps if started far from the optimum, and so to increase the overall stability of the fitting process.

    There are five parameters describing each sample location/direction/color spot size function of the axial distance of the image plane. Assuming radial model (parameters should depend only on the distance from the lens axis only) and using polynomial dependence of each of the parameter on the radius that resulted in some 10-20 parameter per each of the direction/color channel. Here is the source code link to the function that calculates the values and partial derivatives for the LMA implementation.

    Applying radial model to the measured data

    Fig.4 PSF sample points naming

    Fig.4 PSF sample points naming

    Fig.5 Fitting individual spot size functions to radial aberration model Spreadsheet link

    Fig.5 Fitting individual spot size functions to radial aberration model. Spreadsheet link

    When I implemented the LMA and tried to find the best match (I was simultaneously adjusting the image plane tilt too) for the measured lens data, the residual difference was still large. Top two plots on Fig.5 show sagittal and tangential measured and modeled data for eight location along the center horizontal section of the image plane. Fig.4 explains the sample naming, linked spreadsheet contains full data for all sample locations and color/direction components. Solid lines show measured data, dashed – approximation by a radial model described above.

    The residual fitting errors (especially for some lens samples) were significantly larger than if each sample location was fitted with individual parameters (the two bottom graphs on Fig.5). Even the best image plane tilt determined for sagittal and tangential components (if fitted separately) produced different results – one one lens the angle between the two planes reached 0.4°. The radial model graphs (especially for Y2X6 and Y2X7) show that the sagittal and tangential components are “pulling” the result in opposite directions It became obvious that the actual lenses can not be fully characterized in the terms of just the radial model as used for simulation of the designed lenses, the deviations of the symmetrical radial model have to be accounted for too.

    Adjustment of the model parameters to accommodate per-location variations

    I modified the initial fitting program to allow individual (per sample location) adjustment of the parameter values, adding cost of correction variation from zero and/or from the correction values of the same parameter at the neighbors sites. Sum of the squares of the corrections (with balanced weights) was added to the sum of the squares of the differences between the measured PSF sizes and the modeled ones. This procedure requires that small parameter variations result in small changes of the functions values, that was achieved by the modeling function formula modification as described above.

    Lenses tested

    New program was tested with 7 lens samples – 5 of them were used to evaluate individual variations of the same lens model, and the two others were different lenses. Each result image includes four graphs:

    • Top-left graph shows weighted average resolution for each individual color and the combination of all three. Weighted average here processes the fourth power of the spot size at each of the 40 locations in both (sagittal and tangential) directions so the largest (worst) values have the highest influence on the result. This graph uses individually fitted spot size functions
    • Bottom-left graph shows Petzval curvature for each of the 6 (2 directions of 3 colors) components. Dashed lines show sagittal and solid lines – tangential data for the radial model parameters, data point marks – the individually adjusted parameters, so same radius but different direction from the lens center results in the different values
    • Top-right graph shows the resolution variation over radius for the plane at the “best” (providing highest composite resolution) distance from the lens, lines showing radial model data and marks – individual samples
    • Bottom-right graph shows a family of the resolution functions for -10μm (closest to the lens), -5μm, 0μm, +50μm and +10μm positions of the image plane
    Linked spreadsheet files contain more graphs and source data for each lens.

    Evetar N125B04518W

    Evetar N125B04518W is our “workhorse” lens used in Eyesis cameras. 1/2.5″ format lens, focal length=4.5mm, F#=1.8. It is a popular product, and many distributors sell this lens under their own brand names. One of the reasons we are looking for the custom lens design is that while this lens has “W” in the model name suffix meaning “white” (as opposed to “IR” for infrared) it is designed to be a “one size fits all” product and the only difference is addition of the IR cutoff filter at the lens output. This causes two problems for our application – reduced performance for blue channel (and high longitudinal chromatic aberration for this color) and extra spherical aberration caused by the plane-parallel plate of the IR cutoff filter substrate. To mitigate the second problem we use non-standard very thin – just 0.3mm filters.

    Below are the test results for 5 randomly selected samples of the batch of the lenses with different performance.

    Fig.6 Evetar N125B04518W sample #0294 test results

    Fig.6 Evetar N125B04518W sample #0294 test results. Spreadsheet link.

    Fig.7 Evetar N125B04518W sample #0274 test results

    Fig.7 Evetar N125B04518W sample #0274 test results. Spreadsheet link.

    Fig.8 Evetar N125B04518W sample #0286 test results

    Fig.8 Evetar N125B04518W sample #0286 test results. Spreadsheet link.

    Fig.9 Evetar N125B04518W sample #0301 test results

    Fig.9 Evetar N125B04518W sample #0301 test results. Spreadsheet link.

    Fig.10 Evetar N125B04518W sample #0312 test results

    Fig.10Evetar N125B04518W sample #0312 test results. Spreadsheet link.

    Evetar N125B04530W

    High resolution 1/2.5″ f=4.5mm, F#=3.0 lens
    Fig.11 Evetar N125B04530W sample #9101 test results

    Fig.11 Evetar N125B04530W sample #9101 test results. Spreadsheet link.

    Sunex DSL945D

    Sunex DSL945D – compact 1/2.3″ format f=5.5mm F#=2.5 lens. Datasheet says “designed for cameras using 10MP pixel imagers”. The sample we tested has very high center resolution, excellent image plane flatness and low chromatic aberrations. Unfortunately off-center resolution degrades with the radius rather fast.

    Fig.12 Sunex SLR945D sample #1020 test results

    Fig.12 Sunex SLR945D sample #1020 test results. Spreadsheet link.

    Sunex DSL355A-650-F2.8

    Sunex DSL355A – 1/2.5″ format f=4.2mm F#=2.8 hybrid lens.

    Fig.12 Sunex SLR355A sample #9063 test results

    Fig.13 Sunex SLR355A sample #9063 test results. Spreadsheet link.

    Software used

    This project used Elphel plugin for the popular open source image processing program ImageJ with new classes implementing the new processing described here. The results were saved as text data tables and imported in free software LibreOffice Calc spreadsheet program to create visualization graphs. Finally free software Gimp program helped to combine graphs and create the animation of Fig.1.

    by andrey at July 26, 2014 10:37 PM

    July 25, 2014

    ZeptoBARS

    OPA627, genuine one this time : weekend die-shot

    Last time we decapped 2 fake OPA627's from ebay: one was remarked AD744 part, another was unidentified remarked BB part.

    Recently reader sent us one more OPA627 from ebay. This chip appeared to be genuine.

    Die size 2940x2005 µm.


    July 25, 2014 05:02 PM

    Free Electrons

    Marvell publishes the datasheet of the Armada XP processor

    thumb-armada-xpA bit more than a month after publishing the datasheet of the Armada 370 processor, Marvell has now released a similar datasheet for the more powerful Armada XP processor. The datasheet is available as a PDF document, with no registration, at http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf, with a link to it clearly visible on the Armada XP product page.

    As most of our readers probably know, Free Electrons has been working and continues to work significantly on the Linux kernel support for Marvell processors. Thanks to this work done for more than two years now, the mainline Linux kernel has pretty good support for the Armada XP processor. This processor is a nice monster: up to 4 cores (PJ4B cores, which are roughly equivalent to Cortex-A9 but with LPAE support), up to 10 PCIe interfaces, multiple SATA interfaces, up to four Gigabit network interfaces, and many, many other things (XOR engine, cryptographic engine, etc.). Many of the processor features are already supported in mainline, and lately we’ve been focusing on power management features: cpuidle support for Armada XP will be part of 3.16, cpufreq support will either be part of 3.17 or 3.18, and suspend/resume should hopefully be part of 3.18.

    The Armada XP processor is used in publicly available products:

    At Free Electrons, we are again really happy to see Marvell opening this datasheet, as it will allow all community developers to further improve support for this processor in the Linux kernel, but also in other open-source projects.

    by Thomas Petazzoni at July 25, 2014 09:16 AM

    July 24, 2014

    Elphel

    Optimization Intermediate Results

    Description

        Running OSLO’s optimization has shown that having a single operand defined is probably not enough. During the optimization run the program computes the derivative matrix for the operands and solves the least squares normal equations. The iterations are repeated with various values of the damping factor in order to determine the optimal value of the damping factor.     So, extra operands were added to split the initial error function – each new operand’s value is a contribution to the spot size (blurring) calculated for each color, aberration and certain image heights. See Fig.1 for formulas.
    Fig.1 Extra Operands

    Fig.1 Extra Operands

    FieldCurvature(), LateralColor(), LongSpherical() and Coma() functions are defined in a ccl script found here – they use OSLO’s built in functions to get the data. FY – fractional (in OSLO) pupil coordinate – 0 in the center, 1.0 – the edge (at the aperture stop) FBY – fractional (in OSLO) image height (at the image plane) NA – numeric aperture

    Field Curvature (1)

        3 reference wavelengths, 7 image plane points (including center) and sagittal & tangential components make up 42 operands total affecting field curves shapes and astigmatism. To get the contribution to the spot size one need to multiply the value by Numerical Aperture (NA). NA is taken a constant over the full field.

    Lateral Color (2)

        There are 3 bands the pixels are sensitive to – 510-560, 420-480 and 585-655 nm. The contribution to the spot size is then calculated for each band and 6 image plane points – there’s neither central nor tangential component – 18 operands total.

    Longitudinal Spherical (3)

        The spot size contribution is calculated for the 3 reference wavelengths and 7 points at the aperture stop (including center). The tangential and sagittal components are equal, thus there are 42 operands.

    Coma (4)

    It doesn’t have a huge impact on the optimization but it was still added for some control. The operands are calculated for 3 wavelengths and 6 image plane points – adds up 18 extra operands.

    Results

    See Fig.2-5. All of the curvatures and thicknesses were set to variables, except for the field flattener and the sensor’s cover glass. The default OSLO’s optimization method was used – Dump Least Squared (DLS).
    Parameter Comments
    Field Curvature decreased from 20um to 5 um over the field
    Astigmatism decreased max(T-S) from ~15um to ~2.5 um
    Chromatic Focal Shift almost no changes
    Lateral Color almost no changes
    Longitudinal Spherical got better in the middle and worse in the edge
    Resolution somewhat insignificantly improved
    Tried to vary the glasses but this didn’t lead to anything good – it tends to make the front surface extremely thin.

    Questions

    This might be the best(?) what can be achieved with the current curvatures-thicknesses (and glasses) configuration. Spherical aberration seem to contribute the most at the current f/1.8. What would be the next step?
    1. It’s always possible to go down to f/2.0-f/2.5. But we would keep the aperture as wide as possible.
    2. Add extra elements(s)?
      • Where? Make changes closer to the surfaces that affect spherical aberration the most?
    3. Make up extra achromatic doublet(s)?
      • Where? Make changes closer to the surfaces that affect spherical aberration the most?
    4. Introduce aspheric surface(s)?
      • Plastic or glass? Some guidlines suggest to place glass close to the aperture stop and plastic – away. At the same time, “a surface close to the aperture stop tend to affect or benefit spherical aberration, surfaces located further from the stop can help minimize some or all of the off-axis aberrations such as coma and astigmatism”:
        • Glass
          • Where? Make changes to the surfaces that affect spherical aberration the most?
          • One of the surfaces of the achromatic doublet?
        • Plastic
          • Where? Place a plano-aspheric element (flat front, aspheric back) at locations wheres rays are (almost) parallel? The thermal expansion might not affect the performance very much.
          • Plano-aspheric element in the front of the lens?
          • Aspheric surface on the achromatic doublet?
          • As thin as possible? How thin can it be?
          • Make the element after the doublet plano-aspheric?
    Other questions:
    1. Are there glass-plastic (glass-polymer? hybrid?) aspheric achromatic doublets available?
    2. Is it possible to glue a thin plastic aspherics on a glass element (like a contact lens)?


    Links

    Fig.2 Before

    Fig.2 Before

    Fig.3 After

    Fig.3 After

    Fig.4 Before. MTF(green)

    Fig.4 Before. MTF(green)

    Fig.5 After. MTF(green)

    Fig.5 After. MTF(green)

    by Oleg Dzhimiev at July 24, 2014 12:52 AM

    July 11, 2014

    ZeptoBARS

    Milandr 1986VE21 : weekend die-shot

    Milandr 1986VE21 - is a microcontroller for 3-phase electricity meters. Rare example of purely civilian Russian microchip which was not funded by any government agency.


    July 11, 2014 12:05 AM

    July 08, 2014

    Richard Hughes, ColorHug

    Important AppData milestone

    Today we reached an important milestone. Over 25% of applications in Fedora now ship AppData files. The actual numbers look like this:

    • Applications with descriptions: 262/1037 (25.3%)
    • Applications with keywords: 112/1037 (10.8%)
    • Applications with screenshots: 235/1037 (22.7%)
    • Applications in GNOME with AppData: 91/134 (67.9%)
    • Applications in KDE with AppData: 5/67 (7.5%)
    • Applications in XFCE with AppData: 2/20 (10.0%)
    • Application addons with MetaInfo: 30

    We’ve gone up a couple of percentage points in the last few weeks, mostely from the help of Ryan Lerch, who’s actually been writing AppData files and taking screenshots for upstream projects. He’s been concentrating on the developer tools for the last week or so, as this is one of the key groups of people we’re targetting for Fedora 21.

    One of the things that AppData files allow us to do is be smarter suggesting “Picks” on the overview page. For 3.10 and 3.12 we had a farly short static list that we chose from at random. For 3.14 we’ve got a new algorithm that tries to find similar software to the apps you already have installed, and also suggests those. So if I have Anjunta and Devhelp installed, it might suggest D-Feet or Glade.

    by hughsie at July 08, 2014 10:42 AM

    July 05, 2014

    July 02, 2014

    Richard Hughes, ColorHug

    Blurry Screenshots in GNOME Software?

    Are you a pixel perfect kind of maintainer? Frustrated by slight blurriness in screenshots when using GNOME Software?

    If you have one screenshot, capture a PNG of size 752×423. If you have more than one screenshot use a size of 624×351.

    If you use any other 16:9 aspect ratio resolution, we’ll scale your screenshot when we display it. If you use some crazy non-16:9 aspect ratio, we’ll add padding and possibly scale it as well, which is going to look pretty bad. That said, any screenshot is better than no screenshot, so please don’t start removing <screenshot> tags.

    by hughsie at July 02, 2014 08:28 PM

    Elphel

    Defining Error Function for Optical Design optimization (in OSLO)

    Description

    The Error Function calculates the 4th root of the average of the 4th power spot sizes over several angles of the field of view.
    t

     

    Fig.1 Sensor's quantum efficiency

    Fig.1 Pixel’s quantum efficiency

    Fig.2 Example of pixel sensitivity range

    Fig.2 Example of pixel’s sensitivity range

    The function takes into account:
    • Pixels’ sensitivity to a band rather than a single wavelength (Fig.1). It negatively affects the sagittal component of the Point Spread Function (PSF).

    • One of the goals is the uniform angular resolution and applies the corresponding coefficients to the sagittal component. The angular resolution increases with the field angle increase and degrades with negative distortion amount increase with the field angle increase

    Formulas

    Fig.3 formulas

    Fig.3 Formulas 1-5

    • If PSF shape is approximated with a Gauss function (Fig.2) (in OSLO actual PSF shapes’s data can be extracted but anyways) then the sagittal PSF for a range of wavelengths will be a Gauss function as well with its Full Width Half Maximum (FWHM) calculated using (5) (Fig.3). FWHM is the spot size.

    • With a known frequency for the Modulation Transfer Function (MTF) at the value of 1/2 level FWHM for a single wavelength is calculated with (1)-(4) (Fig.3)

    • The final Error Function is shown in (6) (Fig.4). Its value is set as a user-defined operand for minimization (note: the value does not tend to zero).

    • The 4th power is used to be able to improve the worst parameters in the first place
    Fig.4 Error Function

    Fig.4 Error Function

    Data

    • Distortion has not been added yet to the script that sets optimization operands
    • Half of the FoV is manually picked at the moment and is 38°
    • Field angles are picked to split the circular area of the image plane into the rings (circle in the center) of equal area
    • N=6
    i αi, rad cos(αi)
    1 0.0000 1.0000
    2 0.2513 0.9686
    3 0.3554 0.9375
    4 0.4353 0.9067
    5 0.5027 0.8763
    6(N) 0.5620 0.8462
    Pixel's filter color λpeak,nm range,nm
    green 530 510-560
    red 600 585-655
    blue 450 420-480

    Links

    1. The script to set user-defined custom operands before running optimization in OSLO: set_elphel_operands.ccl

    by Oleg Dzhimiev at July 02, 2014 02:05 AM

    June 30, 2014

    Elphel

    Open Hardware Lens for Eyesis4π camera

    initial_design_snapshot_2

     

    Elphel has embarked on a new project, somewhat different from our main field of designing digital cameras, but closely related to the camera applications and aimed to further improve image quality of Eyesis4π camera. Eyesis4π is a high resolution full-sphere panoramic and stereophotogrammetric camera. It is a tiled multi-sensor system with a single sensor’s format of 1/2.5″. The specific requirement of such system is uniform angular resolution, since there is no center in a panoramic image.

    Current lens

    Fig.1. Sensors layout

    Fig.1. Eyesis4π modules layout

    Lens selection for the camera was dictated by small form factor among other parameters and after testing a dozen of different lenses we have selected N125B04518IR, by Evetar, to be used in Eyesis4π panoramic camera. It is M12 mount (also called board lens), EFL=4.5mm, F/1.8 lens with the same 1/2.5″ format as camera’s sensor. This sensor is perfected by volume production and wide use in security and machine vision applications, which contributed to it’s high performance at a relatively low price. At the same time the price-quality balance for board lenses has mostly shifted to the lower price, and while these lenses provide good quality in the center of the image the resolution in the corners is lower and aberrations are worse. Each lens of the same model is slightly different from another, it’s overall resolution, resolution in the corners, and aberrations vary, so we have developed a more or less universal method to measure the optical parameters of the sensor-lens module that allows us to select the best lenses from a received batch. This helped us to formulate quantitative parameters to compare lens performance for our application. We have also researched other options. For example, there are compact lenses for smaller formats (used in smartphones) but most, if not all of them are designed to be integrated with the device. On the consumer cameras side better lenses are mostly designed for formats of at least 3/4″. C-mount lenses we use with other Elphel camera models are too large for Eyesis4π panoramic camera sensor-lens module layout.

    Lens with high resolution over the Full Field of View

    In panoramic application and other multi-sensor tiled cameras we are designing the center can be set anywhere and none of the board lenses (and other lenses) we have tested could provide the desirable uniform angular resolution. Thus there is a strong interest to have the lens designed in response to panoramic application requirements. Our first approach was to order custom design from lens manufacturers, but it proved to be rather difficult to specify the lens parameters, based on a standard specifications list we were offered to fill out. The following table describes basic parameters for the initial lens design:
    Parameter Description
    Mount S-mount (M12x0.5)
    Size compact (fit in the barrel of the current lens)
    Format 1/2.5"
    Field of View V: 51°, H: 65°, D: 77°
    F# f/1.8
    EFL 4-4.5 mm (maybe 4.8)
    Distortion barrel type
    Field Curvature undercorrected (a field flattener will be used)
    Aberrations as low as possible
    The designed lens will be subjected to the tests similar to the ones we use in actual camera calibration before it is manufactured. This way we can simulate the virtual optical design and make corrections based on it’s performance, to ensure that the designed lens satisfies our requirements before we even have the prototype. To be able to do that we realized that we need to be involved in the lens design process much more then just provide the manufacturer our list of specifications. Not having an optical engineer on board (although Andrey had majored in Optics at Moscow Institute for Physics and Technology, but worked only with laser components, and has no actual experience of lens design) we decided to get professional help from Optics For Hire with initial lens design and meanwhile getting familiar with optical design software (OSLO 6.6) – trying to create an error (merit) function that formalizes our requirements. In short, the goal is to minimize the RMS of squared spot sizes (averaging 4th power) over the full field of view taking into account the pixel’s spectral range. Right now we are trying to implement custom operands for minimization using OSLO software.

    Feedback is welcome

    initial_design_snapshot

    Fig.2 Online demo snapshot

    As always with Elphel developments the lens design will be published under CERN Open Hardware License v1.2 and available on github – some early files are already there. We would like to invite feedback from people who are experienced in optical design to help us to find new solutions and avoid mistakes. To make it easier to participate in our efforts we are working on the online demonstration page that helps to visualize optical designs created in Zemax and OSLO. Once the lens design is finished it will be measured using Elphel set-up and software and measurement results will be also published. Other developers can use this project to create derivative designs , optimized for other applications and lens manufacturers can produce this lens as is, according to the freedoms of CERN OHL.

    Links

    1. Eyesis4π
    2. Lens measurement and correction technique
    3. Optical Design Viewer: onlinegithub
    4. Optics For Hire company – Optical Design Consultants for Custom Lens Design
    5. Initial optical design files

    by Oleg Dzhimiev at June 30, 2014 09:19 PM

    June 27, 2014

    Bunnie Studios

    Name that Ware June 2014

    The Ware for June 2014 is shown below.

    This is a reader-submitted ware, but the submitter requested to remain anonymous. Thanks, though, you know who you are!

    by bunnie at June 27, 2014 11:42 AM

    Winner, Name that Ware May 2014

    The Ware for May 2014 was a “screamer tag” from Checkpoint Systems. The board bears the silkscreen markings “SC-TG001 Ver05″, and was made by the Kojin Company for use in Japan. Presumably, this tag is part of an anti-theft system that activates an alarm when connectivity between a pair of contacts, visible in the photo, is broken; or if a signal is received (or lost) via RF.

    A lot of good and very close guesses this time, but I’ll have to hand the prize to Hugo for naming the function quite explicitly. Congrats, email me for your prize!

    by bunnie at June 27, 2014 11:42 AM

    June 25, 2014

    Altus Metrum

    keithp&#x27;s rocket blog: Altos1.4.1

    AltOS 1.4.1 — Fix ups for 1.4

    Bdale and I are pleased to announce the release of AltOS version 1.4.1.

    AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.

    This is a minor release of AltOS, incorporating a small handful of build and install issues. No new features have been added, and the only firmware change was to make sure that updated TeleMetrum v2.0 firmware is included in this release.

    AltOS — TeleMetrum v2.0 firmware included

    AltOS version 1.4 shipped without updated firmware for TeleMetrum v2.0. There are a couple of useful new features and bug fixes in that version, so if you have a TeleMetrum v2.0 board with older firmware, you should download this release and update it.

    AltosUI and TeleGPS — Signed Windows Drivers, faster maps downloading

    We finally figured out how to get our Windows drivers signed making it easier for Windows 7 and 8 users to install our software and use our devices.

    Also for Windows users, we’ve fixed the Java version detection so that if you have Java 8 already installed, AltOS and TeleGPS won’t try to download Java 7 and install that. We also fixed the Java download path so that if you have no Java installed, we’ll download a working version of Java 6 instead of using an invalid Java 7 download URL.

    Finally, for everyone, we fixed maps downloading to use the authorized Google API key method for getting map tiles. This makes map downloading faster and more reliable.

    Thanks for flying with Altus Metrum!

    June 25, 2014 05:35 AM

    June 21, 2014

    Elphel

    DDR3 Memory Interface on Xilinx Zynq SOC – Free Software Compatible

    External memory controller is an important part of many FPGA-centered designs, it is true for Elphel cameras too. When I was working on the board design for NC393 I tried to verify inteface pinout using the code output from the MIG (Memory Interface Generator) module. I was planning to use MIG code as a reference design and customize it for application in the camera, adding more functionality to our previous designs. Memory interface is a rather intimate part of the design where FPGA approach can shine it all its glory – advance knowledge of the types of needed memory transactions (in contrast with the general CPU system memory) helps to increase performance by planning bank and address sequences, crafting memory mapping to utilize close to 100% of the bus bandwidth.
    eddr3_bdiag

    Fig. 1. DDR3 memory controller block diagram, source code at https://github.com/Elphel/eddr3

    Why new DDR3 controller when Xilinx provides MIG?

    That was my original plan, but MIG  code used 6 undocumented modules (PHASER_*,PHY_CONTROL) and four more (ISERDESE2,OSERDESE2,IN_FIFO and OUT_FIFO) that are only partially documented and the source code of the simulation modules is not available to Xilinx users. This means that MIG as it is currently provided by Xilinx does not satisfy our requirements. It would prevent our customers from simulating Elphel code with Free Software tools, and it also would not allow us to develop efficient code ourselves. Developing HDL code, troubleshooting complex cases through simulation is a rather challenging task already, guessing what is going on inside the “black boxes” without the possibility to at least add some debug output there – it would be a nightmare. Why does the signal differs from what I expected – is it one of my stupid assumptions that are wrong in this case? Did I understand documentation incorrectly? Or is there just a bug in that secret no-source-code module? I browsed the Internet support forums and found that yes, there are in fact cases where users have questions about the simulation of the encrypted modules but I could not find clear answers to them. And it is understandable – it is usually difficult to help with the design made by somebody else, especially when that encrypted black box is connected to the customer code that differs from what black box developers had in mind themselves.

    Does that mean that Zynq SOC is completely useless for Elphel projects?

    Efficient connection to the dedicated (not shared with the CPU) high performance memory is a strict requirement for Elphel products and Xilinx FPGA were always very instrumental in achieving this goal. Through more than a decade of developing cameras based on Xilinx programmable logic our cameras used SDR, then DDR and later DDR2 memory devices.  After discovering  that while advancing silicon technology Xilinx made a step back in the quality of the documentation and simulation support I analyzed the set of still usable modules and features of this new device to see if they alone are sufficient for our requirements. The most important are serializer, deserializer and programmable delay elements (in both input and output directions)  on each I/O pin connected to the memory device, and Xilinx Zynq does provide them. The OSERDES2 and ISERDESE2 (serializer and deserializer modules in Xilinx Zynq) can not be simulated with Free Software tools directly as they depend on encrypted code, but their functionality (without undocumented MEMORY_DDR3 mode) matches that of Xilinx Virtex 6 devices. So with the simple wrapper modules that switch between the *SERDESE2 for synthesis with Xilinx tools and *SERDESE1 for simulation with Icarus Verilog simulator that problem was solved. Input/output delay modules have their HDL source available and did not cause any simulation problems, so the minimal requirements were met and the project goals seemed possible to achieve.

    DDR3 memory interface requirements

    Looking at the Xilinx MIG implementation I compared it with our requirements and I’ve got an impression it tried to be the single universal solution for every possible application. I do not agree with such approach that contradicts the very essence of the FPGA solutions – possibility to generate “hardware” that best suits the custom application. Some universal high-level hard modules enhance bare FPGA fabric – such elements as RAM blocks, DSP, CPU – these units being specialized lost some of their flexibility  (compared to  than arbitrary HDL code)  but became adopted by the  industry and users as they offer high performance while maintaining reasonable universality – same modules can be reused in numerous applications developed by users. The lack of possibility to modify hard modules beyond provided configurable options comes as understandable price for performance – these limitations are imposed by the nature of the technology, not by the bad (or good – trying to keep inexperienced developers away from the dangers of the unrestricted FPGA design) will of the vendors. Below is the table that compares our requirements (and acceptable limitations) of the DDR3 memory interface in comparison with Xilinx MIG solution.

    Feature comparison table

    Feature MIG eddr3 notes
    Usable banks HP,HR HP only HR I/O do not support output delays and limit DCI
    Data width any 16 bits Data width can be manually modified
    Multi-rank support yes no Not required for most applications
    FBG484 single bank no yes MIG does not allow 256Mx16 memory use one bank in FBG484 package
    Access type any block oriented Overlapping between accesses may may be disregarded
    R/W activity on-the-fly pre-calculated Bank mapping, access sequences pre-calculated in advance
    Initialization, leveling hardware software Infrequent procedures implemented in software
    Undocumented features yes no Difficult to debug the code
    Encrypted modules yes no Impossible to simulate with Free Software tools, difficult to debug
    License proprietary GNU GPLv3.0+ Proprietary license complicates distribution of derivative code

    Usable I/O banks

    Accepting HR or “high (voltage) range” banks for memory interfacing lead MIG to sacrifice the ODELAYE2 blocks that are available in HP (“high performance”) banks only. And we did not have this limitation, as the DDR3 chip was already connected to HP bank. I believe it is true for other designs too – it makes sense do follow the bank specialization and use memory with HP banks and reserve HR for other application (like I/O) where the higher voltage range is actually needed.

    Block accesses only

    Another consideration is that having abundance of 32Kb block memory resources in the FPGA and parallel processing nature of the programmable logic, the small memory accesses are not likely, many applications do not need to bother with reduced burst sizes, data byte masking or even back-to-back reads and writes. In our applications we use 1/4 of the BRAM size transfers in most cases (1/4 comes from having a 4-page buffer at each channel to implement simple 2-level prioritizing between multiple channels. Block access does not have to be limited to memory pages – it can be any large predefined sequences of data transfer.

    Hardware vs software implementation of infrequent actions

    MIG feature that I think leads to unneeded complication – everything is done in “hardware”, even write leveling and temperature compensation from the on-chip temperature sensor. I was once impressed by the circuit diagram of Apple ][ computer, and learned a lesson that you do not need to waste special hardware resources on what easily can be done in software without significant sacrifice of performance. Especially in the case of a SOC like Zynq where a high-performance dual-core processor is available. Algorithms that need to run once at start-up and very infrequently during operation (temperature correction) can easily be implemented in software. The memory controller implemented in PL is initialized when the system is fully loaded, so initialization and training can be performed when the full software is available, it is not as system memory that has to be operational from the early boot stage.

    Computation of the access sequences in advance

    When dealing with the multi-channel block access (blocks do not need to be the same size and shape) in the camera, it is acceptable to have an extra latency comparable to the block read/write time, that allowed to simplify the design (and make it more flexible at the same time) by splitting generation and execution of the block access sequences in two separate processes. The physical interface sequencer reads the commands, memory addresses and control signals (as well as channel buffer read/write enable from the block memory, the sequence data is prepared in advance from 2 sources: custom PL circuitry that calculates the next block access sequence and loaded directly by the software over AXI channel (refresh, calibrate ZQ, write leveling and other delay measurement/adjustment sequences)

    No multi-rank

    Another simplification - I did not plan to use multi-rank systems, supplementing FPGA with just one (or several, but just to increase data width/bandwidth, not the depth/capacity) high performance memory chip is a most common configuration. Internal data paths of the programmable logic have so much higher bandwidth than the connection to an external memory, that when several memory chips are used they are usually connected to achieve the highest possible bandwidth. Of course, these considerations are usually, but not always valid. And the FPGA are very good for creating custom solutions for particular cases, not just "one size fits all".

    DDR3 Interface Implementation

    Fig. 1 shows simplified block diagram of the eddr3 project module. It uses just one block (HP34) for interfacing 512M x 16 DDR3 memory with pinout following Xilinx recommendations for MIG. There are two identical byte lanes each having 8 bidirectional data signals running in DDR mode (DQ[0]..DQ[7] and DQ[8]..DQ[15] – only two bits per lane are shown on the diagram), one bidirectional differential DQS. There is also data mask (DM) signal in each byte lane – it is similar to DQ without input signal, and while it is supported in the physical level of the interface, it is not currently used on a higher level of the controller. There is also a differential driver for the memory clock input (CLK,~CLK) and address/command signals that are output only and run in SDR mode at the clock rate.

    I/O ports

    Data bit I/O buffers (IOBUF_DCIEN modules) are directly connected to the I/O pads produce read data outputs feeding IDELAYE2 modules, have data inputs for the write data coming form ODELAYE2 modules, output tristate control and DCI enable inputs. There is only one output delay unit per bit, so tristate control has to come directly from the OSERDESE2 module, but that is OK as the it is still possible to meet the memory requirements when controlling tristate at clock half-period granularity, even when switching between read and write commands. But in the block-oriented memory access in the camera it is even easier as there are no back-to-back read to write accesses. DCIEN control is even less timing critical – basically it is just a power reduction feature so turning it off later and turning on earlier than needed is acceptable. This signal  is controlled with the clock period granularity, same as address/command signals.

    Delay elements

    ODELAYE2 and IDEALYE2  provide 5-bit (31-tap) programmable delays  with  78 ps/tap resolution for 200MHz calibration and 52 ps tap for 300MHz one. The device I have on the prototype board has speed grade 1 so I was limited to 200MHz only (300MHz option is only available for the speed grade 2 or higher devices). From the tools output I noticed that these primitives have *_FINEDELAY option and while these primitives are not documented in Libraries Guide they are in fact available in unisims library so I decided to take a risk and try them, tools happily accepted such code. According to the code FINEDELAY option provides additional stage with five levels of delay with uncalibrated 10 ps step and just static multiplexer control though the 3 inputs. It will be great if Xilinx will add 3 more taps to use all 3 bits of fine delay value  the delay range of this stage will cover the full distance between the outputs of the main (31-tap) delay. It is OK if the combined 8-bit (5+3) delay will not provide monotonic results, that can be handled by the software in most cases. With current hardware the maximal delay of the fine stage only reaches the middle between the main stage taps (4*10 ps ~= 78 ps/2), so it adds just one extra bit of resolution, but even that one bit is very helpful in interfacing DDR3 memory. The actual hardware measurements confirmed that the fine delay stage functions as expected and that there are only 5 steps there. Fine delay stage does not have memory registers to support load/set operations as the main stage, so I added it with additional HDL code. The fine delay mode applies to all IDEALYE2 and ODELAYE2 block shown on the diagram, each 8-bit delay value is individually loaded by software through MAXIGP0 channel, additional write sets all the delays simultaneously.

    Source-synchronous clocks

    Received DQS signal in each byte lane goes through input delay and then drives BUFR primitive that in turn provides input clock to all data bit ISERDESE2 modules in the same byte lane. I tried to use BUFIO for that purpose, but the tools did not agree with me.

    Serializers and deserializers, clocks

    The two other clocks driving ISERDESE2 and OSERDESE2 (they have to be the same for input and output paths) are generated by the MMCME2_ADV module. One of them is the full memory clock rate, the other has half frequency. The same MMCME2_ADV module generates another half frequency clock that through the global buffer BUFG drives the rest the controller, registers are inserted in the data paths crossing clock domains to compensate for possible phase variations between BUFG and BUFR. Additional output drives memory clock input pair, MMCME2_ADV dynamically phase shifts all the other outputs but this one, effectively adding one extra degree of freedom for meeting write leveling requirements (zero phase shift between clock and DQS outputs). This clock control is implemented in phy_top.v module.

    I/O delay calibration

    PLLE2_BASE is used to generate 200MHz used for calibration of the input/output delays by the instance of IDELAYCTRL primitive.

    PHY control sequencer

    The control signals: memory addresses/bank addresses, commands, read/write enable signals to channel data buffers are generated by the sequencer module running at half of the memory clock, so the width of data read/write to the data buffers is 64 bits for 16 bit DDR3 memory bus. Sequencer data is encoded as 32-bit words and is provided by the multiplexed output from the read port of one of the two parallel memory blocks. One of these block is written by software, the other one is calculated in the fabric. Primary application is to read/write block data to/from multiple concurrent channels (for NC393 camera we plan to use 16 such channels), and with each channel buffer accommodating 4 blocks it is acceptable to have significant latency in the data channels. And I decided to calculate the control data separately from accessing the memory, not to do that on-the-fly. That simplifies the logic, adds flexibility to optimize sequences and with software programmable memory it simplifies evaluation of different accesses without reconfiguring the FPGA fabric. In the current implementation only one non-NOP command can be issued in the sequencer 2-clock time slot, but which clock to use – first or second is controlled by a program word bit individually for each slot. Another bit adds a NOP cycle after the current command, this is used for bulk of the read/write commands for consecutive burst of 8 accesses. When the sequencer command is NOP the address fields are re-used to specify duration of the pause and the end-of-sequence flag.

    CPU interface, AXI port

    Initial implementation goal was just to test the memory interface, it has only two (instead of 16) memory access channels – program read and program write data, and there is only one of the two sequencer memory banks (also programmed by the software), the only asynchronously  running channel is memory refresh channel. All the communications are performed over AXI PS Master GP0 channel with memory mapped addresses for the controller configuration, delays and MMCM phase set up, access to the sequencer and data memory. All the internal clocks are derived from a single (currently 50MHz) FCLKCLK[0] clock coming from the PS7 module (PS-PL bridge), EMIO pins are used for debugging only.

    EDDR3 Performance Evaluation

    Current implementation uses internal Vref and the Zynq datasheet specifies the maximal clock rate 400MHz (800 Mb/s) rate so I started evaluation at the same frequency. But the memory chip connected to Zynq is Micron MT41K256M16HA-107:E (same as the other two used for the system memory) capable of running at 933MHz, so the plan was to increase the operational frequency later, so 400 MHz clock (1600MB/s for x16 memory) is sufficient just to start porting our earlier camera functionality to the Zynq-based NC393. Initial settings for all output and I/O ports SLEW is “SLOW” so the inter-symbol interference should reveal itself at lower frequencies during evaluation. Power supply voltage  for the HP34 port and memory device is set to 1.5V, hardware allows to reduce it to 1.35V so later we plan to evaluate 1.35V performance also. Performance measurements are implemented as a Python script (it does not look like Pythonian, most of the text was just edited from the Verilog text fixture used for simulation) running on the target system, the results were imported into Libreoffice Calc spreadsheet program to create eye diagram plots. Python script directly accesses memory-mapped AXI PS Master GP0 port to read/write data, no custom kernel space drivers were needed for this project. Both simulation test fixture and the Python script programmed delay values, controller modes and created sequence data for memory initialization, refresh, write leveling, fixed pattern reading, block write and block read operations. For eye pattern generation one of the delay values was scanned over the available range, randomly generated 512 byte block of data was written and then read back. Then the read data was compared  to the one written, each of the 4096 bits in a block was assigned  a group depending on the previous, current and next bit written to the same DQ signal. These groups are shown on the next plots, marked in the legend as binary strings, “001″ means that previous written bit was “0″, current one is also “0″ and the next one will be “1″.  Then the read data was averaged in each block per each of 8 groups, first for each DQ individually and averaged between all of the 16 DQ signals. The delays scanned over 32 values of the main delays and 5 values of fine delays for each, the relative weight of fine delays was calculated from the measured data and used in the final plots.
    DQ input delay common for all bits, DQS input delay variable

    Fig. 2. DQ input delay common for all bits, DQS input delay variable

    DQ and DQS input delay selection by reading fixed pattern from memory

    First I selected initial values for DQ and DQS input delays reading fixed pattern data form the memory – that mode eliminates dependence on write operation errors, but does not allow testing over the random data, each bit toggles simultaneously between zero and one. This is a special mode of DDR3 memory devices activated by control bits in the MR3 mode register, reading this pattern does not require activation or any other commands before issuing READ command.

    Scanning DQS input delay with fixed DQ input delay using randomly generated data

    DQ delays can scan over the full period, but DQS input delay has certain timing dependence on the pair of output clock. Fig. 2. illustrates this – the first transition centered at ~150 ps is caused by the relative input delays of DQ and DQS. Data strobe latches mostly previous bit at delays around 0 and correctly latches the current bit for delays form 400 to 1150 ps, then switches to the next bit. And at around the same delay of 1300 ps the iclk to oclk timing in ISERDESE2 is not satisfied causing errors not related to DQ to DQS timing. The wide transition at 150 ps is caused by a mismatch between individual bit delays, when those individual bits are aligned (Fig. 4) the transition is narrower.
    Fig. 3. Alignment of individual DQ input delays using 90-degree shifted DQS delay

    Fig. 3. Alignment of individual DQ input delays using 90-degree shifted DQS delay

    Aligning individual DQ input delay values

    For aligning individual DQ input delays (Fig. 3) I programmed DQS 90 degrees offset from the eye center of Fig. 2, and find the delay value for each bit that provides the closest to 50% value. Scanning takes over both main (32 steps) and fine (5 steps) delays, there are no special requirements on the relative weights of the two, no need for the combined 8-bit delay to be monotonic. This eye patter doe not have an abnormality similar to the one for DQS input delay, the result plot only depends on DQ to DQS delay, there are no additional timing requirements. The transition ranges are wide, plot averages results from all individual bits, alignment process uses individual bits data.
    Fig.4. DQ input delays aligned, DQS input delay variable

    Fig.4. DQ input delays aligned, DQS input delay variable

    Scanning over DQS input delay with DQ input delays aligned

    After finishing individual data bits (DQ) input delays alignment I measured the eye pattern for DQS input delay again. This time the eye opened more as one of the sources of errors was greatly diminished. Valid data is now from 100 ps to 1050 ps and DQS delay can be set to 575 ps in the center between the two transitions. At the same time there is more than 90 degrees phase shift of the DQS from the value when iclk to oclk delay causes errors. Fig.4. also shows that (at ~1150 ps) there is very little difference between 010 and 110 patterns, same for 001 and 101 pair. That means that inter-symbol interference is low and the bandwidth of the read data transfer is high so the data rate can likely be significantly increased.

    Evaluation of memory WRITE operations

    When data is written to memory DDR3 device is expecting certain (90 degree shift) timing relation between DQS output and DQ signals. And similar to the read operation there are additional restrictions on the DQS timing itself. The read DQS timing restrictions were imposed by the ISERDESE2 modules, in the case of write the DQS timing requirements come form the memory device – DQS should be nominally aligned to the clock on the input pads of the memory device. And there is a special mode supported by DDR3 memory devices to facilitate this process – “write leveling” mode – the only mode when memory uses DQS as input (as in WRITE modes) and drives DQ as outputs (as in READ mode), with least significant bit in each byte lane signals the level of clock signal at DQS rising edge. By varying the DQS phase and reading data it is possible to find the proper delay of the DQS output, additionally the relative memory clock phase is controlled by the programmable delay in the  MMCME2_ADV module.
    Fig. 5. DQ output delay common for all bits, DQS output delay variable

    Fig. 5. DQ output delay common for all bits, DQS output delay variable

    Scanning over DQS output delay with the individual DQ output delays programmed to the same value

    With the DQ and DQS  input delays determined earlier and set to the middle of the respective ranges it is possible to use random data writing to memory for evaluation of the eye patterns for WRITE mode. Fig. 5. shows the result of scanning of the DQS output delay over the full available range while all the DQ output delays were set to the same value of 1400 ps. The optimal DQS output delay value determined by write leveling was 775 ps. The plot shows the only abnormality at ~2300 ps caused by a gross violation of the write leveling timing, but this delay is far from the area of interest and results show that it is safe to program the DQS delay off by 90 degrees from the final value for the purpose of aligning DQ delays to each other.
    Fig. 6. Alignment of individual DQ output delays using 90-degree shifted DQS output delay

    Fig. 6. Alignment of individual DQ output delays using 90-degree shifted DQS output delay

    Aligning individual DQ output delay values

    The output delay of the individual DQ signals is adjusted similarly  to how it was done for the input delays. The DQS output delay was programmed with 90 degree offset to the required value (1400 ps instead of 775 ps) and each data bit output delay was set to the value that results in as close to 50% as possible. This condition is achieved around 1450 ps as shown on the Fig. 6. 50% level at low delays (<150 ps) on the plot comes from the fact that the bit “history” is followed to only 1 before the current, and the range of the Fig. 6 is not centered around the current bit, it covers the range of two bits before current, 1 bit before current and the current bit. And as two bits before current are not considered, the result is the average of approximately equal probabilities of one and zero.
    Fig.7. DQ output delays aligned, DQS output delay variable

    Fig.7. DQ output delays aligned, DQS output delay variable

    Scanning over DQS output delays with the individual data bits aligned

    When the individual bit output delays are aligned, it is possible to re-scan the eye pattern over variable DQS output delays, the results are shown on Fig. 7. Comparing it with Fig. 5 you may see that improvement is very small,  the width of the first transition is virtually the same and on the second transition (around 1500 ps) the individual curves while being “sharper” do not match each other (o10 does not match 110 and 001 does not match 101). This means that there is significant inter-symbol interference (previous bit value influences the next one). There is no split between individual curves around the first transition (~200 ps), but that is just because the history is not followed that far and the result averages both variants, causing the increased width of the individual curves transitions compared to the 1500 ps area. But we used SLEW=”SLOW”  for all memory interface outputs in this setup. This it is quite adequate for the 400MHz (800Mb/s) clock rate to reduce the power consumption, but this option will not work when we will increase the clock rate in the future. Then the SLEW=”FAST” will be the only option.

    Software Tools Used

    This project used various software tools for development.
    • Icarus Verilog provided simulation engine. I used the latest version from the Github  repository and had to make minor changes to make it work with the project
    • GTKWave for viewing simulation results
    • Xilinx Vivado and Xilinx ISE WebPack Edition for synthesis, place and route and other implementation tasks. To my personal opinion Xilinx ISE still provides better explanation of what it does during synthesis than newer Vivado, for example – why did it remove some of the register bits. So I was debugging code with ISE first, then later running Vivado tools for the final bitstream generation
    • Micron Technology DDR3 SDRAM Verilog Model
    • Eclipse IDE (4.3 Kepler) as the development environment to integrate all the other tools
    • Python programming language and PyDev – Python development plugin for Eclipse
    • VDT plugin for Eclipse (documentation) including the modified version of VEditor. This plugin (currently working for Verilog, tested on GNU Linux and Mac) implements support for Tool Specification Language (TSL) and enables easy integration of the 3rd party tools with support of custom message parsing. I’ll write a separate blog post about this tool, this current eddr3 project is the first one to test VDT plugin in real action.
    vdt_screenshot07

    Fig. 8. VDT plugin screenshot with eddr3 project opened

    Conclusions

    The eddr3 project demonstrated performance that makes it suitable for Elphel NC393 camera system, successfully implementing DDR3 memory interface to the 512Mx16 device (Micron MT41K256M16HA-107:E) in a single HP34 bank of Xilinx XC7Z030-1FBG484C. The initial data rate equals to the maximal recommended by Xilinx for the hardware setup (using internal Vref) providing 1600MB/s data bandwidth, design uses the SLEW=”SLOW” on all control and data outputs. Evaluation of the performance suggests that it is possible to increase the data rate, probably to above the 3GB/s for the same configuration. The design was simulated using exclusively Free Software tools without any use of encrypted or undocumented features.

    by andrey at June 21, 2014 12:36 AM

    June 18, 2014

    Altus Metrum

    keithp&#x27;s rocket blog: TeleGPS-Battery-Life

    TeleGPS Battery Life

    I charged up one of the “160mAh” batteries that we sell. (The ones we’ve got now are labeled 200mAh; the 160mAh rating is something like a minimum that we expect to be able to ever get at that size.)

    I connected the battery to a TeleGPS board, hooked up a telemetry monitoring setup on my laptop and set the device in the window of my office. This let me watch the battery voltage through the day without interrupting my other work. Of course, because the telemetry was logged to a file, I’ve now got a complete plot of the voltage data:

    It looks like a pretty typical lithium polymer discharge graph; slightly faster drop from the 4.1V full charge voltage down to about 3.9V, then a gradual drop to 3.65 at which point it starts to dive as the battery is nearly discharged.

    Because we run the electronics at 3.3V, and the LDO has a dropout of about 100mV, it’s best if the battery stays above 3.4V. That occurred at around 21500 seconds of run time, or almost exactly six hours.

    We also have an “850mAh” battery in the shop; I’d expect that to last a bit more than four times as long, or about a day. Maybe I’ll get bored enough at some point to hook one up and verify that guess.

    June 18, 2014 02:23 AM

    June 17, 2014

    Richard Hughes, ColorHug

    DNF v.s. Yum

    A lot has been said on fedora-devel in the last few weeks about DNF and Yum. I thought it might be useful to contribute my own views, considering I’ve spent the last half-decade consuming the internal Yum API and the last couple of years helping to design the replacement with about half a dozen of the packaging team here at Red Hat. I’m also a person who unsuccessfully tried to replace Yum completely with Zif in fedora a few years ago, so I know quite a bit about packaging systems and metadata parsing.

    From my point of view, the hawkey depsolving library that DNF is designed upon is well designed, optimised and itself built on a successful low-level SAT library that SUSE has been using for years on production level workloads. The downloading and metadata parsing component used by DNF, librepo, is also well designed and complements the hawkey API nicely.

    Rather than use the DNF framework directly, PackageKit uses librepo and hawkey to share 80% of the mechanism between PK and DNF. From what I’ve seen of the DNF codebase it’s nice, with unit tests and lots of the older compatibility cruft removed and the only reason it’s not used in PK was that the daemon is written in C and didn’t want to marshal everything via python for latency reasons.

    So, from my point of view, DNF is a new command line tool built on 3 new libraries. It’s history may be of a fork from yum, but it resembles more of a 2014 rebuilt American hot-rod with all new motor-sport parts apart from the 1965 modified and strengthened chassis. Renaming DNF to Yum2 would be entirely the wrong message; it’s a new project with a new team and new goals.

    by hughsie at June 17, 2014 03:12 PM

    Video Circuits

    Étienne-Jules Marey & Georges Demeny

    Marey & Demeny both photographers and inventors in France, working at the same time as Muybridge (and perhaps even more pioneering!) established a programme of research which was to lead to the creation of the ‘Station Physiologique' where they would use a variety of methods to visually record and study various kinds of movement. This was all going on at the dawn of film and many of their inventions were precursors or direct ancestors of the standard film camera and projector. They also recorded some images of sound , data and movement as light which is what I am interested in (see this post on early sound visualization/ photoacoustics)














    http://en.wikipedia.org/wiki/%C3%89tienne-Jules_Marey http://en.wikipedia.org/wiki/Georges_Demen%C3%BF http://www.lumen.nu/rekveld/wp/?p=411 https://sites.google.com/site/drtrippy/chronophotography http://www.mpiwg-berlin.mpg.de/resrep00_01/Jahresbericht_2_3_section.html http://www.cinematheque.fr/marey/abecedaire/abecedaire-m/muscle.html http://victorian-cinema.net/demeny http://lightpaintingphotography.com/light-painting-history/

    by Chris (noreply@blogger.com) at June 17, 2014 12:59 PM

    Free Electrons

    Embedded Linux course in Madrid – July 7-11

    We are happy to announce a new Embedded Linux training course on July 7-11, in Madrid, Spain.

    It is organized by our partners ISEE (the makers of the IGEPv2 board that we are using in this course), and Silica, a well known component is distributor who is welcoming the session in its offices in Madrid.

    The course will be instructed in English by our trainer Marcin Bis. Marcin Bis

    The registrations are directly handled by ISEE. See the flyer (document in Spanish) for this session for all practical details and for registration details.

    by Michael Opdenacker at June 17, 2014 09:11 AM

    June 16, 2014

    Richard Hughes, ColorHug

    datarootdir v.s. datadir

    Public Service Announcement: Debian helpfully defines datadir to be /usr/share/games for some packages, which means that the AppData and MetaInfo files get installed into /usr/share/games/appdata which isn’t picked up by the metadata parsers.

    It’s probably safer to install the AppData files into $datarootdir/appdata as this will work even if a distro has redefined datadir to be something slightly odd. I’ve changed the examples on the AppData page, but if you maintain a game on Debian with AppData then this might affect you when Debian starts extracting AppSpream metadata in the next few weeks. Anyone affected will be getting email in the next few days, although it only looks to affect very few people.

    by hughsie at June 16, 2014 03:52 PM

    Altus Metrum

    keithp&#x27;s rocket blog: Altos1.4

    AltOS 1.4 — TeleGPS support, features and bug fixes

    Bdale and I are pleased to announce the release of AltOS version 1.4.

    AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.

    This is a major release of AltOS, including support for our new TeleGPS board and a host of new features and bug fixes

    AltOS Firmware — TeleGPS added, new features and fixes

    Our new tracker, TeleGPS, works quite differently than a flight computer

    • Starts tracking and logging at power-on

    • Disables RF and logging only when connected to USB

    • Doesn’t log position when it isn’t moving for a long time.

    TeleGPS transmits our digital telemetry protocol, APRS and radio direction finding beacons.

    For TeleMega, we’ve made the firing time for the additional pyro channels (A-D) configurable, in case the default (50ms) isn’t long enough.

    AltOS Beeping Changes

    The three-beep startup tones have been replaced with a report of the current battery voltage. This is nice on all of the board, but particularly useful with EasyMini which doesn’t have the benefit of telemetry reporting its state.

    We also changed the other state tones to “Farnsworth” spacing. This makes them all faster, and easier to distinguish from the numeric reports of voltage and altitude.

    Finally, we’ve added the ability to change the frequency of the beeper tones. This is nice when you have two Altus Metrum flight computers in the same ebay and want to be able to tell the beeps apart.

    AltOS Bug Fixes

    Fixed a bug which prevented you from using TeleMega’s extra pyro channel ‘Flight State After’ configuration value.

    AltOS 1.3.2 on TeleMetrum v2.0 and TeleMega would reset the flight number to 2 after erasing flights; that’s been fixed.

    AltosUI — New Maps, igniter tab and a few fixes

    With TeleGPS tracks now potentially ranging over a much wider area than a typical rocket flight, the Maps interface has been updated to include zooming and multiple map styles. It also now uses less memory, which should make it work on a wider range of systems.

    For TeleMega, we’ve added an ‘Igniter’ tab to the flight monitor interface so you can check voltages on the extra pyro channels before pushing the button.

    We’re hoping that the new Maps interface will load and run on machines with limited memory for Java applications; please let us know if this changes anything for you.

    TeleGPS — All new application just for TeleGPS

    While TeleGPS shares the same telemetry and data logging capabilities as all of the Altus Metrum flight computers, its use as a tracker is expected to be both broader and simpler than the rocketry-specific systems. We’ve build a custom TeleGPS application that incorporates the mapping and data visualization aspects of AltosUI, but eliminates all of the rocketry-specific flight state tracking.

    June 16, 2014 02:48 AM

    June 13, 2014

    Free Electrons

    Linux 3.15 released, an overview of Free Electrons contributions

    The 3.15 of the Linux kernel was released just a few days ago by Linus Torvalds. As explained by LWN.net, the headline features in 3.15 include some significant memory management improvements, the renameat2() system call, file-private POSIX locks, a new device mapper target called dm-era, faster resume from suspend, and more. One can also read the coverage by LWN.net of the first part and the second part of the merge window to get more details about the major new features in this release.

    As usual, Free Electrons contributed to the Linux kernel during this 3.15 cycle, and with a total of 218 patches contributed, it’s a new record for Free Electrons. According to the KPS statistics, Free Electrons ranked #12 in the list of companies contributing to the Linux kernel for the 3.15 kernel (if you exclude the “Unknown” and “Hobbyists” categories, which aren’t really companies).

    The main features contributed by Free Electrons again centered around the support for ARM processors:

    • By far, the largest contribution this cycle was the initial support for the new Armada 375 and Armada 38x processors from Marvell. Gregory Clement, Ezequiel Garcia and Thomas Petazzoni have been working on the code to support these processors since a few months ago, and started pushing the patches to the public in February this year. For the Marvell Armada 38x processor, it means that the code was pushed in mainline even before the processor was announced publicly! The features supported in 3.15 for these processors are: interrupts, GPIO, clocks, pin-muxing, serial, I2C, SPI, timer, L2 cache, SDIO (only for 375), SATA (only 375), XOR, PCIe, MBus, networking (only for 38x), NOR and NAND support. Many other features such as SMP, I/O coherency and various other peripherals will be supported in 3.16.
    • Convert support for the Atmel AT91SAM9RL processor to the Device Tree, done by Alexandre Belloni.
    • Addition of iio-hwmon to the Freescale i.MX23 and i.MX28 processors, which allows to use the internal temperature sensor of the processor. Done by Alexandre Belloni.
    • Multiple fixes and improvements to the AT91 ADC support. Done by Alexandre Belloni.
    • Support for the watchdog in Armada 370 and Armada XP was added, done by Ezequiel Garcia.
    • A driver for the SPI controller found in Allwinner A31 SoC was added, as well as all the Device Tree information to describe this controller and related clocks. Done by Maxime Ripard.
    • Support for the I2C controller found in the Allwinner A31 SoC was added into the existing mv64xxx-i2c driver, as well as the necessary Device Tree information to use I2C on this SoC. Done by Maxime Ripard.
    • Audio support was enabled on the Armada 370 SoC, re-using existing code for Kirkwood, and therefore making audio work on the Armada 370 DB platform. Done by Thomas Petazzoni.
    • A number of issues in the PCIe support for Marvell processors have been fixed, thanks to the reports from a number of users. Done by Thomas Petazzoni, with help from these users.

    We also contributed other things than just support for ARM processors:

    • The main contribution in this area is the addition of UBI block, a driver that allows to use read-only block filesystems such as squashfs on top of a UBI volume. The code was originally written by David Wagner who was an intern at Free Electrons, and later taken by Ezequiel Garcia who did a lot of additional cleanup work and community discussion to get the driver merged. Some details about this feature can be found in the Linux-MTD documentation.
    • A generic Device Tree binding to express NAND ECC related information in the Device Tree was contributed by Ezequiel Garcia.
    • The quest to remove IRQF_DISABLED continued, by Michael Opdenacker.

    In details, all our contributions are:

    by Thomas Petazzoni at June 13, 2014 01:56 PM

    Marvell publishes the datasheet of the Armada 370 processor

    thumb-armada-xpOver the last two years, Free Electrons has contributed support for the Marvell Armada 370 and Marvell Armada XP processors to the mainline Linux kernel. These ARM processors are used mainly in Network Attached Storage devices but also in other devices such as printers. Until now the datasheet for these processors was only available for Marvell customers and partners under NDA, but last week, Marvell finally released the datasheet of the Armada 370 publicly, with no restriction, no registration, no NDA. The Armada 370 processor can already be found in several consumer grade products:

    From now on, on the Marvell page related to the Armada 3xx family, the Armada 370 Functional Specification as well as the Armada 370 Hardware Specifications can be found. While the Armada XP datasheet is not available at this time, it is worth mentioning that the vast majority of the peripherals are exactly the same between Armada 370 and Armada XP, so even Armada XP users will find useful information in this datasheet.

    Free Electrons is happy to see that Marvell is making more and more progress towards mainlining their kernel support and opening their datasheets publicly. We strongly believe that the openness of these datasheets will allow hobbyists and developers to improve the support for Armada 370 in the open-source ecosystem, be it in the Linux kernel, in bootloaders like U-Boot or Barebox or even in other projects.

    by Thomas Petazzoni at June 13, 2014 05:29 AM

    June 11, 2014

    Richard Hughes, ColorHug

    Application Addons in GNOME Software

    Ever since we rolled out the GNOME Software Center, people have wanted to extend it to do other things. One thing that was very important to the Eclipse developers was a way of adding addons to the main application, which seems a sensible request. We wanted to make this generic enough so that it could be used in gedit and similar modular GNOME and KDE applications. We’ve deliberately not targeted Chrome or Firefox, as these applications will do a much better job compared to the package-centric operation of GNOME Software.

    So. Do you maintain a plugin or extension that should be shown as an addon to an existing desktop application in the software center? If the answer is “no” you can probably stop reading, but otherwise, please create a file something like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <!-- Copyright 2014 Your Name Here <your@email.com> -->
    <component type="addon">
    <id>gedit-code-assistance</id>
    <extends>gedit.desktop</extends>
    <name>Code Assistance</name>
    <summary>Code assistance for C, C++ and Objective-C</summary>
    <url type="homepage">http://projects.gnome.org/gedit</url>
    <metadata_license>CC0-1.0</metadata_license>
    <project_license>GPL-3.0+</project_license>
    <updatecontact>richard_at_hughsie.com</updatecontact>
    </component>
    

    This wants to be installed into /usr/share/appdata/gedit-code-assistance.metainfo.xml — this isn’t just another file format, this is the main component schema used internally by AppStream. Some notes when creating the file:

    • You can use anything as the <id> but it needs to be unique and sensible and also match the .metainfo.xml filename prefix
    • You can use appstream-util validate gedit-code-assistance.metainfo.xml if you install appstream-glib from git.
    • Don’t put the application name you’re extending in the <name> or <summary> tags — so you’d use “Code Assistance” rather than “GEdit Code Assistance
    • You can omit the <url> if it’s the same as the upstream project
    • You don’t need to create the metainfo.xml if the plugin is typically shipped in the same package as the application you’re extending
    • Please use <_name> and <_summary> if you’re using intltool to translate either your desktop file or the existing appdata file and remember to add the file to POTFILES.in if you use one

    Please grab me on IRC if you have any questions or concerns, or leave a comment here. Kalev is currently working on the GNOME Software UI side, and I only finished the metadata extractor for Fedora today, so don’t expect the feature to be visible until GNOME 3.14 and Fedora 21.

    by hughsie at June 11, 2014 04:36 PM

    June 09, 2014

    Altus Metrum

    bdale&#x27;s rocket blog: TeleGPS v1.0

    Keith and I are pleased to announce the immediate availability of TeleGPS v1.0!

    TeleGPS is our response to the many requests we've received for an easy-to-use tracking-only board that just provides GPS position information over radio. Combining the same uBlox Max 7Q GPS receiver used in TeleMega and TeleMetrum v2.0 with a 16mW transmitter yields a board that is 1.5 x 1.0 inches (38.1 x 25.4 mm).

    As usual for our products, TeleGPS is designed for use under FCC Part 97 (ham radio) rules or equivalent authorization. In addition to the GPS receiver and UHF radio transmitter, TeleGPS includes on-board flash data storage and a micro USB connector for configuration, post-flight data download, and to power a LiPo battery charger.

    TeleGPS works with our existing ground station products and/or any radio equipped with APRS support, and also emits audible radio direction finding beeps. While TeleGPS can be used with our existing AltosUI and AltosDroid ground station software, Keith is working on a simpler, dedicated application optimized for use with TeleGPS.

    Altus Metrum products are available directly from Bdale's web store, and from these distributors:

    All Altus Metrum products are completely open hardware and open source. The hardware design details and all source code are openly available for download, and advanced users are invited to join our developer community and help to enhance and extend the system. You can learn more about Altus Metrum products at http://altusmetrum.org.

    Thank you all for your continuing support of Altus Metrum, and we hope to see you on a flight line somewhere soon!

    June 09, 2014 12:53 AM

    June 06, 2014

    Video Circuits

    Live Performance

    So me and Dale played live on tuesday, here are some video and audio shot by Anne.
    Dale plays his cassette tape images as scores that are also instruments, I am generating audio from my modular and video from DIY circuits and a fed back video mixer. I'm playing solo in London on Saturday here .









    by Chris (noreply@blogger.com) at June 06, 2014 04:35 AM

    Film Preservation

    Forgot to post these photos from some amazing training I did. If anyone wants to let me look after their video art, computer art or abstract animation I would be more than happy to help.










    by Chris (noreply@blogger.com) at June 06, 2014 04:08 AM

    May 30, 2014

    Video Circuits

    ANALOG DREAMSCAPE: Video & Computer Art in Chicago 1973-1985

    ANALOG DREAMSCAPE:
    Video & Computer Art in Chicago 1973-1985











    http://www.evl.uic.edu/core.php?mod=4&type=4&indi=919

    Friday, June 13th @ 7pm

    University of Illinois at Chicago

    Institute for the Humanities

    701 South Morgan, Lower Level - Stevenson Hall

    Chicago, IL 60607

    In partnership with the Institute for Humanities at UIC, South Side Projections presents ANALOG DREAMSCAPE, a screening and discussion with Daniel J. Sandin and new media historian Jon Cates. Sandin is a trailblazing video artist and director emeritus of the Electronic Visualization Laboratory (co-founded with Tom DeFanti), an interdisciplinary program at the crossroads of art and computer science. Among his many technological accomplishments is the Sandin Image Processor, and analog video synthesizer made in 1973 with the revolutionary ability to radically manipulate images in real time. An early advocate for the DIY, open source ethos, Sandin made the blueprints of rht Image Processor available to the public so that others could hack his original design. The result was a treasure trove of abstract, psychedelic short films that remain utterly hypnotic three decades later. Similar to contemporary glitch aesthetics, the artwork made with the Image Processor conjures up the unconscious of a circuit board, creating a chromatic blur of geometric shapes and patterns. EVL colleague Larry Cube used technology to creating the 3-D computer models used in the Death Star briefing room sequence of Star Wars: A New Hope. Sandin’s additional credits include the first data glove, a device used to control computers via finger movement, and the CAVE™, and immersive virtual reality environment inspired by the Plato’s allegory. He has received numerous grants and his early video “Spiral PTL” (made in collaboration with DeFanti and Mimi Shevitz) is featured in the inaugural collection of video art at the Museum of Modern Art. This program will feature a retrospective of work created by Sandin and others (from both UIC and SAIC) using the Image Processor and early digital computer systems developed at EVL. For more information visit southsideprojections.org.

    by Chris (noreply@blogger.com) at May 30, 2014 09:14 AM

    NOT ABOUT ART: A sampler of short films by AL RAZUTIS—VISUAL ALCHEMY

    NOT ABOUT ART: A sampler of short films by AL RAZUTIS—VISUAL ALCHEMY

    1200 N Alvarado St. (@ Sunset Blvd.) Los Angeles, CA.
    info@echoparkfilmcenter.org

    8 PM
    Thursday, June 12 

    Celebrating avant-garde, Structuralist, formalist, mythopoeic, Situationist and anarchist influences over nearly 50 years of film-making, Al Razutis is pioneer in film/video hybrids, optical manipulations, radical media performance, holographic and 3-D art practice, and all-around troublemaking. Filmmaker will be in attendance to introduce, comment, and engage with audience on the film-forms, context, and interpretation of film practice outside of art institutions, outside of commercial and popular notions of film as experimental and underground cinema. Al Razutis in person!

    www.alchemists.com
    www.xalrazutis.org



    by Chris (noreply@blogger.com) at May 30, 2014 09:13 AM

    May 28, 2014

    Richard Hughes, ColorHug

    AppData progress and the email deluge

    In the last few days, I’ve been asking people to create and ship AppData files upstream. I’ve:

    • Sent 245 emails to upstream maintainers
    • Opened 38 launchpad bugs
    • Created 5 gnome.org bugs
    • Opened 72 sourceforge feature requests
    • Opened 138 github issues
    • Created 8 bugs on Fedora trac
    • Opened ~20 accounts on random issue trackers
    • Used 17 “contact” forms

    In doing this, I’ve visited over 600 upstream websites, helpfully identifying 28 that are stated as abandoned by thier maintainer (and thus removed from the metadata). I’ve also blacklisted quite a few things that are not actually applications and not suitable for the software center.

    I’ve deliberately not included GNOME in this sweep, as a lot of the core GNOME applications already have AppData and most of the gnomies already know what to do. I also didn’t include XFCE appications, as XFCE has agreed to adopt AppData on the mailing list and are in the process of doing this already. KDE is just working out how to merge the various files created by Matthias, and I’ve not heard anything from LXDE or MATE. So, I only looked at projects not affiliated with any particular desktop.

    For far, the response has been very positive, with at least 10% of the requests been actioned and some projects even doing new releases that I’ve been slowly uploading into Fedora. Another ~10% of requests are acknowlegdments from maintainers thay they would do this sometime before the next release. I have found a lot of genuinely interesting applications in my travels, and lot of junk. The junk is mostly unmaintained, and so my policy of not including applications (unless they have AppData manually added by the distro packager) that have not had an upstream release for the last 5 years seems to be valid.

    At least 5 of the replies have been very negative, e.g. “how dare you ask me to do something — do it yourself” and things like “Please do not contact me again – I don’t want any new users“. The vast number of people have not responded yet — so I’m preparing myself for a deluge over the next few weeks from the people that care.

    My long term aim is to only show applications in Fedora 22 with AppData, so it seemed only fair to contact the various upstream projects about an initiative they’re probably not familiar with. If we don’t get > 50% of applications in Fedora with the extra data we’ll have to reconsider such a strong stance. So far we’ve reached over 20%, which is pretty impressive for a standard I’ve been pushing for such a short amount of time.

    So, if you’ve got an email from me, please read it and reply — thanks.

    by hughsie at May 28, 2014 11:15 AM

    May 25, 2014

    Bunnie Studios

    I Broke My Phone’s Screen, and It Was Awesome

    So this past week has been quite a whirlwind — we wrapped up the Novena campaign and smashed all our stretch goals, concluding with over $700k raised, and I got my hair cut in a bar at midnight by none other than the skilled hands of Lenore of Evil Mad Scientist Laboratories (I blame Jake! :). It was an exhilarating week; xobs and I are really grateful for the outpouring of support and we’re looking forward to working with the community to build an open hardware ecosystem that can grow for years to come.

    On my way back home to Singapore, I stopped by Dongguan to have a visit with my supply chain partners to hammer out production plans for Novena. Unfortunately, as I was getting out of the taxi at the Futian border checkpoint going into China, I dropped my phone on the sidewalk and shattered its screen.

    There is no better place in the world to break your phone’s screen than the border crossing into Shenzhen. Within an hour of dropping the phone, I had a new screen installed by skilled hands in Hua Qiang Bei, for a price of $25.

    Originally, I thought I would replace the screen myself — on my broken phone, I hastily visited iFixit for details on the procedure to replace the screen, and then booked it over to Hua Qiang Bei to purchase the replacement parts and tools I would need. The stall I visited quoted me about US$120 for a new screen, but then the lady grabbed my phone out of my hands, and launched a built in self test program on the phone by dialing *#0*# into the phone dialer UI.

    She confirmed that there were no bad pixels on my OLED display and that the digitizer was still functional, but just cracked. She then offered to buy my broken OLED+digitizer assembly off of me, but only if they did the work to replace my screen. I said it would be fine as long as I could watch them do the job, to make sure they aren’t swapping out any other parts on me.

    They had no problem with that, of course — so my phone came apart, had the old broken OLED+digitizer assembly separated, adhesive stripped from the phone body, replaced with a proper new film of adhesive, a “new” (presumably refurbished) OLED+digitizer fitted and re-assembled in 20 minutes. The whole service including parts and labor came out to $25. I kept on thinking “man I should take pictures of this” but unfortunately the device I would use to take said pictures was in pieces in front of me. But, I’ll hint that the process involved a hair dryer (used as a heat gun), copious amounts of contact cleaner (used to soften the adhesive on the OLED+digitizer module), and a very long thumbnail (in lieu of a spudger/guitar pick).

    This is the power of recycling and repair — instead of paying $120 for a screen and throwing away what is largely a functional piece of electronics, I just had to pay for the cost of just replacing the broken glass itself. I had originally assumed that the glass on the digitizer is inseparable from the OLED, but apparently those clever folks in Hua Qiang Bei have figured out an efficient method to recycle these parts. After all, the bulk of the assembly’s cost is in the OLED display, and the touchscreen sensor electronics (which are also grafted onto the module) are also undamaged by the fall. Why waste perfectly good parts, anyways?

    And so, my phone had a broken screen for all of an hour, and it was fixed for less than the cost of shipping spare parts to Singapore. There is no better place to break your phone than in Shenzhen!

    by bunnie at May 25, 2014 08:07 AM

    Name that Ware May 2014

    The Ware for May 2014 is shown below.

    Thanks to @jamoross from Safecast for contributing this ware!

    by bunnie at May 25, 2014 08:07 AM

    Winner, Name that Ware April 2014

    The Ware for April 2014 is a Propeller II from Parallax. Kudos to David for nailing it; email me for your prize!

    by bunnie at May 25, 2014 08:06 AM

    Video Circuits

    F.C. Judd



    The work of Frederick Charles Judd previously neglected somewhat by the history books, has over the last few years received renewed interest due to Ian Helliwell's work. Ian's articles, films and exhibitions have collected and disseminated many of Fred's forgotten work and ideas. One of these was his Chromasonics system, which effectively combined CRT based Lissajous figures with a high speed colour wheel to allow full colour display of the electronic images with movement generated by sound. Fred also wrote a series of articles in Practical Electronics magazine on how to construct such a system as well as other audio visualization techniques such as colour organs. Fred is now recognised as an important electronic and tape music composer with a re-issued collection of works available here.
    I wanted to focus on his visual work, so here are a series of scans from my collection and some links.
    www.fcjudd.co.uk

    Here are some stills of the images generated by the 
    Chromasonics system 


    They are very reminiscent of work by Ben F. Laposky although moving rather than static photographs. Fred was also aware of the Oramics system build by Daphne Oram which also used CRT's. Orams system however used them to turn images of waveforms into electronic signals rather than visualise the sounds themselves. Ian's film Practical Electronica contains some footage Fred created of the Chromasonics system in action. below is a full colour image from the cover of Practical electronics. Fred's work on audio definitely inspired wide range of experimenters, I wonder if any visual work by his readers survive. 




















    Here are some images the construction of the Chromasonics system notice the large colour wheel that synchronised with the refresh rate of the displayed images so as to selectively colourise different signals allowing for multi colour display.




































































    Here are some stills of Chromasonics and the trailer for Ian's film



















    These are some clippings of the the displays Fred developed.

























    And finally a few pics of Fred at work creating sound!





































    Practical Electronica will be screened on Tuesday in London link to the event here 

    by Chris (noreply@blogger.com) at May 25, 2014 05:26 AM

    May 22, 2014

    Video Circuits

    Sketches of my Sister Plus Laurie



    alanpowell2591

    "Experimental video produced at Electron Movers, a video art coop in 1975. The video is made on 1/2" EIAJ B&W video. The dancers are delayed by running the video between two video tape decks. Te sound was produced on a Buchala audio Synthesizer at the national center for Experiments in Television. The video processing equipment was built by George Brown and Built by Alan Powell."

    by Chris (noreply@blogger.com) at May 22, 2014 09:30 AM

    ZeptoBARS

    KR580VM80A - getting ready for reverse engineering : weekend die-shot

    We decided to take a closer look at the most popular soviet processor KR580VM80A (first shoot), so that group of enthusiasts (russian only) would be able to recover schematic from it's layout.



    A bit more dirt, but less overetch:


    Dark field - metal is clearly visible:


    Polarized light - metal and vias are visible:


    After metallization etch. Any ideas why polysilicon gone?


    May 22, 2014 03:19 AM

    May 21, 2014

    Free Electrons

    2014 Q2 newsletter

    This article was published on our quarterly newsletter.

    Free Electrons is happy to share some news about the latest training and contribution activities of the company.

  • Supporting A New ARM platform: The Allwinner SoCs Example – Maxime Ripard
  • by Michael Opdenacker at May 21, 2014 04:13 AM

    May 20, 2014

    Michele's GNSS blog

    Galileo RTK with NV08C-CSM hw 4.1

    Being European I am often subject to skepticism about Galileo and compelled to justify its delays and usefulness. Explaining why Galileo is better and needed is beyond the scope of my blog but IMHO there is one key selling point that not many people stress.

    Galileo was designed from the ground up in close collaboration with the USA: GPS and Galileo share L1 (1575.42 MHz) and L5/E5a (1176.45 MHz). In the future, a dual frequency GPS+Galileo L1/L5 receiver will deliver products with an incredible ratio between (performance+availability)/silicon.
    According to scheduled launches there could be 12+ satellites supporting open L1+L5 by the end of this year already.
    In the meantime, NVS touches base first in the mass-market receiver domain by delivering consistent carrier-phase measurements for GPS+Glonass+Galileo.

    I have recently run zero-baseline double-differences in static, perfect visibility conditions using a high-end survey antenna:
    Figure 1: Galileo double differences in static zero-baseline (NV08C-CSM hw4.1)
    Using E11 as reference, the carrier phase noise is well contained within 0.01 circles (2mm).
    With RTKLIB I run a Galileo-only static IAR and the result is as expected:

    Figure 2: Static IAR with Galileo only (4 IOVs)
    The combined GPS+Galileo static IAR looks like this:

    Figure 3: Static IAR with GPS+Galileo
    Note the 12 satellites above the 10° elevation mask used in the computation of carrier ambiguities :)

    Understandably, Skytraq is working on GPS+Beidou carrier phase and I may publish some results on that too although visibility of Beidou MEOs is not great from here.

    In the meantime, for people who wonder where uBlox NEO6T stands in terms of GPS carrier phase noise in similar conditions to the above here it is my result:
    Figure 4: GPS double differences in static zero-baseline (uBlox NEO6T)
    Which shows similar noise levels to NV08C-CSM.

    by noreply@blogger.com (Michele Bavaro) at May 20, 2014 10:25 PM

    May 17, 2014

    ZeptoBARS

    Toshiba TCD1201D - linear CCD : weekend die-shot

    Toshiba TCD1201D is a monochrome 2048-pixel linear CCD. You can also notice few extra pixels for calibration shielded with aluminum.

    Die size 34814x802 µm.



    With this die we've reached JPEG limits, full image would be 80k+ pixels wide, so we'll show beginning and the end of the CCD separately:




    We are grateful to Kony for this chip.

    May 17, 2014 12:45 PM

    Bunnie Studios

    See you at Maker Faire Bay Area!

    Looking forward to seeing everyone at Maker Faire Bay Area, happening May 17 & 18 at the San Mateo Event Center. xobs and I will be giving a short half-hour talk starting at 10:30AM in the Expo hall on Saturday about Novena, on the Electronics stage. Afterwards, xobs will be hanging out with his Novena at the Freescale booth, also in the Expo hall, about halfway down on the left hand side across from the Atmel/Arduino booth. If you’re curious to see it or just want to stop by and say hi, we welcome you!

    Also, the whole chibitronics crew will be in the Expo hall as well, in the second row between Sony, PCH, and Qualcomm (‽‽‽). We’ll be teaching people how to craft circuits onto paper; attendees who can score a first-come, first-serve spot will receive free circuit stickers and also get a chance to be instructed by the wonderful and dynamic creative genius behind chibitronics, Jie Qi.

    by bunnie at May 17, 2014 04:51 AM

    May 12, 2014

    Michele's GNSS blog

    GNSS carrier phase, RTLSDR, and fractional PLLs (the necessary evil)

    A mandatory principle when processing GNSS -in order to have high accuracy carrier phase- is to have a well defined frequency planning. This entails knowing precisely how the Local Oscillator (LO) frequency is generated.
    With RTL-SDR it is not a trivial task given that both R820T and RTL2832U use fractional Phase Locked Loops (PLLs) in order to derive respectively the high-side mixing frequency and the Digital Down Conversion (DDC) carrier.
    I guess most people use RTL-SDR with a 50ppm crystal so the kind of inaccuracies I am going to describe are buried under the crystal inaccuracy ..within reason.

    Let us start from the common call

    &gt; rtl_sdr -f 1575420000

    This means "set to 1575.42 MHz" but what is hidden is:
    1) R820T, set to 1575.42e6 + your IF
    2) RTL2832U, downconvert the R820T IF to baseband
    .. there are approximations everywhere.

    Now, the R820T has a 16 bit fractional PLL register meaning that it can only set to frequencies multiple of 439.45 Hz (exactly).
    Instead, the RTL2832U has a 22 bit fractional PLL register meaning that is can recover IFs in steps of 6.8665 Hz (exactly).
    Of course, nor 1575.42e6, nor 3.57e6 are exact multiples of either frequency so one always ends up with a mismatch between what he/she thinks he has set, and what really ends up with. Most of the times, this is fine. For GNSS it is not since carrier is accumulated over long intervals and even a few tenths of Hz will make it diverge from the truth.
    So I went down the route of characterising the necessary evil of fractional PLLs.

    The first test I did was to set the tuner to 1575421875, which leads to a -1875 Hz center frequency but is nicely represented in 16 bits using a 28.8 MHz reference (remember the R820T). In fact, 54 + 0.7021484375 = 54 + [1011001111000000]/2^16. ..ok well actually it fits on 10 :)

    Here I found a small bug in the driver  and replaced the following messy (IMHO) code: 

    /* sdm calculator */
    while (vco_fra > 1) {
        if (vco_fra > (2 * pll_ref_khz / n_sdm)) {
            sdm = sdm + 32768 / (n_sdm / 2);
            vco_fra = vco_fra - 2 * pll_ref_khz / n_sdm;
            if (n_sdm >= 0x8000)
                break;
        }
        n_sdm <<= 1;
    }


    with 

    mysdm = (((vco_freq<<16)+pll_ref)/(2*pll_ref)) & 0xFFFF;

    Then I modified the IF of the R820T from 3.57 MHz to 3.6 MHz, as it is only a few kHz away and it is nicely represented on 16 bit  ..ok well it actually fits in 3 :)
    Modifying the IF also impacted the RTL2832U fractional register of course.
    I still had a significant error (about 115 Hz) which I could measure comparing the scaled code rate and the carrier rate (which should be proportional of a factor 1540).
    After a long time wondering what could be happening, I decided to start tweaking the bits of the R820T.
    One in particular called PLL dithering seemed suspicious. Disabling it kind of doubled the error to about 220Hz. Sad.. but I did recall now the resolution of the tuner (439.45 Hz) and guessed that there is a hidden 17th bit which toggles randomly when "dithering" and is instead fixed to 1 when "not dithering". A couple of references which could explain why are here:
    http://petrified.ucsd.edu/~ispg-adm/pubs/KWangDissertation.pdf
    http://www.ece.rochester.edu/users/friedman/papers/ISCAS_04_PLL.pdf

    How sneaky! But I could nicely recover that 17th bit with the RTL2832U (which has 22).
    So I have now rock-solid code-carrier assistance ^_^
    Figure 1: Code-carrier mismatch when tracking a satellite with RTL-SDR
    One step closer to integer ambiguity resolution?

    Cheers,
    Mic

    by noreply@blogger.com (Michele Bavaro) at May 12, 2014 09:30 PM

    Bunnie Studios

    Novena in the X-Ray

    Last week, Nadya Peek from MIT’s CBA gave me the opportunity to play with their CT scanner. I had my Novena laptop with me, so we extracted the motherboard and slapped it into the scanner. Here are some snapshots of the ethernet jacks, which are enclosed metal boxes and thus a target for “intervention” (e.g. NSA ANT FIREWALK featuring their nifty TRINITY MCM).

    Plus, it’s just fun to look at X-rays of your gear.

    The X-ray reveals the expected array of ferrite cores implementing the transformers required by gigabit ethernet.

    by bunnie at May 12, 2014 06:43 PM

    May 08, 2014

    Bunnie Studios

    An Oscilloscope Module for Novena

    One of Novena’s most distinctive features is its FPGA co-processor. An FPGA, or Field Programmable Gate Array, is a sea of logic gates and memory elements that can be wired up according to hardware descriptions programmed in languages such as Verilog or VHDL. Verilog can be thought of as a very strictly typed C where every line of the code executes simultaneously. Thus, every bit of logic in Novena’s Spartan 6 LX45 FPGA could theoretically perform a computation every clock cycle — all 43,000 logic cells, 54,000 flip flops, and 58 fixed-point multiply accumulate DSP blocks. This potential for massive parallelism underlies one half of the exciting prospects enabled by an FPGA.

    The other exciting half of an FPGA relates to its expansive I/O capabilities. Every signal pin of an FPGA can be configured to comply with a huge range of physical layer specifications, from vanilla CMOS to high-speed differential standards such as TMDS (used in HDMI) and SSTL (used to talk to DDR memories). Each signal pin is also backed by a high speed SERDES (serializer/deserializer) and sophisticated clock management technologies. Need a dozen high-precision PWM channels for robotics? No problem, an FPGA can easily do that. Need an HDMI interface or two? Also no problem. Need a bespoke 1000 MT/s ADC interface? Simple matter of programming – and all with the same set of signal pins.

    Novena also hangs a 2Gbit DDR3 memory chip directly off the FPGA. The FPGA contains a dedicated memory controller that talks DDR3 at a rate of 800MT/s over a 16-bit bus, yielding a theoretical peak memory bandwidth of 12.8 Gbits/s. This fast, deep memory is useful for caching and buffering data locally.

    Thus, the FPGA can be thought of as the ultimate hardware hacking primitive. In order to unlock the full potential of the FPGA, we decided to bring most of the spare I/Os on the chip to a high speed expansion header. The high speed header is a bit less convenient than Arduino shield connectors if all you need to do is flash an LED, but as a trade-off the header is rated for signal speeds of over a gigabit per second per pin.

    However, the GPBB (General Purpose Breakout Board) featured as one of the Novena crowdfunding campaign stretch goals resolves this inconvenience by converting the high speed signal format into a much lower performance but more convenient 0.1” pin header format, suitable for most robotics and home automation projects.

    Enter the Oscilloscope
    A problem that xobs and I frequently encounter is the need for a highly programmable, travel-friendly oscilloscope. There’s a number of USB scope solutions that don’t quite cut it in terms of analog performance and UX, and there are no self-contained solutions we know of today that allow us to craft stimulus-response loops of the type needed for fuzzing, glitching, power analysis, or other similar hardware hacking techniques.

    Fortunately, Novena is an ideal platform for implementing a bespoke oscilloscope solution – which we’ve gone ahead and done. Here’s a video demonstrating the basic functionality of our oscilloscope solution running on Novena (720p version in VP8 or H.264):




    Novena was plugged into the large-screen TV via HDMI to make filming the video a little bit easier.

    In a nutshell, the oscilloscope offers two 8-bit channels at 1GSPS or one 8-bit channel at 2GSPS with an analog bandwidth of up to 900MHz. As a side bonus we also wired in a set of 10 digital channels that can be used as a simple logic analyzer. Here’s some high resolution photos of the oscilloscope expansion board:

    Here’s the schematics.

    This combination of the oscilloscope expansion board plus Novena is a major step toward the realization of our dream of a programmable, travel-friendly oscilloscope. The design is still a couple revisions away from being production ready, but even in its current state it’s a useful hacking tool.

    At this point, I’m going to geek out and talk about the tech behind the implementation of the oscilloscope board.

    Oscilloscope Architecture
    Below is a block diagram of the oscilloscope’s digital architecture.

    The FPGA is configured to talk to an ADC08D1020 dual 1GSPS ADC, designed originally by National Semiconductor but now sold as TI. The interface to the ADC is a pair of 8-bit differential DDR busses, operating at up to 500MHz, which is demultiplexed 1:8 into a 64-bit internal datapath. Upon receipt of a trigger condition, the FPGA stores a real-time sample data from the ADC into local DDR3 memory, and later on the CPU can stream data out of the DDR3 memory via the Linux Generic Netlink API. Because the DDR3 memory’s peak bandwidth is only 1.6GSPS, deep buffer capture of 256 Msamples is only available for net sample rates below 1GSPS; higher sample rates are limited to the internal memory capacity of the FPGA, still a very usable 200 ksamples depth. The design is written in Verilog and consumes about 15% of the FPGA, leaving plenty of space for implementing other goodies like digital filters and other signal processing.

    The ADC is clocked by an Analog Devices AD9520 PLL, which derives its time base from a TCXO. This PLL + TCXO combination gives us better jitter performance than the on-chip PLL of the FPGA, and also gives us more flexibility on picking sampling rates.

    The power system uses a hybrid of boost, buck, and inverting switching regulators to bring voltages to the minimum-dropout required for point-of-use LDOs to provide clean power to sensitive analog subsystems. This hybrid approach makes the power system much more complex, but helps keep the power budget manageable.

    Perhaps the most unique aspect of our oscilloscope design is the partitioning of the analog signal chain. Getting a signal from the point of measurement to the ADC is a major engineering challenge. Remarkably, the same passive probe I held in the 90′s is still a standard workhorse for scopes like my Tektronix TDS5104B almost a quarter century later. This design longevity is extremely rare in the world of electronics. With a bandwidth of several hundred MHz but an impedance measured in mega-ohms and a load capacitance measured in picofarads, it makes one wonder why we even bother with 50-ohm cables when we have stuff like oscilloscope probes. There’s a lot of science behind this, and as a result well-designed passive probes, such as the Tektronix P6139B, cost hundreds of dollars.

    Unfortunately, high quality scope probes are made out of unicorn hair and unobtanium as far as I’m concerned, so when thinking about our design, I had to take a clean-sheet look at the problem. I decided to look at an active probe solution, whilst throwing away any notion of backward compatibility with existing scope probes.

    I started the system design by first considering the wires (you can tell I’m a student of Tom Knight – one of his signature phrases is “it’s the wires, stupid!”). I concluded the cheapest high-bandwidth commodity cable that is also rated for a high insertion count is probably the SATA cable. It consists of two differential pairs and it has to support signal bandwidths measured in GHz, yet it costs just a couple of bucks. On the downside, any practical probing solution needs to present an impedance of almost a million times greater than that required by SATA, to avoid loading down the circuitry under test. This means we have to cram a high performance amplifier into a PCB that fits in the palm of your hand. Thankfully, Moore’s Law took care of that in the intervening decades from when passive oscilloscope probes were first invented out of necessity.

    The LMH6518 is a single-chip solution for oscilloscope front-ends that is almost perfect for this scenario. It’s a 900 MHz, digitally controlled variable gain amplifier (VGA) with the added feature of an auxilliary output that’s well-suited for functioning as a trigger channel; conveniently, a SATA cable has two differential pairs, so we allocate one for measurement and one for trigger. We also strap a conventional 8-pin ribbon cable to the SATA cable for passing power and I2C.

    The same LMH6518 VGA can be combined with a variety of front-end amplifiers to create a range of application-specific probes. We use a 1GHz FET op-amp (the ADA4817) to do the impedance transformation required of a “standard” digital oscilloscope. We use a relatively low impedance but “true differential” amplifier to measure voltages developed across a series sense resistor for power signature analysis. And we have a very high-impedance, high CMRR instrumentation amplifier front end for capturing signals developed across small loops and stubs of wire, useful for detecting parasitic electromagnetic emissions from circuits and cables.

    Above: digital probe

    Above: power signature analysis probe

    Above: sidechannel emissions probe

    However, the design isn’t quite perfect. The LMH6518 burns a lot of power – a little over a watt; and the pre-amp plus power regulators add about another watt overall to the probe’s power footprint. Two watts isn’t that bad on an absolute scale, but two watts in the palm of your hand is searing hot; the amplifier chip gets to almost 80C. So, I designed a set of custom aluminum heatsinks for the probes to help spread and dissipate the heat.

    When I handed the aluminum-cased probes to xobs, I warned him that the heat sinks are either going to solve the heat issue, or it’s going to turn the probes into a ball of flaming hot metal. Unfortunately, the heatsink gets to about 60C in still air, which is an ergonomic challenge – the threshold for pain is typically around 45-50C, so it’s very uncomfortable to hold the aluminum cases directly. It’s alright to hold the probes by the plastic connectors on the back, but this requires special training and users will instinctively want to hold a probe by its body. So, probably I’ll have to do some thermal optimization of the design and add either a heat pipe to a large heatsink off the probe body, or use a small fan to force air over the probes. It turns out just a tiny bit of airflow is all that’s need to keep the probes cool, but with passive convection alone they are simply too hot to handle. This won’t, of course, stop us from using them as-is; we’re okay with having to be a little bit careful to gain access to a very capable device. However, nanny-state laws and potentially litigious customers make it too risky to sell this solution to end consumers right now.

    Firmware Architecture

    xobs defined the API for the oscilloscope. The driver is based upon the Generic Netlink API native to the Linux kernel, and relies upon the libnl-genl libraries for the user-space implementation. Out of the various APIs available in the Linux kernel to couple kernelspace to userspace, Netlink was the best match, as it is stream-oriented and inherently non-blocking. This API has been optimized for high throughput and low latency, since it is also the core of the IP network stacks that on servers push gigabits of bandwidth. It’s also more mature than the nascent Linux IIO subsystem.

    In the case of xobs’ driver, he creates a custom generic netlink protocol which he registers with the name “kosagi-fpga”. Generic netlink sockets support the concept of specific commands, and he currently supports the following:


    /* list of valid commands */
    enum kosagi_fpga_commands {
    KOSAGI_CMD_UNSPEC,
    KOSAGI_CMD_SEND,
    KOSAGI_CMD_READ,
    KOSAGI_CMD_POWER_OFF,
    KOSAGI_CMD_POWER_ON,
    KOSAGI_CMD_FPGA_ASSERT_RESET,
    KOSAGI_CMD_FPGA_DEASSERT_RESET,
    KOSAGI_CMD_TRIGGER_SAMPLE,
    __KOSAGI_CMD_MAX,
    };

    The current implementation provisions two memory-mapped address spaces for the CPU to communicate with the FPGA, split along two different chip select lines. Chip Select 0 (CS0) is used for simple messages and register settings, while Chip Select 1 (CS1) is used for streaming data to and from the FPGA. Therefore, when the CPU wants to set capture buffer sizes, trigger conditions, or initiate a transfer, it communicates using CS0. When it wants to stream data from the FPGA, it will do so via CS1.

    The core of the API is the KOSAGI_CMD_TRIGGER_SAMPLE and KOSAGI_CMD_READ commands. To request a sample from the oscilloscope, the userspace program emits a KOSAGI_CMD_TRIGGER_SAMPLE command to the kosagi-fpga Netlink interface. This will cause the CPU to communicate with the FPGA via the CS0 EIM memory space control registers, setting up the trigger condition and the transfer FIFO from the FPGA.

    The userspace program will then emit a KOSAGI_CMD_READ command to retrieve the data. Upon receiving the read command, the kernel initiates a burst read from CS1 EIM memory space to a kernel buffer using memcpy(), which is forwarded back to the userspace that requested the data using the genlmsg_unicast() Netlink API call. Userspace retrieves the data stream from the kernel by calling the nl_recv() API call.

    This call is currently configured to block until the data is available for the userspace program, but it can also be configured to timeout as well. However, a timeout is generally not necessary as the call will succeed in a fraction of a millisecond due to the high speed and determinism of the transfer interface.

    In addition to handling data transfers, the kernel module implementing this API also handles housekeeping functions, such as configuring the FPGA and controlling power to the analog front end. FPGA configuration is handled automatically upon driver load (via insmod, modprobe, or udev) via the request_firmware() API built into the Linux kernel. The FPGA bitstream is located in the kernel firmware directory, usually /lib/firmware/novena_fpga.bit.

    Power management functions have their own dedicated Netlink commands. Calling these commands causes the respective GPIO for the expansion connector power switch to be toggled. When the expanion connector is power-cycled, the module also resets the FPGA and reloads its firmware, allowing for a complete reset of the expansion subsystem without having to power cycle the CPU.

    Above: a snippet of a trace captured by the scope when probing a full-speed USB data line.

    xobs also wrote a wonderful demo program in Qt for the oscilloscope, and through this we were able to do some preliminary performance characterization. The rise-time performance of the probe is everything I had hoped for, and the very long capture buffer provided by the FPGA’s DDR3 memory enables a new dimension of deep signal analysis. This, backed with Novena’s horsepower, tight integration with Linux and a hackable architecture makes for a compelling – and portable – signal analysis solution for field work.

    If the prospect of a a hackable oscilloscope excites you as much as it does us, please consider backing our crowdfunding campaign for Novena and spreading the word to your friends; there’s only a few days left. Developing complex hardware and software systems isn’t cheap, and your support will enable us to focus on bringing more products like this to market.

    by bunnie at May 08, 2014 05:59 AM

    May 03, 2014

    Bunnie Studios

    Novena’s Hackable Bezel

    When designing Novena, I had to balance budget against hackability. Plastic parts are cheap to produce, but the tools to mold them are very expensive and difficult to modify. Injection mold tooling cost for a conventional clamshell (two-body) laptop runs upwards of $250,000. In contrast, Novena’s single body design has a much lower tooling cost, making it feasible to amortize tooling costs over a smaller volume.

    The decision to use flat sheet aluminum for the LCD bezel was also driven in part to reduce tooling costs. Production processing for aluminum can be done using CNC, virtually eliminating up-front tooling costs. Furthermore, aluminum has great hack value, as it can be cut, drilled, tapped, and bent with entry-level tools. This workability means end users can easily add connectors, buttons, sensors, and indicators to the LCD bezel. Users can even design in a custom LCD panel, since there’s almost no setup cost for machining aluminum.

    One of my first mods to the bezel is a set of 3D-printed retainers, custom designed to work with my preferred keyboard. The retainers screw into a set of tapped M2.5 mounting holes around the periphery of the LCD.

    The idea is that the retainers hold my keyboard against the LCD bezel when transporting the laptop, protecting the LCD from impact damage while making it a little more convenient for travel.

    Such an easily customizable bezel means a limitless combination of keyboards and LCDs can be supported without requiring expensive modifications to injection molding tools.

    The flat design also means it’s easy to laser-cut a bezel using other materials. Here’s an example made out of clear acrylic. The acrylic version looks quite pretty, although as a material acrylic is much softer and less durable than aluminum.

    I also added a notch on the bottom part of the bezel to accommodate breakout boards plugged into the FPGA expansion connector.

    The low up-front cost to modify and customize the bezel enables experimentation and serendipitous hacks. I’m looking forward to seeing what other Novena users do with their bezels!

    by bunnie at May 03, 2014 07:08 AM

    May 02, 2014

    ZeptoBARS

    SkyWorks AAT4292 - 7-bit high-side IO expander: weekend die-shot

    SkyWorks AAT4292 is a 7-bit IO expander with 100mA 1.1Ω high-side switches per channel.
    Die size 1193x618 µm.



    After metallization etch:

    May 02, 2014 11:27 PM

    Richard Hughes, ColorHug

    AppData, meet SPDX. SPDX, meet AppData

    A few long months ago I asked everyone shipping a desktop application to also write an AppData file for the software installer. So far over 300 projects have written these files and there are over 500 upstream screenshots that have been taken. The number has been growing steadily, and most active projects now ship a file upstream. So, what do I want you to do now? :)

    The original AppData specification had something like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <application>
    <id type="desktop">gnome-power-statistics.desktop</id>
    <licence>CC0</licence>
    ...
    

    This had a couple of problems. First was the spelling of license. I’m from Blightly, and forgot that I was supposed to be coding in en_US. The second was people frequently got confused that they were supposed to be specifying the license of that specific metadata file, rather than the license of the project as a whole. A few months ago we fixed this, and added the requirement of a copyright statement to please the Debian overlords:

    <?xml version="1.0" encoding="UTF-8"?>
    <!-- Copyright 2013 Richard Hughes <richard@hughsie.com> -->
    <application>
    <id type="desktop">gnome-power-statistics.desktop</id>
    <metadata_license>CC0-1.0</metadata_license>
    <project_license>GPL-2.0+ and GFDL-1.3</project_license>
    ...
    

    The project licenses just have to be valid SPDX strings. You can use “ and ” and “ or ” or even brackets if required, just like in a spec file. The reason for standardising on SPDX is that it’s being used on lots of distros now, and we can also make the licence substrings clickable in gnome-software very easily.

    So, if you’ve already written an AppData file please do three things:

    • Make sure Copyright exists at the top of the file after the <?xml header
    • Convert license into metadata_license and change to a SPDX ID
    • Add project_license and add all the licenses used in your project.

    In Fedora 21 I’m currently doing a mapping from License: in the spec file to the SPDX format, although it’s not a 1:1 mapping hence why I need this to be upstream. KDE is already shipping project_license in thier AppData files, but I’m not going to steal that thunder. Stay tuned.

    by hughsie at May 02, 2014 12:54 PM

    Video Circuits

    Film Night Documentation

    The film night went very well, and a few of the London based artists managed to meet for the first time which was cool, It was very nice to see this kind of work in the real world and I am looking to scale up for the next screening possibly with a live element so watch out for that

    Thanks to Ben for putting the event on, Alex, James, Kate, Jerry, Lawrence, Andi and Gary and everyone else who made it down to watch and all the artists who participated, here are some shots the first few are from Alex.











    by Chris (noreply@blogger.com) at May 02, 2014 08:56 AM

    April 30, 2014

    Mirko Vogt, nanl.de

    Protected: There’s no such thing as bad publicity…

    This post is password protected. To view it please enter your password below:

    by mirko at April 30, 2014 02:38 PM

    April 29, 2014

    Bunnie Studios

    Circuit Stickers Manufacturing Retrospective: From Campaign to First Shipment

    Last December, Jie Qi and I launched a crowdfunding campaign to bring circuit stickers under the brand name of “chibitronics” to the world.

    Our original timeline stated we would have orders shipped to Crowd Supply for fulfillment by May 2014. We’re really pleased that we were able to meet our goal, right on time, with the first shipment of over a thousand starter kits leaving the factory last week. 62 cartons of goods have cleared export in Hong Kong airport, and a second round of boxes are due to leave our factory around May 5, meaning we’ve got a really good chance of delivering product to backers by Mid-May.

    Above: 62 cartons containing over a thousand chibitronics starter kits waiting for pickup.

    Why On-Time Delivery Is So Important
    A personal challenge of mine was to take our delivery commitment to backers very seriously. I’ve seen too many under-performing crowdfunding campaigns; I’m deeply concerned that crowdfunding for hardware is becoming synonymous with scams and spams. Kickstarter and Indiegogo have been plagued by non-delivery and scams, and their blithe caveat emptor attitude around campaigns is a reflection of an entrenched conflict of interest between consumers and crowdfunding websites: “hey, thanks for the nickel, but what happened to your dollar is your problem”.

    I’m honestly worried that crowdfunding will get such a bad reputation that it won’t be a viable platform for well-intentioned entrepreneurs and innovators in a few years.

    I made the contentious choice to go with Crowd Supply in part because they show more savvy around vetting hardware products, and their service offering to campaigns — such as fulfillment, tier-one customer support, post-campaign pre-order support, and rolling delivery dates based on demand vs. capacity — is a boon for hardware upstarts. Getting fulfillment, customer support and an ongoing e-commerce site as part of the package essentially saves me one headcount, and when your company consists of just two or three people that’s a big deal.

    Crowd Supply doesn’t have the same media footprint or brand power that Kickstarter has, which means it is harder to do a big raise with them, but at the end of the day I feel it’s very important to establish an example of sustainable crowdfunding practices that is better for both the entrepreneur and the consumer. It’s not just about a money grab today: it’s about building a brand and reputation that can be trusted for years to come.

    Bottom line is, if I can’t prove to current and future backers that I can deliver on-time, I stand to lose a valuable platform for launching my future products.

    On-Time Delivery Was not Easy
    We did not deliver chibitronics on time because we had it easy. When drawing up the original campaign timeline, I had a min/max bounds on delivery time spanning from just after Chinese New Year (February) to around April. I added one month beyond the max just to be safe. We ended up using every last bit of padding in the schedule.

    I made a lot of mistakes along the way, and through a combination of hard work, luck, planning, and strong factory relationships, we were able to battle through many hardships. Here’s a few examples of lessons learned.

    A simple request for one is not necessarily a simple request for another. Included with every starter kit is a fantastic book (free to download) written by Jie Qi which serves as a step-by-step, self-instruction guide to designing with circuit stickers. The book is unusual because you’re meant to paste electronic circuits into it. We had to customize several aspects of the printing, from the paper thickness (to get the right light diffusion) to the binding (for a better circuit crafting experience) to the little pocket in the back (to hold swatches of Z-tape and Linqstat material). Most of these requests were relatively easy to accommodate, but one in particular threw the printer for a loop. We needed the metal spiral binding of the book to be non-conductive, so if someone accidentally laid copper tape on the binding it wouldn’t cause a short circuit.

    Below is an example of how a circuit looks in the book — in this case, the DIY pressure sensor tutorial (click on image for a larger version).

    Checking for conductivity of a wire seems like a simple enough request for someone who designs circuits for a living, but for a book printer, it’s extremely weird. No part of traditional book printing or binding requires such knowledge. Because of this, the original response from the printer is “we can’t guarantee anything about the conductivity of the binding wire”, and sure enough, the first sample was non-conductive, but the second was conductive and they could not explain why. This is where face to face meetings are invaluable. Instead of yelling at them over email, we arranged a meeting with the vendor during one of my monthly trips to Shenzhen. We had a productive discussion about their concerns, and at the conclusion of the meeting we ordered them a $5 multimeter in exchange for a guarantee of a non-conductive book spine. In the end, the vendor was simply unwilling to guarantee something for which he had no quality control procedure — an extremely reasonable position — and we just had to educate the vendor on how to use a multimeter.

    To wit, this unusual non-conductivity requirement did extend our lead time by several days and added a few cents to the cost of the book, but overall, I’m willing to accept that compromise.

    Never skip a checkplot. I alluded to this poignant lesson with the following tweet:


    The pad shapes for chibitronics are complex polyline geometries, which aren’t handled so gracefully by Altium. One problem I’ve discovered the hard way is the soldermask layer occasionally disappears for pads with complex geometry. One version of the file will have a soldermask opening, and in the next save checkpoint, it’s gone. This sort of bug is rare, but it does happen. Normally I do a gerber re-import check with a third-party tool, but since this was a re-order of an existing design that worked before, and I was in a rush, I skipped the check. Result? thousands of dollars of PCBs scrapped, four weeks gone from the schedule. Ouch.

    Good thing I padded my delivery dates, and good thing I keep a bottle of fine scotch on hand to help bitter reminders of what happens when I get complacent go down a little bit easier.

    If something can fit in a right and a wrong way, the wrong way will happen. I’m paranoid about this problem — I’ve been burned by it many times before. The effects sticker sheet is a prime example of this problem waiting to happen. It is an array of four otherwise identical stickers, except for the LED flashing pattern they output. The LED flashing pattern is controlled by software, and trying to manage four separate firmware files and get them all loaded into the right spot in a tester is a nightmare waiting to happen. So, I designed the stickers to all use exactly the same firmware; their behaviors set by the value of a single external resistor.

    So the logic goes: if all the stickers have the same firmware, it’s impossible to have a “wrong way” to program the stickers. Right?

    Unfortunately, I also designed the master PCB panels so they were perfectly symmetric. You can load the panels into the assembly robot rotated by pi radians and the assembly program runs flawlessly — except that the resistors which set the firmware behavior are populated in reverse order from the silkscreen labels. Despite having fiducial holes and text on the PCBs in both Chinese and English that are uniquely orienting, this problem actually happened. The first samples of the effects stickers were “blinking” where it said “heartbeat”, “fading” where it said “twinkle”, and vice-versa.

    Fortunately, the factory very consistently loaded the boards in backwards, which is the best case for a problem like this. I rushed a firmware patch (which is in itself a risky thing to do) that reversed the interpretation of the resistor values, and had a new set of samples fedexed to me in Singapore for sanity checking. We also built a secondary test jig to add a manual double-check for correct flashing behavior on the line in China. Although, in making that additional test, we were confronted with another common problem –

    Some things just don’t translate well into Chinese. When coming up with instructions to describe the difference between “fading” (a slow blinking pattern) and “twinkling” (a flickering pattern), it turns out that the Chinese translation for “blink” and “twinkle” are similar. Twinkle translates to 闪烁 (“flickering, twinkling”) or 闪耀 (to glint, to glitter, to sparkle), whereas blink translates to 闪闪 (“flickering, sparkling, glittering”) or 闪亮 (“brilliant, shiny, to glisten, to twinkle”). I always dread making up subjective descriptions for test operators in Chinese, which is part of the reason we try to automate as many tests as possible. As one of my Chinese friends once quipped, Mandarin is a wonderful language for poetry and arts, but difficult for precise technical communications.




    Above is an example of the effects stickers in action. How does one come up with a bulletproof, cross-cultural explanation of the difference between fading (on the left) and twinkling (on the right), using only simple terms anyone can understand, e.g. avoiding technical terms such as random, frequency, hertz, periodic, etc.

    After viewing the video, our factory recommended to use “渐变” (gradual change) for fade and “闪烁” (flickering, twinkling) for twinkle. I’m not yet convinced this is a bulletproof description, but it’s superior to any translation I could come up with.

    Funny enough, it was also a challenge for Jie and I to agree upon what a “twinkle” effect should look like. We had several long conversations on the topic, followed up by demo videos to clarify the desired effect. The implementation was basically tweaking code until it “looked about right” — Jie described our first iteration of the effect as “closer to a lightning storm than twinkling”. Given the difficulty we had describing the effect to each other, it’s no surprise I’m running into challenges accurately describing the effect in Chinese.

    Eliminate single points of failure. When we built test jigs, we built two copies of each, even though throughput requirements demanded just one. Why? Just in case one failed. And guess what, one of them failed, for reasons as of yet unknown. Thank goodness we built two copies, or I’d be in China right now trying to diagnose why our sole test jig isn’t working.

    Sometimes last minute changes are worth it. About six weeks ago, Jie suggested that we should include a stencil with the sensor/microcontroller kits. She reasoned that it can be difficult to lay out the copper tape patterns for complex stickers, such as the microcontroller (featuring seven pads), without a drawing of the contact patterns. I originally resisted the idea — we were just weeks away from finalizing the order, and I didn’t want to delay shipment on account of something we didn’t originally promise. As Jie is discovering, I can be very temperamental, especially when it comes to things that can cause schedule slips (sorry Jie, thanks for bearing with me!). However, her arguments were sound and so I instructed our factory to search for a stencil vendor. Two weeks passed and we couldn’t find anyone willing to take the job, but our factory’s sourcing department wasn’t going to give up so easily. Eventually, they found one vendor who had enough material in stock to tool up a die cutter and turn a couple thousand stencils within two weeks — just barely in time to meet the schedule.

    When I got samples of the sensor/micro kit with the stencils, I gave them a whirl, and Jie was absolutely right about the utility of the stencils. The user experience is vastly improved when you have a template to work from, particularly for the microcontroller sticker with seven closely spaced pads. And so, even though it wasn’t promised as part of the original campaign, all backers who ordered the sensor/micro kit are getting a free stencil to help with laying out their designs.

    Chinese New Year has a big impact the supply chain. Even though Chinese New Year (CNY) is a 2-week holiday, our initial schedule essentially wrote off the month of February. Reality matched this expectation, but I thought it’d be helpful to share an anecdote on exactly how CNY ended up impacting this project. We had a draft manuscript of our book in January, but I couldn’t get a complete sample until March. It’s not because the printer was off work for a month straight — their holiday, like everyone else’s, was about two weeks long. However, the paper vendor started its holiday about 10 days before the printer, and the binding vendor ended its holiday about 10 days after the printer. So even though each vendor took two weeks off, the net supply chain for printing a custom book was out for holiday for around 24 days — effectively the entire month of February. The staggered observance of CNY is necessary because of the sheer magnitude of human migration that accompanies the holiday.

    Shipping is expensive, and difficult. When I ran the initial numbers on shipping, one thing I realized is we weren’t selling circuit stickers — at least by volume and weight, our principle product is printed paper (the book). So, to optimize logistics cost, I was pushing to ship starter kits (which contain a book) and additional stand-alone book orders by ocean, rather than air.

    We actually had starter kits and books ready to go almost four weeks ago, but we just couldn’t get a reasonable quotation for the cost of shipping them by ocean. We spent almost three weeks haggling and quoting with ocean freight companies, and in the end, their price was basically the same as going by air, but would take three weeks longer and incurred more risk. It turns out that freight cost is a minor component of going by ocean, and you get killed by a multitude of surcharges, from paying the longshoreman to paying all the intermediate warehouses and brokers that handle your goods at the dock. All these fixed costs add up, such that even though we were shipping over 60 cartons of goods, air shipping was still a cost-effective option. To wit, a Maersk 40′ sea container will fit over 1250 cartons each containing 40 starter kits, so we’re still an order of magnitude away from being able to efficiently utilize ocean freight.

    We’re not out of the Woods Yet. However excited I am about this milestone, I have to remind myself not to count my chickens before they hatch. Problems ranging from a routine screw-up by UPS to a tragic aviation accident to a logistics problem at Crowd Supply’s fulfillment depot to a customs problem could stymie an on-time delivery.

    But, at the very least, at this point we can say we’ve done everything reasonably within our power to deliver on-time.

    We are looking forward to hearing our backer’s feedback on chibitronics. If you are curious and want to join in on the fun, the Crowd Supply site is taking orders, and Jie and I will be at Maker Faire Bay Area 2014, in the Expo hall, teaching free workshops on how to learn and play with circuit stickers. We’re looking forward to meeting you!

    by bunnie at April 29, 2014 11:01 AM

    April 28, 2014

    LZX Industries

    Production & Availability Update

    The past 18 months have been distracted for us here at LZX Industries, due to big changes in both of our lives. We’ve been doing our best to keep up with production, but we know many of you have been waiting on the core modules required to start your systems (Color Video Encoder & Video Sync Generator) for several months now. We are working to make these available again ASAP, as well as new releases we’ve been prototyping. Thank you so much for your patience. We’re very excited to launch into a new era of LZX in 2014.

    Here is a consolidated list of currently in stock and out of stock items.

    In stock at Analogue Haven:
    8 Stage Video Quantizer & Sequencer
    Audio Frequency Decoder
    Color Time Base Corrector
    Differentiator (assembled and DIY kit)
    Function Generator (assembled and DIY kit)
    Sync Bus Bridge Cable
    Triple Video Fader & Key Generator
    Triple Video Interface
    Triple Video Multimode Filter
    Video Blending Matrix
    Video Divisions
    Video Flip Flops
    Video Logic
    Video Ramps
    Video Sync Distribution Chain Cable
    Voltage Bridge

    Out of stock:
    BitVision (assembled and DIY kit)
    Color Video Encoder
    Colorspace Mapper
    Triple Video Processor
    Video Sync Generator
    Video Waveform Generator
    Voltage Interface I

    Other distributors (Modular Square, Fukusan Kigyo and Equinox Oz) have small amounts of stock or are entirely sold out. We will be restocking everything as soon as possible and concentrating more on documentation and user resources soon.

    by Liz Larsen at April 28, 2014 02:11 PM

    April 27, 2014

    OggStreamer

    #oggstreamer – UserInterface for optional LEDs

    I just added a small but neat feature I want to include in the V1.0 of the OggStreamer firmware – it is a user interface that allows to control the optional LEDs on the right side of the device.

    How it works – the main application (oggs_app) is creating a named pipe in the temporary directory, the name of the file is /tmp/userleds

    so the following command will set the optional green led on

    
    echo 1 > /tmp/userleds
    
    

    you can send any parameter from 0 to 7 to /tmp/userleds. The parameter is interpreted as binary representation of the leds. 1 is the GREEN led, 2 is the YELLOW led, 4 is the RED led. 0 is all leds OFF and 7 is all leds ON

    this feature unfolds its potential when you combine it with shell scripts – for example – everyone likes blinking LEDs.

    #!/bin/sh
    while [ 1 ]; do
      echo 7 > /tmp/userleds
      sleep 1
      echo 0 > / tmp/userleds
      sleep 1
    done
    

    But also more useful tasks can be done, for example monitoring whether an IPAddr can be pinged.

    #!/bin/sh
    while [ 1 ]; do
      ping -c 1 $1
      if [ "$?" == "1" ]; then
         #ping did not succed -> display RED Led
         echo 4 > /tmp/userleds
      else
         #ping did succed -> display GREEN Led
         echo 1 > /tmp/userleds
      fi
      sleep 10
    done
    

     

     


    by oggstreamer at April 27, 2014 05:59 PM

    April 24, 2014

    Bunnie Studios

    Name that Ware, April 2014

    The Ware for April 2014 is shown below.

    Apologies for the cracked/munged die, that’s how I received it. The die shot isn’t too high resolution, but I have a feeling its gross features are distinct enough that this ware will be guessed quickly.

    by bunnie at April 24, 2014 05:35 PM

    Winner, Name that Ware March 2014

    While there is no solid consensus on the precise function of this ware, there is a very solid body of evidence that March’s ware is part of a missile guidance system, likely from the AIM series of missiles made by Raytheon Missile Systems. Presumably Raytheon re-uses their missile avionics chassis across multiple product lines, hence it’s difficult to say exactly which design it’s from. The US has exported AIM-9 missiles to…a lot of places, including for example, Iraq, Iran, Pakistan, and nearby Asian countries including Singapore, Taiwan, Japan, Malaysia, and Thailand. So these scrap parts could have come from anywhere, not necessarily the US military. Next time I see one of these on the market, though, I think I will pick it up; it’ll make a great conversation piece for the coffee table.

    As for a winner, I think I’ll go with Chip; congrats, email me for your prize. I found the insight into the CAGE code to be a nice tip, I’ll have to use that in the future. I actually come across military-looking hardware surprisingly regularly in the scrap markets, and they do make for a lively name that ware.

    by bunnie at April 24, 2014 05:35 PM

    Peter Zotov, whitequark

    On tests and types

    Much has been said on the virtues of testing and type systems. However, I say that neither of them ultimately matters. Your codebase could be pure PHP, using exclusively goto for control flow, have no tests, comments, or variable names whatsoever—if you are rightfully sure that it is correct (for any possible input, produces valid output with limited use of resources), the codebase is perfect.

    The big question, of course, is “how can we be sure that it is correct?” There have been impressive advances in the field of authomatic theorem proving, e.g. Coq and CompCert. Unfortunately, we neither able nor should put a scientist behind every menial programming job; even if we could, undecidability means that we could only get a definite answer for a subset of interesting problems.

    The only available option is to rely on human judgement. Any tools or methods a programmer would employ are only useful as long as they enable a deeper understanding of the program, as they rightfully convince her that the program is indeed correct. If you don’t make an error, don’t test for it.

    Invariably, people do not all think alike. There is no single way of reasoning about programs and their behavior; there could be no single technique that enables writing nicest possible code. Thinking that the way that suits you most is the superior of them all is just arrogance. We can do better than that.

    I’m not saying that all languages and methods are born equal. They are not. But let’s reason about them in terms of how easier they make it for a human to analyze the code, for it is the only thing that matters, and not peculiarities of syntax or the big names behind.

    I’m also not saying that all code must be perfect. It doesn’t matter if a few pixels in a cat picture have the wrong color. But you better be sure they do not get executed.

    April 24, 2014 07:44 AM

    Bunnie Studios

    Design Novena’s Logo and Win a Desktop!

    Novena needs a logo. And we need you to help! Today we’re announcing a competition to design a logo for Novena, and the winner will get a desktop version of Novena and a T-shirt emblazoned with their logo.

    The competition starts today. Submissions should be sent to novena@crowdsupply.com by the end of May 11th. On May 12th, all submissions will be posted in an update, and on May 15th we’ll pick a winner.

    We’re also adding a $25 tier for backers who would like to receive a T-shirt with our new logo on it. The base color of the T-shirt will be royal blue, like the blue anodization of Novena’s bezel, and the base fit will be the American Apparel Jersey T-shirt (S,M,L,XL,2XL,3XL) or the Bella Girly Jersey V-Neck T-shirt (S,M,L,XL,2XL — ladies, Bella sizes run small, so round up for a comfortable fit). We aim to ship the T-shirts within 2 months of campaign conclusion.

    For the logo, here are the guidelines for design:

  • Single-color design strongly preferred. However, a multi-color master design can work if a single-color variant also looks good.
  • No halftones or grayscale: logo must be screen printable, laser etchable, and chemically etchable.
  • Only submissions in vector format will be considered, but do include a PNG preview.
  • Target size is approximately 30mm-50mm x 10-15mm tall (printable on the lower left bezel or as an etched metal plaque screwed in place).
  • Target color is Pantone 420U (gray), but other color suggestions and schemes are welcome.
  • Ideally looks good backlit, so we can also make stickers that go on the exposed LCD backlight for a nice effect.
  • The design could say “Novena” or “novena”, but we’re open minded to other names or an icon with no text. Novena was an arbitrary code name we picked based on our naming scheme of Singapore MRT stations.
  • Design should not infringe on any other trademarks.
  • By submitting an entry, the submitter agrees to having their submission publicly posted for review and, if the submitter’s entry is selected as the winner, to automatically give Kosagi globally unlimited, royalty-free and exclusive use of the logo design, with a desktop version of Novena as the sole compensation for the single winning submission. Submitters retain the rights to non-winning submissions.

    If you’ve already backed Novena at the desktop tier or above and you are the chosen winner, we will refund you the campaign value ($1,195) of the desktop pledge level.

    Thanks in advance to everyone who will participate in the Novena logo design competition!

    by bunnie at April 24, 2014 05:17 AM

    April 22, 2014

    Bunnie Studios

    Stretch Goals for Novena Campaign

    First, a heartfelt “thank you” to all those who have backed our crowdfunding campaign to bring Novena-powered open computing devices to the world. xobs and I are very flattered to have reached almost 70% of our goal already.

    One excellent outcome of the campaign is a lot of people have reached out to us to extend the Novena platform and make it even better, and so we’re offering a diverse range of stretch goals to provide an even better open laptop for all walks of users.

    Stretch #1: Partnering with Jon Nettleton for Open 2D/3D Graphics Drivers on Novena: +$50k ($300k total)

    We designed Novena to be the most open platform we could practically build. The hardware blueprints and software source code are available for download. The entire OS is buildable from human-readable source, and requires no binary blobs to boot and run well.

    However, there are elements of the i.MX6 SoC that lie dormant, due to a lack of open source drivers. In particular, the 2D/3D graphics accelerator in the i.MX6 has closed-source drivers. While we don’t force you to use these closed-source drivers, a major impediment to us being “libre” is the lack of open source drivers for these components.

    We’re excited to announce a partnership with Jon Nettleton, an expert on Linux graphics drivers, to enable this crucial piece of the libre puzzle. Here is a short statement from Jon Nettleton himself on the prospect:

    Novena Backers and OSS enthusiasts,

    I am very pleased to announce myself, Jon Nettleton (a.k.a. jnettlet, linux4kix), as a stretch-goal partner for the Novena Project. I will be taking on the task of assuring that the shipping Novena platforms will not require a binary userspace driver for 2D/3D graphics acceleration. Utilizing my experience working on Linux graphics drivers along with my strong community involvement, I will be making sure that contributing developers have everything they need to keep the Etnaviv driver project moving forward.

    To accomplish this we are requesting an additional $10,000 of funding. This additional capital will be used to not just fund my development effort, but to also provide incentives for other contributing developers. It will also benefit me the time to coordinate with other hardware vendors interested in supporting an open source graphics driver implementation for the Vivante chipset, and getting them involved. There is no “US“ and “THEM” in this effort. “WE” will bring to fruition a modern graphics accelerated desktop platform for the Novena Project.

    Therefore, if we can raise $50k over our original target of $250k, we will donate the $10k that Jon needs for the effort for providing open 2D/3D graphics drivers for the Novena platform. The remainder of that raised will be used to help cover the costs of building the hardware you ordered.

    Significantly, since this is an open source effort, everyone in the i.MX6 community can benefit from the outcome of this funding. Because of this, we’ve added a “Buy Jon a Six Pack ($30)” pledge tier (capped at 417 pledges) so that existing i.MX6 users who want to contribute toward this goal without buying our hardware can participate. For every dollar contributed to this pledge tier, we will give Jon Nettleton at least 80 cents, regardless of our ability to reach the first stretch goal. The other ~20 cents go toward compulsory campaign operation costs and financial operator transaction fees.

    Stretch #2: General-Purpose Breakout Board: +$100k ($350k total)

    We include a FPGA and a nice high-speed connector, but many users just want to toggle a GPIO or take a simple analog reading without having to design and build a PCBA from scratch. If we can raise an additional $50k over the previous stretch goal, we will include a General Purpose Breakout Board (GPBB) with every piece of hardware we ship.

    The GPBB buffers 16 FPGA outputs and 8 FPGA inputs to be compatible with either 3.3V or 5V, gang-selectable via software. It also provides six 10-bit analog inputs (up to 200ksps sample rate) and two 10bit analog outputs (~100ksps max rate), all broken out to an easy-to-use 40-pin male 0.1″ dual-row header.

    The GPBB is handy for all kinds of control and sensing situations. Because the GPBB is backed by a powerful FPGA, each of the buffered FPGA output lines can be programmed for a wide range of applications. For example, an FPGA output could be configured as a precision PWM channel with hard-real time feedback control for demanding robotics motor driver applications. Or it can be used to interface with bespoke serial protocols, such as those found in modern LED strip lighting.

    For user who don’t want to muck with FPGA code and prefer to grapple a GPIO from the command line, we have user-space drivers for the board prepared in Linux, through a combination of the Linux GPIO API, and the Linux I2C API. As a result it’s a snap to script up simple applications using your favorite high level language.

    Significantly, the GPBB isn’t vaporware — we developed this board originally for use as a breakout for production testing circuit stickers from our Chibitronics product line. At this very moment, the GPBB design is being used to drive mass production of circuit stickers.

    Stretch #3: ROMulator Breakout Board: +$150k ($400k total)

    We designed Novena to be a versatile hacking tool. Case in point, last December we reported results at 30C3 revealing a secret knock that can allow arbitrary code execution on select SD card controllers. We discovered this in part with the assistance of Novena.

    We used Novena as a ROMulator — a FLASH ROM emulator. For this application, we developed a flexible PCB that’s so thin, it can be soldered in between a TSOP FLASH ROM and the underlying PCB. In this mode, we can use the FPGA built into Novena to snoop the traffic going to and from the FLASH ROM.

    Alternately, the FPGA can be used to emulate a ROM device using its local 256 MiB of DDR3 memory. Since the DDR3 controller implementation is multi-ported, during ROM emulation one can inspect and modify the ROM contents on the fly without disrupting target operation. This has a number of powerful applications, from ToC/ToU attacks to speeding up firmware development on devices that load from NAND.

    If we can raise an additional $50k over the previous tier, we’ll include a ROMulator Breakout Board (in addition to the General Purpose Breakout Board) with every piece of hardware shipped.

    Stretch #4: MyriadRF Software Defined Radio: +$250k ($500k total) or >200 backers for the desktop/laptop/heirloom version

    Software! Defined! Radio! We’re very excited to offer the possibility of teaming up with MyriadRF, to provide a custom-made SDR solution for Novena. Their open hardware SDR solution operates in all the major radio bands, including LTE, CDMA, TD-CDMA, W-CDMA, WiMAX, 2G and many more.

    The retail price of the MyriadRF is $299, and MyriadRF has graciously pulled strings with their fabrication partner and enabled a low minimum order quantity of 200 units to build this custom version for Novena. If we can clear a total raise of $500k or at least 200 total backers for the desktop/laptop/heirloom version, we’ll include with every desktop/laptop/heirloom version a MyriadRF SDR board. Since the MyriadRF is such a high ticket-item, only desktop and higher tiers are eligible to receive this reward.

    Significantly, the MyriadRF extends beyond the front of the Novena case, so part of the money from this tier is going toward buying the extra tooling to provision a removable panel on the front edge of the case, so that when the SDR module is installed it can comfortably hang out of the case, giving easy access to the U.FL RF connectors.

    If you find these stretch goals exciting and/or useful, please visit our campaign page and join the community helping to bring open hardware to the world, and please help us spread the word!

    by bunnie at April 22, 2014 05:08 PM

    April 21, 2014

    Andrew Zonenberg, Silicon Exposed

    Getting my feet wet with invasive attacks, part 1: Target recon

    This is part 1 of a 2-part series. Part 2, The Attack, is here.

    One of the reasons I've gone a bit dark lately is that running CSCI 6974, RPI's experimental hardware reverse engineering class, has been eating up a lot of my time.

    I wanted to make the final lab for the course a nice climax to the semester and do something that would show off the kinds of things that are possible if you have the right gear, so it had to be impressive and technically challenging. The obvious choice was a FIB circuit edit combined with invasive microprobing.

    After slaving away for quite a while (this was started back in January or so) I've managed to get something ready to show off :) The work described here will be demonstrated in front of my students next week as part of the fourth lab for the class.

    The first step was to pick a target. I was interested in the Xilinx XC2C32A for several reasons and was already using other parts of the chip as a teaching subject for the class. It's a pure-digital CMOS CPLD (no analog sense amps and a fairly regular structure) made on a relatively modern process (180 nm 4-metal UMC) but not so modern as to be insanely hard to work with. It was also quite cheap ($1.25 a pop for the slowest speed grade in VQG44 package on DigiKey) so I could afford to kill plenty of them during testing

    The next step was to decap a few, label interesting pins, and draw up a die floorplan. Here's a view of the die at the implant layer after Dash etch; P-type doping shows up as brown. (John did all of the staining work and got great results. Thanks!)

    XC2C32A die floorplan after Dash etch
    The bottom half of the die is support infrastructure with EEPROM banks for storing the configuration bitstream toward the center and JTAG/configuration stuff in a U-shape below and to either side of the memory array. (The EEPROM is mislabeled "flash" in this image because I originally assumed it was 1T NOR flash. Higher magnification imaging later showed this to be wrong; the bit cells are 2T EEPROM.)

    The top half of the die is the actual programmable logic, laid out in a "butterfly" structure. The center spine is the ZIA (global routing, also referred to as the AIM in some datasheets), which takes signals from the 32 macrocell flipflops and 33 GPIO pins and routes them into the function blocks. To either side of the spine are the two FBs, which consist of an 80 x 56 AND array (simplifying a bit... the actual structure is more like 2 blocks x 20 rows x 2 interleaved cells x 56 columns), a 56 x 16 OR array, and 16 macrocells.

    I wanted some interesting data to show my students so there were two obvious choices. First, I could try to defeat the code protection somehow and read bitstreams out of a locked device via JTAG. Second, I could try to read internal device state at run time. The second seemed a bit easier so I decided to run with it (although defeating the lock bits is still on my longer-term TODO.)

    The obvious target for probing internal runtime state is the ZIA, since all GPIO inputs and flipflop states have to go through here. Unfortunately, it's almost completely undocumented! Here's the sum total of what DS090 has to say about it (pages 5-6):
    The Advanced Interconnect Matrix is a highly connected low power rapid switch. The AIM is directed by the software to deliver up to a set of 40 signals to each FB for the creation of logic. Results from all FB macrocells, as well as, all pin inputs circulate back through the AIM for additional connection available to all other FBs as dictated by the design software. The AIM minimizes both propagation delay and power as it makes attachments to the various FBs.
    Thanks for the tidbit, Xilinx, but this really isn't gonna cut it. I need more info!

    The basic ZIA structure was pretty obvious from inspection of the implant layer: 20 identical copies of the same logic. This suggested that each row was responsible for feeding two signals left and two right.

    SEM imaging of the implant layer showed the basic structure to be largely, but not entirely, symmetric about the left-right axis. At the far outside a few cells of the PLA AND array can be seen. Moving toward the center is what appears to be a 3-stage buffer, presumably for driving the row's output into the PLA. The actual routing logic is at center.

    The row appeared entirely symmetric top-to-bottom so I focused my future analysis on the upper half.

    Single row of the ZIA seen at the implant layer after Dash etch. Light gray is P-type doping, medium gray is N-type doping, dark gray is STI trenches.
    Looking at the top metal layer revealed the expected 65 signals.

    Single row of the ZIA seen on metal 4
    The signals were grouped into six groups with 11, 11, 11, 11, 11, and 10 signals in them. This led me to suspect that there was some kind of six-fold structure to the underlying circuitry, a suspicion which was later proven correct.

    Inspection of the configuration EEPROM for the ZIA showed it to be 16 bits wide by 48 rows high.

    ZIA configuration EEPROM (top few rows)
    Since the global configuration area in the middle of the chip was 8 rows high this suggested that each of the 40 remaining EEPROM rows configured the top or bottom half of a ZIA row.

    Of the 16 bits in each row, 8 bits presumably controlled the left-hand output and 8 controlled the right. This didn't make a lot of sense at first: dense binary coding would require only 7 bits for 65 channels and one-hot coding would need 65 bits.

    Reading documentation for related device families sometimes helps to shed some light on how a part was designed, so I took a look at some of the whitepapers for the older 350 nm CoolRunner XPLA3 series. They went into some detail on how full crossbar routing was wasteful of chip area and often not necessary to get sufficient routability. You don't need to be able to generate every 40! permutations of a given subset of signals as long as you can route every signal somehow. Instead, the XPLA3's designers connected only a handful of the inputs to each row and varied the input selection for each row so as to allow almost every possible subset to be selected somehow.

    This suggested a 2-level hierarchy to the ZIA mux. Instead of being a 65:1 mux it was a 65:N hard-wired mux followed by a N:1 programmable mux feeding left and another N:1 feeding right. 6 seemed to be a reasonable guess for N, given the six groups of wires on metal 4.

    ZIA mux structure
    This hypothesis was quickly confirmed by looking at M3 and M3-M4 vias: Each row had six short wires on M3, one under each of the six groups of wires in the bus. Each of these short lines was connected by one via to one of the bus lines on M4. The via pattern varied from row to row as expected.

    ZIA M3-M4 vias

    I extracted the full via pattern by copying a tracing of M4 over the M3 image and using the power vias running down the left side as registration marks. (Pro tip: Using a high accelerating voltage, like 20 kV, in a SEM gives great results on aluminum processes with tungsten via plugs. You get backscatters from vias through the metal layer that you can use for aligning image stacks.) A few of the rows are shown above.

    At this point I felt I understood most of the structure so the next step was full circuit extraction! I had John CMP a die down to each layer and send to me for high-res imaging in the SEM.

    The output buffers were fairly easy. As I expected they were just a 3-stage inverter cascade.

    Output buffer poly/diffusion/contact tracing

    Output buffer M1 tracing
    Output buffer gate-level schematic

    Individual cell schematics
    Nothing interesting was present on any of the upper layers above here, just power distribution.

    The one surprising thing about the output buffer was that the NMOS on the third stage had a substantially wider channel than the PMOS. This is probably something to do with optimizing output rise/fall times.

    Looking at the actual mux logic showed that it was mostly tiles of the same basic pattern (a 6T SRAM cell, a 2-input NOR gate, and a large multi-fingered NMOS pass transistor) except for the far left side.

    Gate-level layout of mux area

    Left side of mux area, gate-level layout
    The same SRAM-feeding-NOR2 structure is seen, but this time the output is a small NMOS or PMOS pass transistor.

    After tracing M1, it became obvious what was going on.

    Left side of mux area, M1

    The upper and lower halves control the outputs to function blocks 1 and 2 respectively. The two SRAM bits allow each output (labeled MUXOUT_FBx) to be pulled high, low, or float. A global reset line of some sort, labeled OGATE, is used to gate all logic in the entire ZIA (and presumably the rest of the chip); when OGATE is high the SRAM bits are ignored and the output is forced high.

    Here's what it looks like in schematic:

    Gate-level schematics of pullup/pulldown logic
    Cell schematics
    In the schematics I drew the NOR2v0x1 cell as its de Morgan dual (AND with inverted inputs) since this seemed to make more sense in the context of the circuit: the output is turned on when the active-low input is low and OGATE is turned off.

    It's interesting to note that while almost all of the config bits in the circuit are active-low, PULLUP is active-high. This is presumably done to allow the all-ones state (a blank EEPROM array) to put the muxes in a well-defined state rather than floating.

    Turning our attention to the rest of the mux array shows a 6:1 one-hot-coded mux made from NMOS pass transistors. This, combined with the 2 bits needed for the pull-high/pull-low module, adds up to the expected 8.  The same basic pattern shown below is tiled three times.
    Basic mux tile, poly/implant
    Basic mux tile, M1
    (Sorry for the misalignment of the contact layer, this was a quick tracing and as long as I was able to make sense of the circuit I didn't bother polishing it up to look pretty!)

    The resulting schematic:

    Schematic of muxes

    M2 was used for some short-distance routing as well as OGATE, power/ground busing, and the SRAM bit lines.

    M2 and M2-M3 vias


    M3 was used for OGATE, power busing, SRAM word lines, the mask-programmed muxes, and the tri-state bus within the final mux.



    M3 and M3-M4 vias

    And finally, M4. I never found out what the leftmost power line went to, it didn't appear to be VCCINT or ground but was obviously power distribution. There's no reason for VCCIO to be running down the middle of the array so maybe VCCAUX? Reversing the global config logic may provide the answer.

    M4
    A bit of trial and error poking bits in bitstreams was sufficient to determine the ordering of signals. From right to left we have FB1's GPIO pins, the input-only pin, FB2's GPIO pins, then FB1's flipflops and finally FB2's flipflops.

    Now that I had good intel on the target, it was time to plan the strike!

    Part 2, The Attack, is here.

    by Andrew Zonenberg (noreply@blogger.com) at April 21, 2014 10:11 PM

    April 19, 2014

    Video Circuits

    VIDEO CIRCUITS FILM NIGHT

    So Ben from Cinematograph Film Club asked me to do a Video Circuits film night as part of his latest group of screenings, So I have put together a list of artists work that I will be screening on the night, I might bring down a CRT and some video gear for fun as well :3

    Time 20:00
    Date 27 April
    Location The Duke Of Wellington, London N1

    here is the facebook event link
    cinematographfilmclub.tumblr.com

    and here is a little experiment form my diy video synth


    Artists:

    James Alec Hardy

    by Chris (noreply@blogger.com) at April 19, 2014 05:31 AM

    April 18, 2014

    Video Circuits

    Jonathan Gillie

    Here is some interesting video collage work from Jonathan Gillie using Tachyons+ gear to generate the video effects and then arranged in after effects



    http://jonathangillieportfolio.tumblr.com/
    http://jongillie.tumblr.com/

    by Chris (noreply@blogger.com) at April 18, 2014 05:59 AM

    April 15, 2014

    Peter Zotov, whitequark

    A guide to extension points in OCaml

    Extension points (also known as “-ppx syntax extensions”) is the new API for syntactic extensions in OCaml. The old API, known as camlp4, is very flexible, but also huge, practically undocumented, lagging behind the newly introduced syntax in the compiler, and just overall confusing to those attempting to use it.

    Extension points are an excellent and very simple replacement introduced by Alain Frisch. In this article, I will explain how to amend OCaml’s syntax using the extension points API.

    Note that the features I describe in this article are so bleeding edge, it’ll need constant transfusions just to stay alive. The last transfusion, er, update, happened on 2014-05-07.

    In order to use the extension points API, you’ll need a trunk compiler. As it already is not shipped with camlp4, you will need to install camlp4 separately. This all can be done with opam:

    1
    2
    
    opam switch reinstall 4.02.0dev+trunk
    opam install camlp4 ocamlfind oasis

    What is Camlp4?

    At its core, camlp4 (P4 stands for Pre-Processor-Pretty-Printer) is a parsing library which provides extensible grammars. That is, it makes possible to define a parser and then, later, make a derived parser by adding a few rules to the original one. The OCaml syntax (two OCaml syntaxes, in fact, the original one and a revised one introduced specifically for camlp4) is just a special case.

    When using camlp4 syntax extensions with OCaml, you write your program in a syntax which is not compatible with OCaml’s (neither original nor revised one). Then, the OCaml compiler (when invoked with the -pp switch) passes the original source to the preprocessor as text; when the preprocessor has finished its work, it prints back valid OCaml code.

    There are a lot of problems with this approach:

    • It is confusing to users. Camlp4 preprocessors can define almost any imaginable syntax, so unless one is also familiar with all the preprocessors used, it is not in general possible to understand the source.

    • It is confusing to tools, for much the same reason. For example, Merlin has no plans to support camlp4 in general, and has implemented a workaround for few selected extensions, e.g. pa_ounit.

    • Writing camlp4 extensions is hard. It requires learning a new (revised) syntax and a complex, scarcely documented API (try module M = Camlp4;; in utop—the signature is 16255 lines long. Yes, sixteen thousand.)

    • It is not well-suited for type-driven code generation, which is probably the most common use case for syntax extensions, because it is hard to make different camlp4 extensions cooperate; type_conv was required to enable this functionality.

    • Last but not the least, using camlp4 prevents OCaml compiler from printing useful suggestions in error messages like File "ifdef.ml", line 17: This '(' might be unmatched. Personally, I find that very annoying.

    What is the extension points API?

    The extension points API is much simpler:

    • A syntax extension is now a function that maps an OCaml AST to an OCaml AST. Correspondingly, it is no longer possible to extend syntax in arbitrary ways.

    • To make syntax extensions useful for type-driven code generation (like type_conv), the OCaml syntax is enriched with attributes.

      Attributes can be attached to pretty much any interesting syntactic construct: expressions, types, variant constructors, fields, modules, etc. By default, attributes are ignored by the OCaml compiler.

      Attributes can contain a structure, expression or pattern as their payload, allowing a very wide range of behavior.

      For example, one could implement a syntax extension that would accept type declarations of form type t = A [@id 1] | B [@id 4] of int [@@id_of] and generate a function mapping a value of type t to its integer representation.

    • To make syntax extensions useful for implementing custom syntactic constructs, especially for control flow (like pa_lwt), the OCaml syntax is enriched with extension nodes.

      Extension nodes designate a custom, incompatible variant of an existing syntactic construct. They’re only available for expression constructs: fun, let, if and so on. When the OCaml compiler encounters an extension node, it signals an error.

      Extension nodes have the same payloads as attributes.

      For example, one could implement a syntax extension what would accept a let binding of form let%lwt (x, y) = f in x + y and translate them to Lwt.bind f (fun (x, y) -> x + y).

    • To make it possible to insert fragments of code written in entirely unrelated syntax into OCaml code, the OCaml syntax is enriched with quoted strings.

      Quoted strings are simply strings delimited with {<delim>| and |<delim>}, where <delim> is a (possibly empty) sequence of lowercase letters. They behave just like regular OCaml strings, except that syntactic extensions may extract the delimiter.

    Using the extension points API

    On a concrete level, a syntax extension is an executable that receives a marshalled OCaml AST and emits a marshalled OCaml AST. The OCaml compiler now also accepts a -ppx option, specifying one or more extensions to preprocess the code with.

    To aid this, the internals of the OCaml compiler are now exported as the standard findlib package compiler-libs. This package, among other things, contains the interface defining the OCaml AST (modules Asttypes and Parsetree) and a set of helpers for writing the syntax extensions (modules Ast_mapper and Ast_helper).

    I won’t describe the API in detail; it’s well-documented and nearly trivial (especially when compared with camlp4). Rather, I will describe all the necessary plumbing one needs around an AST-mapping function to turn it into a conveniently packaged extension.

    It is possible, but extremely inconvenient, to pattern-match and construct the OCaml AST manually. The extension points API makes it much easier:

    • It provides an Ast_mapper.mapper type and Ast_mapper.default_mapper value:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    
    type mapper = {
      (* ... *)
      expr: mapper -> expression -> expression;
      (* ... *)
      structure: mapper -> structure -> structure;
      structure_item: mapper -> structure_item -> structure_item;
      typ: mapper -> core_type -> core_type;
      type_declaration: mapper -> type_declaration -> type_declaration;
      type_kind: mapper -> type_kind -> type_kind;
      value_binding: mapper -> value_binding -> value_binding;
      (* ... *)
    }
    val default_mapper : mapper
    

    The default_mapper is a “deep identity” mapper, i.e. it traverses every node of the AST, but changes nothing.

    Together, they provide an easy way to use open recursion, i.e. to only handle the parts of AST which are interesting to you.

    • It provides a set of helpers in the Ast_helper module which simplify constructing the AST. (Unlike Camlp4, extension points API does not provide code quasiquotation, at least for now.)

      For example, Exp.tuple [Exp.constant (Const_int 1); Exp.constant (Const_int 2)] would construct the AST for (1, 2). While unwieldy, this is much better than elaborating the AST directly.

    • Finally, it provides an Ast_mapper.run_main function, which handles the command line arguments and I/O.

    Example

    Let’s assemble it all together to make a simple extension that replaces [%getenv "<var>"] with the compile-time contents of the variable <var>.

    First, let’s take a look at the AST that [%getenv "<var>"] would parse to. To do this, invoke the OCaml compiler as ocamlc -dparsetree foo.ml:

    1
    
    let _ = [%getenv "USER"]
    
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    
    [
      structure_item (test.ml[1,0+0]..[1,0+24])
        Pstr_eval
        expression (test.ml[1,0+8]..[1,0+24])
          Pexp_extension "getenv"
          [
            structure_item (test.ml[1,0+17]..[1,0+23])
              Pstr_eval
              expression (test.ml[1,0+17]..[1,0+23])
                Pexp_constant Const_string("USER",None)
          ]
    ]
    

    As you can see, the grammar category we need is “expression”, so we need to override the expr field of the default_mapper:

    ppx_getenv.ml
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    
    open Ast_mapper
    open Ast_helper
    open Asttypes
    open Parsetree
    open Longident
    open Location
    
    let getenv s = try Sys.getenv s with Not_found -> ""
    
    exception Error of Location.t
    
    let () =
      Location.register_error_of_exn (fun exn ->
        match exn with
        | Error loc ->
          Some (error ~loc "[%getenv] accepts a string, e.g. [%getenv \"USER\"]")
        | _ -> None)
    
    let getenv_mapper argv =
      (* Our getenv_mapper only overrides the handling of expressions in the default mapper. *)
      { default_mapper with
        expr = fun mapper expr ->
          match expr with
          (* Is this an extension node? *)
          | { pexp_desc =
              (* Should have name "getenv". *)
              Pexp_extension ({ txt = "getenv"; loc }, pstr)} ->
            begin match pstr with
            | (* Should have a single structure item, which is evaluation of a constant string. *)
              PStr [{ pstr_desc =
                      Pstr_eval ({ pexp_loc  = loc;
                                   pexp_desc =
                                   Pexp_constant (Const_string (sym, None))}, _)}] ->
              (* Replace with a constant string with the value from the environment. *)
              Exp.constant ~loc (Const_string (getenv sym, None))
            | _ -> raise (Error loc)
            end
          (* Delegate to the default mapper. *)
          | x -> default_mapper.expr mapper x;
      }
    
    let () = run_main getenv_mapper
    

    The sample code also demonstrates how to report errors from the extension.

    This syntax extension can be easily compiled e.g. with ocamlbuild -package compiler-libs.common ppx_getenv.native.

    You can verify that this produces the desirable result by asking OCaml to pretty-print the transformed source: ocamlc -dsource -ppx ./ppx_getenv.native foo.ml:

    1
    
    let _ = "whitequark"
    

    Packaging

    When your extension is ready, it’s convenient to build and test it with OASIS, and distribute via opam. This is not hard, but has a few gotchas.

    The OASIS configuration I suggest is simple:

    _oasis
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    
    # (header...)
    OCamlVersion: >= 4.02
    
    Executable ppx_getenv
      Path:           lib
      BuildDepends:   compiler-libs.common
      MainIs:         ppx_getenv.ml
      CompiledObject: best
    
    Test test_ppx_protobuf
      Command:        ocamlbuild -I lib -package oUnit  \
                                 -cflags '-ppx $ppx_getenv' \
                                 lib_test/test_ppx_getenv.byte --
      TestTools:      ppx_getenv

    The basic opam package can be generated with oasis2opam.

    After installing, the extension executable will be placed into ~/.opam/<version>/bin.

    It is currently not possible to engage the syntax extension via findlib at all. To use it in applications, the following myocamlbuild.ml rule will work:

    myocamlbuild.ml
    1
    2
    3
    4
    5
    6
    
    dispatch begin
      function
      | After_rules ->
        flag ["ocaml"; "compile"; "use_ppx_getenv"] (S[A"-ppx"; A"ppx_getenv"]);
      | _ -> ()
    end
    

    Conclusion

    The extension points API is really nice, but it’s not as usable yet as it could be. Nevertheless, it’s possible to create and use extension packages without too much ugly workarounds.

    References

    If you are writing an extension, you’ll find this material useful:

    Other than the OCaml sources, I’ve found Alain Frisch’s two articles (1, 2) on the topic extremely helpful. I only mention them now because they’re quite outdated.

    April 15, 2014 11:53 PM

    Bunnie Studios

    Myriad RF for Novena

    This is so cool. Myriad-RF has created a port of their wideband software defined radio to Novena (read more at their blog). Currently, it’s just CAD files, but if there’s enough interest in SDR on Novena, they may do a production run.

    The board above is based on the Myriad-RF 1. It is a fully configurable RF board that covers all commonly used communication frequencies, including LTE, CDMA, TD-CDMA, W-CDMA, WiMAX, 2G and many more. Their Novena variant plugs right into our existing high speed expansion slot — through pure coincidence both projects chose the same physical connector format, so they had to move a few traces and add a few components to make their reference design fully inter-operable with our Novena design. Their design (and the docs for the transceiver IC) is also fully open source, and in fact they’ve one-upped us because they use an open tool (KiCad) to design their boards.

    I can’t tell you how excited I am to see this. One of our major goals in doing a crowdfunding campaign around Novena is to raise community awareness of the platform and to grow the i.MX6 ecosystem. We can’t do everything we want to do with the platform by ourselves, and we need the help of other talented developers, like those at Myriad-RF, to unlock the full potential of Novena.

    by bunnie at April 15, 2014 07:03 PM

    April 14, 2014

    Sebastien Bourdeauducq, lekernel.net

    EHSM-2014 CFP

    CALL FOR PARTICIPATION

    Exceptionally Hard & Soft Meeting
    pushing the frontiers of open source and DIY
    DESY, Hamburg site, June 27-29 2014
    http://ehsm.eu
    @ehsmeeting

    Collaboration between open source and research communities empowers open hardware to explore new grounds and hopefully deliver on the “third industrial revolution”. The first edition of the Exceptionally Hard and Soft Meeting featured lectures delivered by international makers, hackers, scientists and engineers on topics such as nuclear fusion, chip design, vacuum equipment machining, and applied quantum physics. Tutorials gave a welcoming hands-on introduction to people of all levels, including kids.

    EHSM is back in summer 2014 for another edition of the most cutting-edge open source conference. This year we are proud to welcome you to an exceptional venue: DESY, Europe’s second-largest particle physics laboratory!

    Previous EHSM lectures may be viewed at: http://ehsm.eu/2012/media.html

    ATTEND WITHOUT PRESENTING:
    Attendance is open to all curious minds.

    EHSM is entirely supported by its attendees and sponsors. To help us make this event happen, please donate and/or order your ticket as soon as possible by visiting our website http://ehsm.eu.
    Prices are:

    • 45E – student/low-income online registration
    • 95E – online registration
    • 110E – door ticket
    • 272E – supporter ticket, with our thanks and your name on the website.
    • 1337E – gold supporter ticket, with our thanks and your company/project logo on the website and the printed programme.

    EHSM is a non-profit event where the majority of the budget covers speakers’ travel and transportation of exhibition equipment.

    SPEAKERS: SUBMIT YOUR PRESENTATION
    Is there a device in your basement that demonstrates violations of Bell’s inequalities? We want to see it in action. Are you starting up a company to build nuclear fusion reactors? Tell us about it. Does your open source hardware or software run some complex, advanced and beautiful scientific instruments? We are eager to learn about it. Do you have stories to tell about your former job manufacturing ultra high vacuum equipment in the Soviet Union? We want to hear about your experiences. Do you have a great design for a difficult open source product that can be useful to millions? Team up with the people who can help implement your ideas.

    Whoever you are, wherever you come from, you are welcome to present technologically awesome work at EHSM. Travel assistance and visa invitation letters provided upon request. All lectures are in English.

    This year, we will try to improve the conference’s documentation by publishing proceedings. When relevant, please send us a paper on
    your presentation topic. We are OK with previously published work, we simply expect high quality and up-to-date content.

    To submit your presentation, send a mail to team@ehsm.eu with typically the following information:

    • Your name(s). You can be anonymous if you prefer.
    • Short bio
    • Title of the presentation
    • Abstract
    • How much time you would like
    • Full paper (if applicable)
    • Links to more information (if available)
    • Contact information (e-mail + mobile phone if possible)
    • If you need us to arrange your trip:
    • Where you would be traveling from
    • If you need accommodation in Hamburg

    We will again have an exhibition area where you can show and demonstrate your work – write to the same email address to apply for space. If you are bringing bulky or high-power equipment, make sure to let us know:

    • What surface you would use
    • What assistance you would need for equipment transport between your lab and the conference
    • If you need 3-phase electric power (note that Germany uses 230V/400V 50Hz)
    • What the peak power of your installation would be

    Tutorials on any technology topic are also welcome, and may cater to all levels, including beginners and kids.

    We are counting on you to make this event awesome. Feel free to nominate other speakers that you would like to see at the conference, too – just write us a quick note and we will contact them.

    KEY INFORMATION:
    Conference starts: morning of June 27th, 2014
    Conference ends: evening of June 29th, 2014
    Early registration fee ends: February 1st, 2014
    Please submit lectures, tutorials and exhibits before: May 15th, 2014

    Conference location:
    DESY
    Notkestrasse 85
    22607 Hamburg, Germany

    WE ARE LOOKING FORWARD TO WELCOMING YOU IN HAMBURG!
    - EHSM e.V. <http://ehsm.eu>

    by lekernel at April 14, 2014 07:42 PM

    April 13, 2014

    Peter Zotov, whitequark

    XCompose support in Sublime Text

    Sublime Text is an awesome editor, and XCompose is very convenient for quickly typing weird Unicode characters. However, these two don’t combine: Sublime Text has an annoying bug which prevents the xim input method, which handles XCompose files, from working.

    What to do? If Sublime Text was open-source, I’d make a patch. But it is not. However, I still made a patch.

    If you just want XCompose to work, then add the sublime-imethod-fix PPA to your APT sources, install the libsublime-text-3-xim-xcompose package, and restart Sublime Text. (That’s it!) Or, build from source if you’re not on Ubuntu.

    However, if you’re interested in all the gory (and extremely boring) details, with an occasional animated gif, read on.

    Hunting the bug

    To describe the bug, I will first need to explain its natural environment. In Linux, a desktop graphics stack consists of an X11 server and an application using the Xlib library for drawing the windows and handling user input. When it was conceived, a top-notch UI looked like this:

    The X11 protocol and Xlib library are quite high-level: originally, you were expected to send compact, high-level instructions over the wire (such as “fill a rectangle at (x,y,x’,y’)”) in order to support thin clients over slow networks. However, thin clients and mainframes vanished, and in their place came a craving for beautiful user interfaces; and X11 protocol, primitive as it is, draws everything as if it came from 1993. (It is also worth noting that X went from X1 to X11 in three years, and has not changed since then.)

    The Compose key and XCompose files are a remnant of that era. Xlib has a notion of input method; that is, you would feed raw keypresses (i.e. the coordinates of keys on the keyboard) to Xlib and it would return you whole characters. This ranged from extremely simple US input method (mapping keys to characters 1:1) to more complex input methods for European languages (using a dedicated key to produce composite characters like é and ç) to very intricate Chinese and Japanese input methods with complex mappings between Latin input and ideographic output.

    Modern GUI toolkits like GTK and Qt ignore the X11 protocol almost entirely. The only drawing operation in use is “transfer this image and slap it over a rectangular area” (which isn’t even present in the original X11 protocol). Similarly, they pretty much ignore the X input method, favoring more modern scim and uim.

    XCompose is probably the only useful part of the whole X11 stack. Unfortunately, native XCompose support is not present anywhere except the original X input method. Fortunately, both GTK and Qt allow changing their input method to XIM. Unfortunately, Sublime Text somehow ignored the X input method completely even when instructed to use it.

    Sublime Text draws its own UI entirely to make it look nice on all the platforms. As such, on Linux it has three layers of indirection: first its own GUI toolkit, then GTK, which it uses to avoid dealing with the horror of X11, then X11 itself.

    The Xlib interface for communicating with the input method is pretty simple: it’s just the XmbLookupString function. You would feed it the XPressedKeyEvents containing key codes that you receive from the X11 server, and it would give back a string, possibly empty, with the sequence of characters you need to insert in your text area. Also, in order to start communicating, you need to initialize an X input context corresponding to a particular X window. (An X window is what you’d call a window, but also what you’d call a widget—say, a button has its own X11 window.)

    GTK packs the input method communication logic in the gtk_im_context_xim_filter_keypress function it has in its wrapper around the X input method. From there, it’s a pretty deep hole:

    • gtk_im_context_xim_filter_keypress uses a helper gtk_im_context_xim_get_ic to get the X input context, and if no context is returned, it resorts to a trivial US keymap;
    • gtk_im_context_xim_get_ic pulls the X input method handle and associated GTK settings from the ((GtkIMContextXIM *)context_xim)->im_info field;
    • which is initialized by the set_ic_client_window helper;
    • which refuses to initialize it if ((GtkIMContextXIM *)context_xim)->client_window is NULL;
    • which is called (through one more layer of indirection used by GTK to change the input methods on the fly) by Sublime Text itself;
    • which passes NULL as the client_window.

    Now, why does that happen? Sublime Text calls gtk_im_context_set_client_window (the helper that eventually delegates to set_ic_client_window) in a snippet of code which looks roughly like this:

    1
    2
    3
    4
    5
    6
    7
    8
    
    void sublimetext::gtk2::initialize() {
      // snip
      GtkWindow *window = gtk_window_new ();
      // a bit more initialization
      GtkIMContext *context = gtk_im_multicontext_new ();
      gtk_im_context_set_client_window(GTK_IM_CONTEXT(context), window->bin.container.widget.window);
      // snip
    }
    

    What is that window->bin.container.widget.window? It contains the GdkWindow of the GtkWindow; Sublime Text has to fetch it to pass to gtk_im_context_set_client_window, which wants a GdkWindow.

    What is a GdkWindow? It’s a structure used by GTK to wrap X11 windows on Linux and other native structures on the rest of platforms. As such, if the GdkWindow and its underlying X11 window are not yet created, say, because these windows were yet never shown, the field would contain NULL. And since Sublime Text attempts to bind the IM context to the window immediately after creating the latter, this is exactly the bug which we observe.

    It is worth noting that while no input methods that require the window to be know work, a simple GTK fallback that queries the system for the key configured as Compose key, but uses internally defined tables with commonly used sequences, does. This is why if you launch Sublime Text as GTK_IM_METHOD=whatever-really subl allows you to enter ° with <Multi_key> <o> <o>, but not customize it by changing any of the XCompose files.

    Cooking the meat

    How do we fix this? I started with a simple gdb script:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    
    # Run as: $ GTK_IM_MODULE=xim gdb -script fix-xcompose-sublime-text-3061.gdb
    file /opt/sublime_text/sublime_text
    set follow-fork-mode child
    set detach-on-fork off
    run
    inferior 2
    set follow-fork-mode parent
    set detach-on-fork on
    
    b *0x5b3267
    c
    del 1
    set $multicontext = (GtkIMMulticontext*) $r13
    set $window = (GtkWindow*) $rbx
    
    b gtk_widget_show if widget==$window
    c
    fin
    del 2
    
    call gtk_im_context_set_client_window($multicontext,$window->bin.container.widget.window)
    detach inferiors 1 2
    quit

    On a high level, the script does four things:

    1. Sublime Text forks at startup, so the script has to do a little funny dance to attach gdb to the correct process.
    2. Then, it stops at the point in the initialization sequence where my Sublime Text build calls gtk_im_context_set_client_window, and captures the window and multicontext variables, which the compiler happened to leave around in spare registers.
    3. Then, it waits until GTK surely initializes a GdkWindow for the window GtkWindow.
    4. Then, it calls gtk_im_context_set_client_window again, exactly as Sublime Text would, but at the right time.

    The script works. However, it is slow at startup and not very convenient in general. In particular, I would have to rewrite it every time Sublime Text updates. So, I opted for a better approach.

    LD_PRELOAD (see also tutorial: 1, 2) is a convenient feature of Linux dynamic linker which allows to substitute some functions contained in a shared library with different functions contained in another shared library. This is how, for example, fakeroot performs its magic.

    Initially I wanted to intercept gtk_window_new and gtk_im_multicontext_new to get the GtkIMMulticontext and the GtkWindow Sublime Text creates—they’re the first ever created—and then gtk_im_context_filter_keypress to call gtk_im_context_set_client_window before the first keypress is handled. But, somehow these calls were not intercepted by LD_PRELOAD; perhaps a weird way Sublime Text calls dlsym? I never figured it out.

    So, eventually I settled on intercepting the initialization of the GTK XIM input method plugin (which is loaded by GTK itself and therefore can be intercepted easily) and replacing its filter_keypress handler with my own. A filter_keypress handler receives a GtkIMContext and a GdkEvent, which contains the pointer to GdkWindow, so that would give me all the information I need.

    That worked.

    Celebrating the game

    Indeed, the goal was achieved in full. It only took me about ten hours, with practically no prior knowledge of libx11 or libgtk internals, access to Sublime Text source, or experience in reverse engineering.

    But what was this for? I don’t think I ever needed to type ಠ_ಠ in Sublime Text.

    I think I just like the sense of control over my tools.

    April 13, 2014 10:06 PM

    April 12, 2014

    Andrew Zonenberg, Silicon Exposed

    Getting my feet wet with invasive attacks, part 2: The attack

    This is part 2 of a 2-part series. Part 1, Target Recon, is here.

    Once I knew what all of the wires in the ZIA did, the next step was to plan an attack to read signals out.

    I decapped an XC2C32A with concentrated sulfuric acid and soldered it to my dev board to verify that it was alive and kicking.

    Simple CR-II dev board with integrated FTDI USB-JTAG
    After testing I desoldered the sample and brought it up to campus to introduce it to some 30 keV Ga+ ions.

    I figured that all of the exposed packaging would charge, so I'd need to coat the sample with something. I normally used sputtered Pt but this is almost impossible to remove after deposition so I decided to try evaporated carbon, which can be removed nicely with oxygen plasma among other things.

    I suited up for the cleanroom and met David Frey, their resident SEM/FIB expert, in front of the Zeiss 1540 FIB system. He's a former Zeiss engineer who's very protective of his "baby" and since I had never used a FIB before there was no way he was going to let me touch his, so he did all of the work while I watched. (I don't really blame him... FIB chambers are pretty cramped and it's easy to cause expensive damage by smashing into something or other. Several SEMs I've used have had one detector or another go offline for repair after a more careless user broke something.)

    The first step was to mill a hole through the 900 nm or so of silicon nitride overglass using the ion beam.

    Newly added via, not yet filled
    Once the via was drilled and it appeared we had made contact with the signal trace, it was time to backfill with platinum. The video below is sped up 10x to avoid boring my readers ;)


    Metal deposition in a FIB is basically CVD: a precursor gas is injected into the chamber near the sample and it decomposes under the influence of beam-generated secondary electrons.

    Once the via was filled we put down a large (20 μm square) square pad we could hit with an electrical probe needle.

    Probe pad
    Once everything was done and the chamber was vented I removed the carbon coating with oxygen plasma (the cleanroom's standard photoresist removal process), packaged up my sample, went home, and soldered it back to the board for testing. After powering it up... nothing! The device was as dead as a doornail, I couldn't even get a JTAG IDCODE from it.

    I repeated the experiment a week or two later, this time soldering bare stub wires to the pins so I could test by plugging the chip into a breadboard directly. This failed as well, but watching my benchtop power supply gave me a critical piece of information: while VCCINT was consuming the expected power (essentially zero), VCCIO was leaking by upwards of 20 mA.

    This ruled out beam-induced damage as I had not been hitting any of the I/O circuitry with the ion beam. Assuming that the carbon evaporation process was safe (it's used all the time on fragile samples, so this seemed a reasonably safe assumption for the time being), this left only the plasma clean as the potential failure point.

    I realized what was going on almost instantly: the antenna effect. The bond wire and leadframe connected to each pad in the device was acting as an antenna and coupling some of the 13.56 MHz RF energy from the plasma into the input buffers, blowing out the ESD diodes and input transistors, and leaving me with a dead chip.

    This left me with two possible ways to proceed: removing the coating by chemical means (a strong oxidizer could work), or not coating at all. I decided to try the latter since there were less steps to go wrong.

    Somewhat surprisingly, the cleanroom staff had very limited experience working with circuit edits - almost all of their FIB work was process metrology and failure analysis rather than rework, so they usually coated the samples.

    I decided to get trained on RPI's other FIB, the brand-new FEI Versa 3D. It's operated by the materials science staff, who are a bit less of the "helicopter parent" type and were actually willing to give me hands-on training.

    FEI Versa 3D SEM/FIB
    The Versa can do almost everything the older 1540 can do, in some cases better. Its one limitation is that it only has a single-channel gas injection system (platinum) while the 1540 is plumbed for platinum, tungsten, SiO2, and two gas-assisted etches.

    After a training session I was ready to go in for an actual circuit edit.

    FIB control panel
    The Versa is the most modern piece of equipment I've used to date: it doesn't even have the classical joystick for moving the stage around. Almost everything is controlled by the mouse, although a USB-based knob panel for adjusting magnification, focus, and stigmators is still provided for those who prefer to turn something with their fingers.

    Its other nice feature is the quad-image view which lets you simultaneously view an ion beam image, an e-beam image, the IR camera inside the chamber (very helpful for not crashing your sample into a $10,000 objective lens!), and a navigation camera which displays a top-down optical view of your sample.

    The nav-cam has saved me a ton of time. On RPI's older JSM-6335 FESEM, the minimum magnification is fairly high so I find myself spending several minutes moving my sample around the chamber half-blind trying to get it under the beam. With the Versa's nav-cam I'm able to set up things right the first time.

    I brought up both of the beams on the aluminum sample mounting stub, then blanked them to try a new idea: Move around the sample blind, using the nav-cam only, then take single images in freeze-frame mode with one beam or the other. By reducing the total energy delivered to the sample I hoped to minimize charging.

    This strategy was a complete success, I had some (not too severe) charging from the e-beam but almost no visible charging in the I-beam.

    The first sample I ran on the Versa was electrically functional afterwards, but the probe pad I deposited was too thin to make reliable contact with. (It was also an XC2C64A since I had run out of 32s). Although not a complete success, it did show that I had a working process for circuit edits.

    After another batch of XC2C32As arrived, I went up to campus for another run. The signal of interest was FB2_5_FF: the flipflop for function block 2 macrocell 5. I chose this particular signal because it was the leftmost line in the second group from the left and thus easy to recognize without having to count lines in a bus.

    The drilling went flawlessly, although it was a little tricky to tell whether I had gone all the way to the target wire or not in the SE view. Maybe I should start using the backscatter detector for this?

    Via after drilling before backfill
    I filled in the via and made sure to put down a big pile of Pt on the probe pad so as to not repeat my last mistake.

    The final probe pad, SEM image
    Seen optically, the new pad was a shiny white with surface topography and a few package fragments visible through it.

    Probe pad at low mag, optical image
    At higher magnification a few slightly damaged CMP filler dots can be seen above the pad. I like to use filler metal for focusing and stigmating the ion beam at milling currents before I move to the region of interest because it's made of the same material as my target, it's something I can safely destroy, and it's everywhere - it's hard to travel a significant distance on a modern IC without bumping into at least a few pieces of filler metal.

    Probe pad at higher magnification, optical image. Note damaged CMP filler above pad.
    I soldered the CPLD back onto the board and was relieved to find out that it still worked! The next step was to write some dummy code to test it out:

    `timescale 1ns / 1ps
    module test(clk_2048khz, led);

    //Clock input
    (* LOC = "P1" *) (* IOSTANDARD = "LVCMOS33" *)
    input wire clk_2048khz;

    //LED out
    (* LOC = "P38" *) (* IOSTANDARD = "LVCMOS33" *)
    output reg led = 0;

    //Don't care where this is placed
    reg[17:0] count = 0;
    always @(posedge clk_2048khz)
    count <= count + 1;

    //Probe-able signal on FB2_5 FF at 2x the LED blink rate
    (* LOC = "FB2_5" *) reg toggle_pending = 0;
    always @(posedge clk_2048khz) begin
    if(count == 0)
    toggle_pending <= !toggle_pending;
    end

    //Blink the LED
    always @(posedge clk_2048khz) begin
    if(toggle_pending && (count == 0))
    led <= !led;
    end

    endmodule


    This is a 20-bit counter that blinks a LED at ~2 Hz from a 2048 KHz clock on the board. The second-to-last stage of the counter (so ~4 Hz) is constrained to FB2_5, the signal we're probing.

    After making sure things still worked I attached the board's plastic standoffs to a 4" scrap silicon wafer with Gorilla Glue to give me a nice solid surface I could put on the prober's vacuum chuck.

    Test board on 4" wafer
    Earlier today I went back to the cleanroom. After dealing with a few annoyances (for example, the prober with a wide range of Z axis travel, necessary for this test, was plugged into the electrical test station with curve tracing capability but no oscilloscope card) I landed a probe on the bond pad for VCCIO and one on ground to sanity check things. 3.3V... looks good.

    Moving carefully, I lifted the probe up from the 3.3V bond pad and landed it on my newly added probe pad.

    Landing a probe on my pad. Note speck of dirt and bent tip left by previous user. Maybe he poked himself mounting the probe?
    It took a little bit of tinkering with the test unit to figure out where all of the trigger settings were, but I finally saw a ~1.8V, 4 Hz squarewave. Success!

    Waveform sniffed from my probe pad
    There's still a bit of tweaking needed before I can demo it to my students (among other things, the oscilloscope subsystem on the tester insists on trying to use the 100V input range, so I only have a few bits of ADC precision left to read my 1.8V waveform) but overall the attack was a success.

    by Andrew Zonenberg (noreply@blogger.com) at April 12, 2014 11:54 PM

    ZeptoBARS

    Phillips PCF8574 - 8-bit I2C port expander : weekend die-shot

    Phillips PCF8574 is 8-bit I2C port expander, 3µm manufacturing technology.

    April 12, 2014 06:50 PM

    April 08, 2014

    ZeptoBARS

    Fake audiophile opamps: OPA627 (AD744?!)

    Walking around ebay I noticed insanely cheap OPA627's. It's rather old, popular and high-quality opamps, often used in audiophile gear. Manufacturer (Texas Instruments / Burr Brown) sells them 16-80$ each (depending on package & options) while on ebay it's cost was 2.7$, shipping included.

    Obviously, something fishy was going on. I ordered one, and for comparison - older one in metal can package, apparently desoldered from some equipment. Let's see if there is any difference.



    Plastic one was dissolved in acid, metal can was easily cut:


    Comparison

    Remarked "metal can" TI/BB OPA627 chip first. We can see here at least 4 laser-trimmed resistors. Laser trimmed resistors are needed here due to unavoidable manufacturing variation - parts inside opamps needs to be balanced perfectly.


    "Chinese" 2.7$ chip. There is only 1 laser trimmed resistor, but we also notice markings AD (Analog Devices?) and B744. Is it really AD744? If we check datasheet на AD744 - we'll see that metal photo perfectly matches one in the datasheet .


    What happened here?

    Some manufacturer in China put an effort to find cheaper substitute for OPA627 - it appeared to be AD744. AD744 has similar speed (500ns to 0.01%), similar type (*FET), supports external offset compensation. AD744 also support external frequency compensation (for high-speed high-gain applications) but there was no corresponding pin on the OPA627 - so this feature is unused.

    On the other hand AD744 has higher noise (3x) and higher offset voltage (0.5mV vs 0.1mV).

    So they bought AD744 in the form of dies or wafers, packaged them and marked as OPA627. It does not seems they earned alot of money here - it's more of an economic sabotage. Good thing that they did not used something like LM358 - in that case it would have been much easier to notice the difference without looking inside...

    Metal "OPA627" appeared to be some unidentified BB part remarked as OPA627.

    Be careful when choosing suppliers - otherwise your design might get "cost-optimized" for you :-)

    PS. Take a look at our previous story about fake FT232RL.

    April 08, 2014 06:38 AM

    April 07, 2014

    Free Electrons

    Free Electrons welcomes Boris Brezillon and Antoine Ténart

    Boris Brezillon
    Antoine Ténart

    We are happy to announce that our engineering team has recently welcomed two new embedded Linux engineers: Boris Brezillon and Antoine Ténart. Boris and Antoine will both be working from the Toulouse office of the company, together with Maxime Ripard and Thomas Petazzoni. They will be helping Free Electrons to address the increasing demand for its development and training services.

    Antoine started his professional experience with Embedded Linux and Android in 2011. Before joining Free Electrons in 2014, he started with low level Android system development at Archos (France), and worked on Embedded Linux and Android projects at Adeneo Embedded (France). He joined Free Electrons early March, and has already been involved in kernel contributions on the Marvell Berlin processors and the Atmel AT91 processors, and is also working on our upcoming Yocto training course.

    Boris joined Free Electrons on April, 1st, and brings a significant embedded Linux experience that he gained while working on home automation devices at Overkiz (France). He was maintaining a custom distribution built with the Yocto. Boris also has already contributed many patches to the mainline Linux kernel sources, in particular for the Atmel AT91 ARM SoCs. Boris is also developing the NAND controller driver for the Allwinner ARM processors and has proposed improvements to the core Linux MTD subsystem (see this thread and this other thread).

    by Thomas Petazzoni at April 07, 2014 08:42 PM

    Video Circuits

    Joy to the World by William Laziza (1994)

    Recovered by the XFR STN projectJoy to the World is Visual Music designed for ambient presentation. Joy to the World combines, optical image processing, Amiga graphics and recursive video imagery with synthesized sound. What is unique about this piece is that the audio is used to create the visuals is also the sound track. This work was created at the Micro Museum.

    https://archive.org/details/XFR_2013-08-11_1A_01




    by Chris (noreply@blogger.com) at April 07, 2014 10:48 AM

    April 06, 2014

    Altus Metrum

    keithp&#x27;s rocket blog: Java-Sound-on-Linux

    Java Sound on Linux

    I’m often in the position of having my favorite Java program (AltosUI) unable to make any sounds. Here’s a history of the various adventures I’ve had.

    Java and PulseAudio ALSA support

    When we started playing with Java a few years ago, we discovered that if PulseAudio were enabled, Java wouldn’t make any sound. Presumably, that was because the ALSA emulation layer offered by PulseAudio wasn’t capable of supporting Java.

    The fix for that was to make sure pulseaudio would never run. That’s harder than it seems; pulseaudio is like the living dead; rising from the grave every time you kill it. As it’s nearly impossible to install any desktop applications without gaining a bogus dependency on pulseaudio, the solution that works best is to make sure dpkg never manages to actually install the program with dpkg-divert:

    # dpkg-divert --rename /usr/bin/pulseaudio
    

    With this in place, Java was a happy camper for a long time.

    Java and PulseAudio Native support

    More recently, Java has apparently gained some native PulseAudio support in some fashion. Of course, I couldn’t actually get it to work, even after running the PulseAudio daemon but some kind Debian developer decided that sound should be broken by default for all Java applications and selected the PulseAudio back-end in the Java audio configuration file.

    Fixing that involved learning about said Java audio configuration file and then applying patch to revert the Debian packaging damage.

    $ cat /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/sound.properties
    ...
    #javax.sound.sampled.Clip=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider
    #javax.sound.sampled.Port=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider
    #javax.sound.sampled.SourceDataLine=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider
    #javax.sound.sampled.TargetDataLine=org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider
    
    javax.sound.sampled.Clip=com.sun.media.sound.DirectAudioDeviceProvider
    javax.sound.sampled.Port=com.sun.media.sound.PortMixerProvider
    javax.sound.sampled.SourceDataLine=com.sun.media.sound.DirectAudioDeviceProvider
    javax.sound.sampled.TargetDataLine=com.sun.media.sound.DirectAudioDeviceProvider
    

    You can see the PulseAudio mistakes at the top of that listing, with the corrected native interface settings at the bottom.

    Java and single-open ALSA drivers

    It used to be that ALSA drivers could support multiple applications having the device open at the same time. Those with hardware mixing would use that to merge the streams together; those without hardware mixing might do that in the kernel itself. While the latter is probably not a great plan, it did make ALSA a lot more friendly to users.

    My new laptop is not friendly, and returns EBUSY when you try to open the PCM device more than once.

    After downloading the jdk and alsa library sources, I figured out that Java was trying to open the PCM device multiple times when using the standard Java sound API in the simplest possible way. I thought I was going to have to fix Java, when I figured out that ALSA provides user-space mixing with the ‘dmix’ plugin. I enabled that on my machine and now all was well.

    $ cat /etc/asound.conf
    pcm.!default {
        type plug
        slave.pcm "dmixer"
    }
    
    pcm.dmixer  {
        type dmix
        ipc_key 1024
        slave {
            pcm "hw:1,0"
            period_time 0
            period_size 1024
            buffer_size 4096
            rate 44100
        }
        bindings {
            0 0
            1 1
        }
    }
    
    ctl.dmixer {
        type hw
        card 1
    }
    
    ctl.!default {
        type hw
        card 1
    }
    

    As you can see, my sound card is not number 0, it’s number 1, so if your card is a different number, you’ll have to adapt as necessary.

    April 06, 2014 05:30 AM

    Video Circuits

    Photoacoustics

    Photoacoustics as a word is now used in association with various methods of studying electromagnetic activity via acoustic detection in medical and scientific contexts. Originally Alexander Graham Bell & Charles Sumner Tainter discovered the ability to modulate a light source using sound and inversely modulate a sound producing membrane using light when working on their Photophone optical telecommunications system. This line of thinking starting around 1880 with the Photophones invention and continuing right up to the 1920s, eventually made possible inventions like optical sound on film (with all these technologies being indebted to the even earlier discoveries of the photoelectric properties of materials such as selenium). Sound on film interests me a lot in both it's exploitation in the early 20th century by artists and purely for it's interesting technological development. I have gathered a lot of information about the creative use of sound on film but I also became interested to find evidence of still images that recorded sound (also see earlier post on the eidophone) so anyway the first two images are I believe of Bell's experiments from a really cool blog on photography  Homemade Camera 












































    Second are some images produced by Robert W. Wood using single wave fronts
     produced by sparks, the latter image is a diagram based on the first, I believe.
































    Last up is the Phonodeik an instrument designed by Dayton Miller
    that allows the photography over time of complex sound waves. It
    reminds me very much of the earlier Phonautograph but with a
    photographic output.














    http://en.wikipedia.org/wiki/Photophone
    http://en.wikipedia.org/wiki/Sound-on-film
    http://en.wikipedia.org/wiki/Optical_sound
    http://homemadecamera.blogspot.co.uk/2007/08/photoacoustics.html

    http://en.wikipedia.org/wiki/Robert_W._Wood
    http://en.wikipedia.org/wiki/Schlieren_photography

    http://cultureandcommunication.org/deadmedia/index.php/Phonodeik
    http://en.wikipedia.org/wiki/Phonodeik
    http://www.phys.cwru.edu/ccpi/Phonodeik.html
    http://courtneyjl.wordpress.com/
    http://dssmhi1.fas.harvard.edu/

    I have allot more stuff to include on this subject including cymatics and optical sound experiments which I left out to cut down the size of this post, but if you have any interesting links I always welcome tips in the comments

    by Chris (noreply@blogger.com) at April 06, 2014 02:49 AM

    April 05, 2014

    Peter Zotov, whitequark

    Page caching with Nginx

    For Amplifr, I needed a simple page caching solution, which would work with multiple backend servers and require minimal amount of hassle. It turns out that just Nginx (1.5.7 or newer) is enough.

    First, you need to configure your backend. This consists of emitting a correct Cache-Control header and properly responding to conditional GET requests with If-Modified-Since header.

    Amplifr currently emits Cache-Control: public, max-age=1, must-revalidate for cacheable pages. Let’s take a closer look:

    • public means that the page has no elements specific to the particular user, so the cache can send the cache content to several users.
    • max-age=1 means that the content can be cached for one second. As will be explained later, max-age=0 would be more appropriate, but that directive would prevent the page from being cached.
    • must-revalidate means that after the cached content has expired, the cache must not respond with cached content unless it has forwarded the request further and got 304 Not Modified back.

    This can be implemented in Rails with a before_filter:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    
    class FooController < ApplicationController
      before_filter :check_cache
    
      private
      def check_cache
        response.headers['Cache-Control'] = 'public, max-age=1, must-revalidate'
        # `stale?' renders a 304 response, thus halting the filter chain, automatically.
        stale?(last_modified: @current_site.updated_at)
      end
    end
    

    Now, we need to make Nginx work like a public cache:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    
    http {
      # ...
      proxy_cache_path /var/cache/nginx/foo levels=1:2 keys_zone=foocache:5m max_size=100m;
    
      server {
        # ...
    
          proxy_pass              http://foobackend;
          proxy_cache             foocache;
          proxy_cache_key         "$host$request_uri";
          proxy_cache_revalidate  on;
          # Optionally;
          # proxy_cache_use_stale error timeout invalid_header updating
                                  http_500 http_502 http_503 http_504;
        }
      }
    }

    The key part is the proxy_cache_revalidate setting. Let’s take a look at the entire flow:

    • User agent A performs GET /foo HTTP/1.1 against Nginx.
    • Nginx has a cache miss and performs GET /foo HTTP/1.0 against the backend.
    • Backend generates the page and returns 200 OK.
    • Nginx detects that Cache-Control permits it to cache the response for 1 second, caches it and returns the response to user agent A.
    • (time passes…)
    • User agent B performs GET /foo HTTP/1.1 against Nginx.
    • Nginx has a cache hit (unless the entry was evicted), but the entry has already expired. Instructed by proxy_cache_revalidate, it issues GET /foo HTTP/1.0 against the backend and includes an If-Modified-Since header.
    • Backend checks the timestamp in If-Modified-Since and detects that Nginx’s cache entry is not actually stale, returning 304 Not Modified. It doesn’t spend any time generating content.
    • Nginx sets the expiration time on cache entry to 1 second from now and returns the cached response to the user agent B.

    Some notes on this design:

    1. Technically, performing a conditional GET requires sending an HTTP/1.1 request, but Nginx is only able to talk HTTP/1.0 to the backends. This doesn’t seem to be a problem in practice. and you can make Nginx send HTTP/1.1 requests to the backend using proxy_http_version.
    2. Ideally, specifying max-age=0 in Cache-Control would instruct the cache to store and always revalidate the response, but Nginx doesn’t cache it at all instead. HTTP specification permits both behaviors.
    3. You can specify proxy_cache_use_stale directive, so that if the server crashes or becomes unresponsive, Nginx would still serve some cached content. If the frontpage is static, it’s a good way to ensure it will be accessible at all times.

    April 05, 2014 09:25 AM

    Video Circuits

    Magnetic Tape

    Magnetic Tape is interesting to me. On reels or in cassettes each recording (or potential recording) is like a little curly drawing that pulls the sound through space, Only one position on the tape is read and so the linear nature of the tape allows the signal to vary the output is attached to over time. I messed around with wire recorders along time ago because I liked the fact that the sound is concentrated into a tiny line like space with the heaviness of the mark being replaced by the amplitude of the waveforms encoded as magnetic information. Here are some of my diy wall mounted ones, winding the pickup heads was a long day.

















    I also like Nam June Paik’s 1963 work Random Access allot, tape is attached to the wall as a drawing with the playback head made available as a mobile stylus so you can retrace his steps and listen to the recordings using the same gestures he used to stick them down. A kind of playable graphical notation

















    A good friend Dale has gone way further with visual tape based work and kindly sent me some photos of slightly insane pieces he is putting together at the moment. He selects tape based on it's visual tonality and creates geometric slightly illusory patterns building a second information set encoded in the the recording medium. I don't know if Dale does, but I find these relate to visual music and graphic notation practices too. Ill probably try to convince him at his art show at here in london on the 10th of April at six, come if you want to hang out we will probably drink beer after too.













































































    another interesting artist I found using tape in a slightly different
    way is Terence Hannum, I like the areas of ground left visible. pretty black!























    There are loads of other examples I'm sure I would really like to find a graphic score where the composer has stuck down tape, creating a kind of instrument,notation recording in one, it must have been done. If only VHS was as easy to read without a moving head, pixelvision cameras hacked might be the only answer!

    http://www.dalealexanderwilson.com/
    http://en.wikipedia.org/wiki/Wire_recording
    http://en.wikipedia.org/wiki/Tape_recorder
    http://www.medienkunstnetz.de/works/random-access/images/3/
    http://www.guggenheim.org/new-york/collections/collection-online/artwork/9536
    http://arts.brighton.ac.uk/study/fine-art/fine-art-performance/case-study/analogue-tape-glove
    http://anatlas.wordpress.com/2013/10/11/52nd-william-anastasi/comment-page-1/
    http://www.terencehannum.com/
    http://rhizome.org/editorial/2008/jun/26/less-lossy-more-glossy/?ref=archive_post_title


    by Chris (noreply@blogger.com) at April 05, 2014 08:05 AM

    April 04, 2014

    Moxie Processor

    Sign Extension

    Moxie zero-extends all 8 and 16-bit loads from memory. Until recently, however, the GCC port didn’t understand how loads worked, and would always shift loaded values back and forth to either empty out the upper bits or sign-extend the loaded value. While correct, it was overly bloated. If we’re loading an unsigned char into a register, there’s no need to force the upper bits to clear. The hardware does this for us.

    For instance, this simple C code….

    ..would compile to…

    Thanks to help from hackers on the GCC mailing list, I was finally able to teach the compiler how to treat memory loads correctly. This led to two changes…

    1. The introduction of 8 and 16-bit sign extension instructions (sex.b and sex.s). Sometimes we really do need to sign-extend values, and logical shift left followed by arithmetic shift right is a pretty expensive way to do this on moxie.
    2. The char type is now unsigned by default. If you have zero-extending 8-bit loads then you had better make your char type unsigned, otherwise your compiler output will be littered with sign extension instructions.

    Now for the C code above, we get this nice output….

    I believe that this was the last major code quality issue from the GCC port, and the compiler output should be pretty good now

    I’ve updated the upstream GCC, binutils and gdb (sim) repositories, my QEMU fork in github, as well as the MoxieLite VHDL core in the moxie-cores git repo.

    by green at April 04, 2014 08:40 AM

    April 02, 2014

    Bunnie Studios

    Crowdfunding the Novena Open Laptop

    We’re launching a crowdfunding campaign around our Novena open hardware computing platform. Originally, this started as a hobby project to build a computer just for me and xobs – something that we would use every day, easy to extend and to mod, our very own Swiss Army knife. I’ve posted here a couple of times about our experience building it, and it got a lot of interest. So by popular demand, we’ve prepared a crowdfunding offering and you can finally be a backer.



    Background



    Novena is a 1.2GHz, Freescale quad-core ARM architecture computer closely coupled with a Xilinx FPGA. It’s designed for users who want to modify and extend their hardware: all the documentation for the PCBs are open and free to download, and it comes with a variety of features that facilitate rapid prototyping.

    We are offering four variations, and at the conclusion of the Crowd Supply campaign on May 18, all the prices listed below will go up by 10%:

    • “Just the board” ($500): For crafty people who want to build their case and define their own style, we’ll deliver to you the main PCBA, stuffed with 4GiB of RAM, 4GiB microSD card, and an Ath9k-based PCIe wifi card. Boots to a Debian desktop over HDMI.
    • “All-in-One Desktop” ($1195): Plug in your favorite keyboard and mouse, and you’re ready to go; perfect for labs and workbenches. You get the circuit board above, inside a hacker-friendly case with a Full HD (1920×1080) IPS LCD.
    • “Laptop” ($1995): For hackers on the go, we’ll send you the same case and board as above, but with battery controller board, 240 GiB SSD, and a user-installed battery. As everyone has their own keyboard preference, no keyboard is included.
    • “Heirloom Laptop” ($5000): A show stopper of beauty; a sure conversation piece. This will be the same board, battery, and SSD as above, but in a gorgeous, hand-crafted wood and aluminum case made by Kurt Mottweiler in Portland, Oregon. As it’s a clamshell design, it’s also the only offering that comes with a predetermined keyboard.

    All configurations will come with Debian (GNU/Linux) pre-installed, but of course you can build and install whatever distro you prefer!

    Novena Gen-2 Case Design

    Followers of this blog may have seen a post featuring a prototype case design we put together last December. These were hand-built cases made from aluminum and leather and meant to validate the laptop use case. The design was rough and crafted by my clumsy hands – dubbed “gloriously fuggly [sic]” – yet the public response was overwhelmingly positive. It gave us confidence to proceed with a 2nd generation case design that we are now unveiling today.



    The first thing you’ll notice about the design is that the screen opens “the wrong way”. This feature allows the computer to be usable as a wall-hanging unit when the screen is closed. It also solves a major problem I had with the original clamshell prototype – it was a real pain to access the hardware for hacking, as it’s blocked by the keyboard mounting plate.

    Now, with the slide of a latch, the screen automatically pops open thanks to an internal gas spring. This isn’t just an open laptop — it’s a self-opening laptop! The internals are intentionally naked in this mode for easy access; it also makes it clear that this is not a computer for casual home use. Another side benefit of this design is there’s no fan noise – when the screen is up, the motherboard is exposed to open air and a passive heatsink is all you need to keep the CPU cool.

    Another feature of this design is the LCD bezel is made out of a single, simple aluminum sheet. This allows users with access to a minimal machine shop to modify or craft their own bezels – no custom tooling required. Hopefully this makes adding knobs and connectors, or changing the LCD relatively easy. In order to encourage people to experiment, we will ship desktop and laptop devices with not one, but two LCD bezels, so you don’t have to worry about having an unusable machine if you mess up one of the bezels!

    The panel covering the “port farm” on the right hand side of the case is designed to be replaceable. A single screw holds it in place, so if you design your own motherboard or if you want to upgrade in the future, you’re not locked into today’s port layout. We take advantage of this feature between the desktop and the laptop versions, as the DC power jack is in a different location for the two configurations.

    Finally, the inside of the case features a “Peek Array”. It’s an array of M2.5 mounting holes (yes, they are metric) populating the extra unused space inside the case, on the right hand side in the photo above. It’s named after Nadya Peek, a graduate student at MIT’s Center for Bits and Atoms. Nadya is a consummate maker, and is a driving force behind the CBA’s Fab Lab initiative. When I designed this array of mounting bosses, I imagined someone like Nadya making their own circuit boards or whatever they want, and mounting it inside the case using the Peek Array.

    The first thing I used the Peek Array for is the speaker box. I desire loud but good quality sound out of my laptop, so I 3D printed a speakerbox that uses 36mm mini-monitor drivers, and mounted it inside using the Peek Array. I would be totally stoked if a user with real audio design experience was to come up with and share a proper tuned-port design that I could install in my laptop. However, other users with weight, space or power concerns can just as easily design and install a more modest speaker.

    I started the Gen-2 case design in early February, after xobs and I finally decided it was time to launch a crowdfunding campaign. With a bit of elbow grease and the help of a hard working team of engineers and project managers at my contract manufacturing partner, AQS (that’s Celia and Chemmy pictured above, doing an initial PCBA fitting two weeks ago), I was able to bring a working prototype to San Jose and use it to give my keynote at EELive today.

    The Heirloom Design (Limited Quantities)

    One of the great things about open hardware is it’s easier to set up design collaborations – you can sling designs and prototypes around without need for NDAs or cumbersome legal agreements. As part of this crowdfunding campaign, I wanted to offer a really outstanding, no-holds barred laptop case – something you would be proud to have for years, and perhaps even pass on to your children as an heirloom. So, we enlisted the help of Kurt Mottweiler to build an “heirloom laptop”. Kurt is a designer-craftsman situated in Portland, Oregon and drawing on his background in luthiery, builds bespoke cameras of outstanding quality from materials such as wood and aluminum. We’re proud to have this offering as part of our campaign.

    For the prototype case, Kurt is featuring rift-sawn white oak and bead-blasted-and-anodized 6061 aluminum. He developed a composite consisting of outer layers of paper backed wood veneer over a high-density cork core with intervening layers of 5.5 ounce fiberglass cloth, all bonded with a high modulus epoxy resin. This composite is then gracefully formed into semi-monocoque curves, giving a final wavy shape that is both light, stiff, and considers the need for air cooling.

    The overall architecture of Kurt’s case mimics the industry-standard clamshell notebook design, but with a twist. The keyboard used within the case is wireless, and can be easily removed to reveal the hardware within. This laptop is an outstanding blend of tasteful design, craftsmanship, and open hardware. And, to wit, since these are truly hand-crafted units, no two units will be exactly alike – each unit will have its own grain and a character that reflects Kurt’s judgment for that particular piece of wood.

    How You can Help

    For the crowdfunding campaign to succeed, xobs and I need a couple hundred open source enthusiasts to back the desktop or standard laptop offering.

    And that underlies the biggest challenge for this campaign – how do we offer something so custom and so complex at a price that is comparable to a consumer version, in low volumes? Our minimum funding goal of $250,000 is a tiny fraction of what’s typically required to recover the million-plus dollar investment behind the development and manufacture of a conventional laptop.

    We meet this challenge with a combination of unique design, know-how, and strong relationships with our supply chain. The design is optimized to reduce the amount of expensive tooling required, while still preserving our primary goal of being easy to hack and modify. We’ve spent the last year and a half poring over three revisions of the PCBA, so we have high confidence that this complex design will be functional and producible. We’re not looking to recover that R&D cost in the campaign – that’s a sunk cost, as anyone is free to download the source and benefit from our thoroughly vetted design today. We also optimized certain tricky components, such as the LCD and the internal display port adapter, for reliable sourcing at low volumes. Finally, I spent the last couple of months traveling the world, lining up a supply chain that we feel confident can deliver this design, even in low volume, at a price comparable to other premium laptop products.

    To be clear, this is not a machine for the faint of heart. It’s an open source project, which means part of the joy – and frustration – of the device is that it is continuously improving. This will be perhaps the only laptop that ships with a screwdriver; you’ll be required to install the battery yourself, screw on the LCD bezel of your choice, and you’ll get the speakers as a kit, so you don’t have to use our speaker box design – if you have access to a 3D printer, you can make and fine tune your own speaker box.

    If you’re as excited about having a hackable, open laptop as we are, please back our crowdfunding campaign at Crowd Supply, and follow @novenakosagi for real-time updates.

    by bunnie at April 02, 2014 03:58 PM

    Free Electrons

    Embedded Linux Conference 2014, Free Electrons participation

    San JoséOne of the most important conference of the Embedded Linux community will take place at the end of this month in California: the Embedded Linux Conference will be held in San Jose from April, 29th to May, 1st, co-located with the Android Builders Summit. The schedule for both of these events has been published, and it is full of interesting talks on a wide range of embedded topics.

    As usual, Free Electrons will participate to this conference, but this participation will be the most important ever:

    If you are interested in embedded Linux, we highly advise you to attend this conference. And if you are interested in business or recruiting opportunities with Free Electrons, it will also be the perfect time to meet us!

    by Thomas Petazzoni at April 02, 2014 02:39 PM

    March 31, 2014

    Elphel

    Elphel, inc. on trip to Geneva, Switzerland.

    University of Geneva

    Monday, April 14, 2014 – 18:15 at Uni-Mail, room MR070, University of Geneva. Elphel, Inc. is giving a conference entitled “High Performance Open Hardware for Scientific Applications”. Following the conference, you will be invited to attend a round-table discussion to debate the subject with people from Elphel and Javier Serrano from CERN. Javier studied Physics and Electronics Engineering. He is the head of the Hardware and Timing section in CERN’s Beams Control group, and the founder of the Open Hardware Repository. Javier has co-authored the CERN Open Hardware Licence. He and his colleagues have also recently started contributing improvements to KiCad, a free software tool for the design of Printed Circuit Boards Elphel Inc. is invited by their partner specialized in stereophotogrammetry applications – the Swiss company Foxel SA, from April 14-21 in Geneva, Switzerland. You can enjoy a virtual tour of the Geneva University by clicking on the links herein below: (make sure to use the latest version of Firefox or Chromium to view the demos) Foxel’s team would be delighted to have all of Elphel’s clients and followers to participate in the conference. A chat can also be organized in the next few days. Please contact us at Foxel SA. If you do not have the opportunity to visit us in Geneva, the conference will be streamed live and the recording will be available.

    by Alexandre at March 31, 2014 06:04 PM

    Andrew Zonenberg, Silicon Exposed

    Laser IC decapsulation experiments

    Laser decapsulation is commonly used by professional shops to rapidly remove material before finishing with a chemical etch. Upon finding out that one of my friends had purchased a laser cutting system, we decided to see how well it performed at decapping.

    Infrared light is absorbed strongly by most organics as well as some other materials such as glass. Most metals, especially gold, reflect IR strongly and thus should not be significantly etched by it. Silicon is nearly transparent to IR. The hope was that this would make laser ablation highly selective for packaging material over the die, leadframe, and bond wires.

    Unfortunately I don't have any in-process photos. We used a raster scan pattern at fairly low power on a CO2 laser with near-continuous duty cycle.

    The first sample was a Xilinx XC9572XL CPLD in a 44-pin TQFP.

    Laser-etched CPLD with die outline visible
    If you look closely you can see the outline of the die and wire bonds beginning to appear. This probably has something to do with the thermal resistances of gold bonding wires vs silicon and the copper leadframe.

    Two of the other three samples (other CPLDs) turned out pretty similar except the dies weren't visible because we didn't lase quite as long.
    Laser-etched CPLD without die visible
    I popped this one under my Olympus microscope to take a closer look.

    Focal plane on top of package
    Focal plane at bottom of cavity
    Scan lines from the laser's raster-etch pattern were clearly visible. The laser was quite effective at removing material at first glance, however higher magnification provided reason to believe this process was not as effective as I had hoped.
    Raster lines in molding compound
    Raster lines in molding compound
    Most engineers are not aware that "plastic" IC packages are actually not made of plastic. (The curious reader may find the "epoxy" page on siliconpr0n.org a worthwhile read).

    Typical "plastic" IC molding compounds are actually composite materials made from glass spheres of varying sizes as filler in a black epoxy resin matrix. The epoxy blocks light from reaching the die and interfering with circuits through induced photocurrents and acts to bond the glass together. Unfortunately the epoxy has a thermal expansion coefficient significantly different from that of the die, so glass beads are added as a filler to counteract this effect. Glass is usually a significant percentage (80 or 90 percent) of the molding compound.

    My hope was that the laser would vaporize the epoxy and glass cleanly without damaging the die or bond wires. It seems that the glass near the edge of the beam fused together, producing a mess which would be difficult or impossible to remove. This effect was even more pronounced in the first sample.

    The edge of the die stood out strongly in this sample even though the die is still quite a bit below the surface. Perhaps the die (or the die-attach paddle under it) is a good thermal conductor and acted to heatsink the glass, causing it to melt rather than vaporize?
    The first sample seen earlier in the article, showing the corner of the die
    A closeup showed a melted, blasted mess of glass. About the only things able to easily remove this are mechanical abrasion or HF, both of which would probably destroy the die.
    Fused glass particles
    Fused glass particles

    I then took a look at the last sample, a PIC18F4553. We had etched this one all the way down to the die just to see what would happen.
    Exposed PIC18F4553 die
    Edge of the die showing bond pads
    Most bond wires were completely gone - it appeared that the glass had gotten so hot that it melted the wires even though they did not absorb the laser energy directly. The large reddish sphere at the center of the frame is what remains of a ball bond that did not completely vanish.

    The surface of the die was also covered by fused glass. No fine structure at all was visible.

    Looking at the overview photo, reddish spots were visible around the edge of the die and package. I decided to take a closer look in hopes of figuring out what was going on there.
    Red glass on the edge of the hole
    I was rather confused at first because there should have only been metal, glass, and plastic in that area - and none of these were red. The red areas had a glassy texture to them, suggesting that they were partly or mostly made of fused molding compound.

    Some reading on stained glass provided the answer - cranberry glass. This is a colloid of gold nanoparticles suspended in glass, giving it color from scattering incoming light.

    The normal process for making cranberry glass is to mix Au2O3 in with the raw materials before smelting them together. At high temperatures the oxide decomposes, leaving gold particles suspended in the glass. It appears that I've unintentionally found a second synthesis which avoids the oxidation step: flash vaporization of solid gold and glass followed by condensation of the vapor on a cold surface.

    by Andrew Zonenberg (noreply@blogger.com) at March 31, 2014 02:37 PM

    March 29, 2014

    Video Circuits

    Art électronique

    As a British person from 2014 I have never wanted to be a young French kid in in a polo neck from 1978 until now, this is pretty much my dream audio visual studio, featuring some lovely  shots of the EMS Spectron video synthesizer in action as well as a whole host of other nice EMS and custom rack gear for sound and video experimentation. http://www.ina.fr/video/CPA7805092804
    Thanks to Jeff my good friend from across the seas for digging this video up!









    by Chris (noreply@blogger.com) at March 29, 2014 05:19 AM

    March 28, 2014

    ZeptoBARS

    SiTime SiT8008 - MEMS oscillator : weekend die-shot

    SiTime SiT8008 is a programmable MEMS oscillator reaching quartz precision but with higher reliability and lower g-sensitivity. Also SiTime is one of companies who received investments from Rosnano - Russian high-tech investment fund.

    Photo of MEMS die puzzled us for quite some time. Is it some sort of integrated SAW/STW resonator?

    The trick is that to reach maximum Q-factor (up to ~186'000 according to patents) MEMS resonator must operate in vacuum. So they package resonator _inside_ the die in hydrogen atmosphere, then anneal it in vacuum so that hydrogen escapes through silicon. So we see here only a cap with contacts to "buried" MEMS resonator. We were unable to reach the resonator itself without x-ray camera or ion mill.

    MEMS die size - 457x454 µm.

    Thankfully relevant patents were specified right on the die : US6936491 US7514283 US7075160 US7750758 :)



    Digital die contains LC PLL and digital logic for one-off frequency programming and temperature compensation.
    Die size - 1409x1572 µm.



    Poly level:


    Standard cells ~250nm techology.

    March 28, 2014 10:54 PM

    Geoffrey L. Barrows - DIY Drones

    Visually stabilizing a Crazyflie, including in the dark

    I've been working on adding visual stabilization to a Crazyflie nano quadrotor. I had two goals- First is to achieve the same type of hover that we demonstrated several years ago on an eFlite 'mCX. Second is to do so in extremely low light levels including in the dark, borrowing inspiration from biology. We are finally getting some decent flights.

    Above is a picture of our sensor module on a Crazyflie. The Crazyflie is really quite small- the four motors form a square about 6cm on a side. The folks at Bitcraze did a fantastic job assembling a virtual machine environment that makes it easy to modify and update the Crazyflie's firmware. Our sensor module comprises four camera boards (using an experimental low-light chip) connected to a main board with an STM32F4 ARM running. These cameras basically grab optical flow type information from the horizontal plane and then estimate motion based on global optical flow patterns. These global optical flow patterns are actually inspired from similar ones identified in fly visual systems.The result is a system that allows a pilot to maneuver the Crazyflie using control sticks, and then will hover in one location when the control sticks are released.

    Below is a video showing three flights. The first flight is indoors, with lights on. The second is indoors, with lights off but with some leaking light. The third is in the dark, but with IR LEDs mounted on the Crazyflie to work in the dark.

    There is still some drift, especially in the darker environments. I've identified a noise issue on the sensor module PCB, and already have a new PCB in fab that should clean things up.

    by Geoffrey L. Barrows at March 28, 2014 01:44 PM

    March 26, 2014

    Bunnie Studios

    Name that Ware, March 2014

    The Ware for March 2014 is shown below.

    I came across this at a gray market used parts dealer in Shenzhen. Round, high density circuit boards with big FPGAs and ceramic packages tend to catch my eye, as they reek of military or aerospace applications.

    I have no idea what this ware is from, or what it’s for, so it should be interesting judging the responses — if there is no definitive identification, I’ll go with the most detailed/thoughtful response.

    by bunnie at March 26, 2014 07:11 PM

    Winner, Name that Ware February 2014

    The Ware for February 2014 is an SPAC module from the racks of a 3C Series 16 computer, made by Honeywell (formerly 3C). According to the Ware’s submitter, the computer from which it came was either a DDP-116 or DDP-224 computer, but the exact identity is unknown as it was acquired in the 70′s and handed down for a generation.

    As for a winner, it’s tough to choose — so many thoughtful answers. I’ll go the easy route and declare jd the winner for having the first correct answer. Congrats, and email me for your prize!

    by bunnie at March 26, 2014 07:11 PM

    Richard Hughes, ColorHug

    GNOME Software on Ubuntu (II)

    So I did a bit more hacking on PackageKit, appstream-glib and gnome-software last night. We’ve now got screenshots from Debian (which are not very good) and long application descriptions from the package descriptions (which are also not very good). It works well enough now, although you now need PackageKit from master as well as appstream-glib and gnome-software.

    Screenshot_UbuntuSaucy_2014-03-26_15:27:33

    Screenshot_UbuntuSaucy_2014-03-26_15:31:05

    Screenshot_UbuntuSaucy_2014-03-26_15:55:45

    This is my last day of hacking on the Ubuntu version, but I’m hopeful other people can take what I’ve done and continue to polish the application so it works as well as it does on Fedora. Tasks left to do include:

    • Get aptcc to honour the DOWNLOADED filter flag so we can show applications in the ‘Updates’ pane
    • Get aptcc to respect the APPLICATION filter to speed up getting the installed list by an order of magnitude
    • Get gnome-software (or appstream-glib) to use the system stock icons rather than the shitty ones shipped in the app-install-data package
    • Find out a way to load localized names and descriptions from the app-install-data gettext archive and add support to appstream-glib. You’ll likely need to call dgettext(), bindtextdomain() and bind_textdomain_codeset()
    • Find out a way how to populate the ‘quality’ stars in gnome-software, which might actually mean adding more data to the app-install desktop files. This is kind of data we need.
    • Find out why aptcc sometimes includes the package summary in the licence detail position
    • Improve the package details to human readable code to save bullet points and convert to a UTF-8 dot
    • Get the systemd offline-updates code working, which is completely untested
    • Find out why aptcc seems to use a SHA1 hash for the repo name (e.g. pkcon repo-list)
    • Find out why aptcc does not set the data part of the package-id to be prefixed with installed: for installed packages

    If you can help with any of this, please grab me on #PackageKit on freenode.

    by hughsie at March 26, 2014 04:17 PM

    March 25, 2014

    Richard Hughes, ColorHug

    GNOME Software on Ubuntu

    After an afternoon of hacking on appstream-glib, I can show the fruits of my labours:

    1

    This needs gnome-software and appstream-glib from git master (or gnome-apps-3.14 in jhbuild) and you need to manually run PackageKit with the aptcc backend (--enable-aptcc).

    2

    It all kinda works with the data from /usr/share/app-install/*, but the icons are ugly as they are included in all kinds of sizes and formats, and also there’s no long descriptions except for the two (!) installed applications new enough to ship local AppData files.Also, rendering all those svgz files is muuuuch slower than a pre-processed png file like we ship with AppStream. The installed view also seems not to work. Only the C locale is present too, as I’ve not worked out how to get all the translations from an external gettext file in appstream-glib. I’d love to know how the Ubuntu software center gets long descriptions and screenshots also. But it kinda works. Thanks.

    by hughsie at March 25, 2014 05:41 PM

    March 24, 2014

    Michele's GNSS blog

    R820T with 28.8 MHz TCXO

    I recently looked around for tools to use as low cost spectrum scanners, being the objective frequency range 400 MHz to 1.7 GHz (incidentally, DVB-T and GPS).
    Of course rtl-sdr is an attractive option so I dusted off some dongles I had bought 6 months ago in China and played again with them, coming to the conclusion that I really like it especially after its main limitation is overcome :)

    The 28.8 MHz crystal is quite poor. I asked Takuji for a TCXO but he said he emptied his stock rapidly. Of course a replacement is nowhere to be found on the big distribution (Digikey, Mouser, Farnell, RS, etc..), so I went to an old time acquaintance at Golledge and, despite having to order 100 pieces, my request was fulfilled. After all, dongles look quite good with the new crystal:
    Figure 1: RTL-SDR with 28.8 MHz TCXO (Golledge GTXO-92)

    I measured the frequency deviation with my simple GPS software receiver and I happy to report that it is within spec, bounded to 2ppm. By the way, I tried using other GNSS software receivers and will write about my experience in another post soon.

    On the frequency plan side, the R820T combined with the RTL2832U is great for GPS. Most people would use it with an active antenna, where the LNA solves the problem of losses due to the impedance mismatch (50 against 75 ohm) and the noise figure of the tuner (3.5 dB according to datasheet).
    The frequency plan with an IF of 3.57 MHz solves elegantly the problem of LO feedthrough and I/Q unbalance typical of ZIF tuner. The IF is recovered automatically in the digital domain by the demodulator so it does not appear in the recorded file. 8bit I/Q recording at 2.048 Msps is more than sufficient for GPS and I also tracked Galileo E1B/C with it (despite some obvious power loss due to the narrow filter band). In my tests, I used a Dafang technology DF5225 survey antenna and the signal time plot shows that 5 bits are actually exercised. I powered the antenna with 3.3V from a Skytraq Venus8 (Ducat10 with S1216F8) through an all-by-one DC blocked passive 4-way splitter/combiner (6 dB unavoidable loss) from ETL-systems.

    Figure 2, 3 and 4: Power spectrum, histogram, and time series at L1.

    I posted three GPS files here:
    https://app.box.com/s/wxizs3p7zu8x2jmbnzod
    https://app.box.com/s/xvfabkqfkmehg5osa3ra
    https://app.box.com/s/dqrel15mwj73xijflkma

    Since someone asked for it, here are the tracking results of Galileo E19 plotted after the fact with Matlab:





    and Galileo E20:






    More to come later,
    Michele

    by noreply@blogger.com (Michele Bavaro) at March 24, 2014 10:49 PM

    Richard Hughes, ColorHug

    GNOME Software 3.12.0 Released!

    Today I released gnome-software 3.12.0 — with a number of new features and a huge number of bugfixes:

    gnome-software-312-main

    I think I’ve found something interesting to install — notice the auto-generated star rating which tells me how integrated the application is with my environment (i.e. is it available in my language) and if the application is being updated upstream. Those thumbnails look inviting:

    gnome-software-312-details

    We can continue browsing while the application installs — also notice the ‘tick’ — this will allow me to create and modify application folders in gnome-shell so I can put the game wherever I like:

    gnome-software-312-installing

    The updates tab looks a little sad; there’s no update metadata on rawhide for my F20 GNOME 3.12 COPR, but this looks a lot more impressive on F20 or the yet-to-be-released F21. At the moment we’re using the AppData metadata in place of update descriptions there. Yet another reason to ship an AppData file.

    gnome-software-312-updates

    We can now safely remove sources, which means removing the applications and addons that we installed from them. We don’t want applications sitting around on our computer not being updated and causing dependency problems in the future.

    gnome-software-312-sources

    Development in master is now open, and we’ve already merged several large patches. The move to libappstream-glib is a nice speed boost, and other more user-visible features are planned. We also need some documentation; if you’re interested please let us know!

    by hughsie at March 24, 2014 05:31 PM

    March 22, 2014

    ZeptoBARS

    TI TL431 adjustable shunt regulator : weekend die-shot

    TI TL431 in an adjustable shunt regulator often used in linear supplies with external power transistor.
    Die size 1011x1013 µm.


    March 22, 2014 04:25 PM

    March 21, 2014

    Geoffrey L. Barrows - DIY Drones

    What can bees tell us about seeing and flying at night?

    (Image of Megalopta Genalis by Michael Pfaff, linked from Nautilus article)

    How would you like your drone to use vision to hover, see obstacles, and otherwise navigate, but do so at night in the presence of very little light? Research on nocturnal insects will (in my opinion) give us ideas on how to make this possible.

    A recent article in Nautilus describes the research being performed by Lund University Professor Eric Warrant on Megalopta Genalis, a bee that lives in the Central American rainforest and does it's foraging after sunset and before sunrise when light levels are low enough to keep most other insects grounded, but just barely adequate for the Megalopta to perform all requisite bee navigation tasks. This includes hovering, avoiding collisions with other obstacles, visually recognizing it's nest, and navigating out and back to it's nest by recognizing illumination openings in the branches above. Deep in the rainforest the light levels are much lower than out in the open- Megalopta seems able to perform these tasks when the light levels are as low as two or three photons per ommatidia (compound eye element) per second!

    Professor Warrant and his group theorize that the Megalopta's vision system uses "pooling" neurons that combine the acquired photons from groups of ommatidia to obtain the benefit of higher photon rates, a trick similar to how some camera systems extend their ability to operate in low light levels. In fact, I believe even the PX4flow does this to some extent when indoors. The "math" behind this trick is sound, but what is missing is hard neurophysiological evidence of this in the Megalopta, which Prof. Warrant and his colleagues are tying to obtain. As the article suggests, this work is sponsored in part by the US Air Force.

    You have to consider the sheer difference between the environment of Megalopta and the daytime environments in which we normally fly. On a sunny day, the PX4flow sensor probably acquires around 1 trillion photons per second. Indoors, that probably drops to about 10 billion photons per second. Now Megalopta has just under 10,000 ommatidia, so at 2 to 3 photons per ommatidia per second it experiences around 30,000 photons per second. That is a difference of up to seven orders of magnitude, which is even more dramatic when you consider that Megalopta's 30k photons are acquired omnidirectionally, and not just over a narrow field of view looking down.

    by Geoffrey L. Barrows at March 21, 2014 06:47 PM

    March 19, 2014

    Richard Hughes, ColorHug

    AppStream Logs, False Positives and You

    Quite a few people have asked me how the AppStream distro metadata is actually generated for thier app. The actual extraction process isn’t trivial, and on Fedora we also do things like supply missing AppData files for some key apps, and replacing some upstream screenshots on others.

    In order to make this more transparent, I’m going to be uploading the logs of each generation run. If you’ve got a few minutes I’d appreciate you finding your application there and checking for any warnings or errors. The directory names are actually Fedora package names, but usually it’s either 1:1 or fairly predictable.

    If you’ve got a application that’s being blacklisted when it shouldn’t be, or a GUI application that’s in Fedora but not in that list then please send me email or grab me on IRC. The rules for inclusion are here. Thanks.

    by hughsie at March 19, 2014 10:41 AM

    March 18, 2014

    Richard Hughes, ColorHug

    Announcing Appstream-Glib

    For a few years now Appstream and AppData adoption has been growing. We’ve got client applications like GNOME Software consuming the XML files, and we’ve got several implementations of metadata generators for a few distros now. We’ve also got validation tools we’re encouraging upstream applications to use.

    The upshot of this was the same code was being duplicated across 3 different projects of mine, all with different namespaces and slightly different defined names. Untangling this mess took a good chunk of last week, and I’ve factored out 2759 lines of code from gnome-software, 4241 lines from createrepo_as, and the slightly less impressive 178 lines from appdata-tools.

    The new library has a simple homepage, and so far a single release. I’d encourage people to check this out and provide early comments, as as soon as gnome-software branches for 3-12 I’m going to switch it to using this. I’m also planning on switching createrepo_as and and appdata-tools for the next releases too so things like jhbuild modulesets need to be updated and tested by somebody.

    Appstream-Glib 0.1.0 provides just enough API to make sense for a first release, but I’m going to be continuing to abstract out useful functionality from the other projects to share even more code. I’ve spent a few long nights profiling the XML parsing code, and I’m pleased to say the load time of gnome-software is 160ms faster with this new library, and createrepo_as completes the metadata generation 4 minutes faster. Comments, suggestions and patches very welcome. There’s a Fedora package linked from the package review bug if you’d rather test that. Thanks.

    by hughsie at March 18, 2014 02:20 PM

    ZeptoBARS

    TI LM393 - dual comparator : weekend die-shot

    TI LM393 - dual comparator, one of old workhorses of electronics.
    Die size 704x748 µm.


    March 18, 2014 09:34 AM

    March 16, 2014

    ZeptoBARS

    Ti TS5A3159 - 1Ω analog switch : weekend die-shot

    Ti TS5A3159 is an 1.65-5V 2:1 analog switch with ~1Ω matched channel resistance and "break-before-make" feature.
    Die size 1017x631 µm, 1µm technology.


    March 16, 2014 06:15 AM

    March 06, 2014

    Video Circuits

    Some of my stills

    Here are some still from some diy video synth experiments, slow progress




    by Chris (noreply@blogger.com) at March 06, 2014 10:17 AM

    Akirasrebirth

    Akirasrebirth  has some nice circuit bent video stuff and an arduino based video project here 














    by Chris (noreply@blogger.com) at March 06, 2014 10:15 AM

    Victoria Keddie

    Victoria Keddie's beautiful new piece Helios Electro, see an older post about her work here

    "Sound and video feedback systems, signal generation, DAC, wavetek, oscillators, T- resonator, surveillance camera, CRT monitor feedback, For-A, and other things."

    too cool.


    by Chris (noreply@blogger.com) at March 06, 2014 09:52 AM

    March 03, 2014

    Zedstar

    nibble.io

    I have been working on applications that can transfer data using sound on mobile and embedded devices. The first product I have created is called NibblePin which is specifically designed to exchange BBM PINs.  All signal processing is done on the device and the implementation is portable across a range of embedded hardware.  The first port of this application is for Blackberry 10 but I will work on some other mobile OSes and platforms. For further updates check out http://nibble.io

    by john at March 03, 2014 08:44 PM

    February 24, 2014

    OggStreamer

    #oggstreamer – Firmware Release Candidate 3 – released ;)

    it has been a while since there was an official Firmware Update for the OggStreamer – now it is time to release RC3 (maybe the last Release Candidate before V1.0)

    Whats new:

    • Working WebGUI-Firmware upload (until RC3 you had to use the Command Line Tools)
    • Support for MP3 completed
    • Patches for AudioDSP are now working (fixes high pitch mp3 issues, and incorrect samplerates)
    • Support for DynDNS – Services like FreeDNS, DynDNS and many more
    • Support for the ShoutCast (ICY) and legacy IceCast1 Protocol
    • Cleaner Code for WebGUI – now using libcgi to be compliant to GPL

    Where to get it:

    The upload_firmware.sh script and the update-rc3.tgz can be found in the repositories if you want to update from a UNIX like environment

    For windows download the updater tool here

    Once you installed RC3 on your OggStreamer future updates can be done via the WebGUI ;)


    by oggstreamer at February 24, 2014 04:40 PM

    Richard Hughes, ColorHug

    GNOME 3.12 on Fedora 20

    I’ve finished building the packages for GNOME 3.11.90. I’ve done this as a Fedora 20 COPR. It’s probably a really good idea to test this in a VM rather than your production systems as it’s only had a small amount of testing.

    If it breaks, you get to keep all 132 pieces. It’s probably also not a good idea to be asking fedora-devel or fedoraforums for help when using these packages. If you don’t know how to install a yum repo these packages are not for you.

    Comments and suggestions, welcome. Thanks.

    by hughsie at February 24, 2014 02:44 PM

    February 21, 2014

    Free Electrons

    Free Electrons at Embedded World 2014, Nuremberg, Germany

    Embedded World 2014, Germany

    Embedded World is the world’s largest trade show about embedded systems. In 2013, it attracted around 900 exhibitors, over 22,000 visitors and almost 1,500 congress participants.

    This year, Free Electrons will be represented by our CEO Michael Opdenacker. This should be a great opportunity for us to understand our customers better, by meeting embedded system makers, by seeing what their needs are and what technologies they use. It will also be an opportunity to meet well known members of the technical community. In particular, here are a few well know people who are going to speak at the congress:

    Don’t hesitate to contact us if you are attending this event too and are interested in knowing Free Electrons better, for business, partnership or even career opportunities!

    by Michael Opdenacker at February 21, 2014 05:55 AM

    February 20, 2014

    OggStreamer

    #oggstreamer – Talk about the OggStreamer and OpenHardware @ MediaLab Prado

    I had the chance to present the OggStreamer at Medialab Prado and I was also talking about some random thoughts about OpenHardware and the Open Technology Laboratory in Austria http://otelo.or.at

    medialabprado-oggstreamer(click on the image to get to the video)

    Many thanks to the people at MediaLab who made this talk possible ;)


    by oggstreamer at February 20, 2014 04:02 PM

    February 17, 2014

    Altus Metrum

    keithp&#x27;s rocket blog: MicroPeak Approved for NAR Contests

    MicroPeak Approved for NAR Contests

    The NAR Contest Board has approved MicroPeak for use in contests requiring a barometric altimeter starting on the 1st of April, 2014. You can read the announcement message on the contestRoc Yahoo message board here:

    Contest Board Approves New Altimeter

    The message was sent out on the 30th of January, but there is a 90 day waiting period after the announcement has been made before you can use MicroPeak in a contest, so the first date approved for contest flights is April 1. After that date, you should see MicroPeak appear in Appendix G of the pink book, which lists the altimeters approved for contest use

    Thanks much to the NAR contest board and all of the fliers who helped get MicroPeak ready for this!

    February 17, 2014 08:45 AM

    ZeptoBARS

    FTDI FT232RL: real vs fake

    For quite some time when you buy FTDI FT232RL chips from shady suppliers you have a good chance of getting mysteriously buggy chip which only works with drivers 2.08.14 or earlier. We've got a pair of such FTDI FT232RL chips - one genuine and one fake and decided to check if there is an internal difference between them. On the following photo - left one is genuine, right one is fake. One can notice difference in marking - on genuine chip it's laser engraved while on buggy it is printed (although this is not a universal distinguishing factor for other chips).



    Genuine FT232RL



    After etching metal layers:


    Let's take a closer look at different parts of the chip. Here are rows of auto-synthesized standard cells:


    ROM? EEPROM?:


    SRAM:


    Fake FT232RL

    This chip is completely different! We can notice right away that number of contact pads is much higher than needed. Chip has marking "SR1107 2011-12 SUPEREAL"


    After etching metal layers:


    Closer look at standard cells:


    Different block of the chip has different look of standard cells. It is likely that some modules were licensed(?) as layout, not HDL:


    First type of SRAM:


    Second type of SRAM:


    Finally - mask ROM programmed on poly level, so we can clearly see firmware data:


    Comparison of manufacturing technology

    ChipDie sizeTechnologySRAM cell area
    FTDI FT232RL3288x3209 µm600-800 nm123 µm2
    Fake FT232RL3489x3480 µm500 nm68 µm2 and 132 µm2

    While technology node is comparable, it seems that original FT232RL used less metals, hence much lower logic cell density. Fake chip is slightly larger despite slightly more advanced technology.

    Resume

    It seems that in this case Chinese designers implemented protocol-compatible "fake" chip, using mask-programmable microcontroller. This way they only needed to redo 1 mask - this is much cheaper than full mask set, and explains a lot of redundant pads on the die. Fake chip was working kinda fine until FTDI released drivers update, which were able to detect fake chips via USB and send only 0's in this case. It was impossible to foresee any possible further driver checks without full schematic recovery and these hidden tricks saved FTDI profits.

    What's the economic reason of making software fake of well-known chip instead of making new one under your own name? This way they don't need to buy USB VID, sign drivers in Microsoft, no expenses on advertisement. This fake chip will be used right away in numerous mass-manufactured products. New chip will require designing new products (or revisions) - so sales ramp up will happen only 2-3 years later. Die manufacturing cost is roughly the same for both dies (~10-15 cents) .

    From now on one should pay more and more attention when working with small shady distributors. Their slightly lower price could cause numerous hours of debugging fun.

    February 17, 2014 07:29 AM

    February 15, 2014

    Altus Metrum

    keithp&#x27;s rocket blog: Altos1.3.2

    AltOS 1.3.2 — Bug fixes and improved APRS support

    Bdale and I are pleased to announce the release of AltOS version 1.3.2.

    AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.

    This is a minor release of AltOS, including bug fixes for TeleMega, TeleMetrum v2.0 and AltosUI .

    AltOS Firmware — GPS Satellite reporting and APRS improved

    Firmware version 1.3.1 has a bug on TeleMega when it has data from more than 12 GPS satellites. This causes buffer overruns within the firmware. 1.3.2 limits the number of reported satellites to 12.

    APRS now continues to send the last known good GPS position, and reports GPS lock status and number of sats in view in the APRS comment field, along with the battery and igniter voltages.

    AltosUI — TeleMega GPS Satellite, GPS max height and Fire Igniters

    AltosUI was crashing when TeleMega reported that it had data from more than 12 satellites. While the TeleMega firmware has been fixed to never do that, AltosUI also has a fix in case you fly a TeleMega board without updated firmware.

    GPS max height is now displayed in the flight statistics. As the u-Blox GPS chips now provide accurate altitude information, we’ve added the maximum height as computed by GPS here.

    Fire Igniters now uses the letters A through D to label the extra TeleMega pyro channels instead of the numbers 0-3.

    February 15, 2014 10:45 AM

    February 14, 2014

    Altus Metrum

    bdale&#x27;s rocket blog: TeleMetrum v2.0

    Keith and I are pleased to announce the immediate availability of TeleMetrum v2.0, the return of TeleDongle, and that TeleMega is back in stock!

    We've taken our classic TeleMetrum design and updated it with all new components. Same feature set, but better in every way. TeleMetrum v2 is a dual deploy flight computer with 2 pyro channels, 105g accelerometer, 100k' barometer, uBlox Max 7Q GPS and >30mW telemetry system with APRS support.

    Read more about TeleMetrum v2.

    Our original ground station TeleDongle is also back at last, as a part of the Altus Metrum Starter Pack. Each Starter Pack includes a TeleDongle USB-connected ground station for laptops running Linux, Mac OS X or Windows, a battery compatible with any Altus Metrum flight computer, a USB cable, and an Altus Metrum cut vinyl decal.

    Read more about TeleDongle

    We're also pleased to have TeleMega back in stock! TeleMega is an advanced flight computer with 9-axis IMU, 6 pyro channels, uBlox Max 7Q GPS and >30mW telemetry system with APRS support. We designed TeleMega to be the ideal flight computer for sustainers and other complex projects

    Read more about TeleMega

    Altus Metrum products are available directly from Bdale's web store, and from these distributors:

    All Altus Metrum products are completely open hardware and open source. The hardware design details and all source code are openly available for download, and advanced users are invited to join our developer community and help to enhance and extend the system. You can learn more about Altus Metrum products at http://altusmetrum.org.

    Thank you all for your continuing support of Altus Metrum, and we hope to see you on a flight line somewhere soon!

    February 14, 2014 06:46 PM

    Video Circuits

    Bermuda Triangle Lovely Audio Visual Extravaganza featuring James Alec Hardy

    He so James gave me the heads up about this great event this Saturday for the benefit of Resonance104.4fm

    He will be presenting the first performance of his Ziggurat 00120140215 broadcast system around 20:30ish here is a little sneak preview


    and the rest of the audio visual line up looks great too

    When: Saturday 15th February 2014 8pm - 2am
    Where: Roxy Bar & Screen, 128-132 Borough High St, London SE1 1LB
    Door: £5 donation to Resonance104.4fm
    more info here 





    by Chris (noreply@blogger.com) at February 14, 2014 06:59 AM

    Carol Goss


    Carol Goss has been active in abstract video work from very early on, have a look at her excellent website for more information www.improvart.com, here are some selected still's from her site just to give an initial idea of the range of her work.



















    Photo of Carol Goss in live performance at Joseph Papp's Public Theater, NYC 1978.

















    TOPOGRAPHY
    Carol Goss - Paik-Abe Synthesizer
    Paul Bley - Electric Piano
    Bill Connors -Electric Guitar
















    S-CONSTRUCT
    Carol Goss - Computer Animation
    Don Preston - Audio Synthesizer

















    KUNDALINI
    Carol Goss / Video Feedback
    Perry Robinson / Clarinet
    Badal Roy + Nana Vasconcelos / Percussion

















    by Chris (noreply@blogger.com) at February 14, 2014 06:44 AM

    February 12, 2014

    Andrew Zonenberg, Silicon Exposed

    Process overview: UMC 180nm eNVM

    I've been reverse engineering a programmable logic device (Xilinx XC2C32A) made on UMC's 180nm eNVM process for the last few months and have been a little light on blog posts. I'm a big fan of the process writeups Chipworks does so I figured I'd try my hand at one ;)

    The target devices were packaged in a 32-pin QFN. The first part of the analysis was to sanding the entire package down to the middle of the device and polishing with diamond paste to get a quick overview of the die and packaging stack. (Shops with big budgets normally use X-ray systems for this.) There were a few scratches in the section from sanding, but since the closeups were going to be done on another die it wasn't necessary to polish them out.

    Packaged device cross section
    Packaged device cross section

    Total die thickness including BEOL was just over 300 μm. From the optical image, four layers of metal can be seen. The whitish color hinted that it was aluminum rather than copper, but there's no sense jumping to conclusions since the next die was about to hit the SEM.

    A second specimen was depackaged using sulfuric acid, sputtered in platinum to reduce charging, and sectioned using a gallium ion FIB at a slight angle to the east-west routing.

    FIB cross section of metal stack
    From this image, it is easy to get some initial impressions of the process:
    • The overglass consists of two layers of slightly different compositions, possibly an oxide-nitride stack. 
    • The process is planarized up to metal 4, but not including overglass.
    • Metal has an adhesion/barrier layer at the top and bottom and not the sides, and is wider at the bottom than the top. This rules out damascene patterning and suggests that the metal layers are dry-etched aluminum.
    • Silicide layers are visible above the polysilicon gates and at the source/drain implants.
    • Vias have a much higher atomic number than the metal layers, probably tungsten.
    • Stacked vias are allowed and used frequently.
    • Well isolation is STI.
    EDS spectra confirmed all these initial impressions to be correct.

    M1 to M3 have pretty much identical stackups except for slight thickness differences: 100nm of Ti-based adhesion/barrier layer, 400-550 nm of aluminum conductor, then another barrier layer of similar composition. M4 is slightly thicker (850 nm aluminum) and the same barrier thickness.

    The first overglass layer is the same material (silicon dioxide) as ILD; thickness ranges from slightly below the top of M4 to to 630 nm above the top. The second overglass layer has a slightly higher backscatter yield (EDIT: confirmed by EDS to be silicon nitride) and is about 945 nm thick.

    M1-3 pitch is just over 600 nm, while the smallest observed M4 pitch is 1 μm.

    EDS spectrum of wire on M4

    A closer view of M3 shows the barrier metals in more detail. The barrier is a bit over 100 nm thick normally but thins to about 45 nm underneath upward-facing vias, suggesting that the ILD etch for drilling via holes also damages the barrier material. A small amount (around 30 nm) of sagging is present over the top of downward-facing vias.

    Via sidewalls are coated with barrier metal as well, however it is significantly thinner (20 nm vs 100) than the metal layer barrier. The vias themselves are polycrystalline tungsten. Grain structure is clearly visible in the secondary electron image below.

    (Note: The structure at left of the image is the edge of the FIB trench and stray material deposited by the ion beam and is not part of the actual device. The lower via is at a slight angle to the section so it was not entirely sliced open.)
    M3 with upward/downward vias in cross section.
    EDS spectrum of M1-M2 via area
    The metal aspect ratio ranges from 3:1 on M1 to 1.5:1 on M4.

    Now for the most interesting area - the transistors themselves!

    The cross section was taken down the center of the CPLD's PLA OR array between two rows of 6T SRAM cells. Two PMOS transistors from each of two SRAM cells are visible in the closeup below.

    Contacted gate pitch is 920 nm, for total cell width (including the 1180 nm of STI trench) of 2.9 μm. Plan view imaging shows total cell dimensions to be 2.9 x 3.3 μm or 9.5 μm2. This is a bit large for the 180 nm node and probably reflects the need to leave space on M1 and M2 for routing SRAM cell output to the programmable logic array.

    SRAM cell structure and PLA AND array after metal/poly removal and Dash etch. (P-type implants are raised due to oxide growth from stain.)

    Some variability in etch depth and sidewall slope is clearly visible on M1.

    The polysilicon layer was hard to see in this view but is probably around 50 nm thick, topped by about 135 nm of cobalt silicide. (Gate oxide thickness isn't visible under SEM at the 180 nm node and I haven't yet had time to prepare a TEM sample.)

    Source/drain contacts are made with a 70 nm thick cobalt silicide layer. All vias in the entire process appear to be about the same size (300 nm diameter) however the silicide contact pads are larger (465 nm).

    Gate length is almost exactly 180 nm - measurement of the SEM image shows 175 nm +/- 12 nm.

    Active area contacts and PMOS transistors
    EDS spectrum of active-M1 contact
    Closeup of PLA AND array after Dash etch showing PMOS and NMOS channels

    Overall, the process seems fairly typical except for its use of aluminum for interconnect. It was a fun analysis and if I have time I may try to do a TEM cross section of both PMOS and NMOS transistors in the future. My main interest in the chip is netlist extraction, though, so this isn't a high priority.

    I may also do a second post on the Flash portion of the chip.

    EDIT: Decided to post a plan view SEM image of the flash array active area. This is after Dash etch; P-type areas have oxide grown over them. Poly has been stripped. The left-hand flash area is ten bits wide and stores configuration for function block 2's macrocells plus a "valid" bit. The right-hand area stores configuration for FB2's PLA (including both the AND and OR arrays, but not global routing).

    Plan view SEM of flash
    Finally, I would like to give special thanks to David Frey at the RPI cleanroom for assistance with the FIB cross section.

    by Andrew Zonenberg (noreply@blogger.com) at February 12, 2014 02:45 PM

    February 11, 2014

    Free Electrons

    Buildroot meeting and FOSDEM report, Google Summer of Code topics

    As we discussed in a recent blog post, two of our engineers participated to the FOSDEM conference early February in Brussels, Belgium. For those interested, many videos are available, such as several videos from the Lameere room, where the embedded related talks were given.

    Thomas Petazzoni also participated to the two days Buildroot Developers Meeting after the FOSDEM conference. This meeting gathered 10 contributors to the Buildroot project physically present and two additional remote participants. The event was sponsored by Google and Mind, thanks a lot to them! During those two days, the participants were able to discuss a very large number of topics that are often difficult to discuss over mailing lists or IRC, and a significant work to clean up the oldest pending patches was done. In addition to this, these meetings are also very important to allow the contributors to know each other, as it makes future online discussions and collaborations much easier and fruitful. For more details, see the complete report of the event.

    Buildroot Developers Meeting in Brussels

    Buildroot Developers Meeting in Brussels

    Also, if you’re interested in Buildroot, the project has applied to participate to the next edition of the Google Summer of Code. Two project ideas are already listed on the project wiki, feel free to contact Thomas Petazzoni if you are a student interested in these topics, or if you have other proposals to make for Buildroot.

    by Thomas Petazzoni at February 11, 2014 08:30 AM

    February 09, 2014

    Bunnie Studios

    Name that Ware February 2014

    The Ware for February 2014 is shown below.

    This month’s ware is a handsome bit of retro-computing contributed by Edouard Lafargue (ed _at_ aerodynes.org). The ware was a gift to him from his father.

    by bunnie at February 09, 2014 06:59 PM

    Winner, Name that Ware January 2014

    The Ware for January 2014 was a Chipcom ORnet fiber optic transceiver. Per guessed the ware correctly, and is thus the winner. Congrats, email me for your prize! And thanks again to Mike Fitzmorris for the contribution.

    by bunnie at February 09, 2014 06:59 PM

    January 31, 2014

    Free Electrons

    Free Electrons contributions to Linux 3.13

    Version 3.13 of the Linux kernel was released by Linus Torvalds on January, 19th 2014. The kernelnewbies.org site has an excellent page that covers the most important improvements and feature additions that this new kernel release brings.

    As usual Free Electrons contributed to this kernel: with 121 patches merged in 3.13 on a total of 12127 patches contributed, Free Electrons is ranked 17th in the list of companies contributing to the Linux kernel. We also appeared on Jonathan Corbet kernel contribution statistics at LWN.net, as a company having contributed 1% of the kernel changes, right between Renesas Electronics and Huawei Technologies.

    Amongst the contributions we made for 3.13:

    • Standby support added to the Marvell Kirkwood processors, done by Ezequiel Garcia.
    • Various fixes and improvements to the PXA3xx NAND driver, as well as to the Marvell Armada 370/XP clocks, in preparation to the introduction of NAND support for Armada 370/XP, which will arrive in 3.14. Work done by Ezequiel Garcia.
    • Added support for the Performance Monitoring Unit in the AM33xx Device Tree files, which allows to use perf and oprofile on platforms such as the BeagleBone. Work done by Alexandre Belloni.
    • Support added for the I2C controllers on certain Allwinner SOCs, as well as several other cleanups and minor improvements for these SoCs. Work done by Maxime Ripard.
    • Continued the work to get rid of IRQF_DISABLED, as well as other janitorial tasks such as removing unused Kconfig symbols. Work done by Michael Opdenacker.
    • Added support for MSI (Message Signaled Interrupts) for the Armada 370 and XP SoCs. Work done by Thomas Petazzoni.
    • Added support for the Marvell Matrix board (an Armada XP based platform) and the OpenBlocks A7 (a Kirkwood based platform manufactured by PlatHome). Work done by Thomas Petazzoni.

    In detail, the patches contributed by Free Electrons are:

    by Thomas Petazzoni at January 31, 2014 12:55 PM

    Free Electrons at FOSDEM and at the Buildroot Developers Meeting

    FOSDEMThis week-end is the first week-end of February, which on the schedule of all open-source developers is always booked for a major event of our community: the FOSDEM conference in Brussels. With several hundreds of talks over two days, this completely free event is one of the biggest event, if not the biggest of the open-source world.

    For embedded Linux developers, FOSDEM has quite a few interesting tracks and talks this year: an embedded track, a graphics track (with many embedded related talks, such as talks on Video4Linux, the status of open-source drivers for 2D and 3D graphics on ARM platforms, etc.), and several talks in other tracks relevant to embedded developers. For example, there is one talk about the Allwinner SoCs and the community behind it in one of the main track. Our engineer Maxime Ripard is the Linux kernel maintainer for this family of SoC.

    Two Free Electrons engineers will attend FOSDEM: Maxime Ripard and Thomas Petazzoni. Do not hesitate to get in touch with them if you want to discuss embedded Linux or kernel topics!

    Also, right after FOSDEM, the Buildroot community is organizing its Developers Meeting, on Monday, 3rd and Tuesday 4th February. This event is sponsored by Google (providing the meeting location) and Mind (providing the dinner), and will take place in the offices of Google in Brussels. Ten Buildroot developers will participate to the meeting in Brussels, as well as a number of others remotely. On Free Electrons side, Thomas Petazzoni will be participating to the meeting. If you are interested in participating, either physically or remotely, do not hesitate to contact Thomas to register. For more details, see the wiki page of the event.

    by Thomas Petazzoni at January 31, 2014 12:45 PM

    January 27, 2014

    Moxie Processor

    NetHack in your browser

    This is a moxie-rtems port of NetHack running on a modified version of the gdb moxie simulator compiled to javascript with emscripten.

    
                            Terminal uses canvas
                        
    
    
    
    
    

    Krister Lagerström is responsible for this marvellous hack.

    Also, I suppose this blog entry represents a distribution of some GPL’d source code from GDB, so I need to tell you about the:

    And then there’s RTEMS:

    And finally NetHack:

    by green at January 27, 2014 02:12 AM

    January 23, 2014

    Andrew Zonenberg, Silicon Exposed

    Hardware reverse engineering class

    So, it's been a while since I've posted anything and I figured I'd throw up a quick update.

    I've been super busy over the winter break working on my thesis, as well as something new: My advisor and I are running a brand-new, experimental course, CSCI 4974/6974 Hardware Reverse Engineering, at Rensselaer Polytechnic Institute (RPI) this spring!

    I gave the first lecture for the class last Tuesday and it was very well received. We have a full class - 12 undergraduates and 4 graduates as of this writing. As the TA for the class I'm responsible for (among other things) running labs and preparing samples. I've been running all over campus getting trained on various pieces of equipment, booking lab time for the class, and generally making sure this is going to be an awesome semester for all involved.

    Lecture notes are available online on the course website for anyone who wishes to follow along.

    Finally, a few peeks at my microprobing setup. I think I need new micropositioners, the backlash on these is pretty terrible. Whenever I adjust the left-right axis, the probe needle rotates by a degree or two.


    by Andrew Zonenberg (noreply@blogger.com) at January 23, 2014 06:16 PM

    Altus Metrum

    keithp&#x27;s rocket blog: Altos1.3.1

    AltOS 1.3.1 — Bug fixes and improved APRS support

    Bdale and I are pleased to announce the release of AltOS version 1.3.1.

    AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.

    This is a minor release of AltOS, including bug fixes for TeleMega, TeleMetrum v2.0 and AltosUI .

    AltOS Firmware — Antenna down fixed and APRS improved

    Firmware version 1.3 has a bug in the support for operating the flight computer with the antenna facing downwards; the accelerometer calibration data would be incorrect. Furthermore, the accelerometer self-test routine would be confused if the flight computer were moved in the first second after power on. The firmware now simply re-tries the self-test several times.

    I went out and bought a “real” APRS radio, the Yaesu FT1D to replace my venerable VX 7R. With this in hand, I changed our APRS support to use the compressed position format, which takes fewer bytes to send, offers increased resolution and includes altitude data. I took the altitude data out of the comment field and replaced that with battery and igniter voltages. This makes APRS reasonably useful in pad mode to monitor the state of the flight computer before boost.

    Anyone with a TeleMega should update to the new firmware eventually, although there aren’t any critical bug fixes here, unless you’re trying to operate the device with the antenna pointing downwards.

    AltosUI — TeleMega support and offline map loading improved.

    I added all of the new TeleMega sensor data as possible elements in the graph. This lets you see roll rates and horizontal acceleration values for the whole flight. The ‘Fire Igniter’ dialog now lists all of the TeleMega extra pyro channels so you can play with those on the ground as well.

    Our offline satellite images are downloaded from Google, but they restrict us to reading 50 images per minute. When we tried to download a 9x9 grid of images to save for later use on the flight line, Google would stop feeding us maps after the first 50. You’d have to poke the button a second time to try and fill in the missing images. We fixed this by just limiting how fast we load maps, and now we can reliably load an 11x11 grid of images.

    Of course, there are also a few minor bug fixes, so it’s probably worth updating even if the above issues don’t affect you.

    January 23, 2014 04:39 AM

    January 22, 2014

    Richard Hughes, ColorHug

    AppData status for January

    So, it’s been a couple of months since my last post about AppData progress, so about time for one more. These are the stats for Fedora 21 in January (with the stats for Fedora 20 in November in brackets):

    Applications in Fedora with long descriptions: 11% (up from 9%)
    Applications in Fedora with screenshots: 9% (up from 7%)
    Applications in GNOME with AppData: 53% (up from 50%)
    Applications in KDE with AppData: 1% (unchanged)
    Applications in XFCE with AppData: 0% (unchanged)
    

    If you want to see what your application looks like, but don’t want to run gnome-software from Fedora rawhide or jhbuild, you can check the automatically-generated status page.

    Some applications like 0ad and eog look great in the software center, but some like frogr and gbrainy just look sad. As always, full details about AppData here.

    by hughsie at January 22, 2014 11:30 AM

    January 17, 2014

    ZeptoBARS

    ST 34C02 - 2048-bit EEPROM : weekend die-shot

    STMicroelectronics 34C02 is an 2048-bit EEPROM with hardwire write-protect and I2C interface, typically used as SPD chip in DIMM memory modules.
    Die size 1542x1422 µm, 1.2µm half-pitch.


    January 17, 2014 04:10 PM

    January 16, 2014

    Video Circuits

    Christia Schubert

    Christia Schubert has some nice complex vector work here from 1984/85
    Produced using a computer system driving a Soltec/IBM flatbed plotter




    by Chris (noreply@blogger.com) at January 16, 2014 03:12 AM

    January 14, 2014

    Free Electrons

    Free Electrons New Year – 2014

    This article was published on our quarterly newsletter. A French version also exists.

    The Free Electrons team wishes you a Happy New Year for 2014, with plenty of optimism and energy!

    We are taking this opportunity to give some news about Free Electrons.

    In 2013, Free Electrons significantly increased its contribution to open-source projects, especially at the Linux kernel level.

    639 patches integrated in the Linux kernel, mainly to improve support for Marvell ARM processors and Allwinner ARM processors. For all kernel releases published in 2013, Free Electrons has been in the top 30 contributing companies. We now have a significant experience in integrating support for ARM processors in the Linux kernel, and we expect to work more in this area in 2014.

    595 patches integrated in the Buildroot embedded Linux build system, in a large number of areas, making Free Electrons the second most important contributor after Buildroot’s maintainer. This effort allows Free Electrons to keep an up-to-date expertise in cross-compilation and build systems.

    26 patches integrated in the Barebox bootloader:

    22 patches to the Yocto Freescale layer, mainly adding support for the Crystalfontz boards. In the process, a new image type was developed and significant improvements were made to the Barebox recipe.

    Several of these contributions, and many other activities, were driven by development and consulting activities in 2013, with mainly:

    • Linux kernel code development, adding and maintaining support for customer ARM processors or boards in the mainline Linux kernel. Especially on Marvell and Freescale processors.
    • Linux kernel, driver development and build system integration for an Atmel SAMA5 based medical device.
    • Development of Linux kernel drivers for radio-frequency transceivers, on an Atmel SAMA5 based home automation platform.
    • Boot time optimization audits.
    • Buildroot consulting and audit.

    We have also significantly improved and updated our training courses:

    Our training materials remain freely available under a Creative Commons license, including their source code, available from a public Git repository.

    Free Electrons continues to believe that participating to conferences is critical to keep its engineers up to date with the latest Linux developments and create connections with the developers of the Linux community which are essential to make our projects progress faster. For this purpose, we participated to a large number of conferences in 2013:

    • FOSDEM 2013, in Brussels, Belgium. Our CTO and engineer Thomas Petazzoni gave a talk about ARM kernel development
    • Buildroot Developers Meeting, Brussels, Belgium. Our engineer Thomas Petazzoni organized and participated to this 2-days meeting, sponsored by Google, to work on Buildroot developments.
    • Embedded Linux Conference 2013 and Android Builders Summit 2013, in San Francisco, United States. Our engineer Gregory Clement gave a talk about the Linux kernel clock framework. Our engineer Thomas Petazzoni gave a talk about ARM kernel development. See also our videos.
    • Linaro Connect Europe 2013, Dublin Ireland. Our engineer Thomas Petazzoni participated to numerous discussions related to support for ARM processors in the Linux kernel.
    • Linux Plumbers 2013, New Orleans, United States. Our engineer Maxime Ripard attended the conference, and participated to discussions around Android and Linux kernel development.
    • Kernel Recipes, Paris, France. Both Free Electrons CEO Michael Opdenacker and CTO Thomas Petazzoni participated to this Linux kernel conference, and Thomas gave two talks: one about ARM kernel development and one about Buildroot.
    • ARM kernel mini-summit 2013, Edinburgh, UK. Our engineers Gregory Clement, Thomas Petazzoni and Maxime Ripard participated to the invitation-only ARM kernel mini-summit. This summit is the key place to discuss and define the next directions for support for ARM processors in the Linux kernel.
    • Embedded Linux Conference Europe, Edinburgh, UK. Gregory Clement gave a talk about about the Linux kernel clock framework and Thomas Petazzoni gave a talk about the Device Tree.
    • Buildroot Developers Meeting, Edinburgh, UK. Our engineer Thomas Petazzoni organized and participated to this 2-days meeting, sponsored by Imagination Technologies, to work on Buildroot development.

    A very important development of Free Electrons in 2013 is the addition of a new engineer to our team: Alexandre Belloni joined us in March 2013. Alexandre has a very significant embedded Linux and kernel experience, see his profile.

    Now, let’s talk about our plans for 2014:

    • Hire several additional engineers. One of them has already been hired and will join us in April, bringing a significant Linux kernel development experience, including mainline contribution.
    • Our involvement in support for ARM processors in the Linux kernel will grow significantly.
    • Two new training courses will be released: one “Boot time reduction” training course, and an “OpenEmbedded and Yocto” training course.
    • For the first time, we will organize public training sessions (open to individual registration) outside of France.
      • Our next Android system development session in English will happen on April 14-17 in Southampton, UK
      • We are also working on embedded Linux and Kernel and driver development sessions in the USA, to be announced in the next weeks.
      • We also plan to organize embedded Linux and Kernel and driver development sessions in Germany, with German speaking trainers.
      • By the way, our Android system development courses in French will continue to run in Toulouse, but there will also be a session on April 1-4 in Lyon.

      See also the full list of public sessions.

    As in 2013, we will participate to several key conferences. We have already planned our participation to: Linux Conf Australia (January 2014), FOSDEM (February 2014), Embedded Linux Conference (April 2014) and the Embedded Linux Conference Europe (October 2014).

    You can follow Free Electrons news by reading our blog and by following our quick news on Twitter. We now have a Google+ page too.

    Again, Happy New Year!

    The Free Electrons team.

    by Michael Opdenacker at January 14, 2014 02:57 PM

    January 13, 2014

    Richard Hughes, ColorHug

    For artists, photographers and animators it’s often essential to be working with an accurately color calibrated screen. It’s also important to be able to print accurate colors being sure the hard copy matches what is shown on the display.

    The OpenHardware ColorHug Colorimeter device provided an inexpensive way to calibrate some types of screen, and is now being used by over 2000 people. Due to limitations because of the low cost hardware, it does not work well on high-gamut or LED screen technologies which are now becoming more common.

    ColorHug Spectro is a new device designed as an upgrade to the original ColorHug. This new device features a mini-spectroraph with UV switched illuminants. This means it can also take spot measurements of paper or ink which allows us to profile printers and ensure we have a complete story for color management on Linux.

    I’m asking anyone perhaps interested in buying a device in about 9 months time to visit this page which details all the specifications so far. If you want to pre-order, just send us an email and we’ll add you to the list. If there isn’t at least 100 people interested, the project just isn’t economically viable for us as there are significant NRE costs for all the optics.

    Please spread the word to anyone that might be interested. I’ve submitted a talk to LGM to talk about this too, which hopefully will be accepted.

    by hughsie at January 13, 2014 04:56 PM

    January 12, 2014

    ZeptoBARS

    Microchip 24LCS52 : weekend die-shot

    Microchip 24LCS52 is an 2048-bit EEPROM with I2C interface.
    Die size 1880x1880 µm, 2µm half-pitch.



    Closer look at charge-pump:

    January 12, 2014 02:21 PM

    January 11, 2014

    Moxie Processor

    The Moxie Game Console?

    Ok, not quite, but Krister Lagerström recently did something cool..

    nethack

    That’s NetHack ported to RTEMS running on the moxie based Marin SoC.

    It runs on QEMU, via “qemu-system-moxie --nographic --machine marin --kernel nethack.elf“, or on FPGA hardware. I tested with a Nexys 3 Spartan-6 board by simply converting it to an screcord file and sending it via the serial port to the hardware’s boot loader.

    Krister implemented the Marin BSP for RTEMS, then ported ncurses and nethack to moxie-rtems. Like many programs with a UNIX heritage, NetHack reads data files from a local file system. RTEMS solves that by providing a simple in-memory filesystem you can initialize with a tar file and link to your ELF executable.

    For my part, I had to fix a couple of QEMU bugs and point the moxie-cores tools build scripts to staging git repos until the bugs are fixed upstream. As usual, everything should be here: http://github.com/atgreen/moxie-cores.

    Thank you, Krister, and I’m looking forward to the other cool things you have planned!

    by green at January 11, 2014 02:06 PM

    January 09, 2014

    Bunnie Studios

    Make: Article on Novena

    Recently, the Make: blog ran an article on our laptop project, Novena. You can now follow @novenakosagi for updates on the project. I’d also like to reiterate here that the photos shown in the article are just an early prototype, and the final forms of the machine are going to be different — quite different — from what’s shown.

    Below is a copy of the article text for your convenient reading. And, as a reminder, specs and source files can be downloaded at our wiki.

    Building an Open Source Laptop

    About a year and a half ago, I engaged on an admittedly quixotic project to build my own laptop. By I, I mean we, namely Sean “xobs” Cross and me, bunnie. Building your own laptop makes about as much sense as retrofitting a Honda Civic with a 1000hp motor, but the lack of practicality never stopped the latter activity, nor ours.

    My primary goal in building a laptop was to build something I would use every day. I had previously spent several years at chumby building hardware platforms that I’m ashamed to admit I rarely used. My parents and siblings loved those little boxes, but they weren’t powerful enough for a geek like me. I try to allocate my discretionary funds towards things based on how often I use them. Hence, I have a nice bed, as I spend a third of my life in it. The other two thirds of my life is spent tapping at a laptop (I refuse to downgrade to a phone or tablet as my primary platform), and so when picking a thing to build that I can use every day, a laptop is a good candidate.

    SONY DSC I’m always behind a keyboard!

    The project was also motivated by my desire to learn all things hardware. Before this project, I had never designed with Gigabit Ethernet (RGMII), SATA, PCI-express, DDR3, gas gauges, eDP, or even a power converter capable of handling 35 watts – my typical power envelope is under 10 watts, so I was always able to get away with converters that had integrated switches. Building my own laptop would be a great way for me to stretch my legs a bit without the cost and schedule constraints normally associated with commercial projects.

    The final bit of motivation is my passion for Open hardware. I’m a big fan of opening up the blueprints for the hardware you run – if you can’t Hack it, you don’t Own it.

    Back when I started the project, it was me and a few hard core Open ecosystem enthusiasts pushing this point, but Edward Snowden changed the world with revelations that the NSA has in fact taken advantage of the black-box nature of the closed hardware ecosystem to implement spying measures (“good news, we weren’t crazy paranoids after all”).

    Our Novena Project is of course still vulnerable to techniques such as silicon poisoning, but at least it pushes openness and disclosure down a layer, which is tangible progress in the right direction.

    While these heady principles are great for motivating the journey, actual execution needs a set of focused requirements. And so, the above principles boiled down to the following requirements for the design:

    • All the components should have a reasonably complete set of NDA-free documentation. This single requirement alone culled many choices. For example, Freescale is the only SoC vendor in this performance class where you can simply go to their website, click a link, and download a mostly complete 6,000-page programming manual. It’s a ballsy move on their part and I commend them for the effort.
    • Low cost is not an objective. I’m not looking to build a crippled platform based on some entry-level single-core SoC just so I can compete price-wise with the likes of Broadcom’s non-profit Raspberry Pi platform.
    • On the other hand, I can’t spec in unicorn hair, although I come close to that by making the outer case from genuine leather (I love that my laptop smells of leather when it runs). All the chips are ideally available off the shelf from distributors like Digi-Key and have at least a five year production lifetime.
    • Batteries are based off of cheap and commonly available packs used in RC hobby circles, enabling users to make the choice between battery pack size, runtime, and mass. This makes answering the question of “what’s the battery life” a bit hard to answer – it’s really up to you – although one planned scenario is the trans-Siberian railroad trek, which is a week-long trip with no power outlets.
    • The display should also be user-configurable. The US supply chain is weak when it comes to raw high-end LCD panels, and also to address the aforementioned trans-Siberian scenario, we’d need the ability to drive a low-power display like a Pixel Qi, but not make it a permanent choice. So, I designed the main board to work with a cheap LCD adapter board for maximum flexibility.
    • No binary blobs should be required to boot and operate the system for the scenarios I care about. This one is a bit tricky, as it heavily limits the wifi card selection, I don’t use the GPU, and I rely on software-only decoders for video. But overall, the bet paid off; the laptop is still very usable in a binary-blob free state. We prepared and gave a talk recently at 30C3 using only the laptops.
    • The physical design should be accessible – no need to remove a dozen screws just to pull off the keyboard. This design requires removing just two screws.
    • The design doesn’t have to be particularly thin or light; I’d be happy if it was on par with the 3cm-thick Thinkpads or Inspirons I would use back in the mid 2000′s.
    • The machine must be useful as a hardware hacking platform. This drives the rather unique inclusion of an FPGA into the mainboard.
    • The machine must be useful as a security hacking platform. This drives the other unusual inclusion of two Ethernet interfaces, a USB OTG port, and the addition of 256 MiB DDR3 RAM and a high-speed expansion connector off of the FPGA.
    • The machine must be able to build its own firmware from source. This drives certain minimum performance specs and mandates the inclusion of a SATA interface for running off of an SSD.

    After over a year and a half of hard work, I’m happy to say our machines are in a usable form. The motherboards are very reliable, the display is a 13” 2560×1700 (239ppi) LED-backlit panel, and the cases have an endoskeleton made of 5052 and 7075 aluminum alloys, an exterior wrapping of genuine leather, an interior laminate of paper (I also love books and papercraft), and cosmetic panels 3D printed on a Form 1. The design is no Thinkpad Carbon X1, but they’ve held together through a couple of rough international trips, and we use our machines almost every day.

    Laptop parked in front of the Form1 3D printer used to make its body panels.

    I was surprised to find the laptop was well-received by hackers, given its homebrew appearance, relatively meager specs and high price. The positive response has encouraged us to plan a crowd funding campaign around a substantially simplified (think “all in one PC” with a battery) case design. We think it may be reasonable to kick off the campaign shortly after Chinese New Year, maybe late February or March. Follow @novenakosagi for updates on our progress!

    The first two prototypes are wrapped in red sheepskin leather, and green pig suede leather.

    Detail view of the business half of the laptop.

    by bunnie at January 09, 2014 03:23 AM

    January 08, 2014

    Video Circuits

    Early Lighting Effects at The BBC

    Via youtuber Marc Campbell

    This is a video of some beautiful lighing effects work at the BBC 

    more on the history of lighting effects coming very soon

    by Chris (noreply@blogger.com) at January 08, 2014 09:29 AM

    Mars an Optic Aspic

    From youtuber electromedia
     "Bill Etra's real-time live performance from The Kitchen in 1968 was recorded on Color 16mm film by Woody Vasulka. Woody had that film transferred to DV in 2003, and sent one to Bill. Eventually, Bill gave me a copy of the DV with the hope that I could restore MARS to something similar to its original incarnation. Mars an Optic Aspic was originally performed on 9 B&W monitors, but the 16mm film added some unexpected and welcome color effects that lend themselves to the composition. The choice was made to leave them in. So, this is my restoration (and color correction), with no change to the original sound, and for the first time since the original performance we can see the work in a 9-way split."

    by Chris (noreply@blogger.com) at January 08, 2014 09:19 AM

    Mandalamat

    Here is the very cool Mandalamat an analogue computer specifically built by Christian Günther to create interesting patterns either using an XY plotter or an Oscilloscope, I have had an XY plotter for a while and made a few drawings using modular synthesizer and function generators but nothing this beautiful! 




















    by Chris (noreply@blogger.com) at January 08, 2014 03:43 AM

    January 07, 2014

    Bunnie Studios

    Name that Ware January 2014

    The ware for January is shown below.

    Thanks to my buddy Mike Fitzmorris for contributing yet another wonderful ware to this competition.

    by bunnie at January 07, 2014 08:13 AM

    Winner, Name that Ware December 2013

    The Ware for last December 2013 is the beloved 555 timer, specifically the TLC555 by TI, fabricated in their “LinCMOS” process. I was very excited when T. Holman allowed me to post this as a ware, partially because I love die shots, and partially because the 555 is such a noteworthy chip and up until now I had never seen the inside of one.

    The huge transistor on the top left is the discharge N-FET, and the distinctive, round FETs are I believe what makes LinCMOS special. These are tailor-designed transistors for good matching across process conditions, and they form the front ends of the two differential comparators that are the backbone of the threshold/trigger circuit inside the 555.

    Picking a winner this time was tough — many close guesses. I’m going to name “eric” the winner, as he not only properly identified the chip, but also gave extensive analysis in his answer as well. DavidG had a correct guess very early on, but no explanation. Jonathan had the right answer, but the divider underneath the big transistor wasn’t done with resistors, it’s done with FETs, and steveM2 also was very, very close but called it a TLC551Y. So congrats to eric, email me to claim your prize.

    by bunnie at January 07, 2014 08:12 AM

    December 31, 2013

    Free Electrons

    New training materials: boot time reduction workshop

    We are happy to release new training materials that we have developed in 2013 with funding from Atmel Corporation.

    The materials correspond to a 1-day embedded Linux boot time reduction workshop. In addition to boot time reduction theory, consolidating some of our experience from our embedded Linux boot time reduction projects, the workshop allows participants to practice with the most common techniques. This is done on SAMA5D3x Evaluation Kits from Atmel.

    The system to optimize is a video demo from Atmel. We reduce the time to start a GStreamer based video player. During the practical labs, you will practice with techniques to:

    • Measure the various steps of the boot process
    • Analyze time spent starting system services, using bootchartd
    • Simplify your init scripts
    • Trace application startup with strace
    • Find kernel functions taking the most time during the boot process
    • Reduce kernel size and boot time
    • Replace U-Boot by the Barebox bootloader, and save a lot of time
      thanks to the activation of the data cache.

    Creative commonsAs usual, our training materials are available under the terms of the Creative Commons Attribution-ShareAlike 3.0 license. This essentially means that you are free to download, distribute and even modify them, provided you mention us as the original authors and that you share these documents under the same conditions.

    Special thanks to Atmel for allowing us to share these new materials under this license!

    Here are the documents at last:

    The first public session of this workshop will be announced in the next weeks.
    Don’t hesitate to contact us if you are interested in organizing a session on your site.

    by Michael Opdenacker at December 31, 2013 08:33 PM

    December 29, 2013

    Michele's GNSS blog

    Wrapping up 2013 GNSS facts

    Well, it has indeed been quite a long time since I wrote here the last time.
    My personal situation has changed in such a way that it is hard to find the time to share my views and to comment your feedback on current advances in the GNSS R&D domain.
    However I feel like dropping here an "end of the year" summary which serves more as a memorandum to me that anything else.
    I might be challenging this article
    http://gpsworld.com/2013-a-positive-year-for-location-industry/
    but 2013 has not been a very good year for GNSS.
    At least someone generally agrees:
    http://qz.com/161443/2013-was-a-lost-year-for-tech/#!

    Mass market receivers for low cost RTK
    Lately there was one more item on the acquisitions list:
    The above shows how aggressive this market is and leaves just a few players on the field.
    Some of them, such as Intel, Qualcomm and Broadcom don't really sell to private and just target device manufacturers. Others have shelves as well and those are the most interesting for people thinkering with GNSS of course.
    In no particular order:

    Mediatek
    Early in 2013 Mediatek announced MTK3333. This powerful true dual constellation receiver can be found in many modules (for example by Locosys and GlobalTop. Although impressive, it does not seem to offer pseudoranges or carrier phase at the moment.

    uBlox
    IMHO, uBlox has a confusing roadmap with 6th generation modules overlapping with 7th generation and now apparently 8th generation. I design with uBlox modules and it is a little awkward to tell my customers that modules already advertised for are due for release in 6 months. The Company has done an aggressive marketing of a "PPP" technology that has nothing to do with Precise Point Positioning, but rather with carrier phase smoothing. uBlox still manages to sell navigation modules which are not true dual constellation but either one or the other constellation. Their "P" and "T" modules have well established pseudorange, carrier phase and more measurements for GPS.

    ST-Microelectronics
    STM has released in 2013 the TeseoII true dual constellation IC. The STA8088FG is 7x7 mm and is very capable. Pseudoranges can be obtained with some firmware, but never carrier phase. Carrier phase is rumored to be available in Teseo3, which is to be released next year. STM is more open to Galileo than any other Company, but it is weird to find their GNSS products under "Automotive Infotainment and Telematics" category.. not that STM website is an easy one to navigate anyway.

    NVS
    NVS continued to innovate in 2013 by releasing new FW for their NV08C-CSM and -MCM modules. However, after the press release of compatibility with the popular precision navigation software RTKLIB, they went quiet. By the way, I wrote the support driver for their receiver into RTKLIB but never received a mention.. you are welcome. Next year NVS will release a new hardware revision of their modules, but nothing is told about changes to expect against the current. I have high expectations :)

    Geostar Navigation
    This Company was pretty new to me and came as a surprise in 2013. It offers a true dual GPS+Glonass receiver module. In my opinion has still to improve in terms of reliability but the preconditions are all good (website is updated often so at least the Company seems well up and running). Rumors want Geostar-Navigation to release a pseudorange and carrier phase capable firmware (for GPS at least) very soon.

    Furuno
    Furuno came back in 2013 with a true dual constellation chipset called eRideOPUS 7 and module called GN-87F. The Company has expressed interest in releasing Galileo compliant firmware soon and the chip seems to be able to output pseudoranges, but not carrier phase.

    CSR
    CSR has finally delivered a new standalone receiver IC, the SiRFstarV 5e. I bought the Telit Jupiter SE868 V2 (quite a mouthful) evaluation kit from Rutronik. I still did not have a chance of testing it out in real environment but it does track simultaneously GPS, SBAS and Glonass. The chip seems to be very swift and surely has best in class power consumption, but SiRF already departed from raw measurements path with their 3rd generation so I would not expect them to be back on that track now.

    Skytraq
    Last but not least, Skytraq was among the first ones to release a true dual constellation chip and module with the intention of supporting raw measurements. I bought some S4554GNS-LP back in 2011 already. Since then the Company has made a great progress in integration and quality of modules. The latest generation, the Venus8, has GPS 50Hz measurements, or GPS+Glonass at 20Hz. As all new modules comply with the uBlox NEO format, I already had a chance of integrating some S1216F8, S1216F8-GL and S1216F8-BD. Whilst not tested in the field but "only" with an Agilent GNSS simulator, these modules represent for me the greatest promise for 2014.
    All GNSS enthusiastics should check out the NavSpark:
    http://igg.me/p/603168/x/5902022
    Although I am not a crowdfunding enthusiastic (see later as well) the news is that it is possible to get at least an evaluation kit (with libraries) for this powerful baseband processor for USD 199. There is a lot of room to play for sure, and 50Hz GPS raw measurements for less than USD 20 a module will buzz for sure.

      GNSS Software Defined Radios

    Looking out for interesting devices to use for GNSS SDR, this year has been a promising one. But not all promises are kept, as I will explain below.

    Memoto Camera

    One year ago already, following the hype of the Cell-guide snapshot GPS technology, I decided for the first time to back a kickstarters project: the Memoto camera. This "lifelogging device" has an Aclys chip inside which will only turn on for a few milliseconds every so often and record a GPS signal snapshot, in order to achieve the lowest possible battery life. After more than 1 year not only I did not received the camera but my contact has been lost in the transition from Memoto to Narrative. Being my support request unanswered, it is hard to know wheter I have lost my pledge or not... fingers crossed.

    Jawbreaker -> HackRF One

    Michael Ossmann, creator of the Ubertooth, started developing other interesting devices for low cost SDR. I missed by very little the Jawbreaker giveaway back in June, so I decided to support its Kickstarters campaign for HackRF One, which is essen